Release Notes

Version releases

We are constantly adding new features to Procountor API. This page has the planned changes in future releases as well as release notes for the current ones. For anyone interested, we recommend subscribing to our mailing list to get notifications about API changes as soon as they become available.

Subscribe to our mailing list

Currently available API versions

You can find the version update schedule from Procountor news and announcements site.

Planned changes

The following features are on the backlog of our development team but not necessarily with a confirmed schedule. They are presented in no specific order.

• Automatic reconciliation with ledger receipts
• New filtering options

All non-JWT refresh tokens expire by February 2021. Any integrations relying on old refresh tokens for persistent access should switch over to M2M authentication with Client Credentials. All refresh tokens issued since August 2020 are in JWT format and do have a 6 month built-in expiration period.

The legacy authentication method is considered deprecated and will be removed from production in April 2021.

We're making some changes to our API release cycle. These changes do not require actions from API users. Starting from the next supported version, 21.02, we will release supported versions on /supported path one month after the matching latest version. This means that any changes introduced to supported versions will be available one month earlier in the latest version and using version specific paths. This also means that the current supported version, 20.11, will continue to be available on /supported path until March 2021, when it will be replaced by version 21.02.

Release notes

Changes highlighted in red are not backwards compatible

Changes in version 21.01

Endpoints

• A withdrawal/deposit sum calculation issue with GET /bankstatements has been fixed.

• POST /invoices and PUT /invoices/{id} now allow you to specify the approvers and verifiers for a purchase and travel invoices. Approvers and verifiers must have the correct user rights to be able to approve or verify the invoices.
  If approvers and verifiers are not given, the defaults for the environment or business partner are used. If you want the invoice not to have any approvers or verifiers then you need to supply an empty object {} as invoiceApprovalInfo when making the POST or PUT request.

Changes in version 20.12

Endpoints

• PUT /bankstatements/{id}/events/{eventId}/metadata - A new endpoint for adding bank statement metadata. The metadata contains accounting data including ledger account, sum, and VAT percentage and status.
  The same metadata model is also used with reference payments in PUT /referencepayments/{id}/metadata endpoint. This means that the two new optional fields, ledgerAccount and vatStatus, are usable with reference payment metadata as well. Reference payments only allow sales type vatStatus.
  The metadata is returned by GET /bankstatements and GET /referencepayments endpoints.
  Note that reflecting the metadata to ledger receipts requires using the "Update accounting" functionality available in the bank statement and reference payment UIs.
• DELETE /bankstatements/{id}/events/{eventId}/metadata - A new endpoint for removing bank statement metadata.

• GET /businesspartners/{ids}, GET /invoices/{ids}, and GET /ledgerreceipts/{ids} now allow fetching up to 200 resources at a time by specifying a comma separated list of IDs in the request URL.
  When multiple resources are requested the result will contain a list of resources, regardless of how many resources are actually being returned. This list does not contain duplicates. The items in the result list are not guaranteed to be in the same order than in the request. When only a single ID is specified the return model is the same than in previous versions.
  Only resources with valid IDs are returned. If all given IDs are invalid 404 response is returned. As long as the list of IDs contains at least one valid ID the request won't return an error.

• POST /invoices and PUT /invoices/{id} endpoints now allow creating and modifying sales and purchase orders.
• PUT /invoices/{id} now properly updates the accompanying accounting ledger when the invoice contents are modified. Note that modifying the invoice might cause the accounting ledger to be recreated. In this cases a new ledgerReceiptId is returned with the invoice.

• GET /ledgerreceipts - It is now possible to filter the results using the status field.
• PUT /ledgerreceipts/{id}/approve - A new endpoint for approving journal receipts. A journal receipt can be approved if its status is UNFINSHED and the fiscal year it's in has not been closed.

• The following deprecated id fields have been removed.

  Model / Schema	New field	Removed field
  BasicPaymentTransactionData	id	paymentId
  BusinessPartnerBasicInfo	id	registerId
  FactoringContract	id	contractId
  LedgerReceipt	id	receiptId
  LedgerReceiptBasicInfo	id	receiptId
  PaymentEvent	id	paymentEventId
  PaymentRowInfo	id	paymentId
  PersonalDetails	partnerId	personId
  Transaction	id	transactionId
  User	id partnerId	userId personRegisterId

Changes in version 20.11 (supported)

• PATCH /attachments/{id} - A new endpoint, which allows renaming the attachment file. The attachment file extension can not be changed.

• GET /invoices can now be used to search sales and purchase orders as well as invoices.
• GET /invoices/{id}/transactions - A new endpoint for fetching the invoice transaction information for a specified invoice.
• POST /invoices and PUT /invoices/{id} now allow invoices to have empty billing or delivery address. To create an invoice without billing or delivery address an empty object {} needs to be supplied for the intended address. If billing or delivery address is left out of the request body, or given as null, then the existing behavior of copying the counterparty address for billing or delivery address still holds.

Changes in version 20.10

Endpoints

• GET /bankstatements endpoint now supports paging. The paging mechanics are described here. With default settings this endpoint no longer returns more than 50 bank statements at a time.

• GET /businesspartners/{id} endpoint is now returning the intended values for additionalInfo.invoiceLedger field. These values are INVOICE_LEDGER and CLEARING.
• Fields name, type and version are no longer mandatory in PATCH /businesspartners/{id} request body. The version field is still required, but can be given either as a query parameter or in the request body.
• Validations in PATCH /businesspartners/{id} have been updated to match validations in other businesspartners endpoints.

• EDI identifier field ediId has been added to the einvoiceAddress structure used in GET /invoices/{id}, POST /invoices and PUT /invoices/{id} endpoints. This optional field is used with Finnish environments.

• GET /users/otp - This endpoint has been removed. The OTP functionality offered by this endpoint is no longer used in the rest of the API. All two-factor authentication in the API is now handled using the Finago Key app.

Changes in version 20.09

We have added OAuth 2.0 Client Credentials flow to our API authentication. This authentication method is especially suitable for machine-to-machine integrations where the user is not actively involved during the API transactions. You can read more about this authentication method from the M2M authentication page. The Client Credentials flow is usable with all API versions.

Changes in version 20.08 (supported)

The format of Procountor API access tokens and refresh tokens has been changed to JWT. This change affects all API versions.

All new access and refresh tokens will be issued in JWT format. The old format refresh tokens will continue to function normally until their specific expiration dates.

The size of the tokens is up to 512 bytes for access tokens and up to 1024 bytes for refresh tokens.

The JWT tokens encode additional information, including user, audience, and expiration date. Detailed information of the tokens' contents is available on the API authentication page.

Changes in version 20.06

Endpoints

• PUT /businesspartners/{id} - Renewed endpoint for updating business partners. The old functionality is available using PATCH /businesspartners/{id}.

• The referenceCode field has been renamed to bankReferenceCode in GET /invoices/{id}, POST /invoices and PUT /invoices/{id} endpoints.
• The generatedReferenceType field has been renamed to bankReferenceCodeType in GET /invoices/{id}, POST /invoices and PUT /invoices/{id} endpoints. If present, the value in this optional field is used to validate the value given in the bankReferenceCode field.

Changes in version 20.05

Endpoints

• PUT /businesspartners/{id} endpoint has been changed to PATCH /businesspartners/{id}. The functionality remains the same.

• The response models for GET /invoices/{id} and POST /invoices now show the same information. Missing fields were added to both models and the numeric precision in the existing fields was adjusted to match.
• Address validation rules in POST /invoices and PUT /invoices/{id} now match the rules in the UI

• POST /payments now correctly handles payment methods not allowed in the UI.

• GET /users/rights - A new endpoint for getting access rights for the currently logged in user

Other

• We have changed the way unset reference ids are returned by all API endpoints. In case the returned JSON object contains reference id field with no value the field will be returned as null. This changes the behaviour in some of the endpoints where 0 or "" value was returned before.

• The following id fields can now be found with new names. The old fields have been marked as deprecated and will be removed in the future.

  Model / Schema	New field	Old field
  BasicPaymentTransactionData	id	paymentId
  BusinessPartnerBasicInfo	id	registerId
  FactoringContract	id	contractId
  LedgerReceipt	id	receiptId
  LedgerReceiptBasicInfo	id	receiptId
  PaymentEvent	id	paymentEventId
  PaymentRowInfo	id	paymentId
  PersonalDetails	partnerId	personId
  Transaction	id	transactionId
  User	id partnerId	userId personRegisterId

• Number of previously generalized error conditions now return more specific error codes and messages.
• Errors caused by failing validation rules have been clarified.

Changes in version 20.04 (supported)

Endpoints

• GET /businesspartners/{id}/defaults/products - A new endpoint for getting the default products for a given business partner.
• GET /businesspartners/{id}/defaults/accounts - A new endpoint for getting the default accounts for a given business partner.

• POST /businesspartners endpoint has been extended to support all fields except id, attachments and version.
• E-Invoice addresses given to business partners using POST /businesspartners or PUT /businesspartners/{id} endpoint are now validated against used environment and country.

Changes in version 20.03

Endpoints

• PUT /invoices - A new endpoint for modifying existing invoices. The invoice type, status or attachments cannot be modified using this endpoint.
• PUT /invoices/{invoiceId}/notes - A new endpoint for modifying the internal notes of an invoice.

• PUT /referencepayments/metadata endpoint has been renamed to PUT /referencepayments/{referencePaymentId}/metadata.
  The targetResourceId parameter has been removed from the request body and reintroduced as the referencePaymentId path parameter. The request body now consists only from a list of AllocationMetadataRows.
• DELETE /referencepayments/metadata/{referencePaymentId} endpoint has been renamed to DELETE /referencepayments/{referencePaymentId}/metadata.

• PUT /invoices/pay endpoint has been removed. Note that this is different from POST /payments and PUT /invoices/{invoiceId}/payments/markpaid endpoints, which provide means to pay invoices or mark invoices as paid.

• POST /payments - A new field has been added bankReferenceCodeType. If present, the information in this optional field is used to validate the value given in the bankReferenceCode field.
• POST /payments/directbanktransfers - A new field has been added to the endpoint: bankReferenceCodeType. If present, the information in this optional field is used to validate the value given in the bankReferenceCode field.
  This field replaces the fikGikCode field. Implementations relying on fikGikCode must switch to this field, and its corresponding values: GIK01, GIK04, GIK15, FIK71, FIK73, FIK75.
• POST /payments/directsalarypayments - A new field has been added: bankReferenceCodeType. If present, the information in this optional field is used to validate the value given in the bankReferenceCode field.

• POST /payments - DENMARK_EXPRESS_PAYMENT is no longer a supported paymentMethod with this endpoint.
• POST /payments/directbanktransfers - DENMARK_EXPRESS_PAYMENT is no longer a supported paymentMethod with this endpoint.

• Invoice row ordering given to POST /invoices endpoint is now preserved.
• Invoice rows returned by GET /invoices/{invoiceId} now follow the ordering given using the POST /invoices endpoint or in the UI.
• GET ​/invoices​/{invoiceId}/paymentevents now returns description for the payment event.
• PUT /invoices/{invoiceId}/payments/markpaid - It is now possible to mark credit invoices as paid (payments with negative amounts) using this enpoint.

Other

• Marking sales invoices paid using PUT /invoices/<invoiceId>/paymentevents/markpaid no longer requires full rights for "Mark paid elsewhere". Viewing rights suffice just like in the UI.
• API error messages have been clarified.

Changes in version 20.02

Endpoints

• GET /invoices/{invoiceId}/paymentevents/{id} - A new endpoint for getting single payment events.

• You can now use originalInvoiceNumber to filter results returned by GET /invoices.
• Invoice rows returned by GET /invoices/{invoiceId} now have an unique id.
• Field names in GET /businesspartners have been changed to match field names in GET /businesspartners/{id} as follows:
• code → invoicingInfo/identifier
• codeType → invoicingInfo/identifierType
• customerNo → invoicingInfo/customerNumber
• active → registryInfo/active

Other

• Performance issues in GET /bankstatemets have been addressed.
• Pagination related bug in GET endpoints' metadata has been fixed.
• Electronic invoice address validation bug affecting Swedish environments has been fixed.

Older release notes

Older release notes can be found from their own page.

Old release notes