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

Planned changes ahead

We would like to inform you that we are planning to migrate our OpenAPI specification from version 3.0.1 to version 3.1.0.

This update is scheduled for release in April and will apply to all API versions.

While we do not anticipate breaking changes to API functionality, related to this migration, we recommend reviewing your integrations to ensure compatibility with OpenAPI 3.1.0.

Changes in version 26.03

Endpoints

Changes in existing endpoints

GET /payrolls/salaryslips

• We have added support for batch GET /payrolls/salaryslips/{id} for fetching multiple resources with a single API call. It is possible to fetch up to 200 resources by specifying a comma-separated set of resource IDs.
• Recourses with a valid ID are returned. The items in the result are ordered by resource ID, duplicates are not included. When multiple resources are requested the result is provided as a list - even for 1 returned resource. When request contains more than 200 IDs, an error response 400 is returned.

GET /payrolls/employees/{id}/holidaypay

• It is now possible to fetch holiday related remaining figures (remaining holiday days, remaining holiday pay, remaining holiday bonus days, remaining additional leave days) per holiday credit year.
• The endpoint returns the same totals plus a per-year breakdown (yearlyRemainings array).

POST /payrolls/salarylists PUT /payrolls/salaryslips/{salaryslipId}

• We have added a new validation for car benefit emission value with salary type 3010, paydays in year 2026, the emission value must be 0 or null.

Changes in version 26.02

No changes released in this version

Changes in version 26.01

Endpoints

New endpoints

GET /invoices/transactions

• It is now possible to fetch invoice transactions for multiple invoices in a single API call. This enhancement improves performance when working with large sets of invoices and reduces the need for repeated requests.
• To use this functionality, provide one or more invoiceIds as query parameters (up to 200 IDs). The response will include a list of invoice entries, each containing its corresponding transaction history.
• The new functionality is available in the GET /invoices/transactions API endpoint.

Changes in version 25.12

Endpoints

Breaking changes

• /PUT/company

  If the company’s contract type is set to production usage the businessIdentifier field is not editable.

  A new additional validation step is introduced to ensure that if a company ID is changed while the company’s contract type is set to production usage, the client receives a 403 (Access Denied) error.

Changes in existing endpoints

GET /users/rights change

• We have created a new user right "Mark salary as paid" to the endpoint GET /users/rights. A new field markSalaryAsPaid has been added to the search results.
• With "Mark salary as paid" user right it is possible to mark salary slips as paid elsewhere and remove the "Marked paid" status from salary slips. This right has been separated from general "Mark as paid right".
• The new right is not available in long term supported, supported or deprecated API versions.

GET /journals endpoint has been improved with added Date search parameters

• New search parameters have been added for GET /journals endpoint → createdStartDate, createdEndDate, startDate, endDate, versionStartDate and versionEndDate.
• The change allows API users to filter journals based on a specified date or date range, instead of just retrieving all records at once.

GET /invoices - possibility to search sales offers

• We have fixed an existing malfunctioning feature which enables API users to search sales offers by calling GET /invoices?isOffer=true with new search parameters. See the API reference for more information.

Changes in version 25.11

Endpoints

New endpoints

We have created a new endpoint GET /mfatransactionresult/{transactionIdentifier}

• This endpoint replaces multiple existing confirmation endpoints which are marked as deprecated:
  • PUT /users/{transactionIdentifier}/confirm
  • PUT /invoices/{transactionIdentifier}/confirm
  • PUT /payments/directsalarypayments/{transactionIdentifier}/confirm
  • PUT /payments/directbanktransfers/{transactionIdentifier}/confirm
  • PUT /payments/{transactionIdentifier}/confirm
• These existing endpoints have been marked as PUT but they have been functioning as GET endpoints, so there is no change in the functionality itself.
• The response model for the new endpoint has been improved. There is a separate field for each response model type and only one field is returned, according of transaction type. Please check OpenAPI documentation for further information.

With a new endpoint PUT /products/{id}/defaults/dimensions/{dimensionId} it is now possible to add default dimensions to products.

• Dimensions can be added to products by using PUT /products/{productId}/defaults/dimensions/{dimensionId}
• Fetching the default dimensions of products can be done with endpoints GET /products/{id}/defaults/dimensions/{dimensionId} and GET /products/{id}/defaults/dimensions.
• The validation logic within the endpoints is following the Procountor UI:
  • percent sum has to be 100%
  • names cannot be duplicated for items
  • item name has to be correct
  • product for the added default dimension has to exist

Improvements

A new field partnerId has been added to the endpoint GET /ledgerreceipts/{receiptId}

• This should help API users to stay on track i.e. in cases where a business partner has been changed on the invoice, but not on the ledger receipt.
  • If a ledger receipt is linked to an invoice, the business partner id from the linked invoice is displayed in GET /ledgerreceipts/{id} as partnerId field.
  • Sometimes the partnerId field with GET /ledgerreceipts/{id} may also return result null, i.e. if the ledger receipt is not linked to an invoice, or the business partner's partnerId on the invoice is null if the business partner has not been created to the business partner register (partnerId not given).

Improved endpoint specification for GET /invoices

• API reference for GET /invoices endpoint has been updated.
• For most of the addresses name in API is not required. The field name has been marked as required only in:
  • InvoiceCounterpartyAddress
  • PaymentRecipientNameAndAddress
• Description about sales and sales order invoices is displayed only for invoice address:
  • InvoiceBillingAddress
  • InvoiceCounterpartyAddress

A new field added to GET /products and GET /products/{id}

• A new field version has been added to GET /products and GET /products/{id} response bodies alongside with a possibility to search by versionStartDate and versionEndDate and orderByVersion with GET /products.
• The change enables API users to detect when a product's information has been modified and enable searching only modified products.

New optional field

• We have added optional field bccAddresses in counterParty in the following Invoices API endpoints:

  • GET /invoices
  • POST /invoices
  • GET /invoice/{invoiceId}
  • PUT /invoice/{invoiceId}

• And in these BusinessPartners API endpoints, bccAddresses is added to invoicingInfo

  • POST /businesspartners
  • GET /businesspartners/{id}
  • PUT /businesspartners/{id}
  • PATCH /businesspartners/{id}

• bccAddresses field is supported only in sales invoice, sales order and offer with these validations

  • Maximum 4 email addresses can be provided
  • Must not be the same as the main email address
  • Each Bcc address must be free of special characters and no longer than 256 characters

General

Improved usability with Procountor API activation

• Procountor API activation “state” parameter delivered with the callback URL.
• We have added a “state” parameter to the API activation callback URL to be passed on, so that when activating Procountor API our integrators are able to direct their users to the right state and environment between their system and Procountor API activation system.
• The feature is in use automatically when using the newer API activation flow.

Tax card information

• Starting in Procountor version 107, tax cards now have income types. In the Procountor API, they can be left out of tax card related queries, which in interpreted as tax card not having a set income type. If they are present, they are given as a String in same form that VeroApi handles them. Values that Procountor API handles are "000024" - "000040", "000042".
• Tax card income types are used when selecting what tax card to use when creating salary slips. The selection is made based on a selection made in salary info view. This selection is coming to the Procountor API in the future. The default is the old behavior.
• VeroApi documentation: https://api-developer.vero.fi/api-details#api=IIT&operation=postGetWithholdingPercentage

Payroll API

Changes to existing endpoints

• We have added new tax card income type and class has been updated to contain the new incomeType variable.
• Income type is not mandatory, and it can be left out or set as null.
• If incomeType is given it needs to be 00000, 000024-000040, 000042 or otherwise, an error is given that says the given value is unexpected, 400 error code.
• Tax-At-Source tax cards do not have an income type, so assigning any should end in 400 error code with message “Invalid tax card income type”
• The change concerns following endpoints:
  • GET/payrolls/employees/{id}/salaryinfo/taxcards
  • POST/payrolls/employees/{id}/salaryinfo/taxcards
  • GET/payrolls/employees/{id}/salaryinfo/taxcards/{taxCardId}
  • PUT/payrolls/employees/{id}/salaryinfo/taxcards/{taxCardId}
  • DELETE/payrolls/employees/{id}/salaryinfo/taxcards/{taxCardId}

Changes in version 25.10

Endpoints

New Payroll features

We have improved the Payroll API with following changes:

• With the new endpoint PUT /payrolls/salaryslips/{id}/cancelapproval customers are now able to cancel the approval of a salary slip through the API.

  • The new endpoint cancels approvement from the salary slip with given salary slip ID. Only salary slips with status APPROVED can be handled with the endpoint.

• Existing endpoint PUT /payrolls/salaryslips/{id} improvements

  • We have synchronized the additional base salary type's quantity to match with the main salary type's quantity when the salary type is added as a new entry through the API.
  • New salary row of salary type's 2411 Sick leave wage – monthly positive quantity value will now match together with the additional base salary row 1017, deductions from base salary, sick leave pay negative quantity value.
  • Also new salary rows of Overtime salary types (1230-1239) quantity values and related additional base salary row 1220 - Overtime compensation base hourly salary or 1221 - Overtime compensation base monthly salary quantity values will now match.
  • On Prcountor UI there is no link/syncronisation for main and additional base salary row and the default Qty is always 1.
• The customer benefit is that Payroll clerks don't need to do manual adjustments when paying sick leave or overtime salary through the API, because:
  • New salary rows with Sick leave pay 2411 quantity value will now match with the base salary deduction row 1017 negative quantity value.
  • New salary rows with Overtime salary types 1230-1239 quantity now matches with the overtime compensation base salary type 1220 or 1221 quantity value

Changes in version 25.09

Endpoints

New Payroll features

As part of the Payroll API we are introducing changes to existing endpoints

• New features with endpoint PUT /payrolls/salaryslips/{id}

  • We have added support for modifying working hour reduction rows with quantity within the ranges allowed by earned hours/days during the whr periodic setting, unit value within commonly allowed ranges. Correction e.g. unjust enrichment and recovery is not supported.
  • We have added support for modifying holiday/holiday bonus/additional leave days rows as on the UI - quantity, unit value (for monthly), holiday days spent (for monthly workday). Correction e.g. unjust enrichment and recovery is not supported.
  • Support for changing salary slip's payday

• New feature with endpoint POST /payrolls/salarylists

  • Possibility to pay working hour reduction

Paying working hour reduction will take place with automation so that it is only needed to provide payable amount of days or hours, and Procountor will distribute these days/hours to different (if there is) year's remaining days/hours starting from the oldest remaining working hour reduction days/hours. Both workingHourReductionHours and workingHourReductionDays must be positive or omitted (null), not 0.

Other endpoints

• GET /company endpoint.

  It is now possible to fetch the company currency and currency rate search density in the GET /company endpoint response. This enhancement provides additional details about the company's financial settings. The new fields can be found in the response payload of the GET /company API. To use this functionality, simply call the GET /company endpoint, and the response will include the companyCurrency and currencyRateSearchDensity fields.

Changes in version 25.08

Endpoints

Breaking changes:

• POST /bankaccounts

• PUT /bankaccounts/{id}

  Background:

  Holvi bank connection is planned to be released on version 104. If user had Holvi bank account before the release 104 date, they are marked as "old Holvi customer". Old Holvi customer can't use payment features.

  Summary:

  Now we restrict the conditions while creating and updating Holvi bank account. This applies only for old Holvi bank customers. If any of the payment features are chosen, the request will be turned down with 400 status code with description Invalid argument. Bank account is not allowed for payment methods.

  Restricted payment features:

  • allowPayments
  • allowForeignPayments
  • allowSalaryPayments
  • allowExpressPayments
  • defaultForPayment

  Reason:

  Holvi bank payment features are not supported for old Holvi customers. Contact cutomer service to remove that special right and enable payment features.

  How to use it:

  If you are old Holvi customer, you need to set as false all payment features listed above.

New Payroll endpoint

As part of the Payroll API we are introducing new endpoints:

• PUT /payrolls/salaryslips/{id}/approve this endpoint approves salary slip with given salary slip ID in case there are no contraindications / validation failures for a slip to be approved.

• GET/payrolls/salaryslips/{id}/accounting fetches accounting for given salary slip ID

• PUT/payrolls/salaryslips/{id}/accounting possible to update accounting data for given salary slip ID and especially possible to create and update dimension entries.

  Salary slip needs to be first approved with PUT /payrolls/salaryslips/{id}/approve endpoint before it is possible to fetch accounting details with GET/payrolls/salaryslips/{id}/accounting endpoint, and then it is possible to update accounting details for example dimensions by using PUT/payrolls/salaryslips/{id}/accounting endpoint. Principle is the same as when updating dimensions for the invoices with PUT /ledgerreceipts/{receiptId}/transactions/{transactionId}/dimensions

New endpoints

• GET /vats/settings to retrieve company VAT settings:

  • isUnitPricesIncludeVatSales specifies if VAT is included in sales invoice products by default.
  • isUnitPricesIncludeVatPurchase specifies if VAT is included in purchase invoice products by default.

• GET /company/usagesettings to retrieve company usage settings. This endpoint provides detailed information about the company's usage settings, including:

  • defaultInvoiceChannel specifies the default method for sending invoices (e.g., email, mail, electronic invoice etc.).
  • cashDiscount settings indicates whether cash discounts are applied for sales and purchase invoices.
  • accountingByRow settings provides details on whether posting by row is enabled for sales invoices, purchase invoices, travel and expense invoices, and salaries.

  This endpoint requires Management -> Basic company info viewing rights.

Changes to existing endpoints:

• POST /payrolls/salaryslips we have added more validations for rows

• PUT /payrolls/salaryslips/{id} endpoint currently does not support:

  • modifying holiday pay rows
  • modifying working hour reduction rows
  • modifying payday

• POST /payrolls/salarylists we have added possibility to pay holiday pay, holiday bonus pay and additional leave days and holiday compensation with POST/payrolls/salarylists.

  Paying holiday or holiday bonus pay or additional leave days will take place with automation so that it’s only needed to provide payable amount of days and Procountor will distribute these days to different (if there is) year’s remaining days and also with different calculation basis (if there is) starting from the oldest remaining holiday days. Therefore there is no need to know which salary type needs to be used for paying holiday pay/holiday bonus pay/additional leave days.

  With right for time of the payable holiday compensation sum needs to be provided and this sum will be distributed for different holiday credit years starting from the oldest one where is unpaid holiday compensation.

  Support for paying working hour reduction with API will be released in September release.

Changes in API documentation

• In the documentation for the GET /journals endpoint, all instances of the term journal invoice have been replaced with the term journal receipt.

Older release notes

Older release notes can be found from their own page.

Old release notes