Skip to main content

Structure of the CSV file

  • File encoding must be UTF-8.
  • CSV format specification RFC 4180 (http://tools.ietf.org/html/rfc4180) serves as a guideline.
  • Separator can be semicolon (;) or comma (,).
  • (Text) fields must be enclosed in double quotation marks (“).
  • When using double quotation marks to enclose fields, double quotation marks in a field must be escaped by prefixing it with another double quotation mark.
  • Field length is max. 255 characters.
  • The first line is reserved for the column headers.
  • A number of columns are mandatory, these are indicated in bold.
  • Unused columns do not need to be included in the CSV file.
  • The order of columns is not important.

Processing

  • The CSV file must present all invoices that must be processed by Payt for sending, reminding, etc. Please note that filtering from the accounting system on only “outstanding items” can sometimes be incomplete. For example, when an invoice is created within 24 hours and immediately matched with a cash payment. At the time of export, this invoice will no longer be in the outstanding items, while Payt may still have to send the invoice. As a guideline, Payt recommends that invoices must appear in the CSV file for a month, to minimize the risk of missing invoices, credit notes or zero invoices.
  • Payments are calculated and registered based on the outstanding amount of the invoice.
  • When an invoice has disappeared from the import, Payt marks the invoice as paid.
  • This means that empty CSV files are interpreted as there are no outstanding invoices. So all invoices are seen as paid. A setting is available in the application that can serve as protection for loading an empty file.

Data types

Headers

Debtor

The debtor_* fields must be delivered consistently for all invoices. E.g. the postal address must be the same for all invoices from the same debtor, as must fields like emails, phone numbers, relation manager, etc. If it is desirable to use a different address for different invoices from one debtor, the invoice_contact_* fields can be used.

Language code

The languages Dutch, German, English, French, Spanish, Italian and Polish are supported in the application. When a different language code is supplied, the application falls back to the language set as fallback on the administration. When Dutch is used for Belgian customers, Flemish is used.

Name and address fields

At least one of the fields debtor_company_name or debtor_firstname / debtor_lastname -> (this is merged into debtor_fullname in the code) must be filled.

Invoice-specific contact person

It is possible to assign an invoice-specific contact person to an invoice. If an invoice has an invoice-specific contact person, the details of the contact person will be used instead of the details of the debtor. Note: If there is an invoice-specific contact person, the fields invoice_contact_origin_id and (invoice_contact_firstname or invoice_contact_lastname) must both be filled. The invoice_contact_origin_id field contains the unique source ID of the contact. If invoice_contact_origin_id is filled, but the name is missing, the invoice-specific contact person will not be loaded and a validation error will be displayed. Keep in mind that the corresponding invoice and debtor will be loaded in this case. If no specific email address for sending invoices is known for the contact person, the email address for sending invoices of the debtor is used. If this address is also unknown, the general email address of the contact person will be used. Finally, if no general email address of the contact person is known, the general email address of the debtor is used. If no specific email address for sending reminders is known for the contact person, the email address for sending reminders from the debtor is used. If this address is also unknown, the general email address of the contact person will be used. Finally, if no general email address of the contact person is known, the general email address of the debtor is used.

Payments

If no payments are provided Payt will create one based on the difference between total and open amount of the invoice. This payment created by Payt only contains the paid amount and a date, the date of the import. The payments field allows you to take control of the payments that will be created. It also allows you to update existing payments. There are a few things to note when providing the payments:
  • all payments of the invoice must be provided, also the historical ones. This allows Payt to recognize when payments have been changed or destroyed in the bookkeeping system and apply these changes.
  • the payments must be ordered chronologically with the oldest first
  • the sum of the payment amounts must be equal to the difference between the total and open amount of the invoice.
For invoices with no payments, an empty array should be provided:

Invoice lines

Invoice lines describe the products and/or services that are being invoiced. Invoice lines are not required for most of the features within Payt. When you want Payt to create the invoice document or UBL then the invoice lines are required. There are a few things to note when providing the invoice_lines:
  • the sum of the amounts in the invoice lines must be equal to the total amount of the invoice.
  • if changes in the invoice_lines are detected these changes will automatically be applied. Invoice lines no longer present in the set will be removed.
  • if an empty set of invoice lines is provided then all invoice_lines will be removed.
  • once an invoice is published, it is sent to the debtor, it is no longer allowed to change the invoice lines.

Changelog

Last modified on June 18, 2026