Accounts Receivable Automation: A Four-Layer Design

Accounts receivable automation is turning into an AI category. In August, Tabs introduced a Collections Agent that prioritizes accounts, drafts outreach, handles routine requests and applies incoming payments. On 19 August, Oddr released AI-drafted collections emails and automated follow-up sequences, with an agentic collector entering early access. A week later, Waystar announced agents that act across revenue-cycle workflows.

The direction is real. The framing is incomplete.

Writing a reminder is the cheapest part of collecting an invoice. A useful system must first know what is still owed, decide which case deserves attention, preserve the customer context, and stop when a payment arrives. My position is simple: an AI collections agent should be the exception manager inside a deterministic receivables system, not the owner of the balance.

That distinction decides whether automation reduces days sales outstanding or merely produces more email.

What does accounts receivable automation include?

Receivables work looks like one workflow from a distance: send invoice, wait, remind, collect. In software it is four different problems with different tolerances for error.

The first and fourth layers should remain boring. A balance cannot be probabilistic. If a customer owes 10,000 euros and pays 9,700, the system has a short payment, not a 97% confidence that the invoice is closed. The agent may explain the likely fee or deduction. It may not erase the remaining receivable because the explanation sounded plausible.

The middle layers are where models help. Customer conversations are unstructured, priorities change, and one overdue invoice can be routine while another signals a dispute. This is context work, not arithmetic.

Why is prioritization harder than sending reminders?

We checked normal invoices marked paid in Norman over the last twelve months, restricting the sample to invoices with a valid issue date, due date and payment date. More than a thousand invoices met those conditions.

Roughly one in four was paid after its due date. Among the late group, the median payment arrived 17 days late. The slowest tenth took close to four months after the due date. The median payment term itself was only a little over two weeks.

That shape matters more than the average. A universal reminder on day three can handle the dense middle of the distribution. It does little for the long tail. An invoice that is 114 days late is rarely waiting for a more eloquent version of the same email. It may have a purchase-order mismatch, a disputed line, a changed contact, a partial payment or a promise somebody forgot to record.

This is why a collections queue should rank work, not merely age. Age is an input. So are amount, prior payment behaviour, an unanswered message, a broken promise, a short payment and whether the customer has raised a dispute. The model can summarize those signals. The policy must decide which signals it is allowed to use and what action each score can trigger.

The legal sequence for German reminders is a separate question. We already maintain a practical guide to the German payment-reminder and Mahnung process. Automation should encode that approved process, not improvise it.

Which parts should AI automate?

Start with tasks where a wrong suggestion is visible and reversible.

An agent can prepare a daily queue with a reason beside every item: payment promise expired, message unanswered, material short payment, or first-time late customer. It can compress a thread into three sentences. It can draft a friendly reminder in the customer’s language and adjust the tone to a policy selected by the finance team. It can classify an inbound reply as a dispute, request for a copy, promised payment date or wrong contact.

It should not invent the balance, change a due date from a conversational hint, or move an invoice into legal escalation because a sentiment score looked negative. Those actions change the company’s books or relationship with the customer. They need typed inputs, explicit rules and, at the boundary, a person.

At Norman, the overdue trigger is deterministic: the invoice has a due date, the date has passed, the invoice is still unpaid, and an active rule matches. We store each reminder level as an event rather than deriving history from the current state. That means a later policy change cannot rewrite what was actually sent. Review-first rules create a pending action for a person; automatic rules use the same recorded path.

That is less cinematic than an autonomous collector. It is also the foundation that makes an agent safe to add.

How should cash application work?

Collections does not end when money reaches the bank. It ends when the receipt is matched to the right open item and the books agree with the bank.

A high-confidence match is mostly deterministic. In our system, candidate payments must already be booked income in the correct currency, have the invoice amount, remain unattached, and fall inside a bounded date window. Invoice number and customer links strengthen the match. If several candidates remain, the system can choose only under narrow rules; otherwise it leaves the invoice open.

AI can make the exception queue easier to work. It can explain that the difference looks like a bank fee, find a remittance note in a document, or summarize how one payment might cover three invoices. The final posting still needs a balanced, auditable result.

This is particularly important across borders. Settlement fees, currency conversion and batch payments can make the bank amount differ from the invoice amount for legitimate reasons. A system that optimizes only for match rate will close the wrong items. Measure false closes separately from unresolved matches. The first damages the ledger; the second creates work.

For cash planning, those open items must also flow into a real forecast. Our liquidity-planning guide explains the broader cash view, including receivables that may not arrive on schedule.

How do you choose a receivables automation platform?

The vendor category tells you less than the system boundary.

Use a historical pilot, not a scripted demo. Give every candidate the same closed period and hide the outcomes. Ask it to identify the invoices that deserved attention, propose actions, match receipts and explain every uncertain decision. Score false closures, missed promises and inappropriate escalations, not just messages generated.

For a German exporter, add currency and jurisdiction tests. Can the system keep invoice currency separate from settlement currency? Can it distinguish a commercial reminder from legal escalation? Can it preserve localized communication without translating contractual facts? Can it show who approved a send?

No platform should win because its email sounds the most human.

What should you measure after launch?

Days sales outstanding is useful, but it is too broad to diagnose the system. Track the queue in parts:

• time from due date to first appropriate action;
• share of promises followed up on the promised date;
• time spent on exceptions per collected invoice;
• false cash matches and reopened invoices;
• disputes identified before a reminder was sent;
• payment time at the median and at the slowest tenth.

The last line is the one I would put on the founder dashboard. Averages reward automation for making easy cases slightly faster. The slowest tenth reveals whether the system can preserve context, notice a broken promise, route a dispute and keep working after the first reminder fails.

Eventually some receivables become genuinely uncollectible. That is an accounting state, not a failure label an agent should guess. The process for writing off bad debt in a German GmbH remains a separate, evidenced decision.

AI is moving collections from scheduled messages toward active queue management. That is a worthwhile change. But the product is not the message generator. The product is the four-layer contract around it: exact state, explainable priority, controlled outreach and auditable cash application. Build those layers in that order, and the agent can help collect. Reverse the order, and it will only help write.