Old Release Notes

Old Release Notes

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

Current release notes

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.

Changes in version 24.05

Endpoints

• base_url and documentationfields from GET /status have been removed from all API versions.
• We have added a new field procountorVersion that returns Procountor version in use in GET /status endpoint. e.g. "88.0.0".
• GET /invoices/{invoiceId}, PUT /invoices/{invoiceId} and POST /invoices endpoints now support PURCHASE_ORDER in counterparty.email . Support has been added in all API versions.
• POST/reports/generalledger/{id} now returns the proper response with default vatStatus when VAT status is empty. It no longer returns the 400 error.
• Fixes to required user rights
  • To fetch invoices waiting for personal approvals via GET /invoices/personalapprovals endpoint, logged in user must have "All rights" to Approval in “Invoice circulation” in Management > Users and user rights. If not, API sends empty list in response.
  • To fetch invoices waiting for personal verifications via GET /invoices/personalverifications endpoint, logged in user must have "All rights" to Verification in “Invoice circulation” in Management > Users and user rights. If not, API sends empty list in response.
  • Even if the "Prevent creating new invoices and editing invoices page" limitation is in use in Management > Users and user rights, it's now possible to
    • Approve the invoice via PUT /invoices/{invoiceId}/approve, and
    • Mark invoice as paid via PUT /invoices/{invoiceId}/paymentevents/markpaid.
    • However, please note that adding or editing invoices is still not possible using the POST /invoices or PUT /invoices/{invoiceId} endpoints, respectively.

Updates in API reference documentation

• We have updated our API reference documentation by replacing the references to EXPENSE_INVOICE with BILL_OF_CHARGES.
• In addition, the address field now correctly maps to the appropriate model and includes its own description in the following endpoints:

Changes in version 24.04

Endpoints

• We have added a new endpoint GET /invoices/personalverifications to fetch invoice ids waiting for verification from the currently logged in user, including those invoices where the user has been assigned as a substitute. Details of the returned invoice can be fetched from GET /invoices/{invoiceId}. This endpoint returns empty list
  • If the user doesn’t have any invoice to verify
  • Invoice circulation is disabled for all the supported invoice types (useForPurchaseInvoices and useForTravelAndExpenseInvoices are false in GET /company/invoicecirculation/settings)
  • If the user doesn't have "All rights" to verify (verification in PurchasesRights in GET users/rights)

This endpoint supports required query parameter types, which accepts more than one type, separated by comma. Available values are PURCHASE_INVOICE,TRAVEL_INVOICE, BILL_OF_CHARGES. If the user doesn’t have required permission to the given invoice types, 403 error is returned.

• We have also added a new endpoint GET /invoices/personalapprovals to fetch invoice ids waiting for approval from the currently logged in user, including those invoices where the user has been assigned as a substitute. Details of the returned invoice can be fetched from GET /invoices/{invoiceId}. This endpoint returns empty list
  • If the user doesn’t have any invoice to approve
  • Invoice circulation is disabled for all the supported invoice types (useForPurchaseInvoices and useForTravelAndExpenseInvoices are false in GET /company/invoicecirculation/settings)
  • If the user doesn't have "All rights" to approve (approval in PaymentTransactionsRights in GET users/rights)

This endpoint supports required query parameter types, which accepts more than one type, separated by comma. Available values are PURCHASE_INVOICE,TRAVEL_INVOICE, BILL_OF_CHARGES. If the user doesn’t have required permission to the given invoice types, 403 error is returned.

Others

• API reference documentation has been updated
  • Endpoints that support batch requests, their ID parameter is now of type string and format multi
  • Endpoints that accept integer parameters, format of those parameters have been changed from int64 to int32

This has been fixed for all API versions.

Changes in version 24.03

Endpoints

• From now onwards following endpoints check whether usage settings (in Procountor UI: Management > Company info > Usage settings) to use cash discount is in use or not. If cash discount is not in use, API returns 400 error code when request is sent with cashDiscount. This affects all API versions.

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

• GET/businesspartners/{id} and GET/invoices/{id} endpoints from now onwards do not return cashDiscount in BusinessPartnerPaymentInfo and PaymentInfo object respectively, when there is no cash discount or cash discount is not in use (in Usage settings). This affects all API versions.

• In Swedish and Danish environments, GET /ledgerreceipts and GET /ledgerreceipts/{receiptId} endpoints now return optional serialNumber, if it exists. SerialNumber object consists of series and number.

Others

API Developers portal has been updated with own links for Sweden (e.g. Swedish Procountor API Terms of Use, General use and customer agreement terms, Partner program for Swedish software companies, Support and consultancy, Procountor customer service).

Changes in version 24.02

Endpoints

• To ensure that only the latest invoice is updated and there are no multiple accounting pages for the same invoice, it is now mandatory to send the latest invoice version in version when calling PUT /invoices/{invoiceId} endpoint. Use GET /invoices or GET /invoices/{invoiceId} to obtain the latest invoice version. When trying to update invoice with an older invoice version, API now returns error code 400 with proper error message. Note this change applies only to the latest API version.
  

No new API release in January, 2024

Changes in version 23.12

Endpoints

• From GET /businesspartners/personaldetails endpoint, following fields in BusinessPartnerPaymentDetails have been removed as they do not belong to a Person in Person register:

  • cashDiscountDays
  • cashDiscountPercentage

• Documentation for query parameter originalInvoiceNumber in GET /invoices endpoint has been changed from integer to string in all API versions. Note, API request was already accepting string.

• POST /invoices, PUT /invoices/{invoiceId} and GET /invoices/{invoiceId} endpoints now support 1 - 3 cash discount options in CashDiscountOption. When sending more than 1 cash discount option in POST /invoices or PUT /invoices/{invoiceId} endpoint:

  • numberOfDays and discountPercentage must be unique
  • Smaller numberOfDays must have bigger discountPercentage
  • discountPercentage must be less than 100

  Otherwise in the above cases, API returns 400 error response.

  Provided cash discount options are saved in ascending order by numberOfDays.

• POST /businesspartners, PUT /businesspartners/{id}, PATCH /businesspartners/{id} and GET /businesspartners/{id} endpoints now support 1 - 3 cash discount options in CashDiscountOption. When sending more than 1 cash discount option in POST /businesspartners, PUT /businesspartners/{id} or PATCH /businesspartners/{id} endpoint:

  • numberOfDays and discountPercentage must be unique
  • Smaller numberOfDays must have bigger discountPercentage
  • discountPercentage must be less than 100

  Otherwise in the above cases, API returns 400 error response.

  Provided cash discount options are saved in ascending order by numberOfDays.

• GET /businesspartners/personaldetails endpoint now returns currently logged in user's invoicing information from Person register in the newly added object BasicInvoicingInfo, which contains customerNumber, identifierType and identifier. If the values for these fields are missing, empty invoicingInfo is returned.

• From now on PUT /invoices/{invoiceId}/verify and PUT /invoices/{invoiceId}/approve endpoints will validate VAT status / VAT% combination when verifying or approving invoices. If the invoice row has VAT% other than 0%, VAT status must be 'Domestic'. If this validation fails, API sends 400 error and invoice status isn't changed.

Changes in version 23.11

Endpoints

• Following new optional fields have been added to cashDiscount in paymentInfo used in Invoice endpoints: GET /invoices/{invoiceId}, POST /invoices, PUT /invoices/{invoiceId}, and Business partners endpoints: GET /businesspartners/{id}, POST /businesspartners, PUT /businesspartners/{id}, PATCH /businesspartners/{id}

  • optionList that contains numberOfDays and discountPercentage
  • cashDiscountsTermType that indicates the start point for payment due date calculation and can be either FROM_INV_DATE or FROM_END_OF_MONTH. FROM_INV_DATE is default for all countries. FROM_END_OF_MONTH can be used only in Denmark.

    Still maximum 1 cash discount option is supported. Any additional cash discount options sent in POST /invoices, PUT /invoices/{invoiceId}, POST /businesspartners, PUT /businesspartners/{id} or PATCH /businesspartners/{id} request will be ignored.

• We have added a new validation rule when setting business partner group to inactive in PUT /businesspartners/groups/{id}. If a business partner group has been set as the Maksuvahti automated invoice sending exclusion group, that group cannot be set to inactive. If that is attempted, 400 error response is returned with descriptive error message. You should remove the group from Maksuvahti's "Prevent automatic transferring" setting in Procountor UI Management > Company info > Debt collection settings, to be able to set the business partner group inactive again.

• GET /businesspartners/groups now supports filtering by type. Supported types are CUSTOMER, SUPPLIER and PERSON. For other type, API returns 400 error response.

Changes in version 23.10

Endpoints

• In Swedish and Danish environments, receipts are now automatically assigned a new serial number when financial year is closed. This is to ensure an unbroken receipt series and prevent invalidation after year is closed.

  • Purchase invoice, sales invoice, expense claim, travel invoice and journal with a serial number can not be invalidated anymore with PUT /invoices/{invoiceId}/invalidate request. Otherwise, 400 error response is returned.
  • Journal with a serial number can not be invalidated anymore with PUT /ledgerreceipts/{receiptId}/invalidate request. Otherwise, 400 error response is returned.
  • Journal with a serial number can not change its status to Unfinished through PUT /ledgerreceipts/{receiptId}/unfinished request. Otherwise, 400 error response is returned.

• We have added a new optional field receiptNumber that returns number of the ledger receipt in GET /ledgerreceipts endpoint.

• From now on, API sends 403 error response when trying to delete payment event in MARKED_PAID status that was created by credit invoice allocation via DELETE /invoices/{invoiceId}/paymentevents/{paymentEventId} endpoint.
• Bug in PUT /invoices/{invoiceId}/sendToCirculation that sent INVALID_BIC error when trying to approve Swedish purchase e-invoice, where the payment method was Bankgiro or Plusgiro has been fixed.

Others

• Link to Privacy policy has been added to API login page. This has been implemented for all API versions.
• Earlier in API login page, when trying to navigate back from “Company select” view, previous API UI login page was not displayed. This has now been fixed.
• Examples of curl request for sending sensitive information has been added to API authentication and M2M authentication pages in API documentation.

Changes in version 23.09

Endpoints

• To increase security, from now onwards request sent with URL parameters during API and M2M authentication in the following endpoints will receive HTTP 403 error code. This affects all API versions. But if you are already sending request parameters in body and not as params in URL - no change is required on your side.

  • /api/oauth/token
  • /api/oauth/key

• We have added a new endpoint GET /invoice/{invoiceId}/image to fetch invoice image as PNG, one page at a time.

• GET /products endpoint now supports filtering by product name, including part of product name.
• In GET /businesspartners endpoint, it is now possible to filter business partners by part of partner name. Earlier, name header parameter supported only full match.

Changes in version 23.08

Endpoints

• Following query parameters will no longer be supported. This change will affect all API versions. Those sensitive data need to be provided instead in their respective HTTP request headers.
  • username in GET /attachments
  • accountNumber in GET /bankstatements
  • name and identifier in GET /businesspartners
  • accountNumber in GET /referencepayments

Changes in version 23.06

Endpoints

• In following endpoints, sensitive data can now be sent in HTTP header, which is the preferred way. This is supported in all API versions. Please note from Procountor release version 78.0.0 (API version 23.08) onwards, these data can't be sent in query parameters anymore.
  • username in GET /attachments
  • accountNumber in GET /bankstatements
  • name and identifier in GET /businesspartners
  • accountNumber in GET /referencepayments
• When the invoice is paid in foreign currency, new optional fields paidCurrency and paidAmount in GET /invoices/{invoiceId}/paymentevents endpoint allows you to now view the payment events for the specified invoice in the paid currency.
• When the invoice is paid in foreign currency, new optional fields paidCurrency and paidAmount in GET /invoices/{invoiceId}/paymentevents/{paymentEventId} endpoint allows you to now view the specified payment event for the specified invoice in paid currency.
• When the invoice in foreign currency is marked as paid, new optional fields paidCurrency and paidAmount in GET /invoices/{invoiceId}/paymentevents/markpaid endpoint allows you to now view the amount in the paid currency.

Others

• To login faster in API UI login page, it's now possible to save password in the browser so that credentials can be autofilled in the next login.
• User can now easily choose the company to acccess to in API UI login page. As user types text in the company dropdown list, list gets sorted/filtered.

Changes in version 23.05

Endpoints

• Batch endpoint GET /products/{ids}
  • Can now fetch up to 200 product details at a time when comma separated list of product IDs is sent in the request URL
  • Only resources with valid IDs are returned. The items in the result list are ordered by productID and does not contain duplicates
  • When multiple resources are requested, the result will contain a list of resources - even for 1 returned product details
  • When only a single ID is specified in the request, the return model will be same as in GET /products/{productId}
  • If more than 200 IDs are given, 400 error response is returned. If all the given IDs are invalid, 404 error response is returned. As long as the list of IDs contains at least one valid ID, the request won't return an error

No new API release in April, 2023

No new API release in March, 2023

Changes in version 23.02

Endpoints

• POST /payments endpoint now requires mandatory field invoiceVersion to ensure correct invoice is paid. Invoice's version can be fetched from GET /invoices/{invoiceId} or GET /invoices endpoints.
• In POST /reports/generalledger{id} we have added the possibility to filter general ledger accounting report for the given ledger account by supported accountingCoaLanguages mentioned in GET /company.
• In POST /reports/ledgeraccounts we have added the possibility to filter ledger accounts accounting report by supported accountingCoaLanguages mentioned in GET /company.
• In POST /reports/accounting we have added the possibility to filter income statement, balance sheet and cash flow accounting reports by supported accountingCoaLanguages mentioned in GET /company.
• In the following API endpoints, maximum pagination size has been increased to 200. i.e size request parameter will now accept maximum value up to 200. If size isn't given, 50 will be set as default, as before
  • GET /attachments
  • GET /bankaccounts
  • GET /bankstatements
  • GET /businesspartners/groups
  • GET /businesspartners
  • GET /factoringcontracts
  • GET /invoices
  • GET /invoices/{invoiceId}/paymentevents
  • GET /ledgerreceipts
  • GET /payments
  • GET /payments/directsalarypayments
  • GET /payments/errormessages
  • GET /products
  • GET /referencepayments
  • GET /webhooks

Changes in version 23.01

Endpoints

• In PUT /bankstatements/{statementId}/events/{eventId}/metadata endpoint, instead of ledgerAccount object ledgerAccountCode should be given in the request body.
• In PUT /referencepayments/{referencePaymentId}/metadata endpoint, instead of ledgerAccount object ledgerAccountCode should be given in the request body.
• In POST /invoices and PUT /invoices/{invoiceId} endpoints, if invoice channel is MAIL in sales invoice and sales order, billingAddress.city will be required. If billingAddress isn't given in the request, it must be specified in counterPartyAddress.city.
• New field version has been added in the GET /invoices/{invoiceId} endpoint, whose value is automatically generated by Procountor and updated every time invoice is modified. Earlier invoice version was returned only in GET /invoices.
• GET /currencies/exchangerate endpoint now returns error code 404 instead of 500, when exchange rate can't be found.
• If required fields in billingAddress are missing in POST /invoices and PUT /invoices/{invoiceId} endpoints, API error response now tells which field it is.

Other

• Updated Webhook reference documentation.
• Added missing response body and possible error codes for PATCH /attachments/{attachmentId} endpoint in API reference documentation.

Changes in version 22.12

Endpoints

• New optional fields headerText and explanationTexts have been added to InvoiceRow used in the GET /invoices/{invoiceId}, POST /invoices and PUT /invoices/{invoiceId} endpoints to support header and explanation texts in sales offers, sales orders and sales invoices. Header texts are shown before the product row and explanation texts after the product row comment. They both support maximum 512 characters.
• New field active has been added in the GET /coa endpoint to indicate if the ledger account is active or not.
• New field accountingCoaLanguages has been added to GET /company endpoint to return list of languages supported for accounting coa in the company environment.
• POST /reports/ledgeraccounts, POST /reports/accounting and POST /reports/generalledger/{id} endpoints have now been fixed so that they return same results as in Procountor UI when filtered by reportStatus.
• If mandatory fields are missing when receipt type is SALES_INVOICE and invoice channel ELECTRONIC_EINVOICE, POST /invoices and PUT /invoices/{id} endpoints now return proper field in API error response.

Other

• Added missing description in API reference documentation for idin POST /reports/generalledger/{id}.
• When field given in the request body is unsupported, API error message now correctly mentions field is invalid instead of its value. This has been fixed for all API endpoints.

Changes in version 22.11

Endpoints

• In POST /invoices and PUT /invoices endpoints, for invoice type SALES_INVOICE if invoiceChannel is ELECTRONIC_INVOICE, in addition to name following fields will be required in billingAddress and counterParty > counterPartyAddress
  • street
  • zip
  • city

type that wasn't needed in POST /reports/ledgeraccounts has been removed from LedgerAccountsReportRequest.

type that wasn't needed in POST /reports/generalledger/{id} has been removed from GeneralLedgerReportRequest.

GET /coa endpoint now returns translations for ledgerAccounts in Chart of accounts supported languages, if translations are available.

POST /ledgerreceipts with parameter "createReconciliation=true" now correctly rounds decimals in accountingValue that have more than 2 decimals. Receipt is now even after adding reconciliation row.

New attachment type REFERENCE_PAYMENT_EVENT has been added to the GET /attachments endpoint to return attachments added to the reference payment transactions/event.

Other

• In API reference documentation, GET /coa now points to the correct Chart of accounts link in Procountor manual.
• OpenAPI JSON for receiptStatus and receiptType, which had default and enum in wrong places in following models have been corrected. API documentation for those schemas have been also updated.
  • receiptStatus in
    • AccountingReportRequest
    • LedgerAccountsReportRequest
    • GeneralLedgerReportRequest
    • ReportRequest
  • receiptType in
    • AccountingReportRequestOptions
    • LedgerAccountsReportRequestOptions
    • GeneralLedgerReportRequestOptions
    • ReportRequestOptions

Changes in version 22.10

Endpoints

• In POST /invoices, PUT /invoices/{invoiceId} and GET /invoices/{invoiceId} endpoints, comment in invoiceRows now supports up to 512 characters instead of 255.

Changes in version 22.09

Endpoints

• POST /invoices endpoint was fixed so that a new sales invoice can be created successfully even when user has no other right than to create new sales invoice or group invoice.

Changes in version 22.08

Endpoints

• We are introducing new endpoint POST /reports/ledgeraccounts to retrieve ledger accounts accounting report. This new endpoint mimics Procountor UI functionality behind Accounting -> Accounting reports (new) and Accounting report type 'Ledger accounts'. This endpoint has following limitations:
  • Date range (end date - start date) can't be more than 1 year
  • Report is presented in 'every month and total sum' format
  • Comparison data options aren't supported
  • Only handful of presentation options are supported
  • Filtering by dimensions isn't supported
• In POST /reports/accounting endpoint, transactionValue can now be filtered with comparison symbols ( >,=>,=<, <). For example, '> 210.00'.

Other

• Bugs fix included in this version:
  • POST /invoices endpoint now checks if user has right to view the corresponding register if partnerId is given. If user doesn't have the required right, 403 forbidden error is returned with an appropriate error message.
  • When creating sales invoice via endpoint POST /invoices, if partnerId is given but not penaltyPercent, penalty percent is fetched from the business partner's penalInterestRate. If the business partner doesn't have penalInterestRate, sales invoice's penaltyPercent shall be set to 0,00.
  • In POST /invoices endpoint, if partnerId and penaltyPercent are missing, penaltyPercent is set from Management > Company info > Usage settings > 'Collection and penal expense settings', if it's set there. Otherwise, penaltyPercent will be set according to the country's specific general penalty percent.
  • PUT /users endpoint now checks if mobilePhone starts with prefix '+'. If it doesn't, error code 400 is returned.
  • All API requests using Webhooks that receive response transactionIdentifier will include additional confirmationApp field to indicate which application was used to confirm the transaction (FINAGO_KEY or PROCOUNTOR_KEY). In future, Finago Key will be replaced by Procountor Key as a 2-factor authentication application.
  • In POST /reports/generalledger/{id} endpoint ledgerReceiptTransactions doesn't anymore return first row with receiptDate and transactionDescription.
  • ledgerReceiptTransactions returned by POST /reports/generalledger/{id} endpoint now returns vatStatus as integer instead of string.
  • deliveryInstructions in PUT /invoices/{invoiceId}, GET /invoices/{invoiceId} and POST /invoices now supports maximum 255 chars instead of 250.

Changes in version 22.06

Endpoints

• We are introducing new endpoints regarding business partner's default dimensions:
  • GET /businesspartners/{id}/defaults/dimensions to fetch the basic information on default dimensions and their items of a particular business partner.
  • GET /businesspartners/{id}/defaults/dimensions/{dimensionId} to fetch the default dimensions items for a particular business partner.
  • PUT /businesspartners/{id}/defaults/dimensions/{dimensionId} to update the dimension items percents for a particular business partner. 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 /businesspartners/{id}/defaults/dimensions/{dimensionId} can be called first to fetch the item's other details.
• We are introducing new endpoint POST /reports/generalledger/{id} to retrieve the general ledger accounting report for a particular ledger account.
  • This endpoint has following limitations:
    • Ledger receipts are sorted by receipt number in DESC order
    • Date range (end date - start date) can't be more than 1 year
    • Filtering by dimensions, balance sheet items, balance sheet items in transactions, ledger accounts, ledger account numbers aren't supported
    • Only handful of presentation options are supported
• We are introducing new endpoint GET /company/expenses/collectionpenal/settings to fetch the environment's collection and penal expenses settings that is available in Procountor UI under Management > Company Info > Usage settings.

Other

• Developer portal updates:
  • Procountor API Terms of Use has been updated
  • Contact forms for Requesting a testing environment and Requesting access to production have been updated

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

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