K-02
Fill Rate
Of what the customer ordered, how much shipped — counted in units, lines, or orders, at first pass or eventually, against the original ask or the ask after cancellations?
There is a reference build of this metric: the Service & Delivery Performance dashboard in the showcase runs this definition over frozen, simulated data — not a live client system.
Definitions and source tables below are current to the date above — verify against current SAP, Oracle, Microsoft, Infor, and Databricks documentation before you build.
What fill rate measures
Fill rate is the quantity question on its own: of what the customer ordered, how much actually shipped. There is no clock in it. A line ordered for the first of the month and shipped complete three weeks late has a fill rate of 100%, because every unit eventually moved. That is not a flaw in the metric — it is the metric's job. Fill rate isolates availability from promise-keeping.
It is the quantity half of OTIF, and it belongs beside OTIF rather than instead of it. Reported alone, a healthy fill rate says nothing about whether anything arrived when it was supposed to; reported beside on-time delivery, it tells you which of the two failures you are actually looking at. What it must never be is multiplied by an on-time rate to approximate the joint metric — late lines are disproportionately short lines, so the product overstates OTIF and no correction factor fixes it.
Three switches decide what your fill rate number is: what you count (units, lines, or orders), when you stop counting (first shipment, a cutoff date, or eventually), and what sits in the denominator (the ask as placed, or the ask after cancellations). Every one of them moves the reported number, and only the last one moves it dishonestly.
Also answers to Fill Rate · Unit Fill · Line Fill · Case Fill · IFR
The decision switches
Every fill rate in the wild is a setting of these three switches. Change one and the same month of shipments moves by double digits — so the settings belong on the chart, not in a footnote.
| Switch | Settings | Practice default |
|---|---|---|
| Weighting | Unit fill · Line fill · Order fill | Unit fill for supply conversations, line fill as the modeling default — both roll up from the same fact. |
| First pass vs cumulative | First pass · Cumulative by cutoff · Eventually shipped | First pass, with backorder recovery reported separately. |
| Demand basis | Original ordered quantity · Open quantity after cancels | Original ordered quantity, with the cancellation rate published alongside. |
Weighting
- dependsUnit fill — volume-weighted; what allocation and supply planning conversations actually use
- dependsLine fill — the modeling default — it matches the grain of every ERP's sales line
- lowers the scoreOrder fill — one short line fails the whole order, so big orders are structurally penalized
Practice default Unit fill for supply conversations, line fill as the modeling default — both roll up from the same fact.
First pass vs cumulative
- lowers the scoreFirst pass — only what shipped on the first shipment counts — the availability discipline metric
- dependsCumulative by cutoff — the line must complete by a declared date — the honest middle
- raises the scoreEventually shipped — backorders filled months later still count, so the number approaches 100% by construction
Practice default First pass, with backorder recovery reported separately.
Demand basis
- lowers the scoreOriginal ordered quantity — scores the ask as the customer placed it
- raises the scoreOpen quantity after cancels — every cut order launders a shortage out of the denominator
Practice default Original ordered quantity, with the cancellation rate published alongside.
Formula & grain
Fill rate = Σ qty shipped (first pass) ÷ Σ qty ordered
- Numerator
- Units shipped on the first shipment against the line
- Denominator
- Units originally ordered on that line
- Grain
- Order line — aggregated by summing both sides, never by averaging per-line percentages
- Note
- Switching to cumulative or eventually-shipped changes only which shipments feed the numerator; the denominator should not move.
Common pitfalls
- Averaging the ratio — A mean of per-line fill rates weights a 2-unit line exactly like a 2,000-unit line. Sum the numerator, sum the denominator, then divide — at every level of the rollup.
- The missing clock — Fill rate contains no time test, so a portfolio can post a strong fill rate while nothing arrives when promised. Pair it with on-time delivery or OTIF, and label which question each number answers.
- Post-cut denominators — Measuring against the quantity left after cancellations makes cutting orders look like good service. If the shortage caused the cancellation, removing it from the denominator hides the shortage.
- Substitutions counted as fills — When a different item ships against the ordered line, someone decides whether that is a fill. Either answer is defensible; an undeclared answer is not, because the two produce different numbers from the same shipments.
- Two metrics named “service level” — Cycle service level counts replenishment cycles that ended without a stockout — an event count per cycle — while fill rate is a quantity ratio over demand. The two share a name in the wild and move differently on the same operation, so when a contract or a planning parameter says “service level”, ask which construction it scores before quoting either number against it.
Source tables — SAP
Source tables — JD Edwards
Source tables — Dynamics 365
SalesLine holds the ordered quantity and the still-open remainder; the packing-slip journal carries the delivered side, with load lines tying warehouse execution back to the source line. Pin dataareaid in every filter and every join.
Source tables — Infor M3
Source tables — Oracle EBS
The ordered and shipped quantities meet on the delivery detail, which is the shipping side's line-grain record. MOAC striping applies, so the operating unit belongs in the filter before any of it is comparable.
Source tables — Oracle Fusion
The fulfillment line, not the order line, carries shipped quantity — order orchestration splits an order line into fulfillment lines, and the delivery detail hangs off those. Build the ratio at fulfillment-line grain and roll up.
Store the components, not the ratio
Every switch above is a different way of reading the same underlying facts, so the components — quantities, dates, values, flags — are what belongs in the gold layer, never the finished percentage. Bronze keeps the source tables as extracted, silver resolves the encodings once, and gold carries a component-level fact that each variant of Fill Rate reads as a SELECT — the pattern worked through in full in the OTIF entry's landing pattern.