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.

Release notes

Changes highlighted in red are not backwards compatible

Changes in version 21.06

Endpoints

• GET /invoices now returns correct default values for cashDiscount fields.
• Bug affecting invoice row ordering in GET /invoices/{id} has been fixed. The invoice rows are now returned in the same order they have been given.
• GET /products does now show correct active values for returned products for all API versions.
• Bug with GET /products TRAVEL product date filtering has been fixed for all API versions. The endpoint returns products which have been valid at any point between given startDate and endDate.

Changes in version 21.05

Endpoints

• GET /invoices results can now be filtered using invoiceChannel. More than one invoice channel can be given in a comma separated list.
• Factoring information is now correctly returned for sales orders with GET /invoices/{id}.
• Counterparty information is now correctly saved and returned when creating or modifying purchase orders with POST /invoices and PUT /invoices/{id}.

Other

• Multiple rare error cases with the API now return a more detailed error description instead of just a generic 500 error.

Changes in version 21.04

The legacy authentication method has been removed from production.

Endpoints

• We are introducing new GET /company/invoicecirculation/settings endpoint, which returns the company specific invoice circulation settings including default verifiers and acceptors.
• We are introducing new GET /company/invoicecirculation/verifierlists endpoint, which returns basic data from all the invoice verifier lists configured in the company environment.
• We are introducing new GET /company/invoicecirculation/verifierlists/{id} endpoint, which returns verifiers and acceptors connected to a specific verifier list.

• POST /invoices and PUT /invoices/{id} now return correct error when trying to create or update an invoice with cash discounts in an environment which does not allow using cash discounts.

• We are changing the pagination in GET /products endpoint to be in line with other endpoints supporting pagination. With this change the results are now returned in results object instead of products object, the maximum number of returned products is now controlled with size query parameter instead of limit query parameter, and meta object containing pagination related information is now returned with the results. We have also added orderById query parameter to control the order of the returned items.

Changes in version 21.03

The legacy authentication method has been removed from the API public test server.

Endpoints

• Missing currency codes, e.g. CNH, have been added to GET /bankaccounts and other API endpoints returning currency code information.
• GET /bankstatements results can now be filtered by bank account number using accountNumber query parameter. This filter uses exact matching.
• POST /invoices and PUT ​/invoices​/{invoiceId} endpoints will now replace all line breaks (\n or \r) with spaces in address fields like counterPartyAddress, billingAddress and deliveryAddress. This prevents invoices being caught in an error because of forbidden characters.
• GET /products results can now be filtered by product code using code query parameter. This filter uses substring matching.

Other

• Issues some customers have faced on the public API test server with endpoints requiring two-factor authentication have been fixed.

Changes in version 21.02

All refresh tokens more than 6 months old expire with this release. This means that if your integration is relying on login performed more than six months ago relogin is required to continue accessing the API. All refresh tokens issued since August 2020 have inbuilt 6 month expiration period. Any integrations relying on refresh tokens for persistent access should switch over to M2M authentication with Client Credentials.

We have adjusted our API release cycle. These changes do not require actions from API users. From here on out the supported versions will be released a month after the same changes have been introduced in latest and numbered versions. This means that the version 21.02 released now will be available on the numbered /v2102 path, but will be updated to /supported path in the next version release in March.

Endpoints

• PATCH /businesspartners/{id} no longer requires einvoiceAddress or einvoiceOperator if there are no changes to these fields.

• You are now able to mark SALES_ORDERS as offers using the isOffer field with POST /invoices and PUT /invoices/{id} endpoints.
• You can now send purchase invoices to circulation using PUT /invoices/{id}/sendToCirculation endpoint.

• You are now able to request automatic reconciliation for journal receipts using createReconciliation=true query parameter with POST /ledgerreceipts and PUT /ledgerreceipts/{id}. This functionality matches the functionality in the UI by creating/modifying the reconciliation entry row in the ledger receipt in order to make the ledger sum to zero. This row can overwrite any already existing reconciliation entry row.

• It is now possible to choose charging fees for all foreign payments with all currencies when using POST /payments and POST ​/payments​/directbanktransfers endpoints. Information about the charging fee is stored in the serviceCharge field, and is also returned by GET /payments/{paymentId} from the value of serviceCharge.
• Trying to set a payment due date with POST /payments or POST /payments/directbanktransfers to a Danish bank holiday when using Arbejdernes Landsbank (BIC: ALBADKKK), will result in a 400 Bad Request response with message DATE_MUST_BE_WORKING_DAY. This is because AL bank doesn't accept payments on bank holidays.

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

• 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.

Older release notes

Older release notes can be found from their own page.

Old release notes