A useful API carries the evidence, approval and updates behind a recovery case, giving finance teams control over what happens after an invoice becomes overdue.
By Lars Holdgaard, Founder of Debitura
An overdue balance is easy to export. A case that another organisation can act on takes more work. The invoice may sit in the accounting system while the contract, delivery evidence and latest customer response remain in separate inboxes. Across borders, the receiving agency also needs to know which legal entity owes the money and which entity is entitled to collect it.
An application programming interface, or API, can connect those records to external recovery and bring updates back. Its practical value comes from carrying a complete case and an explicit decision to escalate. Moving an overdue invoice faster is useful only when it moves the right invoice, with the right evidence and authority.
Start with shared meaning
The European Commission describes EN 16931 as a core semantic model for electronic invoices: a common definition of the information an invoice contains. ISO 20022 guidance on APIs makes a related point about shared business concepts and consistent meaning between systems. Neither source defines a debt recovery workflow, but both illustrate why agreeing on meaning should precede automating an exchange.
Recovery needs a minimum case record of its own. It should identify the legal creditor and debtor, amount and currency, invoice and due dates, debtor country, supporting documents, dispute status and relevant contact history. Internal invoice and customer references let finance staff connect subsequent recovery updates to the source ledger.
Consider a hypothetical group with two subsidiaries. Both export an invoice marked overdue. One customer has stopped responding; the other is waiting for an agreed credit note. If the integration sends only an amount, due date and email address, the two cases look alike. If it carries the reason for non-payment and the pending adjustment, the finance team can approve the first for recovery and hold the second for correction.
This is a mapping problem as much as a technology problem. Different accounting systems can retain their own structures, provided their fields resolve into the same business meaning. Missing or contradictory information should produce a visible exception with a named owner, rather than a case that appears complete until a local specialist opens it.
Keep approval separate from transmission
Age alone does not establish that an invoice should enter external recovery. A dispute, payment in transit or incorrect debtor entity can change the decision. The integration should make that judgment visible.
A useful workflow gathers the case evidence, identifies unresolved issues and records approval before submission. Finance owns the escalation policy; technology implements it. The case record should retain who approved the handoff and when, so staff can distinguish a deliberate decision from an automatic export.
That distinction also matters when an API request fails. Retrying an approved submission should not create another case or change the approved amount. The receiving process needs a way to recognise the same submission, while an uncertain result should trigger reconciliation before staff try again.
Bring events back into the finance process
The initial submission is only one part of the connection. A recovery case may need another document, receive a payment or close without payment. Those developments should reach the people responsible for the receivable.
Webhooks are notifications that a platform sends to a connected system when an event occurs. A receiving workflow can open a task or flag a record for reconciliation instead of relying on repeated manual checks. A reported payment should reach finance for reconciliation; it should not silently become proof that the money has cleared the creditor's bank account.
Notifications can arrive more than once when delivery is retried. The receiving system should retain event identifiers and recognise duplicates, so one update does not create two tasks or two accounting entries. A failed delivery also needs monitoring and an owner. Otherwise, the dashboard can look current while the source ledger remains out of date.
Protect the case throughout the handoff
Invoices and supporting documents can contain personal data and commercially sensitive information. Finance and technology teams should agree which documents are necessary, who will receive them and how access will be removed when it is no longer needed. Cross-border document handling also requires a review of the applicable data protection and transfer requirements before live sharing begins.
API authentication establishes which account is making a request. Access controls must also determine what that account is allowed to see or change. OWASP's API Security guidance highlights the need to check permission for individual records and functions, a useful distinction when several subsidiaries or external providers share a workflow.
Credentials should be stored securely, connections should use HTTPS and incoming notifications should be authenticated before they alter a record. Debitura's documented webhook system, for example, requires HTTPS endpoints and signs deliveries using HMAC-SHA256. These controls help authenticate the exchange; they do not replace decisions about document recipients, retention or lawful cross-border sharing.
Give local specialists a consistent case
An API can standardise a handoff without standardising every country's recovery process. Language, legal options and appropriate escalation remain matters for local assessment. A common case record should help the local specialist understand the claim while giving the creditor a consistent view of progress.
Debitura is a software platform connecting businesses with local collection agencies and law firms, which perform the recovery work. Its customer API supports case creation, document uploads and access to case activity and recorded payments. For finance teams, that illustrates how one technical connection can support the handoff while local providers handle execution.
The choice between a direct API connection and existing accounting or workflow connections depends on the source systems and available technical resources. The Debitura integrations overview provides examples of these connection routes. Whichever route is used, it should preserve the approved case, return useful updates and leave someone responsible for exceptions.
Test whether the handoff actually works
A pilot should test more than whether a request returns a successful response. The hypothetical subsidiary cases offer a useful starting point: does the disputed or adjustable invoice remain on hold, while the approved case reaches the receiving workflow with its supporting documents?
Other tests should cover a missing document, a repeated submission, a duplicate notification and a payment reported after escalation. Each test needs an expected business outcome and an owner for any exception. Passing a technical test is insufficient if finance cannot explain what happened to the receivable.
Once live cases begin, measure incomplete submissions, time from approval to successful handoff and time to resolve information requests. Check whether status changes reach the source workflow. Those measures reveal whether the connection reduces manual clarification or merely moves it to a different team.
The goal is a finance process in which an approved case leaves with its evidence and subsequent developments return to the people who own the balance. APIs can make that process more consistent across borders, provided the integration carries the decisions and responsibilities as carefully as it carries the data.
About the author
Lars Holdgaard is the founder of Debitura and has 10+ years of experience across debt collection, accounts receivable, technology, and startups. Before Debitura, he co-founded and led product and technology work at startups and scaleups, building software for financial administration and receivables management. Lars studied at the IT University of Copenhagen and the Technical University of Denmark.
This article provides general information and should not be interpreted as legal advice.