You deliver your outstanding items in three ways: through the API (per item, as soon as something changes), through a file that POM collects for you (the complete list, usually every night) or through an integration with your accounting package. Which way fits depends on your system and whether you have an IT team. What the portal then does with the items is explained in Collection Sync explained.
The three ways side by side
| Way | For whom | What you deliver | Who builds it |
|---|---|---|---|
| API | Organisations with their own IT team or integration partner | One item per call, at the moment something changes | You, with the API documentation |
| File | Organisations that can export from their system but do not want to build an API integration | The complete list of outstanding items, as a CSV or text file on a secure server | POM sets up the processing |
| Accounting integration | Organisations with an online accounting package | Nothing; POM collects the list daily | POM, you log in once |
The main difference is what happens to an item that is no longer in your list:
- If you deliver the complete list (file or accounting integration), the portal knows which running collection orders are missing. Those become Paid.
- If you deliver per item (API), there is no moment at which the list is complete. You close a collection order by sending amount 0. An item that you simply stop sending keeps running.
Through the API
The API has a separate synchronisation endpoint: POST /v3/collection_orders/sync. You call it again and again with the current state of one customer and one payment reference. The portal creates the collection order if it does not exist yet, updates the invoices if the amount changed and closes the collection order when nothing is outstanding anymore. The full documentation is at api.pom.eu/docs.
How it works
- Request access to the API from POM. You receive a client ID and client secret for your client. Test in your test environment first.
- Make sure the customer exists. Create or update the customer through
/v3/debtors. For a new collection order the portal copies the customer's contact details onto the collection order. - For each outstanding item, send a call to
POST /v3/collection_orders/syncwith the customer number, the payment reference and the invoices that are outstanding now. - Read the response. It tells you what the portal did and which events were logged.
- Repeat this every time something changes in your system, or at a fixed moment each day.
Fields in the call
| Field | Required | Meaning |
|---|---|---|
debtor_number |
Yes | Customer number (3 to 35 characters) |
payment_reference |
Yes | Payment reference (3 to 35 characters). Together with the customer number this decides which collection order is updated. |
invoices |
Yes, for a new collection order | The invoices that are outstanding now. Per invoice: number, description and amount in cents. Optional: type, date, due_date, description2, description3, amount2, amount3, quantity. |
concerning |
No | Subject of the collection order, for example "Rent April 2025" |
flow_status |
No | active, pause or withdraw. Sets the status of the collection order to the status in your accounting system. |
payment_modules |
No | Payment methods for the collection order. If you leave this out, a new collection order gets the default payment methods of your client and an existing collection order keeps its payment methods. |
batch_id |
No | Name of the batch, useful to find a delivery again |
return_url |
No | Page the customer goes to after paying |
variables |
No | Custom fields variable1 to variable500, for use in templates and flows |
The response
| Field | Meaning |
|---|---|
action |
What happened: created (new collection order), updated (amount or invoices changed), closed (set to paid), unchanged (nothing changed), status_updated (only the status changed) or skipped (skipped, for example amount 0 without a running collection order) |
collection_order_id |
The number of the collection order, if there is one |
events |
The event codes of this call, in order. See Collection Sync: events and event codes. |
Good to know about the API
- A new collection order starts in the default flow of your client. The first flow step is scheduled one hour after the call. If you send a new state for the same item within that hour, it is processed first.
- If several running collection orders share the same customer number and payment reference, the portal updates the most recent one.
- Invoices that have not reached the start moment yet, or that were paid through POM within the payment respite, are skipped.
- The API has a limit of 5000 points per minute for your whole client; a synchronisation costs 1 point. In the test environment every call costs 10 points. When you exceed the limit you get status 429 with a waiting time in the header.
- If an old payment arrangement from before the current settlements is still running on the collection order, the call is rejected with status 422.
- An endpoint to close collection orders that are no longer in your complete list is in development (planned). Until then you close a collection order through the API by sending amount 0.
Through a file
If you can export your outstanding items, POM can collect and process that export for you. You do not have to build anything yourself.
How it works
- You agree a file layout with POM (usually CSV) and a secure place where you put the file, for example an SFTP server.
- At a fixed moment, for example every night, you make the complete list of outstanding items available. Per item at least: customer number, payment reference, invoice number, amount and date. Also the customer details you want to use in messages, such as name, address, email address and phone number.
- POM collects the file, converts it to the portal's format and processes it with Collection Sync. The processed file is moved to an archive folder on the server.
- After processing you see a notification in the portal with the numbers: new items, dropped items, synchronised items and skipped items. Together they add up to the total of your list, so you can check that everything was picked up.
Good to know about a file
- Because you deliver the complete list, a collection order that is no longer in the file becomes Paid. So make sure a failed export does not produce an empty or partial file.
- You can give each item a status (active, pause, withdraw) if your system knows it.
- The file also sets the variables of the collection order; they are refreshed with every run.
Through an integration with your accounting package
If you work with an online accounting package, POM can collect the list of outstanding items from it every day. You log in to your package once to give permission; after that it runs by itself. The processing is the same as for a file: the complete list is compared and whatever is missing becomes paid.
Supported packages include Exact Online, Twinfield, SnelStart, Yuki, Moneybird, Minox, AFAS Profit, Cash, e-Boekhouden.nl, Exact Multivers, Boekhoud Gemak, Microsoft Dynamics 365 Business Central, Reeleezee, Visma eAccounting and Xero. Ask POM for the current list and the options for your package.
Manual upload
If you want to deliver a list once or now and then, you will soon be able to upload it yourself in the portal under Uploads. This part still has the Coming soon badge. See What is coming.