The strongest finance automation does not try to automate every overdue invoice. It identifies uncertainty early and routes the right cases to human judgment.

By Lars Holdgaard, Founder of Debitura

Accounts-receivable automation is easy to admire when every case follows the happy path. An invoice is issued, the due date passes, a reminder is sent and the payment arrives. The software removes repetitive work and gives the finance team a consistent process.

The real test begins when the data stops agreeing with the workflow. A customer disputes part of the delivery. A promised payment never appears. The legal entity on the purchase order differs from the one in the CRM. A long-standing customer suddenly stops responding. These are not reminder problems. They are exceptions that require classification, evidence and judgment.

Treat uncertainty as a first-class output

Many systems are designed to produce an action: send a reminder, assign a task or escalate an account. A better design also produces a confidence level and the evidence behind it.

For each overdue invoice, the system should distinguish at least four kinds of uncertainty:

·         Identity: Are the contracting party, invoiced entity and communication contact aligned?

·         Obligation: Is the invoice supported by the correct order, delivery record and agreed terms?

·         Promise: Has the customer made a specific payment commitment, and has that commitment been kept?

·         Solvency: Are there credible signs that the customer cannot pay rather than merely will not pay?

These signals do not need to produce a legal conclusion. Their job is to show the operator why a case should leave the automated lane.

Use confidence and consequence together

Confidence alone is not enough. A low-confidence classification on a small administrative invoice may justify a quick human check. The same uncertainty on a material cross-border exposure may require an immediate stop.

A practical decision rule combines confidence with consequence. High-confidence, low-consequence tasks can proceed automatically. Low-confidence or high-consequence cases should move to a review queue. The threshold should tighten when a dispute, insolvency signal, large balance or unfamiliar jurisdiction is involved.

This is where human-in-the-loop design becomes operational rather than cosmetic. The reviewer needs the original documents, the latest customer message, the model or rule output and a clear record of prior actions. A button labelled “approve” is not meaningful if the evidence is hidden.

Build one traceable case record

An exception layer works only when it can reconstruct the case. The contract or order, invoice, delivery evidence, customer correspondence, payment promises and adjustments should be connected rather than scattered across systems.

Version history matters. If the customer disputes one line, preserve the original invoice, the disputed amount, any credit note and the remaining balance. If terms change, record who approved the change and when. If a colleague overrides an automated classification, capture the reason.

Traceability becomes even more important when a case crosses borders. The registered debtor entity, country, currency, language, governing-law clause and known asset location may point to different operational routes. A regional workflow for debt recovery across North America can help organize that handoff, but the system still needs the underlying facts before a specialist can act.

Measure decisions, not message volume

An automated process can look productive because it sends many reminders. Better measures show whether the system helps the team reach the right decision.

Useful metrics include time to classify an exception, dispute age, promise-kept rate, time to ownership and the share of escalated cases with complete documentation. Teams should also track manual overrides by exception type. Repeated overrides often reveal a missing data field, weak integration or threshold that needs redesign.

The review queue itself is a product signal. If the same exception appears every week, the answer may be to improve invoice data, change a commercial process or add a new validation rule, not simply to assign more people.

Let automation narrow the human problem

The objective is not maximum automation. It is a smaller, clearer set of cases that deserve human attention.

Software should handle deterministic work, monitor commitments, surface conflicting evidence and keep the record consistent. People should own ambiguity, commercial judgment and decisions whose consequences extend beyond the next reminder. Designed this way, the exception layer is not a failure of automation. It is what makes automation trustworthy.

Author bio

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.