Order-to-cash process flowchart (order received to cash applied)
A six-lane order-to-cash process flowchart: order and master data check, credit hold and release, dispatch, proof of delivery, invoicing, cash application, short-payment deductions, dunning and write-off.
What the order-to-cash process flowchart (order received to cash applied) process is
Order-to-cash is the only process in a company where the money actually arrives, and it is almost never owned by one person. Sales owns the order, credit control owns the limit, the warehouse owns the goods, billing owns the invoice and accounts receivable owns the chase, and each of them is measured on a different number: orders booked, exposure, on-time dispatch, invoices issued, days sales outstanding. The result is a cycle that looks healthy in every function's own dashboard and still takes seventy days end to end. The damage is rarely in the middle of a lane. It is at the joins: an order sitting on credit hold that nobody has told the customer about, a delivery with no signed proof so billing will not release the invoice, an invoice rejected by a customer's accounts payable portal for a missing purchase order number so the payment clock never started, a short payment recorded as an overdue balance and chased for three months by someone who does not know a dispute exists. Every one of those is invisible from inside the function that caused it, which is why drawing the whole cycle on one page is usually the cheapest way to find out where your own cash is really stuck.
This chart is the full cycle, which means it is deliberately shallow in the two places where a sibling page goes deep. The warehouse half (stock allocation, backorders, partial shipments, picking, packing and the carrier handover) is compressed into a single step here and drawn properly at /templates/order-fulfillment-process, with the floor-level detail at /templates/picking-packing-process. The collections half (the reminder ladder, instalment plans, credit note authority and bad-debt provisioning) is reduced to one dunning step, a referral to collections and a write-off approval, and drawn properly at /templates/accounts-receivable-process. How a customer gets a credit limit in the first place, as opposed to how an order is checked against one, is a separate approval flow at /templates/customer-credit-approval-process. Everything before the order exists (lead, quotation, discount and terms approval, and the signed order form) is the front half of the quote-to-cash cycle at /templates/quote-to-cash-process, which spans the same arc as this page but carries its depth in the pricing work rather than in fulfilment and collections. And the procurement mirror of this cycle, where you are the customer and the money leaves rather than arrives, is at /templates/erp-p2p-process-flow. Use this page when the question spans functions; use one of those when the question sits inside one.
Three joins are drawn explicitly because most written procedures leave them to habit. The credit hold is a loop rather than a gate: "Credit hold released?" branches three ways (released, prepay first, refused) and the prepayment route comes back for a re-check instead of leaving the process, so an order taken off hold by a payment is still an order somebody has to confirm and release. "Proof of delivery received?" sits between dispatch and billing rather than after it, which makes the invoice depend on evidence that the goods arrived instead of on the fact that they left. And "Paid in full by the due date?" branches three ways, not two: a short payment goes to "Code the deduction and open a dispute" and is investigated against the order and the proof of delivery by the people who can settle it, while silence goes to the dunning ladder. Separating a short payment from a non-payment is the single change that most reduces wasted collections effort, because the two have different causes, different owners and different fixes.
What this flowchart covers
In this template
- Six swimlanes (Customer, Sales and customer service, Credit control, Warehouse and logistics, AR and cash application, Finance controller) laid across five phases: Order capture, Credit and confirmation, Fulfil and deliver, Invoice and cash, and Collections and closure.
- Order capture with a real correction loop: "Order and master data complete?" sends an incomplete order back to the customer to "Supply the missing order details" rather than on into the warehouse queue, with a note on which master-data fields should block an order and which should only warn.
- The credit-hold release loop. "Credit exposure within limit?" routes an over-limit order to "Place the order on credit hold", and "Credit hold released?" then branches three ways: released, prepay first (which loops back for a re-check) or refused, ending at "Order cancelled on credit refusal".
- A billing gate that depends on evidence rather than on dispatch. Fulfilment is one collapsed step, then "Proof of delivery received?" either releases billing or sends the order to "Chase the carrier for proof" and back round to the same test.
- A three-way "Paid in full by the due date?" decision separating payment, short payment and silence, so a deduction is never worked as though it were an overdue balance and a genuinely overdue balance is never parked as though it were a dispute. "Customer response?" then routes a customer who disputes once chasing has started back into the same investigation rather than opening a second one.
- The deduction branch and three endings. A short payment goes to "Code the deduction and open a dispute", is investigated against the order and POD, and a "Deduction valid?" test either raises a credit note or joins the dunning ladder; the cycle ends at "Invoice cleared and order closed", at "Balance written off" once a controller approves it, or at the cancelled order.
When to use this template
- You are trying to shorten a cash conversion cycle and need to see whether the delay sits in credit release, in dispatch, in getting the invoice out, or in unresolved deductions, before anyone starts a project.
- You are implementing or reconfiguring order-to-cash in an ERP and want the credit-block rules, the billing trigger and the deduction reason codes agreed by the business before they are encoded as configuration.
- Sales and credit control are arguing about held orders, and you need the release authority, the response time and the prepayment route drawn rather than negotiated case by case.
- Your AR ageing is full of small residual balances nobody can explain, and you need the short-payment route separated from the overdue route so deductions reach the person who can settle them.
- You are writing the process narrative for an internal or external audit of the revenue cycle and need one controlled diagram showing where the credit, delivery-evidence, billing and write-off controls sit.
How it works
Rename the lanes to your own organisation
Replace Customer, Sales and customer service, Credit control, Warehouse and logistics, AR and cash application, and Finance controller with the functions you genuinely have. Small finance teams merge credit control into AR and lose nothing; shared service centres usually need billing split from collections, because they are different teams in different places. If a third-party logistics provider ships for you, give the 3PL its own lane so the boundary of your own control is visible. Keep the person who approves a write-off in a different lane from the person who chases the debt.
Write your credit policy into the exposure check
"Credit exposure within limit?" is inert until you say what exposure means. State whether it includes open orders, goods delivered but not yet invoiced, invoices outstanding and amounts under dispute, then check what your ERP actually calculates, because the two are often different. Record the limit source — an internal scorecard, a credit agency rating, a group limit shared across trading entities — and what happens to a brand-new customer with no history, which is usually prepayment or a small starter limit rather than a blank field.
Give the credit hold a service level and an owner
A hold with no clock is an order lost. Name who may release one and up to what value, set a response time in working hours rather than days, and decide who tells the customer their order is on hold and what they are allowed to say. Add the escalation route for a release above the limit — usually a finance controller or commercial director — and require a reason on every release. Held orders with no recorded reason cannot be reviewed later, and the pattern in those reasons is where your limits need changing.
Decide what makes an order billable
This chart blocks the invoice until "Proof of delivery received?" is answered. Decide whether that is right for you: some businesses bill on goods issue, some on delivery confirmation, some on customer acceptance, and services bill on milestone or on time recorded. Whatever you choose, write down where the evidence is stored and how long you will chase a missing proof before treating it as a delivery failure. Invoicing ahead of evidence buys a few days of DSO and pays for it in deductions a quarter later.
Build the deduction reason codes before you need them
"Code the deduction and open a dispute" only works if the codes exist and mean something: price, quantity, shortage, damage, promotion or rebate, freight, returns, and duplicate payment. Assign each code a default owner, because that is what routes the investigation — pricing disputes to sales, shortages to the warehouse, rebate claims to whoever signed the agreement. Set a value threshold below which a residual balance is written off without investigation, and agree whether dunning pauses while a dispute is open, and for how long.
Walk it through with the people who do the work, then publish a version
Take the chart to a sales order desk, a credit controller, the dispatch office and a cash applier, and follow three real orders through it: one clean, one that sat on credit hold, and one that was short-paid and disputed. Correct the diagram to what people actually do rather than to what the procedure says, and add the systems and documents to each step. Then publish that revision and keep the earlier ones, so anyone opening the chart later can tell which version they are reading and what changed.
Frequently asked questions
What are the steps in the order-to-cash process?
A customer order is received and checked against the order and master data; the customer's credit exposure is checked against their limit, and an over-limit order is placed on hold and either released, prepaid or refused; the order is confirmed with a promised date and released to fulfilment; the goods are picked, packed and dispatched; proof of delivery is obtained; the invoice is created from the delivery and issued; the payment is matched at the due date; cash is applied and the invoice cleared. Beyond that spine sit the two branches that decide whether the cycle actually works: a short payment is coded as a deduction and investigated against the order and proof of delivery, ending in a credit note or a continued chase, and an unpaid invoice enters dunning, then collections, and finally a write-off approved by someone independent of the collection effort.
What is the difference between order-to-cash and accounts receivable?
Accounts receivable is the collection half of order-to-cash: the invoice, the payment terms, the reminders, the disputes and the cash. Order-to-cash is the whole cycle, starting at the customer order and running through credit checking, order confirmation, dispatch and delivery evidence before the invoice exists at all. The distinction matters because most order-to-cash problems are created upstream of AR and land on it: a wrong ship-to address becomes a delivery dispute, a missing purchase order number becomes an invoice rejected by the customer's portal, an unrecorded partial shipment becomes a deduction. If you want the collections detail — the dunning calendar, instalment plans, credit note authority and bad-debt write-off — use the accounts receivable process flowchart at /templates/accounts-receivable-process. If you want to know why AR keeps receiving broken invoices, use this page, which shows the steps that produced them.
What is a credit hold and who should be able to release one?
A credit hold is an automatic block placed on an order when the customer's exposure breaches their credit limit, or when their account is overdue beyond a set point. It stops the order progressing to fulfilment until somebody decides. Release authority should be graded by value and sit with credit control rather than with sales, precisely because the person who wants the order shipped should not be the person who decides the customer can afford it. Three things make the difference between a control and a bottleneck: a response time measured in working hours, a defined escalation for releases above the credit controller's authority, and a recorded reason on every release. Reasons matter more than they look — reviewing a quarter's worth of them usually shows either a limit that is set too low for a good customer, or a limit being routinely overridden for a customer who should not have one.
How should short payments and deductions be handled?
Separately from overdue invoices, and immediately. A short payment is a customer telling you something is wrong, so the useful response is investigation, not a reminder. Code the reason at the point the remittance is applied — price, quantity, shortage, damage, promotion or rebate, freight, returns, duplicate payment — and route the case to whoever can settle that class of problem: sales for pricing, the warehouse for shortages, whoever signed the rebate agreement for a promotional claim. Set a small-value threshold below which a residual is cleared without investigation, because chasing a two-pound difference costs more than the difference. Then track deductions by reason code over time. The codes are worth far more as a defect report on your own order-to-cash process than as a collections queue: a rising shortage code is a warehouse problem, and a rising price code is a pricing or contract problem you will keep paying for until it is fixed.
How do you measure whether the order-to-cash cycle is working?
Days sales outstanding is the headline figure, but on its own it hides where the time goes, and it moves with sales volume as much as with performance. Break the cycle into the intervals this chart makes visible: order to confirmation, time spent on credit hold, confirmation to dispatch, dispatch to proof of delivery, delivery to invoice issued, and invoice to cash applied. Add three quality measures alongside them — first-pass invoice accuracy, the proportion of cash that applies automatically without manual matching, and deductions as a share of billed value, split by reason code. Measured that way, the largest single delay often turns out not to be the customer at all. It is delivery-to-invoice, or an order sitting on hold, or unapplied cash on account, all of which are inside your own control and none of which show up in a DSO number by themselves.
Where this process fits
In most operations this process follows Lead-to-order process flowchart (lead capture to booked order).
Comes before
- Lead-to-order process flowchart (lead capture to booked order) — Lead-to-order process flowchart template: capture and deduplication, lead scoring and the MQL gate, SDR outreach and sales acceptance, CPQ configuration, discount approval, quote acceptance, credit check and order booking.