K-07
Perfect Order Rate
Did the order arrive on time, complete, undamaged, and correctly billed — and which of those tests are actually inside your version of perfect?
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 perfect order rate measures
Perfect order rate is OTIF's stricter sibling: an order counts only if it passes every test in a declared set — arrived on time, arrived complete, arrived undamaged, and was billed correctly. It is a joint condition, evaluated on the same order, not a family of related percentages.
The component set is the definition. Perfect order with two tests and perfect order with four tests are different metrics wearing the same name, and the shorter list always scores higher. That is why the list belongs on the chart: an audience told a number is a perfect order rate will assume the full classical set unless told otherwise.
The practical difficulty is that the components do not live in one place. On time and in full come from the order and delivery trail; damage comes from the shipment or a claim; billing accuracy comes from the invoice and, more honestly, from the deductions the customer takes. Assembling them means mapping three different grains back to one order — which is exactly the work the metric is worth doing for, and exactly the work that gets skipped when the components are simply multiplied together instead.
Also answers to Perfect Order · POF · Perfect Order Fulfillment · POI
The decision switches
Three switches, and the third is not a preference — multiplying the component rates produces a number that is wrong in a knowable direction.
| Switch | Settings | Practice default |
|---|---|---|
| Component set | On time and in full only · Plus damage-free · Plus documentation and invoice accuracy | Declare the list on the chart, include only components you can actually measure — and rename the metric if you drop one. |
| Grain | Order · Line | Compute the components at line grain, then declare the order-level joint test explicitly. |
| Joint test vs multiplied rates | Joint test per order · Multiplied component rates | Joint, always — the same trap as OTIF's, one metric up. |
Component set
- raises the scoreOn time and in full only — perfect order is then OTIF renamed, and should be called that
- dependsPlus damage-free — adds a condition test that usually lives with the shipment, not the order
- lowers the scorePlus documentation and invoice accuracy — the full classical set, and the hardest to assemble from one system
Practice default Declare the list on the chart, include only components you can actually measure — and rename the metric if you drop one.
Grain
- dependsOrder — the classical definition, and what the customer actually experiences
- dependsLine — where the data lives, and where every component test is computable
Practice default Compute the components at line grain, then declare the order-level joint test explicitly.
Joint test vs multiplied rates
- dependsJoint test per order — the real metric — every declared component must pass on the same order
- raises the scoreMultiplied component rates — assumes the failure modes are independent, and they never are
Practice default Joint, always — the same trap as OTIF's, one metric up.
Formula & grain
Perfect order rate = orders passing every declared component test ÷ orders shipped
- Numerator
- Orders where on time, in full, damage-free, and billing-accurate all pass, as declared
- Denominator
- Orders shipped in the period, with exclusions declared
- Grain
- Order, assembled from line-level component facts
- Note
- The exclusions have to match the OTIF definition's, or the two metrics will disagree about the same month.
Common pitfalls
- Multiplying component percentages — The failure modes correlate — late lines are disproportionately short lines, and disputed invoices cluster on troubled orders. The product of the component rates misstates the joint metric, and there is no correction factor that repairs it.
- Components at different grains — Damage lives at the shipment, invoice errors at the invoice, quantity at the order line. Map each one explicitly back to the order before the joint test runs, and write down what you did when a shipment covers several orders.
- Silently unmeasurable components — Damage data is usually the first test to be dropped because nobody records it cleanly. Dropping it is fine; keeping the name perfect afterwards is not.
- Denominator drift — If cancels and returns are treated one way in OTIF and another way here, the two metrics stop being comparable and the stricter one can end up scoring higher. Settle the exclusions once, in one place.
Source tables — SAP
Source tables — JD Edwards
Source tables — Dynamics 365
The packing-slip journal carries the delivery component and the invoice journal the billing component. Sentinel dates need NULL-wrapping before any date test, and the company belongs in every filter and join.
Source tables — Infor M3
Source tables — Oracle EBS
Delivery details carry the shipped side of the fulfillment components; customer transactions carry the billing side. All four are operating-unit striped, so MOAC handling comes before the joint test, not after.
Source tables — Oracle Fusion
Fulfillment lines carry the shipped side, and the order header is what the joint test ultimately rolls up to. Customer transactions supply the billing component, so the order-to-invoice link has to be reconstructed before the test can run.
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 Perfect Order Rate reads as a SELECT — the pattern worked through in full in the OTIF entry's landing pattern.