How do you measure order-to-cash cycle time in SAP?
The document flow already holds the answer. The work is picking the right intervals and the right statistic.
The short answer
You measure order-to-cash cycle time in SAP by reading the sales document flow table VBFA, which links every sales order to the deliveries, goods issues, and billing documents that descend from it, and then computing the elapsed time between the creation timestamps of each linked pair. That gives you four intervals rather than one number — order to delivery, delivery to goods issue, goods issue to invoice, and invoice to cash clearing — and each interval belongs to a different owner, which is why a single blended "O2C days" figure is almost never actionable. Report the median and the 90th percentile rather than the average, because order-to-cash distributions are long-tailed: a handful of disputed or blocked orders will drag a mean far away from what your business actually experiences. You do not need a dedicated process-mining platform to get a first credible baseline — the document flow is already in the system, and a governed read-only query over VBFA joined to VBAK, LIKP, and VBRK produces defensible numbers in hours instead of a procurement cycle. On a reference estate (a live ECC system we analyze end to end; a customer's numbers come from their own system) that read covers 8,360 sales orders and their downstream documents, and the same method runs unchanged against S/4HANA.
The single "O2C days" number is the problem, not the answer
Most organizations can quote an order-to-cash figure. Very few can act on it, because the number is a blend of four independent processes owned by four different functions. If order-to-cash is 34 days and it moves to 31, nobody knows who did that or how to do it again.
The useful decomposition is the chain the documents themselves describe. An order becomes one or more deliveries; a delivery becomes a goods issue; a goods issue becomes an invoice; an invoice becomes a cleared receivable. Sales owns the first gap, logistics the second and third, and finance and collections the fourth. Measured separately, each gap points at a specific queue — credit blocks, picking capacity, billing runs, dunning discipline — and each one has a different fix.
The analogy is a delayed flight. "Total travel time" tells you the trip was bad. Splitting it into check-in, security, taxi, and air time tells you whether to leave earlier or fly a different airline. Only the second version changes behavior.
Where the timestamps actually live
The measurement is a join, not a project. Every interval is the difference between two creation timestamps on documents that VBFA has already connected for you, with the predecessor/successor relationship and the document category telling you which link is which.
- VBAK — sales order header. ERDAT and ERZET give the order creation date and time; AUART lets you separate order types so returns and free-of-charge orders do not pollute the baseline.
- VBFA — document flow. The spine of the whole measurement: VBELV (preceding document), VBELN (subsequent document), and VBTYP_N (subsequent document category) let you walk order to delivery to invoice without guessing.
- LIKP / LIPS — delivery header and items. Creation timestamps for the delivery, plus the goods-issue date (WADAT_IST) that separates "we promised it" from "it left the dock."
- VBRK — billing header. FKDAT and creation timestamps close the logistics-to-invoice gap.
- BSEG / BSAD — the receivable and its clearing date, which is the only place the cash half of order-to-cash is honestly visible.
Use the median and the 90th percentile, never the average
Order-to-cash intervals are long-tailed by nature. Most orders flow cleanly in days; a small population sits for weeks behind a credit block, an incomplete master-data field, or a disputed invoice. An arithmetic mean is pulled toward that tail and describes no real order.
Report the median as the typical experience and the 90th percentile as the exception you are actually paying for. The distance between those two numbers is itself the finding: a median of four days with a p90 of thirty says your standard process is fine and your exception handling is not, which is a completely different remediation than a process that is uniformly slow.
Count in calendar days for cash-flow arguments and in working days for operational ones, and say which you used. Mixing the two is the most common way a cycle-time slide loses an audience of controllers.
Do you need a process-mining platform?
Dedicated process-mining tools are genuinely good at what they do — conformance checking, variant explosion, long-run monitoring — and if you already own one, use it. But they are usually bought before the baseline exists, which inverts the order of work: the extraction, modeling, and licensing cycle arrives months before the first number that could have justified it.
The pragmatic path is to compute the baseline first, directly against the live system through a governed read-only path, and let the result decide whether continuous mining is worth the platform. A first pass over document flow tells you which of the four intervals is the problem. That is enough to scope a fix, and enough to decide whether you need instrumentation or just a process change.
What the baseline is for in an ECC to S/4HANA move
Cycle time is the measurement that makes a migration business case concrete. Custom-code retirement is a cost argument; days out of order-to-cash is a working-capital argument, and finance already knows how to value it. Attaching measured lead times to the stages of a process map turns "we will improve order-to-cash" into a specific interval, a specific owner, and a specific before-number that the after-number can be judged against.
It also protects you from claiming credit you did not earn. If the goods-issue-to-invoice gap was already two days, no amount of S/4HANA will produce a dramatic improvement there, and saying so early is what keeps the rest of your numbers believable. Measure before you promise — the baseline is the evidence that the promise was real.
Frequently asked
Can this be measured without a full data extract?
Yes. The intervals are computable with aggregate, read-only queries over document flow and header tables — counts, medians, and percentiles rather than row-level customer records. That keeps the analysis inside a governed read path and avoids the data-transfer and privacy review that a full extract triggers.
Does the same approach work on S/4HANA, or only ECC?
It works on both. The document flow model — VBFA linking orders, deliveries, and billing documents — is unchanged in S/4HANA, so a baseline measured on ECC before conversion is directly comparable to the same measurement taken after. That comparability is precisely what makes it useful as a before-and-after for the migration.
How far back should the measurement window go?
Twelve months is the usual answer, because it covers seasonality and any period-end billing effects that a single quarter would hide. If volumes are high, a rolling twelve months with the trend shown by month is more informative than a single blended figure, since a cycle time that is quietly drifting upward matters more than the absolute number.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading