How I Would Rebuild Accounts Receivable Collections as an AI-Native Workflow

Direct Answer

An AI-native collections system is a classifier before it is a sender. Its first job is to decide why each overdue invoice is unpaid (genuinely late, blocked by a dispute, never delivered, or billed to the wrong legal entity) and route the blocked ones to whoever can unblock them. Only the genuinely late are chased.

Key Takeaways

• The bottleneck in accounts receivable is not reminder cadence. It is that the ledger records an invoice as open without recording why, so every unpaid invoice gets the same treatment.
• Chasing a blocked invoice does not move it. It moves the relationship, in the wrong direction.
• The due date is a derived fact, not a typed field. Under Directive 2011/7/EU, what a customer legally owes depends on contract terms, receipt date and whether the debtor is a public authority.
• Asserting a legal claim (statutory interest, a credit hold, a referral to legal) stays human. So does deciding that a named customer is no longer worth extending credit to.

What problem does this system actually own?

It owns one question: for each open invoice, what is the actual reason money has not arrived?

That question is not answered anywhere in most finance stacks. The general ledger holds the amount, the customer, the invoice date and the due date. The aging report sorts those into 30, 60 and 90-day buckets. Neither field says whether the customer disputed two lines, never received the PDF, is waiting on a credit note the sales rep promised in March, or simply pays everything at 75 days because that is what they do.

So the reason lives in a person’s head, or in an email thread nobody has connected to the invoice number. When that person is on holiday, the reason is gone, and the invoice gets a reminder it did not need.

This is not a dunning-cadence optimisation. Sending the same reminder at better times to a customer who is blocked on a credit note produces a customer who filters your emails. It is also not a credit-scoring product, and the distinction matters legally: I come back to that below.

The 2026 edition of Intrum’s European Payment Report, a survey of 8,385 businesses across 20 European countries, reports that the B2B payment gap, the distance between agreed terms and actual payment, widened from 16 days in 2023 to 20 days, while the share of businesses using AI somewhere in payments rose from 59 percent to 66 percent. Intrum sells credit management services, so read the framing accordingly. But the direction of those two lines is worth sitting with. More automated chasing arrived and the gap grew. That does not prove the tools fail. It does mean the thing they automate is probably not the binding constraint.

The existing workflow I would map first

Before designing anything, I would sit with whoever runs collections today and write down the route as it actually happens.

It usually looks like this. The invoice is issued from the accounting system and emailed as a PDF to an address someone typed into the customer record three years ago. Thirty days pass. An aging report is exported to a spreadsheet on the first working day of the month. Someone sorts by days overdue, picks the top twenty, and starts writing. Half the replies are not payment: they are questions. “We never got this.” “Line 4 is wrong.” “Send it to accounts payable, not to me.” “It’s in approval.” Those replies go into an inbox. The spreadsheet does not know they happened.

Two weeks later the same aging report is exported again, and the same twenty invoices are still at the top.

Look at the middle rows. The steps that break are not the sending steps. They are the ones where information changes hands and stops being attached to the invoice.

That pattern is the same one I described in redesigning invoice processing from the accounts payable side. Both sides of the same transaction are running on documents that arrive by email and get re-keyed into a system that then disagrees with the email.

Why is collections still manual?

Most of the route is not stupidity, and it is worth understanding before proposing to delete it.

Invoicing by PDF exists because there was no shared identifier between two companies’ finance systems, and for most SME pairs there still is not one. The aging report is a snapshot because ledgers were built to answer “what is the balance” rather than “what happened to this claim”. Disputes leave the system because the person who can resolve a dispute (the account manager, the warehouse, the engineer who did the work) does not have a login to the finance system and has no reason to want one.

The escalation step is genuinely judgement, and should stay that way. Deciding to put a customer on credit hold is a commercial decision with consequences the finance team does not fully own.

How the system would run

I would build the collections system as a claim register rather than a mailing list. Every open invoice is an object with a state, an owner, a reason, and a next event. The model’s job is to keep that state correct, not to write persuasive emails.

One: derive the real due date. Pull the contract or the agreed terms, the invoice date, and the delivery or receipt date, and compute what is actually owed and from when. Under the 2011 directive, B2B invoices must be paid within a maximum of 60 days unless a longer period is expressly agreed and is not grossly unfair to the creditor, public authorities generally have 30 days, and statutory interest runs at at least 8 percentage points above the European Central Bank reference rate. A public-sector customer and a private one on the same terms sheet do not have the same deadline. Most tools treat the due date as a typed field, which is how a system ends up confidently wrong about who is late.

Two: classify why each invoice is open. This is the part that earns the build. Read the mailbox, the delivery receipts, the credit notes, the open support tickets and the bank feed, and assign every open invoice one of a small set of states: delivered and simply unpaid, never delivered, disputed on specific lines, awaiting a credit note, awaiting the customer’s internal approval, already paid but unapplied. Low confidence is its own state and gets a human, not a guess.

Three: route rather than chase. A disputed invoice goes to the person who can resolve the dispute with a deadline attached, not to the customer with a reminder. An undelivered invoice gets re-issued to a verified address. An unapplied payment goes to cash application. Only the “delivered and simply unpaid” bucket gets a reminder, and it gets one written against the actual facts of that invoice.

Four: close the loop. Every resolution writes back to the claim (dispute closed, credit note issued, payment applied) so the state is current on the next run without another spreadsheet export.

The measurable claim is not “faster collections”. It is a reduction in reminders sent against invoices that a reminder could never have moved, and a reduction in the time a dispute sits without an owner. Those are countable before and after. I have written separately about how to tell whether an AI workflow is actually working, and collections is a domain where the vanity metric, messages sent, is especially easy to mistake for progress.

What stays under human control?

“Human in the loop” is not a mode you switch on for a whole system. It is a decision taken action by action, and in collections exactly three actions fail the test, for three different reasons. I have set out the general version of that test in where human-in-the-loop actually belongs in an AI workflow; here is how it lands on a receivables ledger.

Asserting a legal claim. Charging statutory interest, issuing a formal notice of default, or referring an account to legal counsel are assertions with legal effect. The system can compute the interest, draft the notice and show the evidence trail. A named person signs it. This is the same boundary I drew in the prior authorization teardown: the model can prepare the adverse action and must never be the author of it.

Commercial decisions about a relationship. Credit hold, renegotiated terms, writing off a balance to keep an account. These trade cash against a relationship, and the trade is not visible in the receivables data.

Anything that scores a person. Here the line is legal and easy to cross by accident. Annex III of the EU AI Act classifies AI systems “intended to be used to evaluate the creditworthiness of natural persons or establish their credit score” as high-risk, with a carve-out only for fraud detection. Scoring a limited company’s payment behaviour is outside that. Scoring a sole trader or a freelancer is not: they are natural persons. A collections tool that quietly adds a “customer risk score” and applies it to a customer base containing individuals has changed regulatory category without anyone filing a ticket. Keep behavioural signals attached to invoices and accounts, and if a score of people is genuinely needed, treat it as a high-risk system and build it as one. The same logic runs through what an AI-native compliance workflow would look like.

Worth noting on the regulatory side: the European Commission proposed in 2023 to replace the directive with a regulation capping payment terms at 30 days, and the European Parliament adopted a position in April 2024. The file has been blocked in Council since. Anyone hard-coding a 30-day rule today is encoding a proposal, not a law.

When this is the wrong build

Skip it if your receivables are concentrated in a handful of customers. Twelve accounts do not need a classifier; they need someone who knows them to make twelve phone calls.

Skip it if the reasons for non-payment are not recoverable from any system you have. If invoices are disputed by phone and nothing is written down, the classifier has nothing to read, and you are building a cold-start data collection project wearing an AI costume. Fix the recording first.

Skip it if the real problem is upstream. If your invoices are frequently wrong, late, or sent to the wrong entity, a collections system will very efficiently discover that fact and then have nothing useful to do about it. That is the failure mode I described in why adding an AI agent to a broken workflow usually fails, the process was already the problem.

And skip it if the intended outcome is more pressure. Automated pressure applied to customers who are themselves waiting to be paid is how the gap propagates: 62 percent of businesses in the Intrum survey said delays in receiving payments cause them to pay their own suppliers late.

Summary

This is a designed system, not one I have deployed. It stays that way until someone who runs a real ledger loads twelve months of invoices, disputes and bank lines into it and shows me which of my six states the messy cases refuse to fit.

But the design principle holds independently of the build. A collections system that treats “overdue” as a single condition will send reminders into disputes forever, and it will get faster at doing so every year. The useful question is not how quickly you can chase an invoice. It is whether anything in your stack knows why the invoice is still open and if the answer is only a person’s memory, that is the system to build first.