Order-to-cash, procure-to-pay and record-to-report

What are order-to-cash, procure-to-pay and record-to-report?

They are the three end-to-end process families that most ERP and automation work is aimed at, and each is named after where it starts and where it stops. Order-to-cash (O2C) runs from a customer order to the money sitting in your bank account. Procure-to-pay (P2P) runs from someone needing something to the supplier being paid for it. Record-to-report (R2R) runs from a booked transaction to the figures you report.

The naming style is deliberate. Sales, the warehouse, purchasing and finance each have their own department word for their piece of the work. Order-to-cash refuses to pick one of them and names the whole run instead, from the first system that touches the order to the last one that touches the payment.

The names are industry vocabulary, not a standard, so check the boundaries before you compare numbers with anyone. Microsoft's business process catalog for Dynamics 365 gives order to cash the number 65 and record to report the number 90, and calls its purchasing family source to pay, because it starts a step earlier: at sourcing and supplier selection instead of at the requisition. SAP's own training material and most process mining vendors use the shorter procure-to-pay.

Order-to-cash, step by step

The run is: a customer orders, you check credit and availability, you confirm, you deliver, you invoice, the customer pays, and you settle that payment against the right invoice. Microsoft defines it as everything from a customer placing an order until the payment is received and settled with the invoice. It ends at the bank, which is why the name says cash and not invoice.

Four figures tell you how the run is doing.

• Days sales outstanding (DSO). Celonis defines it as the average time in days a company takes to collect payment for goods and services sold on credit: accounts receivable divided by credit sales, times the days in the period. It converts straight into cash.

• Order-to-delivery time. The customer's clock, from ordering to having the goods. This is the figure that turns up in complaints.

• Invoice accuracy. The share of invoices that leave right the first time: right price, right quantity, right VAT number, right order reference.

• Dispute rate. The share of invoices a customer queries. A dispute stops the payment clock without stopping the invoice, so it inflates DSO in a way that reads on a dashboard as slow-paying customers.

What one problem costs. A wholesaler turning over 3 million euro carries 500,000 euro of open receivables, so DSO is 500,000 divided by 3,000,000, times 365: about 61 days, on payment terms of 30. One day of DSO is worth 3,000,000 divided by 365, about 8,200 euro. Getting from 61 days to 45 releases 16 times 8,200, roughly 130,000 euro of cash, once. That is the credit line the company is renting from its bank to fund its own invoicing habits. The customers turn out not to be the main cause: about one invoice in sixteen is queried over a price or a delivered quantity, and each query sits some nine days before anyone answers it.

Procure-to-pay, step by step

The run is: someone needs something, a requisition is raised and approved, a purchase order goes to the supplier, the goods or the service arrive and get receipted, the supplier's invoice comes in, it is matched and approved, and it gets paid. The order of the steps is the point. An invoice that arrives before anyone raised a purchase order cannot be matched against anything, and from there it is a phone call, not a process.

Three-way matching is the control at the centre of it. Microsoft's accounts payable documentation describes it as matching the price information on the invoice against the price on the purchase order, and the quantity on the invoice against the quantity on the product receipts that were posted. Three documents have to agree: what you ordered, what you received, what you are billed for. Two-way matching drops the receipt and compares the invoice against the order only. Tolerances make it workable, so a company can allow a price variance of a few percent and hold anything outside that until someone approves it. The usual failure is not a wrong invoice slipping through. It is a correct invoice stuck for a week because nobody in the warehouse posted the goods receipt.

• Touchless invoice rate. The share of supplier invoices that arrive, get read, matched, approved and posted with no person touching them. Ardent Partners' 2025 accounts payable benchmark puts the top performers at 49.2 percent, which also tells you that handling half your invoices by hand is still a good result.

• Cost per invoice. The same benchmark has best performers processing one for 2.78 dollars, against an all-buyer average of around ten. Almost the whole gap is matching and approval routing, not typing.

• Payment on time. Paying late costs supplier goodwill and early-payment discounts; paying everything the day it lands costs working capital.

• Maverick buying. Any purchase made outside the organisation's procurement policies, approved contracts or preferred supplier lists, in Esker's wording: a non-contracted supplier, no purchase order, a company card. Measure it as the share of spend that lands with no matching purchase order.

What one problem costs. A manufacturer handles 6,000 supplier invoices a year and measures its own cost at about 8 euro each in staff time. One in five goes through untouched, and of the ones that get touched, roughly half are held because the goods receipt was never posted, so a clerk chases the warehouse and reprocesses the invoice two days later. Posting receipts on the day of delivery, and nothing else, lifts the touchless rate to 45 percent: 1,500 fewer invoices by hand, about 12,000 euro a year. On the same site, 180,000 euro of the 1.2 million in non-strategic spend is bought off-contract, and a sample of ten items shows those purchases running about 8 percent above the negotiated price, another 14,000 euro. Neither number needed new software to find. Both needed a purchase order number on the invoice.

Record-to-report, step by step

The run is: transactions get captured in the sub-ledgers, they post to the general ledger, accounts get reconciled, adjustments and accruals get booked, entities get consolidated, and the statements come out. Microsoft groups the same family as data gathering, journal entry, account reconciliation, financial reporting and financial analysis, and calls it the financial recording and close process.

R2R differs from the other two in one way that changes how it behaves: week to week, nobody outside the company is chasing it. No customer is waiting on your bank reconciliation and no supplier phones about your accruals, so the work slides to the end of the queue, and the cost of it sliding shows up later, as decisions taken on old figures.

• Days to close. Count the calendar days between running the trial balance and signing off the consolidated figures. APQC's general accounting benchmark measures exactly that, and the published cross-industry medians have sat in the range of roughly a working week for years. The number matters less than the trend in your own numbers: if the close took six days in January and nine in June, something in the source processes changed.

• Manual journal entries. Every manual entry is either a real accounting judgement or a system that did not post what it should have. Split them by cause: the second group is a configuration problem, not an accounting one.

• Reconciliation exceptions. Open items on bank, intercompany and clearing accounts that nobody has explained yet. The age of the oldest one tells you more than the count does.

What one problem costs. A group of two legal entities with forty staff books about 180 manual journal entries a month. The controller times them at roughly seven minutes each to prepare, check and file: 21 hours a month, about 250 hours a year, which at a loaded 60 euro an hour is 15,000 euro. Split by cause, 110 of the 180 are the same recurring accruals every month, which a recurring journal template posts on its own. That is about 9,000 euro of the 15,000, and two days off a close that runs to twelve working days. Those twelve days are the more expensive half: June's margin lands on the managing director's desk on 18 July, so a mispriced product line sold from early June gets corrected in late July, after seven weeks of orders at the wrong margin.

Why the names are worth using

The first reason is commercial: these are the units the market is organised around. Process mining vendors sell an order-to-cash app and a procure-to-pay app, and Microsoft's catalog goes six levels deep under each one, down to test cases. Say "our invoicing is slow" and you get a demo. Say "our order-to-cash cycle is 61 days and we think disputes cause it" and you get a conversation about your own numbers.

The second reason is that each family crosses departments, which is why it needs a name of its own. Order-to-cash passes through sales, the warehouse, invoicing and credit control, and nobody in the line hierarchy owns the whole run, so each department optimises its own leg while the total gets worse. Sales books a delivery date the warehouse cannot make, the warehouse ships in the cheapest configuration and the invoice goes out wrong, and credit control chases a customer who is right to refuse. The process owner entry covers the job of holding that run together.

The third reason is where the money sits. Almost every measurable loss in these three families is at a handover rather than inside a step, and a handover has no department to send the bill to. The next section names the three that cost the most.

APQC's Process Classification Framework, the other widely used taxonomy, cuts the same work the other way. Its thirteen level-1 categories are functional, such as Market and Sell Products and Services and Manage Financial Resources, and one order-to-cash run passes through several of them. The functional taxonomy is for saying who does what; the end-to-end names are for following one order all the way through.

Where the three processes meet

Microsoft's catalog lists record to report as a downstream process of both order to cash and source to pay, and the two operational families as upstream and downstream of each other. That gives you three interfaces you can point at on a whiteboard.

An unpaid O2C invoice becomes an R2R problem. It ages in the receivables list, it drives the bad debt provision, and if it was invoiced in the wrong period it moves revenue across the cutoff. Finance argues about a number whose cause is a delivery dispute from two months ago that sales settled by email.

A missing goods receipt in P2P blocks two processes at once. Accounts payable cannot three-way match the invoice, so the supplier waits. At the same time the accrual for goods received but not invoiced is wrong, so R2R closes on a stock and cost figure that does not match what is on the racks.

A direct delivery ties O2C to P2P in one step. Microsoft notes that in a direct delivery sales model the sales order itself can trigger the purchase order with the supplier. From that moment your customer's delivery date depends on your supplier's, and a purchasing delay reaches you as a sales complaint.

Procure-to-pay against order-to-cash

The two look like mirror images on paper: same documents, same matching logic, opposite directions. They behave nothing alike, and the reason is which side of the transaction you stand on.

In order-to-cash you are the seller. You issue the invoice and then you wait, because the cash arrives when somebody else decides to release it. Your exposure is timing, and timing is your customer's choice. Cutting DSO means changing their behaviour, with reminders, credit limits, order holds and, at the far end, stopping the deliveries. That is a commercial decision before it is a process one.

In procure-to-pay you are the buyer. The invoice arrives and you decide when to release the payment, so your supplier is the one waiting on you. Lifting the touchless rate means changing what your own people do, and you can decide it on a Tuesday without asking anyone outside the building. That is why procure-to-pay automation projects tend to finish, while order-to-cash projects turn into a policy discussion about credit terms and who is allowed to stop shipping to a customer.

If you have no ERP, you still have all three

The processes are not created by the software. A ten-person company that quotes in Word, invoices from an accounting package and keeps stock in a spreadsheet is running order-to-cash exactly as described above. What changes is where the timestamps live. In an ERP, the moment an order was confirmed is a field in a table. In a mailbox it is a sent item nobody will ever aggregate, which is why process mining has little to work with in a company like this, while the same company can usually tell you in one afternoon where the waiting happens.

So the first move is not a system. Pick one of the three families, write the steps on one sheet with a name against each, then take last month's cases and count how many went through in that order and how many did not. The second number is your list. In an SME it is usually short and usually the same three causes: an approval that lives with one person, a document that gets created twice, and a step nobody is responsible for because it falls between two people who each think it belongs to the other.