Why the way you invoice decides how much work reconciliation becomes, what an agent takes over in the chain, and where it stops.
What is order to cash?
Order to cash, often shortened to O2C, is the whole process from the moment a customer orders something to the moment the money is in your account and the item is reconciled. In steps:
- The customer places an order
- The order is accepted and credit is checked
- Goods or services are delivered
- An invoice is raised
- The invoice is sent and chased where needed
- The customer pays
- The payment is linked to the open items
- Differences are cleared and disputes resolved
Steps 4 through 8 are receivables. That is what AI agents for accounts receivable covers. This piece is about the chain around it, and above all about the link between how you invoice and how heavy your reconciliation becomes.
This is the mirror of procure to pay on the buying side. The patterns rhyme, with one difference that genuinely matters: on the buying side you set the process, on the selling side your customer decides how they pay.
Where the chain breaks in practice
| Step | What goes wrong | What we saw |
|---|---|---|
| Order | The customer's reference never makes it onto the invoice | Without that reference they cannot approve it, so they pay late or in part |
| Entity | You invoice from one entity, the customer pays centrally from the group | At a travel services company on NetSuite invoicing runs per entity while one group payment arrives, which makes putting it back manual |
| Invoicing | What the contract says is not in the invoicing rhythm | Deviating terms and tiers live in a contract, not in the system that raises the invoice |
| Consolidating | You bundle to spare the customer and burden yourself | That same company deliberately sends one consolidated payout statement so suppliers do not get hundreds of invoices, and then has to tick off hundreds of lines one by one in the ERP |
| Payment | The customer withholds something or pays in another currency | A receipt in euros cannot go against an invoice in Canadian dollars, so it runs through a suspense account |
| Reconciliation | A one-cent difference blocks the match | €90 against €90.01 halts the entire bank reconciliation |
| Bank | There is no live connection | Statements are exported and uploaded by hand every day |
Look at the fourth row. That is the sharpest version of what this article is about: a choice you make to help your customer moves the work into your own books. Nobody made that trade-off deliberately, and nobody measures what it costs.
Why the invoicing side decides the reconciliation side
Three things at the start of the chain almost entirely decide how heavy the end becomes.
Whether the customer's reference is on the invoice. Large buyers pay against their own order number or purchase reference. If it is not there, the invoice stalls in their approval process, and when payment does come it is often an amount that lines up with nothing.
Whether you invoice per order or consolidated. Consolidating is customer-friendly and makes your own reconciliation heavier, unless you send along how the bundle is built up. That is the trade-off nobody makes explicitly.
Whether your invoicing entity matches the entity that pays. If it does not, one amount arrives that has to be split across several sets of books. That is doing by hand what a system could have done, every month again.
None of those three is solved by better reconciliation software. You solve them by doing something different at the front, or by having something at the back that can cope with it.
Six things an agent takes over in the order to cash chain
1. Invoicing from what was actually agreed
Raising invoices from contracts, subscriptions, delivered hours or orders, including the deviating terms and tiers agreed per customer. The point is not that it goes faster, but that what the contract says travels to the invoice without anyone retyping it.
2. Carrying the customer's reference through
Order number, purchase reference, cost centre, approval contact. An agent pulls those from the order, from earlier correspondence or from the customer's portal, and makes sure they are on the invoice. This is the cheapest intervention in the whole chain and it is rarely done, because it sits slightly differently per customer and that is hard to capture in fixed rules.
3. Sending the build-up with a consolidated invoice
If you invoice consolidated, a machine-readable specification belongs with it. Then the customer can handle their side and you can put their payment back later without ticking off a hundred lines. An agent assembles that specification in the format that works for that customer.
4. Putting payments back across entities and currencies
One group payment that has to be split across several sets of books. A receipt in one currency against invoices in another. A customer withholding a bank charge or factoring fee. An agent links the lines, clears the difference by your rule, and records why.
5. Classifying differences before anyone looks at them
A discount, a credit note, an exchange difference, a withholding and a genuine dispute each call for a different action. Only the last is worth a conversation with the customer. An agent decides the category, handles what your rule allows, and presents the rest with the reason attached.
6. Making visible where the chain structurally leaks
Which customers structurally pay without a usable reference. Which customers always stall on the same withholding. Which entities produce the same manual work every month.
That list falls out of the work the agent does anyway, because it meets every exception and knows why it arose. For a finance director that is more useful than a DSO report, because it points at something you can change rather than only reporting that it takes longer.
Traditional order to cash versus agents
| O2C suite or ERP module | AI agent on top | |
|---|---|---|
| Starting assumption | The customer pays the way you invoice | The customer pays the way they want, and that is the starting point |
| Payment without a reference | Sits there until someone works it out | Candidates proposed on amount, customer and history |
| Consolidated payment | Tick off line by line | Specification read and linked |
| Foreign currency | Suspense account plus journal entry | Matched across currencies, exchange difference by your rule |
| Rollout | Months, migration | On top of what you have |
| What you can report | How long it took | Where it structurally goes wrong, and with whom |
This is not an argument for tearing out your existing receivables tool. If you invoice per order, the customer's reference is always on it and one payment arrives per invoice, what you have is enough. If reality differs from that, and it does at almost everyone, that is where your work sits.
Where it stops
Your customer decides how they pay. That is the essential difference with the buying side. You can ask them to send a remittance advice, but you cannot enforce it. An agent can cope with it better; it cannot change it.
Without any clue there is nothing to link. One amount with no description that fits no combination of open items stays a question for the customer. The agent asks that question and processes the answer, but it does not guess.
We do not build the selling side. Claridy runs on invoicing, receivables and reconciliation, and reads your orders out of your ERP. If you want a system for quotes, contracts and order management, that is a different category.
How to start
- Measure what share of your incoming payments does not link automatically. That single number is your business case, and it appears in no standard report.
- Break that group down. Missing reference, consolidated payment, partial payment, withholding, currency, cent difference. Each category has a different fix, and two of them are fixed on the invoicing side.
- Look at your consolidated invoices. If you bundle to spare the customer, send a machine-readable specification with it. That is often the cheapest intervention in the whole chain.
- Write down your clearing rules. Up to what amount a difference can be cleared, to which account per type.
- Run the agent supervised first. Every link as a proposal, your team approves, then you move the threshold.
Frequently asked questions
Order to cash is the whole chain from order to money received. Receivables management is the part from the invoice onward. Most of the work in receivables is caused by what was or was not carried through in the invoicing step.
That chain is the mirror on the buying side: from request to payment. The patterns rhyme, with this difference: on the buying side you set how the process runs, on the selling side your customer decides how they pay. More on that: AI agents in procure to pay.
It depends where your work sits. If you want to manage quotes, contracts and orders, you need a sales system. If your work is invoicing and putting payments back, an agent on your ERP solves that faster, without a migration.
Then that is the first question, and it is worth asking it of the ten customers who together carry the most volume. For the rest, an agent can propose candidates on amount, customer and history, and you confirm those rather than hunting for them.
Partly. Faster reconciliation keeps your open items list correct, so you chase the right customers. The biggest gain is in hours, not in days. Measure the number of manually linked lines instead.
Processing inside the EU, read-only where possible, and an exportable audit trail per action. The SOC 2 programme is under way and certification is coming. In more depth: is AI safe for your books.
What Claridy does on this chain sits on the order to cash and reconciliation product pages. The receivables side: AI agents for accounts receivable. The mirror on the buying side: AI agents in procure to pay. Deeper on reconciliation itself: reconciliation software and matching.
Last checked: 2026-08.