Old Release Notes

Information about past API releases

Old Release Notes

This page contains release notes for API versions older than 21.05.
Recent release notes can be found from the release notes page.

Current release notes

Changes in version 22.05

Endpoints

  • New optional field invoiceOperatorInfo that contains operator and receivingAddress information have been added to InvoiceRow used in the GET /invoices/{invoiceId} endpoint for PURCHASE_INVOICE type.
  • We are introducing new endpoint GET /company/deliveryterms to view list of delivery terms allowed in invoice types PURCHASE_INVOICE, PURCHASE_ORDER, SALES_INVOICE and SALES_ORDER.
  • New optional field deliveryTermsInfo that contains name of the delivery term and municipality have been added to InvoiceRow used in the GET /invoices/{invoiceId}, POST /invoices and PUT /invoices/{invoiceId} endpoints.

Other

  • API reference page updates:
    • The following resources names have changed
      • from Report to Reports
      • from User to Users
    • At the top of the page (just before the Servers link), OpenAPI JSON links have been added to all supported API versions

Changes in version 22.04

Endpoints

  • We are introducing new endpoint PUT /invoice/{invoiceId}/reject to reject payment of the specified invoice. Supported invoice types are PURCHASE_INVOICE, TRAVEL_INVOICE and BILL_OF_CHARGES. Invoice with rejected payment transits to PAYMENT_DENIED status.
  • New optional fields startDate and endDate have been added to InvoiceRow used in the GET /invoices/{invoiceId}, POST /invoices and PUT /invoices/{invoiceId} endpoints to enable row level accrual periods in invoices.
  • New optional fields startDate and endDate have been added to Transaction used in the GET /ledgerreceipts/{receiptId}, POST /ledgerreceipts and PUT /ledgerreceipts/{receiptId} endpoints to enable transaction level accrual periods in ledger receipts.
  • PUT /invoices/{invoiceId}/approve endpoint now approves invoice of type PURCHASE_INVOICE, TRAVEL_INVOICE, BILL_OF_CHARGES in PAYMENT_DENIED status.

Changes in version 22.03

Endpoints

  • We are introducing new endpoint POST /reports/accounting to mimic the new accounting reports functionality available in Procountor UI under Accounting > Accounting reports (new).
    • Syntax of the report rows returned by the endpoint depends on report formulas. Please check Procountor manual to learn more about default report formulas used in income statement, balance sheet and cash flow reports.
    • This endpoint has following limitations:
      • Accounting reports are returned in JSON format
      • Supports only these accounting report types: INCOME_STATEMENT, CASH_FLOW, BALANCE_SHEET
      • Custom reports aren't supported
      • Supports only these filtering options: receiptType, receiptCurrency, receiptName, customerCompanyId, entryPeriodStart, entryPeriodEnd, transactionValue, transactionCurrency (not considered if transactionValue is missing)
      • Comparison data options aren't supported and only handful of presentation options can be configured
  • New optional fields allowPersonalSubstitution and substitutes have been added to GET /company/invoicecirculation/settings to support invoice circulation substitution.
  • A bug where empty attachment list was returned in GET ​/ledgerreceipts​/{receiptId} for ledger receipt type BANK_STATEMENT_AS_RECEIPT that had attachment, has been fixed.

Changes in version 22.02

Endpoints

  • We are introducing new endpoint GET /businesspartners/groups to fetch business partner groups.
  • We are introducing new endpoint POST /businesspartners/groups to create business partner group.
  • We are introducing new endpoint GET /businesspartners/groups/{id} to fetch details of the given business partner group.
  • We are introducing new endpoint PUT /businesspartners/groups/{id} to update business partner group. Changing business partner group type isn't supported with this endpoint.
  • New optional field reportGroupId has been added to RegistryInfo structure used in the GET /businesspartners/{id}, POST /businesspartners and PUT /businesspartners/{id} endpoints. The reportGroupId must be one of the ids from business partner groups in partnerGroups.
  • New optional field id has been added to BusinessPartnerGroup structure returned by the GET /businesspartners/{id} endpoint. In POST /businesspartners and PUT /businesspartners/{id} endpoints:
    • If user gives conflicting id and name for business partner group, id is honored.
    • If all business partner groups have id, reportGroupId is required.
    • Either all business partner groups in partnerGroups must have id or id for all business partner groups must be null.
  • PUT /businesspartners and POST /businesspartners endpoints now save business partner groups information given in reportGroupId and partnerGroups fields. If group information isn't given, group assignments won't be changed. To remove partner groups associations please provide empty list [] for partnerGroups.
  • In PUT /invoices/{invoiceId}/paymentevents/markpaid endpoint if given currency is different than environment's base currency, payment amount will now be converted to base currency with currency rate from the invoice. This change will apply to these invoice types: sales, purchase, travel.
  • GET /invoices results can now be filtered using invoiceNumber.

Other

  • All resources in API reference page have been collapsed.

Changes in version 22.01

Endpoints

  • New optional field statementNumber has been added to BankStatement structure returned by the GET /bankstatements endpoint to get bank statement number. This number starts from 1 and is reset each year.
  • New optional field receiptNumber has been added to LedgerReceipt structure returned by the GET /ledgerreceipts/{id} endpoint. This field contains the receipt number used e.g. with ledger receipts of type BANK_STATEMENT_AS_RECEIPT. The field is also available in POST /ledgerreceipts and PUT /ledgerreceipts/{id} endpoints.
  • POST /invoices and PUT /invoices/{id} endpoints now check if mandatory EInvoiceAddress is given when creating sales invoice with paymentMethod DIRECT_PAYMENT. If the address is missing, API returns error message EINVOICE_ADDRESS_MISSING.

Changes in version 21.12

Endpoints

  • A modified timestamp has been added to FiscalYear and TrackingPeriod structures returned by the GET /fiscalyears endpoint.

Changes in version 21.11

Endpoints

  • New invoice field invoiceTemplateId allows you to see the used invoice template in invoices returned by GET /invoices/{id} endpoint. The invoice template can be set with POST /invoices or PUT /invoices/{id} endpoints.
  • Bank account number is no longer required when making or updating purchase invoices and orders with CREDIT_CARD_CHARGE or OTHER payment method using POST /invoices or PUT /invoices/{id} endpoints.
  • Address validations for POST /businesspartners and PUT /businesspartners/{id} endpoints now follow the UI validations more closely.
  • We are introducing new GET /company/invoicetemplates endpoint, which returns a list of invoice templates (name and ID only) available in the company environment.

Other

  • Previously undocumented error messages and invoices endpoint batch functionality have been added to API reference.

Changes in version 21.10

We have removed support for weak TLS 1.2 cipher suites from our API services. This change took effect on Monday 27 September 12.00 EEST (09.00 UTC).
The following cipher suites are still supported with TLS 1.2: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_DHE_RSA_WITH_AES_256_CCM_8, TLS_DHE_RSA_WITH_AES_256_CCM, TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384, TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_CCM_8, TLS_DHE_RSA_WITH_AES_128_CCM, TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256, TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256

Other

  • We have changed the wording of "API login only" user right limitation to "Allow only M2M login to API" to better reflect the functionality behind this limitation. Enabling this limitation means that the user is allowed to log in to Procountor only using the API with M2M authentication method.

Changes in version 21.09

Other

  • We are adding a new user right restriction: API login only. When enabled for a user they will only be able to log in using the API and M2M authentication. We recommend enabling this setting for technical users created for backend API integrations.

Changes in version 21.08

Endpoints

  • In addition to type, GET /attachments results can now be filtered using referenceId. Note that the same reference id can exist for references of multiple types.
  • GET /invoices/{id} no longer incorrectly returns cashDiscount details for those invoice types where cash discount is not applicable.
  • PUT /invoices/{id} can now be used to modify invoices in RECEIVED state as well as in UNFINISHED state.
  • GET /products results can now be filtered using the active field.

Other

  • Descriptions in API reference have been clarified.

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.

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

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

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.

Changes in version 20.01

Starting from January 2020, we will enforce a 100 refresh token limitation for (API client, company, user) -tuple. This means that a single user can have at most 100 valid refresh tokens for a single company using the same client software at a time. When new tokens are requested at the limit the oldest tokens get removed.

Starting from 1st of January 2020, the refresh token lifespan will be set to 6 months. The lifespan of tokens created before then is calculated from January 1st. This means that such tokens will expire 1st of July 2020 if not invalidated before then.

Endpoints

  • GET /factoringcontracts - A new endpoint for searching factoring contracts
  • POST /factoringcontracts - A new endpoint for creating factoring contracts
  • GET /status - An endpoint for checking the API health
  • PUT /referencepayments/metadata - A new endpoint for allocating VAT metadata to a reference payment
  • DELETE /referencepayments/metadata/{referencePaymentId} - A new endpoint for removing VAT metadata from a reference payment
  • You can now filter invoices returned by GET /invoices endpoint by factoring contract id.
  • PUT /invoices/{invoiceId}/paymentevents/markpaid now returns details of the created payment event.
  • You can now add factoring contract for business partners using POST /businesspartners and PUT /businesspartners/{id} endpoints.
  • You can now filter business partners returned by GET /businesspartners endpoint based on their modification date. The date of the last modification is also returned with every business partner.
  • Missing address.name field has been added to GET /businesspartners/{id} response.

Other

  • Field validations, error messages and documentation have been clarified.

Changes in version 19.12

Endpoints

  • DELETE /products/groups/{groupId} - A new endpoint for removing sales and purchase product groups from the product catalog
  • DELETE /products/{productId} - A new endpoint for removing sales and purchase products from the product catalog
  • We've added a custom ID field to direct salary payment lists. The custom ID can be up to 80 characters in length and can be used to filter the lists returned by GET /payments/directsalarypayments.
  • You can now filter the direct salary payment lists returned by GET /payments/directsalarypayments endpoint by name.

Other

  • The page titles in API login have been changed. The basic login page is now Finago login, the reset page (opened from the Forgot password? link) is Finago password reset and the API password changing page is now titled as Finago password change.
  • A bug where the TRAVEL products were not available from the API in some environments has been fixed.
  • A bug where an invoice creation is erroneously reported as failing when using limited dimensions has been fixed.
  • Security related fixes
  • Small bug fixes and improvements

Changes in version 19.11

Endpoints

Direct salary payments
  • POST /payments/directsalarypayments - A new endpoint for creating a list of direct salary payments which will be processed as a single bundle by Procountor and a bank. Requires 2-factor authentication.
  • GET /payments/directsalarypayments - A new endpoint for accessing created direct salary payment lists.
  • PUT /payments/directsalarypayments/{paymentlistId}/cancel - A new endpoint for cancelling a created direct salary payment list before it is being processed by a bank. Requires 2-factor authentication.
  • PUT /payments/directsalarypayments/{transactionId}/confirm - A new endpoint for following the status of direct salary payment transactions.
  • Two new webhooks related to direct salary payments
  • DIRECT_SALARY_PAYMENTS_CREATED for newly created payment lists
  • DIRECT_SALARY_PAYMENTS_CANCELED for cancelled payment lists
Product endpoints
  • GET /products - The endpoint now returns only SALES and PURCHASE products if a product type is not defined with the type query parameter. TRAVEL products are returned only when the queried type is set to TRAVEL. The startDate and endDate fields are only used with TRAVEL products.
  • GET /products/{productId} - The endpoint now returns startDate and endDate fields only for products whose type is TRAVEL.
  • GET /products/groups - We've renamed the productType query parameter to type in this endpoint. When type is not given the endpoint returns all SALES and PURCHASE product groups. TRAVEL groups are returned only if the type parameter is set to TRAVEL. A matching type field is also returned with all found product groups.
  • POST /products - A new endpoint for adding new sales and purchase products to the product register.
  • PUT /products/{productId} - A new endpoint for modifying existing sales and purchase products in the product register.
  • POST /products/groups - A new endpoint for adding new sales and purchase product groups to the product register.
  • GET /products/groups/{groupId} - A new endpoint for fetching details of individual product groups from the product register.
  • PUT /products/groups/{groupId} - A new endpoint for modifying existing sales and purchase product groups in the product register.
Other endpoints
  • POST /invoices - You can now use the paymentInfo/generatedReferenceType field to specify a type for an automatically created reference code when POSTing invoices.
  • GET /vats/default - We have added vatStatuses list to this endpoint. The list contains the valid VAT statuses for the active environment.

Other

  • A bug in the Invoices API where the user was not always able to fetch a purchase invoice after it had been verified has been fixed.
  • A bug where the user defined KID was substituted with an automatically generated one when POSTing an invoice in an Norwegian environment has been fixed.

Changes in version 19.10

Starting from this release the API versioning will follow YY.MM convention. We are also making the API support cycle more consistent. We'll release a new latest version of the API every month. Every three months we release a supported version of the API, which will be available for the following six months.

Other

  • Calling ../{transactionId}/confirm endpoints is no longer necessary in order to execute an API transaction requiring 2-factor confirmation. The confirm endpoint still returns the status of the transaction like before, but the transaction itself is completed once the user accepts it in Finago key application. Changes in a transaction status can be received using webhooks, and the status will also be available through the confirm endpoint for 24 hours from the start of the transaction.
  • We have enhanced the documentation of the webhooks

Changes in version 13.1

Endpoints

  • POST /invoices:
  • The following change affects invoices in all environments:
    • The following optional field has been added to Address model: subdivision
  • The following changes affect Sales and Purchase invoices in Finnish environments:
    • The following optional fields have been added to Invoice model: orderNumber, agreementNumber, accountingCode, deliverySite, tenderReference
  • GET /invoices/{invoiceId}:
  • The following change affects invoices in all environments:
    • The following optional field has been added to Address model: subdivision
  • The following changes affect Sales and Purchase invoices in Finnish environments:
    • The following optional fields have been added to Invoice model: orderNumber, agreementNumber, accountingCode, deliverySite, tenderReference
  • We are introducing webhooks service for subscribing to and receiving push notifications from select events. The following endpoints can be used to control the webhooks:
  • GET /webhooks: for searching subscribed webhooks
  • POST /webhooks: for subscribing to webhooks
  • PUT /webhooks/{uuid}: for updating a webhook
  • DELETE /webhooks/{uuid}: for deleting a webhook

Other

  • The format of the API specification has been changed from "Swagger 2.0" to "OpenAPI 3.0.1".
  • We have improved error handling of our endpoints.
  • There are a number of security related enhancements in this update.

Changes in version 13

Endpoints

  • GET /fiscalyear: The response model has been changed. Field isOpen has been removed and a new field status is introduced.
  • PUT /fiscalyears/{fiscalYearId}/trackingPeriods/{trackingPeriodId}: A new endpoint for changing the status of a tracking period. Currently, it is possible to change the status from OPEN to PENDING.
  • POST /businesspartner: Support for the payment method "NETS" has been added for creating customers. A new field customerAccountNumber can be filled when using NETS as a payment method (NETS is valid payment method for customers in Danish Procountor environments).

Changes in version 12

Endpoints

  • POST /invoices: It is now required to provide the VAT status of the invoices by filling the VATstatus field
  • GET /invoices/{invoiceId}: The invoices now provide the VAT status through the VATstatus field
  • GET: /company: The response model now contains the id of the corresponding accounting office
  • GET /attachments: Fetch attachments from Procountor. The user can search by date (start date - end date), name (file name), user (full name of the user), and receipt types.
  • POST /businesspartner: Create business partners through the API
  • For DELETE endpoints the response is 204 in case of success
  • Messages for wrong requests have been unified
  • Every endpoint response is now in JSON format

Other

VAT status and API versions

The newest API version 12 requires a VAT status when creating new invoices through the API. In case the VATstatus field is empty, invoices cannot be created using API version 12. If necessary, use older API versions to create invoices without providing a VAT status. The VAT status will be populated in Procountor according to the VAT defaults.

Changes in version 11

Endpoints

  • In all endpoints where a 2-factor authentication is required (all /confirm endpoints), the field name value in the response model is changed to transactionIdentifier.
  • POST /payments/directbanktransfers : We added an optional customId field to the parameters. The endpoint processes requests and responds with paymentId, customId pairs, in which customId is given in the request. If customId is not provided in the response field, they are null.
  • POST /payments: We changed the response for the requests sent to this endpoint. The response model now contains a list of pairs of paymentId, invoiceId.
  • GET payments/errormessages: General error message type BANK_TRANSFER is renamed to DIRECT_BANK_TRANSFER.
  • GET payments/errormessages: receiptId is renamed to referenceId, generalReceiptType is renamed to referenceType.
  • PUT /ledgerreceipts/{receiptId}/invalidate: New endpoint to invalidate journal receipts.
  • PUT /ledgerreceipts/{receiptId}/unfinished: New endpoint to set the journal receipt status to unfinished.

Other

TLS Protocols

Procountor will permanently disable support for legacy TLSv1 and TLSv1.1 protocols in API interfaces starting from May 18th at noon (12:00). Currently, the supported version is TLSv1.2. If your API integration does not already use TLSv1.2, the integration will stop working after May 18th. Support for TLSv1.3 protocol will be added at the same time as the old protocols are deprecated. After the release, the supported versions are thus TLSv1.2 and TLSv1.3.

Possibility to change passwords

A new user interface has been added to allow API users to change their password.

Changes in version 10

Endpoints

  • GET /invoices and /invoices/{invoiceId}: Sales orders, offers and purchase orders are now supported
  • PUT invoices/{invoice-id}/paymentevents/markPaid and invoices/{invoice-id}/paymentevents/markPaid/confirm: Mark as paid for sales invoices has been merged to the same endpoint with other invoice types
  • Key confirmation requirement has been removed for mark as paid (concerns all invoice types)
  • PUT /invoices/{invoiceId}/approve: Invoice approval in API now supports sales invoices
  • PUT /invoices/{invoiceId}/send: API now supports sending sales invoices
  • PUT /users: Users can now update their personal information via PUT /users
  • POST /attachments: API now supports "send with invoice" functionality in sales invoices’ attachments

Changes in version 9

Endpoints

  • PUT /invoices/pay will soon be deprecated
  • GET /invoices/{invoiceId}/comments: New endpoint for getting comments related to invoices
  • POST /invoices/{invoiceId}/comments: New endpoint for posting comments related to invoices
  • PUT /invoices/{invoiceId}/paymentevents/markPaid: New endpoint for marking sales invoices, purchase invoices, travel and expense invoices, salary slips and self-assessed tax returns as Marked paid
  • DELETE /invoices/{invoiceId}/paymentevents/{paymentEventId}/: New endpoint for removing Marked paid payment events. (Note: If the event is related to a real payment, the previously created endpoint DELETE /payments is used instead)

Other

  • API logout now removes the refresh token and all related access tokens
  • GET /invoices: Expanded the parameters with new data fields; createdStartDate, createdEndDate, versionStartDate, versionEndDate, orderByCreated, orderByVersion
  • GET /ledgerreceipts: Expanded the parameters with new data fields; createdStartDate, createdEndDate, versionStartDate, versionEndDate, orderByDate, orderByCreated, orderByVersion
  • POST /payments: Added support for foreign payments, express payments and direct bank transfers

Changes in version 8

Endpoints

  • PUT /invoices/pay will soon be deprecated
  • GET /payments: New endpoint for getting payment transactions
  • POST /payments: New endpoint for paying invoices
  • Supports only bank transfer and requires that the user has full rights to payments and to the receipt type in question
  • This will replace PUT /invoices/pay, which can be still used in version 8 but will be deprecated later
  • PUT /payments/cancel: New endpoint for canceling a payment transaction, when the payment is still waiting to be transferred to bank (payment status is "payment queued")
  • DELETE /payments: New endpoint for removing a payment transaction, when the payment is already transferred to bank (payment status is "payment sent to bank")
  • PUT /payments/confirm: New endpoint for confirming actions
  • GET /invoices/paymentevents: New endpoint for getting all payment data related to the invoices, including "Paid elsewhere"

Other

The new payments endpoint will introduce a new way of 2-step verification via API, which will also be utilized in specific endpoints in the future. We will publish a more specific documentation of the new way on our developer site after the January version release.

Changes in version 7

Endpoints

  • GET /paymenterrors: New endpoint for getting payment errors and their details with creation date or error status
  • PUT /company: New endpoint for updating the basic info of the company in Procountor
  • GET /sessioninfo: New endpoint for getting information of the current user

Other

  • GET /users: expanded with several new data fields; First name, Last name, Email address and Mobile phone number with country code (e.g. +358 50 xxx xxxx)
  • GET /company: expanded with several new data fields; Business ID, Contract type, Postal address, Billing address and in Norwegian environments also MVA (dropdown) and Trade register (checkbox)
  • A limit of 10,000 characters has been set on the invoice field additionalInformation

Changes in version 6

Endpoints

  • GET /businesspartners: New endpoint for getting all business partners (customers, suppliers, persons) from the registers in specific Procountor environment
  • GET /ledgerreceipts: Added support for all ledger receipt types
  • GET /referencepayments: New endpoint for getting reference payment data
  • GET /businesspartners/{id}: Added coverage for several data fields
  • GET /attachments: Added support for reference payments as referenceType
  • POST /attachments: Added support for reference payments as referenceType
  • PUT /businesspartners (customer and supplier): New endpoint for updating customer and supplier information
  • POST /dimensions: New endpoint for creating dimensions and their items

Other

  • Secured token requests Added support for supplying authorization code and especially client secret as request body parameters instead of supplying them as URL parameters when getting access and request tokens.

Changes in version 5.3

During Q2/2018, we have released a few minor updates to API version 5:

Endpoints

  • GET /company: New endpoint for providing basic information regarding currently logged in company.
  • GET /ledgerreceipt: Support for travel and expense invoices.
  • PUT /ledgerreceipt: Support for travel and expense invoices.

Changes in version 5.2

During Q1/2018, we have released a few minor updates to API version 5:

Endpoints

  • GET /products: Added search parameters for product validity. May be used with travel/expense products.
  • POST /invoices: Parameter vatCountry can now be supplied regardless of foreign VAT special right.

Resources

  • Invoice: Added a field for bank clearing code. Allows to post invoices with clearing as payment method.
  • Invoice: Fixed an issue which prevented from creating an invoice without a reference number. Clarified documentation.

Changes in version 5.1

An incremental update to API version 5 took place on 18th December 2017.

  • GET /businesspartners/personaldetails: New endpoint for getting basic information of the current user from the person register.
  • GET /products/({id}): Product objects now contain localised names for travel and expense invoice products when includeLocalizations parameter is given.
  • GET /products/({id}): Travel and expense invoice products no longer require access rights to product register (they are standardised and public information).
  • GET and POST /invoices: Fixed to also work for users with Personnel role in Procountor.

Changes in version 5

Endpoints

  • GET /userinfo/profiles/{userId}: New endpoint for getting basic information of persons in the current company.
  • GET /products/groups: New endpoint for fetching a list of product groups by product type.
  • GET /products: Now accepts type and group parameters for search.
  • GET /currencies: New endpoint for getting all currencies used in Procountor.
  • GET /currencies/company: New endpoint for getting the currency of the current company.
  • GET /currencies/latest: New endpoint for getting the latest currency rates.
  • GET /currencies/exchangerate: New endpoint for getting exchange rates between two currencies for a given day.
  • GET /vats/default: New endpoint for getting all VAT percentages and related information in the current company.

  • GET /vats/country: New endpoint for getting a list of VAT percentages used in a given country.

  • POST /invoices: Now supports travel invoices.

  • PUT /invoices/{invoiceId}/approve: Supports commenting the invoice.
  • PUT /invoices/{invoiceId}/verify: Supports commenting the invoice.
  • PUT /invoices/{invoiceId}/sendToCirculation: New endpoint for sending travel invoices to circulation.

Resources

  • Data model for purchase, travel and expense invoices now contains user IDs of verifiers and approvers.

Other

  • Introducing refresh tokens. Starting from API version 5, access tokens expire in a predefined time and can be renewed by using refresh tokens.

Changes in version 4

Endpoints

  • GET /products: Implemented pagination. (breaking change)
  • GET /ledgerreceipts: Implemented and documented proper pagination. (breaking change)
  • GET /invoices: Now supports expense invoices.
  • GET /invoices/{invoiceId}: Now supports travel and expense invoices.
  • PUT /ledgerreceipts/{receiptId}: Now supports ledger receipts for sales and purchase invoices. This functionality allows to e.g. define ledger accounts and add dimensions to invoices.
  • PUT /invoices/{invoiceId}/approve: Now supports travel and expense invoices.
  • PUT /invoices/{invoiceId}/verify: New endpoint for verifying purchase, travel and expense invoices.

Resources

  • Invoice: If referenceNumber field is empty when creating an invoice, a reference number is generated by Procountor.
  • Invoice: Added invoiceNumber field.
  • Invoice: Added attachments field containing a list of attachment details.
  • Invoice: Added fields related to travel/expense invoices.
  • LedgerReceipt: Extended to cover all UI fields.
  • Transaction: Extended to cover all UI fields.
  • Transaction: Removed reversingEntry field and introduced transactionType field. (breaking change)

Other

  • Documented validation error codes.

Changes in version 3

  • Introduced a new endpoint GET /invoices for searching invoices. The endpoint returns a paginated list of invoice metadata. Full invoice details can be fetched by using the GET /invoices/{id} endpoint. The invoice search supports sales, purchase, travel and periodic tax return invoices.
  • GET /invoices/{id} now supports periodic tax return invoices.
  • Added notes field to invoice model.
  • Response for posting an invoice now contains ledgerreceiptId.
  • For consistency with the UI, a BIC code (paymentInfo.bankAccount.bic) cannot be specified for sales invoices anymore.
  • Invoice orderReference field is now limited to max 70 characters as is in the UI.
  • Added support for state parameter in OAuth flow.
  • Improved API documentation.

Changes in version 2

  • New API URLs
  • JSON serialization was changed: empty strings and null values are no longer added to JSON response
  • GET /businesspartners/
  • All three type of Partners can be queried: PERSON, CUSTOMER and SUPPLIER
  • Invoice.deliveryMethod now uses a limited set of values.
  • User rights checks in /products endpoint had a bug that caused them to be too lenient. This has been fixed.
  • Added support for posting sales invoices
  • New endpoint for attachments
  • Sales invoice field "notes" has been renamed "additionalInformation"
  • Added GET /fiscalyears