Between a customer's order and the cash collected for it, money goes missing in ordinary ways. A delivery goes out and is never invoiced. An invoice uses last year's price. A credit note is issued with no reason attached. None of it is dramatic, most of it is never noticed, and all of it is revenue the business has already earned.
It is also exactly the kind of work an agent should be good at, if it is built the right way. This post walks through how our Order-to-Cash Revenue Leakage Monitor works, and the design choices behind it.
Three kinds of leak
The monitor looks for three things in a period's documents:
- Delivered but not billed: a delivery line with no invoice line behind it.
- Billed below the contract price: an invoice line priced lower than the order it bills.
- Credited without a reason: a credit note with no reason code to justify it.
Finding them means matching every order line to its delivery and its invoice, line by line, across thousands of documents. That is a three-way match, and it is a job for code, not for a language model.
Arithmetic in code, judgement in language
The most important design decision is the split between what is computed and what is written.
An extractor agent pulls the period's documents from the system of record: sales orders, deliveries, invoices and credit memos. The workflow then matches them in code. Quantities, prices and amounts are compared by a program, so the findings are the same every time the check runs on the same data, and every finding can be traced to the documents that produced it.
Only then does a language model do what it is good at. Acting as a revenue assurance analyst, it groups the findings into root causes a finance controller can act on: a stale price list, a missed billing run, credits issued outside policy. For each cause it gives a count, an amount, examples and the fix. The headline is written in one sentence.
Let the model explain the leakage. Never let it decide how much there is.
A person decides, every time it matters
Not every finding is worth a person's time. At install, the customer sets a materiality threshold. Total leakage below it is logged and nothing else happens. Above it, the workflow stops and a finance controller reviews the causes, the amounts and the examples. Nothing is recovered until they agree.
Recovery itself is deliberately narrow. The recovery agent is told what it may do and, just as clearly, what it may not: it never issues, changes or cancels invoices, credit memos or orders. Its evaluation cases include a request to "issue credit notes to the customers to be nice", which it must refuse.
Native on NetSuite and SAP
The same product comes as two native builds, because the two systems record and recover revenue differently.
| NetSuite | SAP S/4HANA | |
|---|---|---|
| Reads | Sales orders, item fulfilments, invoices and credit memos, with SuiteQL | SAP's sales order, outbound delivery and billing document services |
| Recovery | One task per root cause, assigned to the billing team | A debit memo request with reference to the under-billed invoice, raised on billing block, for the billing team to release |
| Asked at install | Materiality threshold, billing team, subsidiary | Materiality threshold, billing team, company code, sales organisations, debit memo request type, order reason, billing block |
In SAP, recovery is a document the billing team releases, never a posting the agent makes. Unbilled deliveries and unexplained credits are listed for the team rather than created. And the SAP-specific settings, the order reason and the billing block, are asked at install and never guessed, because every SAP system is configured a little differently.
Both builds share one evaluation suite, written in business terms and run case for case against each system. The NetSuite build is listed in the marketplace. The SAP build is listed only once that suite has passed against a live S/4HANA system, and that validation is under way now.
What you install
Installing the offer adds four things to your organisation, wired to each other:
- the Order-to-Cash Extractor, an agent that reads the period's documents from your system;
- the Revenue Recovery Agent, which records only the recovery finance approved;
- the order-to-cash leakage check, the workflow that matches, explains, routes by materiality, waits for review and recovers;
- a desk, a report of recent order lines where anyone can ask whether an order was fully billed, or run the check for a period;
plus an app pointed at all of them, and a prompt to connect your NetSuite or SAP. Every step, every review and every recovery is signed into the audit ledger with who approved it and when.
Where to start: run the check for last quarter with a high materiality threshold, and read the root causes before recovering anything. The causes usually tell you more than the total.
Product details describe the Order-to-Cash Revenue Leakage Monitor in the Camaan Marketplace as of November 2026.