Every accounting system has a "who owes us money" report. 1C, MoySklad, Bitrix, any CRM. It opens in three clicks, lists debtors with amounts, and sorts by days overdue.

Almost nobody works from it.

That isn't laziness. It follows from the report answering the wrong question. It says "Ivanov owes 340,000, 47 days." What a person needs in order to do anything is different: is the debt actually overdue, which of these seventy rows should I write to today, and what did this customer say last time?

Between those two questions sits roughly an hour of work per debtor. That is why nobody works from the report: it doesn't save time, it assigns time.

What follows is where the line actually runs. What an accounting system does in this task — with no AI needed anywhere near it — and what simply wasn't being done before language models, not for lack of integrations, but because half the source data was text rather than numbers.

## First — where AI is not needed

Let me start with what you shouldn't pay for, because a lot of unnecessary things get sold around receivables.

**Adding up debts and bucketing them by age is arithmetic.** Every accounting package does it: shipments minus payments, split into 0–30, 30–60, 60–90. Receivables turnover is a two-line formula. If someone offers you a neural network that "analyses your receivables" and hands back those same buckets, you are being sold a report at the price of an agent.

**Reminding on a calendar is a scheduler.** A CRM task on a date, a mail-out on a schedule, a notification three days before the due date. That is configuration, not a model.

Everything below starts where those two tools end.

## Three reasons the number in the report is wrong

**First: those 47 days overdue are usually fiction.**

The report counts from the shipment date plus whatever term sits in the settings. The real payment term lives in the contract. Every customer has their own: thirty days, sixty, "ten banking days from the date the acceptance certificate is signed" — and for one of them, "on sale", which means the clock hasn't started at all.

And a contract is not a database field. It is a PDF. In an EDI system it sits as a non-formalised document whose very filename is stored not in the structure but in metadata, as a string: `FileName: Contract.pdf`. The machine sees an attachment, not a term. Until a model could read the document and pull the term and the settlement order out of it, those forty-seven days were simply never checked by anyone.

**Second: part of the amount isn't debt, it's a discrepancy.**

Of that 340,000, 120 may be disputed: we shipped, the customer didn't accept, or accepted in part, and that is visible only in the reconciliation act. The reconciliation act is its own document type in EDI (`AktSverIskh` and `AktSverVkh` in SBIS, its own in Diadoc), with a period you have to request explicitly.

And reconciling is matching two lists of operations whose names don't agree: ours reads "Shipment No. 112 of 14.05", theirs reads "UPD 000112". Everyone who has tried to automate this with rules knows how it ends — the rule works for one counterparty and breaks on the next. This is precisely the task where rules are helpless and a model is not.

**Third: the customer's promise is stored nowhere.**

"We'll pay after the next batch ships", "send us a reconciliation act, we show a discrepancy", "our accountant is on leave until Monday" — that is an email or a chat message. It is a fact that changes both the priority and the wording of your next letter. It exists nowhere in the accounting system, and it never will.

Three reasons, and all three are about the same thing: what you need to know about a debt lives in text, and the accounting system sees only numbers. Which is why its report is technically correct and practically useless. But there is a fourth, and it costs more than the first three combined.

## And the fourth, most expensive reason: it's already too late to write

Everything above is about writing to someone sooner. There is a separate row where the question is different: whether to write at all, or to go to court.

A customer who has entered bankruptcy proceedings, who has enforcement proceedings against them, or who lost three arbitration cases in a row last month, is not "a debtor 47 days overdue". That is a debtor with a queue forming, and your place in it is decided by a date, not by how politely your letter is worded.

None of that is in your accounting system and never could be — it lives in state registries and counterparty-check services. Signs of bankruptcy, arbitration cases, enforcement proceedings, an express risk rating: all of it is returned by tax number, and in batches — seventy debtors are checked in a single pass, not one at a time by hand.

And the same services carry the mechanism that makes this worth setting up once: **a monitoring list.** Debtors go into it, and the service returns the changes since your last read. The question "has anything happened to the people who owe us" stops being a task you have to remember to perform, and becomes a line that arrives by itself on the day something happens.

The same section holds the second date people remember too late. **The limitation period is three years**, and it runs not from your last letter but from the moment the obligation should have been performed. A debt that is two years and ten months old isn't a row in a report, it's a deadline. And it is interrupted by the customer acknowledging the debt — the most ordinary form of which is a signed reconciliation act, the very one this task is already collecting.

The report doesn't distinguish any of this: to it, a 47-day debt and a 1,040-day debt are two rows sorted descending. The difference is that the second one is about to stop existing.

## What the agent does

The difference between a report and an agent here is not intelligence. It is how many places one row is assembled from.

**It takes the debt from source documents, not from the report.** That is less obvious than it sounds. MoySklad, for instance, has a ready-made "Counterparties" report — and you must not take debts from it: it holds sales metrics rather than settlements, and it also requires a separate permission on the employee's role. Debt is computed from unpaid shipments: per customer, the sum of the differences between the document total and the part already paid. With its own traps — amounts arrive in kopecks and must be converted to roubles before summing, not after; accounts that don't issue shipments have to be read from invoices and orders instead; and an unlinked payment, entered by the bookkeeper but never matched to a shipment, inflates the debt and looks exactly like an overdue balance.

None of those traps is about AI. But every one of them is about why "just export the debts" doesn't work, and why the figure in your very first letter to the customer turns out to be wrong.

**It reads the contract and extracts the term.** Not "searches for keywords", but answers a question: from what event does the deferral run, how many days, is there a penalty and from which day. Then the overdue count is recalculated for real — and the list gets shorter, sometimes by half.

**It reconciles and separates disputed from undisputed.** Because writing to a customer about 340,000 when only 220,000 of it is undisputed hands them a reason to pay nothing at all and spend a month sorting it out.

**It pulls in the correspondence and remembers what was promised.** A customer who wrote "we'll pay on Friday" two weeks ago and a customer who has been silent since May are two different conversations, and the difference between them isn't the amount.

**It checks debtors against registries and watches the clock.** One pass by tax number across all of them — and the top of the list turns out to hold not whoever owes the most, but whoever has entered bankruptcy or is running out of limitation period.

What comes out is not a report but a list for today: who to write to, why this one, how much is undisputed, what they said last time, and what the next step is. Fifteen minutes instead of an hour — and, more importantly, a list you can hand to someone who doesn't understand accounting.

## Where the agent has to stop

Now the awkward part, the one usually skipped in announcements.

**Our agent does not send the letter to the debtor itself.** Prepare it — yes: gather the amount, attach the act, write the text taking the history into account. But an outbound action — sending a message, an email, publishing something — requires a human's confirmation at any autonomy level, including the one where the agent is allowed to change data without asking.

This looks like an unfinished feature and is in fact a deliberate decision. Here is the reason. When an agent changes something inside your systems, you can roll it back. When it has written to your customer, nothing can be rolled back. A second person appears, one nobody consulted, and the cost of a mistake stops being internal. A payment demand sent to the wrong counterparty, or with the wrong amount, costs more than the whole hour you saved.

Separately, about the thing that sounds tempting and works badly: **auto-dialling debtors**. Technically it is doable — telephony connects, speech synthesis exists. In practice the first non-standard answer ("our act isn't signed, sort it out and call back") turns the call into irritation, and irritation converts into non-payment more reliably than any reminder. Receivables are a relationship with a customer you want to take money from and keep working with. Blasting identical demands at everyone breaks exactly the thing it set out to fix.

## What it looks like in practice

The routine we usually set up first sounds mundane: every morning at nine.

The agent pulls unpaid shipments, computes debt per customer, goes into EDI for the contracts of everyone formally overdue, recalculates the real terms, separates disputed amounts using the reconciliation acts, pulls the latest correspondence, and folds all of it into one list. The list arrives in chat.

Then a person looks at five rows instead of seventy and says: write to these two, I'll call this one myself, this one is a dispute — prepare the act.

What matters here, and is usually underrated: **the value is not in the wording of the letter, it is in the list getting shorter.** Any model can write a polite reminder; that is the cheapest part of the job. Filtering out those whose term hasn't come, those with a dispute, and those who already replied — that is the work that took an hour and that nobody was doing.

## What follows

**First: don't ask whether the AI "works with receivables", ask how many sources one row is assembled from.** If it's one — your accounting system — you are being sold a report you already own. The value appears at the second and third source: the contract and the correspondence.

**Second: half the effect is not money collected, it's letters not sent.** Customers whose term hasn't come, customers with a disputed amount, customers who have already replied — every unnecessary demand costs you the relationship. The report can't tell them apart. In that sense good receivables automation is measured not by how much was sent, but by how much shorter the list became.

**Third, and it reaches beyond receivables.** The line between "report" and "agent" doesn't run along computational difficulty. It runs along whether the source data sits in a table. Everything in a table was automated twenty years ago, and a language model adds nothing there. Everything in a contract, an email, a scan or a chat was, until recently, handled only by a human — and that is where all the unclaimed value currently sits. Receivables are simply the clearest case, because they come with a price in roubles and a deadline.