Order to Cash (O2C)
The revenue-generating process, end to end. Every company has one; every ERP implementation spends the most workshop time on it.
The chain
Inquiry ──▶ Quotation ──▶ Sales Order ──▶ Delivery ──▶ Picking ──▶ Goods Issue
│ │
(ATP check, Stock ↓, COGS ↑
credit check, │
pricing) ▼
Billing ──▶ AR ──▶ Payment ──▶ Clearing
│
Revenue ↑, Tax ↑
Pre-sales documents
| Document | Binding? | Purpose |
|---|---|---|
| Inquiry | No | Customer asks “can you supply X?” — captures demand interest |
| Quotation | Conditionally | A priced offer with a validity date. May be legally binding once accepted |
| Contract / outline agreement | Yes | Terms over a period. Value contract or quantity contract |
| Scheduling agreement | Yes | Contract plus a delivery schedule; releases replace individual orders |
Quotation → order conversion rate is a core sales metric, and the reason quotations belong in the ERP rather than in a spreadsheet.
The sales order
The pivot of the whole process.
Header: sold-to, ship-to, bill-to, payer
sales area (sales org / distribution channel / division)
order type, currency, payment terms, incoterms
customer PO number, requested delivery date
pricing date, billing block, delivery block
Item: material, quantity, plant, unit price, conditions
item category (standard / free / return / text / service)
requested and confirmed delivery date
cost object (for make-to-order)
Schedule line: confirmed quantity per date ← one item, several dates
Conditions: price, discounts, surcharges, freight, tax
Partners: per header and per item
Texts: delivery instructions, packing notes
Schedule lines — the concept people miss
One order item can have several confirmed dates:
Item 10: 1,000 units requested 15 March
Schedule lines after ATP:
400 units confirmed 15 March (from stock)
350 units confirmed 22 March (from an inbound PO)
250 units confirmed 05 April (from production)
This is how a system tells the customer “you’ll get it in three drops” instead of just “not available”. If your model is one date per line, you cannot represent partial availability — and partial availability is the normal case.
Item categories
| Category | Behaviour |
|---|---|
| Standard | Priced, delivered, billed |
| Free of charge | Delivered, not billed. Still costs COGS |
| Text item | Information only, no material |
| Service | Billed, no delivery |
| Returns | Reverse flow |
| Third-party | Vendor ships direct, purchase requisition created automatically |
| Bill of material — main item | Priced at header, components delivered |
| BOM — sub-item | Delivered, priced at zero |
| Consignment fill-up / issue / pickup / return | Stock moves to/from the customer, revenue only on issue |
Item category determines: is it priced, is it delivered, is it billed, does it generate a requirement in planning, does it consume credit. It’s derived from order type + material item group + usage + higher-level item category.
Order entry channels
| Channel | Notes |
|---|---|
| Internal sales user | Classic screen |
| EDI (850 / ORDERS) | Retail and automotive. High volume, needs robust error handling |
| E-commerce / webshop | API into order creation |
| Customer portal | Self-service |
| Punchout | Customer’s procurement system browses your catalogue |
| Field sales app | Often offline-capable |
| CSV / batch upload | The pragmatic fallback everyone actually uses |
| CPQ handoff | Configure-Price-Quote tools push finished quotes in |
Each channel needs the same validations. Put order creation behind one service with one validation path, not one path per channel — otherwise the EDI orders get a different credit check from the web orders, and you’ll find out during an audit.
Order validation sequence
1. Customer exists, not blocked (order block, delivery block, billing block)
2. Sales area valid for this customer
3. Material exists, not blocked for sales, extended to this sales area and plant
4. Minimum order quantity / value
5. PRICING — determine all conditions
6. TAX determination
7. CREDIT CHECK
8. ATP / availability check → confirm schedule lines
9. Trade compliance / sanctions screening
10. Route and shipping point determination
11. Output determination (order confirmation)
12. Save
The order in which pricing, credit, and ATP run matters: credit needs the net value from pricing; ATP result may change what’s confirmed and therefore the credit exposure.
Delivery
Creating a delivery is the commitment to ship.
Delivery creation:
- Selects due order items (delivery due list)
- Combines items into one delivery per (ship-to, shipping point, route, date)
- Rechecks availability
- Determines picking location, batch, and route
- Creates picking tasks
Picking:
- Warehouse picks; may confirm less than requested
Packing:
- Handling units created, labels printed
Goods issue:
- Stock decreases, COGS posts
- Order item status updates
- Billing due list entry created
Delivery split happens when items can’t legally or physically travel together: different ship-tos, different routes, different incoterms, weight/volume limits, or dangerous goods separation. Delivery consolidation merges multiple orders to one ship-to on one truck.
Goods issue is the accounting moment. Before it, nothing has left. After it, inventory is down and cost is recognised. Under most Incoterms it’s also the point revenue becomes recognisable — see Revenue Recognition.
Billing
Billing due list → billing document → accounting document
Options:
- One invoice per delivery (default)
- Collective invoice: many deliveries → one invoice
- Split: one delivery → several invoices (different payers, different tax)
- Invoice list: many invoices → one statement for a payer
- Periodic billing: monthly for a contract
- Milestone billing: project percentage points
- Down payment / advance invoice
Billing splits happen automatically when header data differs (payer, terms, currency, billing date). Users find splits confusing — expect to explain “why did I get three invoices” a lot, and build a report showing the split criteria.
Pro-forma invoices are printed for customs, letters of credit, or the customer’s internal approval. They create no accounting document. Confusing a pro-forma with a real invoice in a custom report is a classic bug.
Order statuses
Derived, never stored as a single field:
Order item:
Not delivered → Partially delivered → Fully delivered
Not invoiced → Partially invoiced → Fully invoiced
Open → Completed (fully delivered AND fully invoiced)
Rejected (with a reason code)
Blocks (orthogonal to status):
Credit block, delivery block, billing block, approval block
The rejection reason is important data: “price too high”, “lead time too long”, “customer cancelled”, “no stock”. Analysing rejections tells you why you’re losing revenue. Make the field mandatory when rejecting.
Special O2C flows
Consignment
Fill-up: stock moves to customer location, STILL YOURS, no revenue
Issue: customer reports consumption → revenue + COGS
Pickup: unsold stock comes back
Return: defective consignment stock returns
The consignment stock at the customer must stay on your balance sheet. Reconciling it against the customer’s reported consumption is an ongoing operational task.
Returns
Return order → Returns delivery → Goods receipt into returns stock →
inspection → disposition → credit memo
Disposition options: restock as unrestricted, restock as blocked, repair, scrap, return to vendor. Each has different accounting. See Returns and RMA.
Rush order
Delivery is created automatically at order save; picking happens immediately.
Cash sale
Order, delivery, and billing happen in one step with immediate cash posting. Counter sales, cash-and-carry.
Third-party / drop ship
Order creates a purchase requisition; the vendor ships direct to the customer. You bill the customer when the vendor confirms shipment (or when the vendor invoices you, depending on config).
Make to order
The sales order item becomes a cost object. Production is planned specifically for it, stock is segregated as sales-order stock, and cost and revenue settle to that order at billing.
O2C metrics
| Metric | Meaning |
|---|---|
| Order-to-delivery cycle time | Speed |
| OTIF — on time in full | The headline service metric |
| Perfect order rate | On time + complete + damage-free + correct invoice |
| Order fill rate | Lines shipped complete first time |
| Quote-to-order conversion | Sales effectiveness |
| Order accuracy / error rate | Data quality |
| Invoice accuracy | Feeds disputes and DSO |
| DSO | Collection speed |
| Backlog / open order value | Forward revenue |
| Rejection reasons distribution | Lost revenue analysis |
Developer rules
- One order-creation service, all channels.
- Schedule lines, not a single delivery date.
- Snapshot the price, tax code, address, and terms on the order. They must not change when master data does.
- Derive status from quantities, never store it as truth.
- Goods issue is the inventory and COGS moment; billing is the revenue and AR moment. They are separate events and may fall in different periods.
- Reprice explicitly. Automatic repricing at delivery or billing surprises everyone; make it a configured, documented decision per condition type.
- Every rejection and every block needs a reason code.
- Pro-forma documents never post.