Debt collection starts in somebody else's ledger
A collections platform is only as good as the receivables it can see. Maesn pulls the debtor, the unpaid invoice and the document behind it out of your customers' accounting systems, in one shape, so the reminder you send is the right one at the right moment.
Overdue invoices live in the creditor's accounting system
Collections runs as an escalation ladder, from payment reminder through formal dunning to collection. Which rung an invoice belongs on is decided by facts your product does not hold.
A nudge with no legal weight attached.
Fees and a deadline enter the letter.
The claim moves outside your product.
So the same debtor is not dunned twice for the same invoice.
So the chase stops the moment the money arrives.
How far the ladder goes depends on the platform. Some products stop at a polite reminder, others carry a claim all the way into formal collection, and behind the ones that do there is usually a law firm specialising in exactly that. The scope differs; the data question does not. Every rung needs to know who owes what, since when, and on the strength of which document.
That is the awkward part of building a collections product: none of those facts originate with you. They sit in the creditor's ledger, they change without telling you, and the two most damaging mistakes in this field both come from acting on a stale version of them. Sending a second reminder for an invoice that was already chased makes a careful process look careless. Dunning somebody who paid last Tuesday is worse.
So the two boxes underneath the ladder are not extras. They are the reason the documented flow has six steps rather than three, and they are what turns a list of overdue invoices into a process you can defend.
One API for the debtor, the invoice and the document
Maesn reads all three out of the creditor's accounting system through one connection, in the same shape on every system. Each has a documented call, and one of the three deserves a footnote.
The debtor comes first, because a claim addressed to the wrong legal entity is not a claim. Reading the customer record from the creditor's own system means you work with the name, address and identifiers their accountant uses, rather than whatever was typed into a form once. It arrives through the same normalized object on every system, so a debtor from a Dutch system and one from a German system read the same way in your code. The creditor authorises once, whether their books sit in Lexware Office, Xero or one of the other connected systems, and the calls below are the same either way.
The open items are where the wording deserves care. Accountants say open items, the documented route is the invoice list with a payment-status or due-date filter, and those are the same information reached two ways. There is also an open items object in the model, and only a couple of connected systems expose it directly, so the filtered invoice list is the route that actually works everywhere. The same filtering and paging behaves identically across systems, which is what makes a nightly sweep for newly overdue invoices a single query rather than one per vendor.
The document is the part people underestimate until a claim is contested. A dunning notice with fees attached, or a handover to a lawyer, rests on the invoice as it was issued. There is a dedicated call for that original file, so it can travel with the case instead of being reconstructed from fields.
Never dun twice, and stop the moment they pay
A collections product is judged on precision rather than volume. The two errors that damage it most are not bugs in the escalation logic, they are decisions made without a fact that was available. Both have a documented step in the flow whose only job is to prevent them.
The second reminder
duplicateChasing a settled invoice
already paidThe reminder read is the more interesting of the two, because it carries something a bare invoice list cannot: the dunning level an invoice has already reached. The documentation is explicit that this is what it is for, identifying the correct level and avoiding duplicate communication, and that is exactly the knowledge a platform inherits when it takes over a creditor's receivables mid-process rather than from the first day.
The payment read is simpler and just as consequential. Money lands in the ledger, not in your product, so a scheduled read of payments is what lets the chase stop by itself. Where a system emits events, webhooks shorten that loop further, and settling the outstanding item against the incoming payment is the neighbouring job described under payment reconciliation.
A collections platform already runs on this
Paywise automates debt collection with Maesn.
“With Maesn, we enable our customers to connect their accounting and ERP systems directly within Paywise, making debt collection seamless, automated and significantly more efficient.”
Paywise connects its customers' accounting and ERP systems from inside its own product, which is the shape this use case takes in practice: the creditor authorises once, and the receivables that drive the process flow from there. It is also the honest test of the model, because a collections platform cannot work around bad debtor data with clever workflow.
Debt collection coverage, system by system
Counted per system from the per-system documentation, with what is supported today kept apart from what is only marked on demand.
| What you need | Today | On demand | System cannot |
|---|---|---|---|
| Debtor master data | 20 | 2 | 7 |
| Invoices, reading | 13 | 14 | 2 |
| Payments, reading | 4 | 18 | 7 |
| Credit notes | 5 | 19 | 5 |
| Open items, as an object | 2 | 22 | 5 |
The first two rows are the ones this use case stands on, and they are the strong ones: debtor records and invoice reading are the best covered objects in the whole chain. That matters more than a high average would, because a collections process that cannot identify the debtor or list the unpaid invoices has nothing to escalate.
Payment reminders are absent from the table on purpose. The documented flow uses them, and the per-system documentation does not yet describe them, so there is no honest number to print. Where one system keeps something the shared model does not carry, reaching past the model is the documented way to it, and the receivable side of the same relationship is accounts receivable.
We deliver the data, you run the collection process
In this field the line between data and decision is also a line between engineering and law, which is why it is drawn rather than blurred.
- The debtor from their ledger
- Unpaid invoices, filtered
- The original document
- Reminders already sent
- When a reminder escalates
- Fees, deadlines and wording
- The legal process itself
- Which claims a lawyer takes
Everything on the left is a read from somebody else's system, kept current and shaped the same way regardless of which system it came from. That is the part that would otherwise become one integration per accounting platform, each with its own authentication, its own field names and its own idea of what an unpaid invoice is. Building on one authentication layer is what collapses that work into a single connection your customer approves once.
Everything on the right is your platform, and in collections it is more than product design. When a reminder becomes a formal dunning, which fees and deadlines attach to it, how the wording escalates and which claims a lawyer takes on are decisions with legal weight. A layer that made them for you would be overstepping, and a layer that pretended those decisions were technical would be misleading you about what it does.
One property belongs here rather than only on the security page. Requests are processed in real time, and what Maesn keeps is the record that a transfer happened, not the transferred data. For a platform that handles other companies' debtor information, that is a smaller surface to explain to a customer and a smaller one to defend. The lastModified filter on the read endpoints is what makes staying current cheap without keeping a copy of everything.
Whether a dunning run stops at the right moment is judged by financial teams, not by the integration that sent it.
Common questions
What does a collections platform actually need from the accounting system?
How do we avoid sending a reminder that has already been sent?
What stops us chasing an invoice that has already been paid?
Is this about reminders, dunning or collection?
You mention open items. Is there an open items endpoint?
Can we get the invoice as a PDF, or only the data?
Do we have to keep a copy of our customers' receivables?
How current is the data we read?
Which systems does this work with?
Does Maesn run the collection process for us?
Build once on the Unified API.
See how debt collection works for your integration, or dive into the technical reference.