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

• In the future, we will deprecate Persons from Business Partners. This change will be communicated later.

Changes in version 25.06

Endpoints

New Payroll endpoint

As part of the Payroll API we are introducing new endpoint for creating new salary list

• POST /payrolls/salarylists creates new salary list and salary slips in it from salary base.

• Working time allocation days are prefilled and calculated from Payment period start and end date, user will be able to adjust them with PUT /payrolls/salaryslips/{id} endpoint which is planned to be released in July release, then also adding salary slip rows will be possible.

• Notes to salary slips are not supported in POST /payrolls/salarylists because those are not visible in salary list search view anymore.

Fields required in salary list object:

• name
• paymentPeriodStart
• paymentPeriodEnd
• accountingDate
• dueDate
• payday
• employeesDataForSalarySlip

Optional fields:

• earningsPeriodStart
• holidayYear
• earningsPeriodEnd

For employee data only employeeId is required, other values can be filled automatically.

Optional fields for employee data:

• calendarWorkdays
• absentDays
• pensionInsuranceContributionPercent
• unemploymentInsurancePercent
• accidentInsurancePercent
• groupLifeInsurancePercent
• healthCareInsurancePercent

For creating new salary list through API it's possible utilize also new salary period endpoints. These are used to fetch salary period details for salary list creation:

• GET /payrolls/salaryperiods - returns a list of basic information about salary period lists for a given holiday credit year (query parameter holidayCreditYear must be always provided). The endpoint requires at least read rights for salaries.
• GET /payrolls/salaryperiods/{id} - returns a list of salary periods for a given salary period list ID (path parameter {id} must be provided when fetching)

Other endpoints

• A new endpoint GET /payments/paymentevents with invoiceId as search parameter has been created
  • It is possible to search payment events for a batch of 200 invoiceIDs
• An existing endpoint GET /payments has a new search result
  • It is now possible to see paidAmount and paidCurrency in GET /payments response

Changes in version 25.05

Endpoints

Breaking changes

• A new validation has been introduced which affects the payment endpoints within Swedish environments:
  • Affected endpoints:
    • POST /payments
    • POST /payments/directbanktransfers
  • The validation checks whether payerBankAccount has SEK currency when using payment method Bankgiro SWEDISH_DOMESTIC_PAYMENT_BANKGIRO or Plusgiro SWEDISH_DOMESTIC_PAYMENT_PLUSGIRO.
  • If the validation fails, the following error code is returned by the endpoints: ONLY_PAYER_ACCOUNT_WITH_SEK_CURRENCY_IS_SUPPORTED_WITH_BANKGIRO_OR_PLUSGIRO_PAYMENT_METHOD.

New Payroll endpoint

As part of the Payroll API we are introducing new endpoint regarding salary slip

• GET /payrolls/salaryslips/{id} Returns salary slip for given salary slip ID with detailed information of:
  • Salary slip information (data varies depending on settings): id,employeeId, employeeName, status, paidStatusDetails, slipNumber, salaryBaseNote, incomesRegisterReportingSetting
  • If employee has holiday pay/working hour reduction settings on: workingTimeAllocation, holidaysWorkingTime, workingTimeInFirstMonth, workingTimeInSecondMonth, workingTimeType, averageDailyActualWorkday, actualWorkdaysInFirstYear, actualWorkdaysInSecondYear, workingHourReductionWorkingDays, workingDaysInFirstYear, workingDaysInSecondYear
  • Salary slip row details: id, salaryTypeCode, customName, quantity, unitValue,paymentPercent, recoveryDetails, id, netRecoveryTaxValue, paymentPeriodStart, paymentPeriodEnd, earningsPeriodStart, earningsPeriodEnd, payday, taxAtSourceValue
  • Car benefit details: id, carAgeGroup, benefitLimited, emissionValue, odometerReading
  • Other salary row details: baseSalaryRow, earningsPeriodStart, earningsPeriodEnd, showEarningPeriodInExport, unjustEnrichment, comment
  • Holiday row details: holidayCreditYear, holidayPayPercentage, holidayDaysSpent, holidayBonusCalculationBasis, correction
  • Working hour reduction row details: year, systemNoticication
  • Settings: noObligationExceptionTypes, notSubjectExceptionTypes, pensionVoluntarilyPaid, accountingDate, dueDate, salaryChannel, additionalInformation
  • Adjustments: payday, employment, startDate, endDate, type, terminationReason, registrationGroundId
  • Insurance details: pensionContractId, accidentInsurancePolicyId
  • Slip notes
  • Version
  • Unit, Total, Gross salary and Net salary, Basic information will not be returned, neither are Employer contribution details nor tax days, calendar workdays and absences

Changes to existing Payroll API endpoint results:

• GET /payrolls/salarylists/{id}
  • Workdays has been removed from the results
  • paidStatusDetails has been added to results
• GET /payrolls/salaryslips
  • paidStatusDetails has been added to results

Swedish support for Factoring contracts via API

• We have added new endpoints for the Swedish environments:
  • GET /se/factoringcontracts endpoint has been added for SE environments so that now it is possible to fetch factoring contracts from Procountor.
  • POST /se/factoringcontracts endpoint has been added for SE environments so that now it is possible to insert factoring contracts to Procountor.

Other endpoints:

• Updating dimension information on ledger receipts via API

  • It is now possible to update dimensions, dimension items and their values with the new endpoint:
    • PUT /ledgerreceipts/{receiptId}/transactions/{transactionId}/dimensions
  • The logic of necessary user rights follow Procountor UI functionalities. I.e. it is possible to modify dimension information even with the user rights limitation "Prevent editing of the accounting page" enabled.

• We have added a new a field to the result set of the endpoint GET /products?type=TRAVEL response body

  • The new field is bookkeepingAccount.
  • By using the renewed endpoint it is possible to also fetch the ledger account information that has been set for the travel product.

• Possibility to allocate and remove payment transactions on bank statement events with invoices via API

  • We have added new endpoints
    • PUT /bankstatements/{statementId}/events/{eventId}/invoices.
      • It is possible to allocate a payment transaction bank statement event to an invoice by using this endpoint.
    • DELETE /bankstatements/{statementId}/events/{eventId}/invoices.
      • It is also possible to remove an allocation between a payment transaction bank statement event and invoice by using this endpoint`.

• With endpoints POST /ledgerreceipts and PUT /ledgerreceipts/{receiptId} an error message was improved to be more descriptive.

  • Previously, when ledger account was not found, the endpoint returned ERROR_LEDGERACCOUNT_VATPERCENTAGE_COMBINATION error message. It was a wrong description.
  • Now the error code was changed to more descriptive ERROR_LEDGERACCOUNT_NOT_EXIST_OR_INACTIVE.
  • Validation now also checks if the ledger account is active or not.

• New parameters were added for Inventory Management with endpoints PUT /invoices/{invoiceId}/approve and PUT /invoices/{invoiceId}/unfinished

  • The endpoint PUT /invoices/{invoiceId}/approve has a new parameter updateInventory
    • If updateInventory is true and the user has necessary user rights for inventory and invoices, the inventory is updated accordingly
    • If the user doesn't have necessary user rights for inventory management No access to inventory management error message is returned
    • If the user doesn't have necessary user rights for handling the invoices, the flag is ignored and the inventory will not be updated
  • The endpoint PUT /invoices/{invoiceId}/unfinished works so, that if there are products in the inventory management related to the products on the invoice, the inventory management is automatically updated accordingly.

• It is now possible to use API for importing comments and messages to bank statement ledger receipts / accounting page transaction description field.

  • New field comment, which can be used to add comments to transaction description field by row, was introduced which is used in following endpoints:
    • PUT /referencepayments/{referencePaymentId}/metadata
    • PUT /bankstatements/{statementId}/events/{eventId}/metadata
  • In some cases banks are using the same transaction description field for their messages. On the UI, we trim the messages so that the maximum length of the transaction description is 255 characters. If the bank delivered message is 50 characters and rest of the message is 300 characters, we will show only 205 characters for the rest of the message (255-50=205).
  • The new field comment was also added for metadata (allocationMetadataRows) for reference payment and banks statements. It is now also supported with GET endpoints:
    • GET /bankstatements
    • GET /referencepayments

Changes in version 25.04

Endpoints

Breaking changes

• To align with our naming conventions and ensure consistency, these 2 SIE file endpoints have been renamed:
  • from GET /SIE/availability to GET /sie/availability
  • from GET /SIE/file to GET /sie/file
• When fetching default accounts of a supplier via GET /businesspartners/{id}/defaults/accounts endpoint, if the user doesn't have any access rights to PURCHASE_SUPPLIER_REGISTER, 403 Forbidden error is returned instead of 404 Not found error.
• When trying to set passive dimension item to a ledger receipt transaction with POST /ledgerreceipt or PUT /ledgerreceipts/{receiptid} endpoints, the error message has been improved and changed to be more descriptive.
  • The new error message is DIMENSION_ITEM_IS_PASSIVE_OR_DOES_NOT_EXIST_IN_DIMENSION
  • The former error message was DIMENSION_OR_DIMENSION_ITEM_IDENTIFIERS_DOES_NOT_MATCH_THOSE_STORED_IN_DATABASE

New Payroll endpoints

• As part of the Payroll API we are introducing new endpoints regarding salary list and salary slip

  • GET /payrolls/salarylists

    • Returns the list of salary lists with information: id, name, numbeOfSlips, statuses of the slips belonging to the list, PaymentPeriodStart, PaymentperiodEnd, created and createdby
    • It is possible to search salary lists by payment period start and end dates and by salary slip’s name
    • Pagination and sorting are supported.
    • Partial search is supported for name

  • GET /payrolls/salarylists/{id}

    • Returns salary list with given salary list id with information of salary list and salary slips included in the list. Returned information from the salary slips like: id, EmployeeName, PaymentPeriodStart, Payday, SlipNumber, status and so on
    • Only not invalidated slips will be returned along with the list
    • Versioning is supported

  • GET /payrolls/salaryslips

    • Returns the list of salary slips with information: id, EmployeeName, PaymentPeriodStart, Payday, SlipNumber, status, slipNotes, salaryChannel, sentStatus, reportStatus, salary, fringe Benefits, salaryForIns, deductionToTaxable, tax, taxableCompensation, taxFreeItems, otherDeductions, netPay and eSalaryStatus
    • We support salary slip search with: Payday end and star date, Employee name, Salary slip number and Salary slip statuses (new search criterion are not supported)
    • Pagination and sorting are supported
    • Partial search is supported for employee name

• New validations/functionality to existing Payroll API endpoints:

  • POST /payrolls/employees/salaryinfo and PUT /payrolls/employees/{id}/salaryinfo
    • No possibility to uncheck ‘non-resident taxpayer’ when salary base contains 2922 salary type in salary rows.
    • Salary base row with salary type 2922 can not be saved without ‘non-resident taxpayer’ configured in salary info.
    • API salary info endpoint has constraint, ‘non-resident taxpayer’ can not be switched off when salary base contains salary type 2922 rows.
  • PUT /payrolls/employees/{id}/salarybase
    • When user will call API endpoint PUT salarybase and new row which has related row (see RelatedSalaryRow and OvertimeSalaryRowFactory) is added then automatically related rows should be created and saved in salary base.
    • Salary types which have related rows available in salary base:
      • 2205 → related salary type 1016
      • 2411 → related salary type 1017
    • Overtime salary types:1230, 1231, 1232, 1233, 1234, 1235, 1236, 1237, 1238, 1239
    • Overtime related row:
      • if base salary type is hourly → 1220
      • for other base salary types → 1221
    • This new functionality fallows the same logic than UI in the software.

Changes with other endpoints

• We are introducing a new endpoint for fetching journal receipts of all statuses:

  • GET /journals
    • Supports query parameter statuses that accepts one or more statuses separated by comma
    • Supported statuses are Unfinished, Approved and Invalidated

• We have added optional support for JPEG/JPG images with endpoint GET /invoices/{invoiceId}/image

  • It is now possible to fetch invoice images also in JPEG/JPG format by using an optional query parameter format
  • If the query parameter format is not used, the invoice image is returned in PNG format by default

Improvements with the Easier Integration Activation Process

• We have added a new endpoint GET /integrations/{integrationId}/customers so that integrators can now check whether their customers are using the new easier API activation flow or not. User sending the request must belong to the company that contains "API Integrator tool", and the environment has to be the owner of the integration represented by integrationId, otherwise 403 is returned.
  • Endpoint returns list of companyId that are using the new integration flow and their integrationVersionStatus
  • Please note to migrate to the new integration activation process with an existing integration, you need to submit the form in https://dev.procountor.com/contact/request-migration-to-easier-api-activation/

Bug fixes

• A new logic has been implemented for the PUT /ledgerreceipts/{receiptId} endpoint. When updating a ledger receipt with a reconciliation row and setting the createReconciliation parameter to true (createReconciliation=true), the VAT type of the reconciliation row, if left empty, will now be inherited from the main ledger receipt's VAT type.
• When editing a reconciliation row for a ledger receipt by calling the PUT /ledgerreceipts/{receiptId}?createReconciliation=true endpoint, if the VAT type is left empty, reconciliation row will now automatically inherit the VAT type from the ledger receipt.

Changes in API documentation

In API documentation multipleOf information for penaltyPercent and discountPercent have been removed from the following endpoints:

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

Changes in version 25.03

Endpoints

Breaking changes

• Support for salary category EMPLOYER_PAYMENTS has been removed from GET /payrolls/salarytypes endpoint.
• GET /invoices/{invoiceId}/comments/taggableusers endpoint now checks if the user has rights to the given invoice AND if the invoice specific discussion setting is enabled or not (allowInvoiceSpecificDiscussion in GET /company/invoicecirculation/settings endpoint). If the validation fails, endpoint returns 403 error code instead of 200 successful response.

Introducing A New, Easier Integration Activation Process

• We are excited to announce the release of our new API activation process, designed to streamline and enhance the integration experience for both integrators and the integration users.
• For integrators, this new process offers a seamless way to create, manage, and share integration specifications. You can efficiently enroll new customers into your integrations and handle change management with ease.
• For customers, the new activation process is a game-changer. Integrations can now be activated through a simple self-service flow. By clicking on an “activation link”, specific to each integration, customers are guided through an automated activation process that requires no technical knowledge.
• At the end of a successful integration activation flow:
• A technical user, defined by the integrator in the integration specification, is added to the customer environment(s) with the user role of "API technical user"
• The API key is created for this technical user and shared with the integrator
• User rights for this technical user are set as defined in the integration specification in customer's environment(s)
• "Allow the usage of invoiceable API clients" setting is enabled in customer's environment(s) in Management > Company info > Usage settings
• A confirmation email is sent to the user who initiated the integration activation(s)
• This new activation process will replace the current manual method of setting up integrations, becoming the default method moving forward. Please note that this process is supported only for M2M authentication.
• Additionally, existing integrations can be transitioned to this new process. To start with the migration, please submit this form.
• For more information and detailed instructions please check
  • Creating an integration specification - for integrators
  • Activating Integrations in Procountor - for customers

New Integrations endpoints in Version 25.03

• The following new endpoints are related to the new integration activation flow mentioned above.
• GET /integrations/{requestId}
  • Returns information on companies looking to activate the integration for the specified requestId, which is appended in the "Integration callback URL" during the new integration activation flow.
  • User sending the request must belong to the company that contains API Integrator tool.
  • requestId must be valid. If it has expired, 410 error is returned.
  • It's possible to activate integration for multiple companies using the same requestId.
  • Information returned in extraInfo depends on the fields marked as required for user consent in the integration specification.
• PUT /integrations/{requestId}
  • To approve and/or reject integration activation request.
  • User sending the request must belong to the company that contains the API Integrator tool.
  • Request parameter requestId must be valid. If it has expired, 410 error is returned.
  • The number of companyId in request body in approve and reject combined must match the number of companyId returned in GET /integrations/{requestId} response in companiesToIntegrate. Otherwise, 400 is returned.
  • If the request is successful, a technical user with the "API technical user" role is added to all the approved companies, and an API key for the technical user is generated and returned. If the technical user already belongs to the approved environment (e.g. it has been added manually), its existing API key is returned.

New Payroll Endpoints in Version 25.03

• As part of the Payroll API, we are introducing new endpoints for employees’ salary base:
• GET /payrolls/employees/{id}/salarybase
  • Endpoint for fetching the salary base of the specified employee.
  • Salary base should always have at least one salary row in rows. Some base rows are created automatically and others can be added. Each salary base row consists of id, salaryTypeCode, customName, quantity,unitValue,paymentPercent,recoveryDetails,carBenefitDetails,baseSalaryRow.
  • Apart from the salary base row, it also returns id, employeeId, notes, version.
• PUT /payrolls/employees/{id}/salarybase
  • Endpoint for updating the salary base for the specified employee.
  • notes and salary base row information can be updated.

Changes to other endpoints in version 25.03

• If the due date of the e-invoice is in the past or the current day, API returns error code 400 in these endpoints: POST /invoices, PUT /invoices/{invoiceId}, PUT /invoices/{invoiceId}/send
• In the following endpoints, if the electronic invoice operator ID is same as electronic invoice address or EDI ID, API returns 400, unless they are same in Tieke register. In the latter case, error code isn't returned.
  • POST /invoices
  • PUT /invoices/{invoiceId}
  • POST /businesspartners
  • PUT /businesspartners/{id}
  • PATCH /businesspartners/{id}

Changes in version 25.02

Endpoints

Breaking changes

• preventPayeeInformationChange field has been removed from GET /company/invoicecirculation/settings endpoint as this setting is no longer supported in UI.

Changes to other endpoints

• Bug fix: During high load, trying to fetch a specific sales or purchase invoice by calling GET /invoices/{invoiceId} resulted in UNABLE_TO_GET_CONNECTION error. This has been fixed now.
• We have made performance improvements to GET /invoices endpoint endpoint. You can now expect faster response times.

Changes in version 25.01

Endpoints

Breaking changes

• Since EDI (OVT) identifier is supported only in Finnish environments, from now on POST /invoices will return error OVT_NOT_ALLOWED instead of INVALID_OVT when counterparty.einvoiceAddress.ediId is sent for environments other than Finnish.

New Payroll endpoints

• As part of the Payroll API we are introducing new delete endpoints for employee’s employment details in salary info:
  • DELETE /payrolls/employees/{id}/salaryinfo/employments/{employmentId}
    • Deletes employee’s employment.
    • Salary base is automatically recreated after deletion.
    • To delete employment, full payroll user rights is required and employment id must be valid.
    • Employment must belong to employee with employee id id.
  • DELETE /payrolls/employees/{id}/salaryinfo/taxCards/{taxCardId}
    • Deletes employee’s tax card.
    • Salary base is automatically recreated after deletion.
    • To delete taxcard, full payroll user rights is required and tax card id must be valid.
    • Tax card must belong to employee with employee id id.
  • DELETE /payrolls/employees/{id}/salaryinfo/laborUnionMemberships/{laborUnionMembershipId}
    • Deletes employee’s labor union membership.
    • Salary base is automatically recreated after deletion.
    • To delete labor union membership, full payroll user rights is required and labor union membership id must be valid.
    • Labor union membership must belong to employee with employee id id.

Changes to other endpoints

• Bug fix: When the email communications setting - “Notifications if I have been mentioned in a discussion” was enabled in Procountor UI Basics > Personal info and settings, API returned 400 when attempting to tag a user in a comment via POST /invoices/{invoiceId}/comments endpoint in invoices that didn’t have ledger receipt. This has now been fixed.

Changes in version 24.12

Endpoints

Breaking changes

• When fetching dimensions, if user doesn't have viewing or all rights to "Basic accounting info", GET /dimensions endpoint returns 403 error code instead of 200.
• When fetching details of a specific dimension, if user doesn't have viewing or all rights to "Basic accounting info", GET /dimensions/{dimensionId} endpoint returns 403 error code instead of 200.

New Payroll endpoints

• As a part of the Payroll API, we are introducing following new endpoints for employee's employment details in salary info:
  • GET /payrolls/employees/{id}/salaryinfo and PUT /payrolls/employees/{id}/salaryinfo
    • Endpoints for fetching and updating the salary info for the specified employee.
    • GET returns and PUT updates the salary info data under incomeConfiguration, insurancesConfiguration and internationalSituationsConfiguration.
    • Employment, tax card and labor union have their own endpoints.
    • PUT automatically updates the salary base for the employee based on salary info data.
  • POST /payrolls/employees/salaryinfo
    • Creates a new employee salary info and returns it.
    • Also creates automatically salary base for employee based on salary info data under incomeConfiguration, insurancesConfiguration and internationalSituationsConfiguration.
    • To be able to create a new employee with POST /payrolls/employees/salaryinfo, first create person with POST /persons.
  • GET /payrolls/employees/{id}/salaryinfo/employments and POST /payrolls/employees/{id}/salaryinfo/employments
    • Endpoints for fetching and creating employment details for the specified employee.
    • POST creates and GET returns the following employment data: id, keva, startDate, endDate, type, terminationReason, registrationGroundId and version.
  • GET /payrolls/employees/{id}/salaryinfo/employments/{employmentId} and PUT /payrolls/employees/{id}/salaryinfo/employments/{employmentId}
    • Endpoints for fetching and updating the specified employment details for the specified employee.
    • GET returns and PUT updates the following employment data: id, keva, startDate, endDate, type, terminationReason, registrationGroundId and version.
  • GET /payrolls/employees/{id}/salaryinfo/taxcards and POST /payrolls/employees/{id}/salaryinfo/taxcards
    • Endpoints for fetching and creating the tax card details for the specified employee.
    • POST creates and GET returns the following tax card data: id, type, revised, validFrom, basePercent additionalPercent, annualIncomeLimit, limitUsed, comments, created and version.
    • Only ONE_INCOME_LIMIT and TAX_AT_SOURCE types are supported.
    • POST automatically recreates salary base for the employee.
  • GET /payrolls/employees/{id}/salaryinfo/taxcards/{taxCardId} and PUT /payrolls/employees/{id}/salaryinfo/taxcards/{taxCardId}
    • Endpoints for fetching and updating the specified tax card details for the specified employee.
    • GET returns and PUT updates the following tax card data: id, type, revised, validFrom, basePercent additionalPercent, annualIncomeLimit, limitUsed, comments, created and version.
    • Only ONE_INCOME_LIMIT and TAX_AT_SOURCE types are supported.
    • PUT automatically recreates salary base for the employee.
  • GET /payrolls/employees/{id}/salaryinfo/laborunionmemberships and POST /payrolls/employees/{id}/salaryinfo/laborunionmemberships
    • Endpoints for fetching and creating the labor union details for the specified employee.
    • GET returns and POST creates following the labor union data: id, laborUnionSettingId, department, membershipId membershipStart, membershipEnd, explanation and version.
  • GET /payrolls/employees/{id}/salaryinfo/laborunionmemberships/{laborUnionMembershipId} and PUT /payrolls/employees/{id}/salaryinfo/laborunionmemberships/{laborUnionMembershipId}
    • Endpoints for fetching and updating the specified labor union details for the specified employee.
    • GET returns and PUT updates the following labor union data: id, laborUnionSettingId, department, membershipId membershipStart, membershipEnd, explanation and version.

Changes to other endpoints

• Bug fix: When payment based accounting is used and vatStatus wasn't provided during the invoice creation, GET /invoices/{invoiceId} endpoint will now return vatStatus from the ledger receipt. Earlier in such case vatStatus was returned.
• In POST /businesspartners, GET /businesspartners/{id} and PUT /businesspartners/{id} endpoints, we have added these new optional fields under invoicingInfo: buyerReferenceIdentifier, sellerReferenceIdentifier, orderReference, orderNumber, agreementNumber, accountingCode, deliverySite, tenderReference. These fields are supported only in Finnish environments.

Changes in version 24.11

Endpoints

Breaking changes

• PUT /dimensions has been removed. Please use PUT /dimensions/{dimensionId} instead, as communicated earlier.

• When fetching attachments, GET /attachments endpoint returns 403 error instead of 200 OK response with empty list, in the following situations:

  • When special right is missing
  • There is no attachment to return because of insufficient user right
  • User doesn't have the necessary right to any of the types given in the request parameter

• To fetch list of supported delivery terms, GET /company/deliveryterms endpoint requires all rights to sales or purchase invoices. If the required right is missing, endpoint returns 403 error instead of 200 OK response.

• When fetching sales or purchase products, if the required rights are missing, GET /products endpoint returns 403 error instead of 200 OK response with empty list. Note, to fetch travel products, type parameter must be given and it doesn't require user rights.

** New SIE endpoints**

• Following new SIE endpoints are supported only in Swedish environments:
  • GET /SIE/availability
    • New endpoint that returns possible date options (lastValidEndDate and list of accounting period start dates in accountingPeriodStart) for exporting a SIE-file through the API.
  • GET /SIE/file
    • The endpoint requires two parameters: accountingPeriodStart and exportEndDate. The accountingPeriodStart defines the starting point for comparison years (RAR -1 and RAR -2 etc.) and needs to match the start date of the existing financial years. The exportEndDate determines the end of export time period and all transactions for that financial year are included in the file.

** New Payroll endpoints**

• As a part of the Payroll API, we are introducing a new endpoint for salary types.
  • GET /payrolls/salarytypes
    • Returns the list of salary types with basic information: name, code, category, unit, unitValue, paymentPercent, affectsHealthInsurance, affectsPensionInsurance affectsUnemploymentInsurance, affectsAccidentAndGroupLifeInsurance, incomeType and incomeTypeCode.
    • It is possible to filter salary types by the following parameters: name, code category incomeType and incomeTypeCode.
    • Pagination and sorting by salary type code are supported.
    • Partial search is supported for name and incomeType.
    • Endpoint also returns translations for the salary type name.

** Other endpoints**

• If Ropo Capital has been selected as the debt collection partner, then collectionPartner in GET /company/expenses/collectionpenal/settings endpoint returns "ROPO" instead of "TRUST".
• If Kravia has been selected as the debt collection partner, then collectionPartner in GET /company/expenses/collectionpenal/settings endpoint returns "KRAVIA" in both Finnish and Swedish environments.

Changes in version 24.10

Endpoints

Breaking changes

• The temporary GET /users/rights/old endpoint, which was created to give extra time to adjust to the changes made in GET /users/rights that returned new schema for rights, will be removed as previously communicated. To see how the fields in the new schema map to the old ones, please refer to Release notes from API version 24.07
• For security reasons, GET /webhooks endpoint will no longer return sharedSecret in authenticationMeta when HMAC authentication type is used.
• In GET /ledgerreceipts, when filtering ledger receipts by types BANK_STATEMENT_AS_RECEIPT or REFERENCE_PAYMENT, endpoint will now return 403 error instead of 200, if the user right to Payments > Bank statements and reference payments is missing.
• In GET /ledgerreceipts/{receiptId}, when fetching specific ledger receipt where receiptId is either BANK_STATEMENT_AS_RECEIPT or REFERENCE_PAYMENT, endpoint will now return 403 error instead of 200, if the user right to Payments > Bank statements and reference payments is missing.
• Since Procountor is exiting Denmark in the end of 2024, Danish Sales invoices cannot be set as to be Sent from the PUT /invoices/{invoiceId}/send endpoint anymore, if the invoice date is after 31.12.2024. API will return 400 error instead.

New Payroll endpoints

• As a part of the Payroll API, we are introducing new endpoints related to employees in the Employee register, salaries basic information and labor union settings.
  • GET /payrolls/employees
    • New endpoint to fetch the list of employees with basic information: id, lastName, firstName, ssn, employeeAddress, salaryChannel, automatedTaxCard and information if the employee is active.
    • It is possible to filter employees by the following query parameters:
      • name, ssn - supported in header
      • personNumber, personGroupId, includeInactive and salaryChannel - supported in url
    • Partial search is supported for name, ssn and personNumber.
    • Pagination and sorting by id are also supported.
  • GET /payrolls/salariesbasicinfo
    • New endpoint to fetch salaries basic information: yearlyFigures, workHours, incomesRegisterConfiguration, pensionContracts, accidentInsurancePolicies.
  • GET /payrolls/laborunionsettings
    • New endpoint to fetch the list of labor union settings with id and name.

Automatic handling of collection fees and penal expenses

• In this version we have added support for automatic handling of collection fees and penal expenses on sales invoice. For these following endpoints have been modified. As this feature is already supported in Procountor UI, for more information please check Procountor manual.
  • PUT /invoices/{invoiceId}/paymentevents/markpaid
    • It now supports request parameter addPenalExpense. When marking the overdue sales invoice as paid, if you want to automatically include a penal expense in the business partner's next sales invoice, then call the endpoint with addPenalExpense=true. Default is false, so penal expense is not added automatically.
    • Automatic handling of collection and penal costs setting must be enabled prior to this. This setting can be checked from GET /company/expenses/collectionpenal/settings. In Procountor UI, it is found under Management > Company info > Debt collection settings.
  • DELETE /invoices/{invoiceId}/paymentevents/{paymentEvent}
    • This endpoint will also remove uncollected penal expenses when removing overdue sales invoice's payment transaction, which was earlier marked as paid. The deletion of uncollected penal expenses will only occur after the user approves the action via 2-factor authentication.
  • POST /invoices
    • It now supports request parameter addCollectionPenalCosts when creating a new sales invoice to a business partner. Use addCollectionPenalCosts=true if you want to automatically add collection fees and penal expenses to the new sales invoice for the business partner who had paid the invoice late and to whom the payment reminders were sent. Default is false, so these costs aren't added automatically.
    • Note, if the invoice was paid late but payment reminders weren't sent to the business partner -> only penal expense will be added, or if the invoice wasn't paid late but payment reminders were sent -> only collection fee will be added.
    • These fees are added only if
      • Automatic handling of collection and penal costs setting is enabled
      • For adding collection fees, collection costs product is defined
      • And for adding penal expenses, penal expense product is defined
    • These settings can be checked from GET /company/expenses/collectionpenal/settings. In Procountor UI it is found under Management > Company info > Debt collection settings.

Other endpoints

• In POST /businesspartners, GET /businesspartners/{id}, PUT /businesspartners/{id}, PATCH /businesspartners/{id} endpoints, there is now a new field called denyEInvoiceReminders in the paymentInfo value. This value doesn't affect anything yet, but it will deny the sending of payment reminders to the given business partner as e-invoice or email in Finland, if a related setting from the Debt collection settings on the Procountor UI is on. The Debt collection setting on the Procountor UI will be released later, and the new field will start affecting from that point onwards.
• We are introducing a new endpoint, GET /company/einvoiceaddresses, to fetch company's electronic invoice addresses. These addresses can be found in Procountor UI under Management > Company info > E-invoice and Scanning addresses.
• Bug fix: When ledger receipt is updated via PUT /ledgerreceipts/{receiptId}, invoice version will no longer be updated. This occurred previously, when the ledger receipt was updated for the first time.
• Bug fix: In POST /invoices and PUT /invoices/{invoiceId} endpoints, counterpart.contactPersonName will again accept maximum 70 characters instead of 28.

Updated API Developers Portal

• Under Getting started, you can find carousel of reference companies that already use Procountor.

Changes in version 24.09

Endpoints

• As part of the Payroll API we are introducing new endpoints regarding Person’s default dimensions:
  • GET /persons/{id}/defaults/dimensions
    • Fetches the basic information on default dimensions and their items for a particular person.
  • GET /persons/{id}/defaults/dimensions/{dimensionId}
    • Fetches the detailed information on default dimensions items for a particular person.
  • PUT /persons/{id}/defaults/dimensions/{dimensionId}
    • Updates the dimension items percents for a particular person. The number of items in a dimension is unlimited but the total percent must equal to 100.Since only percent can be updated, new endpoint GET /persons/{id}/defaults/dimensions/{dimensionId} can be called first to fetch the item's other details.
  • GET /persons/{id}/defaults/products
    • Fetches the default products for a particular person.
• In POST /payments endpoint a new restriction has been added for Danish environments: payments cannot be made after 31.12.2024. If the payment date is on 1.1.2025 or later, status code 400 is returned with the error PAYMENT_DATE_IS_AFTER_ENDING_SUPPORT_FOR_DANISH_ENVIRONMENTS
• In GET /invoices/{invoiceId}/comments endpoint inactive users are no longer listed as tagged users under taggedUsersInfo.
• PUT /invoices/{invoiceId}/comments/{commentId}/{userTagId}/read endpoint has been renamed to PUT /invoices/{invoiceId}/comments/{commentId}/read so that user who is tagged multiple times in the same comment can mark the comment as read in the single request. Additionally, from now on only the tagged user is able to mark the comment as read. Otherwise, API sends 400 error.
• In GET /dimensions endpoint dimensions can now be filtered by name and codeName. Also partial search is supported. Filtering result is returned in an array.
• In GET /invoices/{invoiceId} endpoint invoice row with null quantity is no longer returned in invoiceRows.

Changes in version 24.08

Endpoints

Endpoints for new resource Persons

• We are introducing new endpoints for Persons resource for adding, editing and fetching person information from the Person register. In the future, we will be deprecating Persons from the Business Partners. This will be informed later well ahead of the change.
• Person's id is same as business partner's partnerId for type PERSON.
• New endpoints for Person:
  • GET /persons
    • Returns the list of persons with basic information: id, lastName, firstName, jobTitle, deliveryAddress, invoicingInfo, registryInfo.
    • It is possible to filter persons by the following parameters:
      • name and identifier in header.
      • personNumber, mainPersonGroup, personGroupId and includeInactive in url.
    • Also pagination and sorting by id are supported.
    • Partial search is supported for name, identifier and personNumber.
  • GET /persons/{id}
    • Returns person's detailed information.
    • To get more information on Person group, please use GET /businesspartners/groups/{id}.
  • POST /persons
    • New endpoint to add a new person to the Person register.
    • Note in Swedish environments, personNumber is required.
  • PUT /persons/{id}
    • New endpoint to modify details of an existing person in the Person register.
    • Note if the person is already in Employee register,
      • identifier and identifierType can't be updated
      • if salary channel is e-salary, accountNumber must support e-salary
      • accountNumber can be changed but it can't be removed
      • Otherwise, in the above 3 cases, API sends 400 error

Endpoints related to invoice comments

• We have added a new endpoint GET /invoices/{invoiceId}/comments/{commentId} to get more detailed information about the tagged users in the comment.
  • In case a comment does not contain any tagged user, the response will not include the taggedUsers array.
  • The read property within the taggedUsers array indicates the timestamp when the comment was read.
  • If a tagged user has not read the comment, the read property will not be included in the response for that user.
• We have added a new endpoint PUT /invoices/{invoiceId}/comments/{commentId}/{userTagId}/read to indicate that the tagged user has read the specified comment.
  If the comment has been marked as read for the tagged user already, API sends 400 error response when the same request is sent next time.
• We have added taggedUsersInfo optional object in existing endpoint GET /invoices/{invoiceId}/comments to fetch information about the tagged users.
  • taggedUsersInfo contains numTaggedUsers and readByAllTaggedUsers fields.
  • taggedUsersInfo is returned only if the comment has at least 1 tagged user.
  • Comments can be also filtered by optional query parameter readByAllTaggedUsers. Only those comments that have been read by all tagged users are returned. Comments without tagged users aren't returned.

Endpoints related to Dimensions

• We have added a new endpoint PUT /dimensions/{dimensionId} to update specific dimension's name. PUT /dimensions, which is currently used for this will be removed in future. This will be communicated later in advance.

Other endpoints

• Earlier when user had "No access" right to Sales or Purchases Product register, API returned 500 error when trying to add a new bank account via POST /bankaccounts. This has now been fixed and error isn't returned anymore.

Updates in API developers documentation

• Validation Error Codes page has been simplified. Model and Name columns have been removed from the table. Error description is now easier to find.

Changes in version 24.07

Endpoints

• From this version onwards GET /users/rights endpoint will return a new schema aligned with Procountor UI (Management > Users and user rights) for the rights property. This change is applicable only to the latest API version. The GET /users/rights/old endpoint released in Procountor version 89 (June 2024) will continue to return the old schema until version 93 (October 2024). At this point, the endpoint will be removed.
  • Even though the endpoint will return a new schema, underlying rights will not change. For example, earlier if a user had no rights to accounting reports, this will remain the same also after the change.
  • All the properties under rights that accept String will accept one of these enum values NO_ACCESS, VIEWING_RIGHTS, ALL_RIGHTS, NOT_ENABLED. Please note NO_RIGHTS has been replaced by NO_ACCESS.
  • In the following table you can see how the fields in the new schema are mapped to the old one (currently returned by the GET /users/rights/old endpoint):

• In GET /invoices and GET /invoices/{invoiceId} endpoints we have now added an optional field invoiceSumInfo to return invoice's total sum. This is supported for all receipt types except PERIODIC_TAX_RETURN, which doesn't support invoice rows. To get additional information on excludingVatTotal and vatSumTotal, please use GET /invoices/{invoiceId} endpoint.
  
  If the invoice has currency other than the one set for the environment (when field inAccountingCurrency is false), it returns sum in both the accounting and invoice currency.

Updated API reference documentation

• Documentation for GET /invoices/personalapprovals and GET /invoices/personalverifications endpoints now correctly specifies that the types field is required (not type), and that it accepts multiple receipt types separated by a comma. Available values for types include PURCHASE_INVOICE, TRAVEL_INVOICE, and BILL_OF_CHARGES.
• Unnecessary mandatory fields uriParams and/or uriInfo have been removed from several endpoints, which were added lately. NOTE only documentation was incorrect.
  • GET /attachments
  • GET /payments/directsalarypayments
  • GET /bankaccounts
  • GET /products/{productId}
  • GET /bankstatements
  • GET /referencepayments
  • GET /currencies/exchangerate
  • GET /webhooks
  • GET /factoringcontracts
  • GET /products
  • GET /invoices
  • GET /products/groups
  • GET /ledgerreceipts
  • GET /payments/errormessages
  • GET /payments
• Some enum values were listed incorrectly lately – they either had Finnish translations or had duplicates or didn’t list the enum values. They have been corrected. NOTE only documentation was incorrect.
  • GET /products/{productId}
  • POST /products
  • PUT /products/{productId}
  • GET /company
  • GET /businesspartners/personaldetails
  • POST /payments/directbanktransfers
  • GET /payments
  • POST /payments
  • GET /payments/errormessages
  • GET /payments/{paymentId}
  • GET /users
• In Examples page, extra information has been added in Calculating invoice sum section (this was removed in version 25.03).

Changes in version 24.06

Endpoints

• From now on during error situations, following endpoints will no longer include the model field in their error responses. Instead, the field will provide the full JSON path to the invalid value.
  • POST /payments for invoice payment
  • POST /payments/directsalarypayments for direct salary payment
  • POST /payments/directbanktransfers for direct bank transfer

We have added a new endpoint GET /users/rights/old that will continue to return the old schema (similar to the current behavior of GET /users/rights). This endpoint will be available for three months until Procountor release version 93 (October 2024). This grace period allows integrators to adapt their systems and migrate to the new schema that will be returned by GET /users/rights in Procountor release version 90 (July 2024). Please check "Upcoming API breaking changes" section above.

If you do not have time to adjust to the breaking change that will be releaed in July, you can use this new endpoint GET /users/rights/old until it is removed in Procountor release version 93.

Updated API reference documentation

• In API reference documentation version is no longer mentioned as required for POST /invoices endpoint. Please note that version is still required for PUT /invoices/{invoiceId} endpoint.
• At the top of the API reference page, there is a new section on "Batch endpoints". This is only a reminder to the batch endpoints we already support.
• At the end of the API reference page, Schemas are now sorted in alphabetical order A -> Z.

Older release notes

Older release notes can be found from their own page.

Old release notes