OTIF Decomposition: Why the Two Rates Do Not Multiply

The Two Rates That Do Not Multiply

OTIF decomposition starts with a count that most service scorecards never perform. A shipping report gives two numbers: the share of orders that arrived on time, and the share that arrived complete. Teams that need one service figure multiply them. That product is almost never the real on-time in-full rate.

The reason is that the two failures are not independent events. A supplier that runs short on a line often ships the remainder later, so one root cause puts both a late flag and a short flag on the same order. Multiplying two rates assumes the failures land on different orders at random. In practice they cluster.

The error is small in percentage points and large in decisions. It changes which fix gets funded, because it changes how many orders each fix can actually recover.

Why does on-time times in-full not equal OTIF?

Multiplying an on-time rate by an in-full rate assumes the two failures hit different orders at random. They do not. One stockout can make an order both short and late, so the two failure sets overlap. The product understates OTIF when failures cluster together and overstates it when they are spread apart.

Independence is the hidden assumption, and it is testable in one line. Take the on-time failure rate and the in-full failure rate, multiply them by total orders, and compare the result with the count of orders that failed both conditions.

In the example below, independence predicts 2 orders in 1,000 failing both. The actual figure is 14. That ratio of seven to one is the clustering. It is not noise, and it does not average out across months.

It reflects an operating reality. A single upstream shortage produces a partial shipment now and a balance shipment later, so the same order carries both defects.

Once the failures cluster, no arithmetic performed on the two headline rates can recover the true figure. The overlap has to be counted directly.

OTIF Decomposition: The Four-Cell Order Partition

Every order in a period falls into exactly one of four cells. The cells are counts, they are mutually exclusive, and they sum to the total. That makes them a clean fit for a KPI tree whose parent nodes are sums of their children.

Take 1,000 orders in a month. 960 arrived on time, a 96.0 percent on-time rate. 950 arrived complete, a 95.0 percent in-full rate.

Cell A, on time and in full: 924 orders. This is the OTIF numerator.

Cell B, on time and short: 36 orders. Arrived when promised, missing units.

Cell C, late and in full: 26 orders. Complete, but outside the delivery window.

Cell D, late and short: 14 orders. Both conditions failed on one order.

The cells reconcile. A plus B equals 960, the on-time count. A plus C equals 950, the in-full count. All four sum to 1,000. OTIF is 924 divided by 1,000, or 92.4 percent. The product of the two rates gives 91.2 percent, understating the real figure by 1.2 points and 12 orders.

Independence would have put 2 orders in cell D. The actual count is 14. That gap is the entire argument for counting the overlap instead of inferring it from two published rates.

What are the four cells of an OTIF partition?

An OTIF partition splits every order into four counts: on time and in full, on time and short, late and in full, and late and short. The four are mutually exclusive and sum to total orders. OTIF is the first count divided by the total. The other three name the exact failure to fix.

The partition is worth building because each cell has a different owner and a different remedy. Cell B, on time and short, points at inventory availability and allocation rules. Cell C, late and in full, points at production scheduling, dock capacity or carrier performance. Cell D points at both at once.

Each cell then splits again by reason code, and reason codes are also counts. A cell C of 26 orders might split into 14 carrier delays, 8 dock congestion events and 4 production overruns. Those sum back to 26 with no allocation logic, which is what makes the tree auditable.

A tree built this way answers a question a rate cannot answer. It says how many orders a named fix can move, not how many percentage points it might be worth.

What Each Single-Condition Fix Actually Recovers

Fixing one condition completely does not produce a 100 percent OTIF rate. It produces an OTIF rate capped by the other condition.

Eliminate every late delivery and cells C and D move to on time. Cell C, already complete, joins cell A. Cell D was short, so it becomes an on-time short order and stays outside the numerator. OTIF rises from 924 to 950, or 95.0 percent, which is exactly the in-full rate.

Eliminate every short shipment instead and the mirror result appears. Cell B joins cell A, cell D becomes a late complete order, and OTIF reaches 960, or 96.0 percent, exactly the on-time rate.

The cap is always the other rate. A perfect on-time program buys 2.6 points here, not 7.6. Teams that size the on-time project against a 92.4 percent starting figure and a 100 percent target overstate the return by roughly three times, the same sizing error an additive variance bridge is built to prevent.

Cell D Is the One Nobody Sizes

Cell D, the orders that arrived late and short, is invisible in both headline rates. It sits inside the 4 percent late figure and inside the 5 percent short figure, and it is the only cell that no single-condition fix can move into the numerator.

Fourteen orders is a small number until the chargeback arrives. Under a retailer program that penalizes each violation, an order failing both conditions is still one order and may attract one penalty, but it consumes two remediation programs to recover.

That asymmetry is the practical reason to count the cell rather than infer it. Independence predicted 2 orders. The actual 14 means a shared upstream cause is producing both failures, and one fix aimed at that cause recovers all 14 at once.

The tree does not name the cause. It sizes the prize, which is what decides whether anyone goes looking.

Should OTIF be measured in orders, lines or cases?

Pick one unit and hold it across the whole tree. Order-level counting is strictest, because one short line fails the entire order. Line-level and case-level counting are more forgiving and hide partial failures. Mixing units breaks the partition, because the four cells no longer share a denominator and stop summing to the total.

Fill rate is reported three ways, and the three disagree by design. Order fill rate divides completed orders by total orders. Line fill rate divides completed order lines by total lines. Case fill rate divides cases shipped by cases ordered.¹

The trap is measuring on time at order level and in full at case level, which is how many scorecards are actually configured. The two rates then describe different populations. The four cells stop being a partition of anything, nothing reconciles, and the tree returns a number nobody can tie back to a shipment.

A tree exposes the error immediately, because the four children stop summing to the parent. That is the first test to run, and it takes one subtraction.

Three Ways to Model OTIF in a Tree

There is little ambiguity about which model to use, once the reconciliation requirement is written down.

The pattern that fails is not a missing model. It is a parent node defined as a product of rates sitting above children defined as counts, so the level above and the level below describe the same orders in incompatible terms.

The table names what each parent node holds, whether the arithmetic reconciles, and what each approach cannot tell you.

OTIF Is Two of the Four Perfect Order Conditions

SCOR, the supply chain reference model maintained by ASCM, defines Perfect Order Fulfillment as a level 1 reliability metric. It covers four conditions: delivered on time against the customer's definition of on time, in the right quantity, in the right condition, and with complete and accurate documentation.² ³ OTIF is the first two of those four.

That matters for tree design rather than for vocabulary. A team that carries damage and documentation flags on the order record can extend the same partition from four cells to sixteen without changing the math, because every cell stays a count.

A team that does not carry those flags should stay at OTIF and label it OTIF. Reporting a perfect order rate the underlying data cannot support is the failure mode, and it is common enough that the distinction is worth stating in the tree itself.

Why the Retailer Scorecard Splits Them Too

Retailer compliance programs are the reason most suppliers measure OTIF at all, and those programs already treat the two conditions separately.

Walmart's supplier program scores on time and in full against separate published thresholds rather than one blended rate, with targets differing by whether the supplier ships prepaid or collect. Supplier guidance retrieved on 24 August 2026 describes an in-full target of 95 percent and a chargeback assessed at 3 percent of the cost of goods on the non-compliant portion, with thresholds varying by category.⁴ ⁵ Walmart lowered its on-time requirement in 2024 after suppliers struggled against the earlier standard.⁶

The specific numbers change. The structure does not. The customer evaluates the conditions separately, so a supplier that models them as one multiplied rate cannot reconcile its internal service figure to the scorecard it is actually paid against.

Four Tests for an OTIF Tree

Test 1: the cells sum to the parent. A plus B plus C plus D equals total orders exactly, with no residual. A residual means the two conditions are flagged on different populations or in different units.

Test 2: the margins recover the headline rates. A plus B equals the on-time count. A plus C equals the in-full count. If either fails, one condition is being evaluated on a subset of the orders.

Test 3: the clustering is measured, not assumed. Compare cell D against the two failure rates multiplied by total orders. Record the ratio every period. A ratio far from one is the finding, not an error to correct.

Test 4: the caps are written down before the project is funded. State the OTIF ceiling from fixing each condition alone. A business case that assumes a 100 percent target from one fix is wrong by construction, not by estimate.

Where an OTIF Tree Is the Wrong Instrument

An OTIF partition is a counting model. It reports how many orders failed and in which combination. It does not say why, and three situations make it the wrong first move.

Low order counts. A four-cell split on 40 orders a month produces cells of two and three. Those move on single events and invite over-reading. Aggregate to a quarter, or stay with raw counts and skip the rates.

Disputed on-time definitions. If the customer measures against a requested date and the supplier measures against a confirmed date, the partition is arithmetically clean and describes the wrong thing. Settle the definition before building anything.

Root causes outside the order record. When lateness traces to one supplier's raw material, the useful analysis is a supplier review, not an order-level partition. The tree will show cell C growing and stop there.

A tree earns its place when the failure mix is genuinely mixed and the counts are large enough to read.

Building the Partition in kpitree.io

kpitree.io is a self-service KPI tree builder for finance, business and product analysts. The OTIF partition fits its model directly, because every node in the partition is a count.

Upload one CSV of orders carrying two flags per row, on time and in full, plus a reason code. Total orders becomes the parent. The four cells become children whose values sum to it. Every identity in the tree is addition or subtraction, which is the only kind kpitree.io stores.

The OTIF rate is then derived inside the tree by dividing two summable columns, OTIF orders over total orders. No row holds a ratio, so the partition stays reconcilable when a filter changes the population. That is the mechanism, and it is why a filtered view of one region still sums correctly.

Evidenced ingest today is CSV upload. Teams that want a scheduled feed should plan on exporting to file.

FAQ

Is OTIF the same as fill rate?

No. Fill rate measures completeness only. OTIF requires completeness and timeliness on the same order. A 95 percent fill rate says nothing about whether those complete orders arrived inside the window.

Can OTIF be higher than the product of the two rates?

Yes. Whenever late orders and short orders overlap more than chance predicts, the product understates OTIF. The worked example above understates it by 1.2 points, or 12 orders in 1,000.

What is a good OTIF rate?

It depends on the counting unit and the on-time definition, which is why cross-company benchmarks mislead. Compare against your own prior period on an unchanged definition, and against the customer's published threshold.

How does OTIF relate to perfect order fulfillment?

OTIF covers two of the four conditions in the SCOR definition of Perfect Order Fulfillment. The other two are delivery in the right condition and complete, accurate documentation.²

Does an OTIF tree need daily data?

No. Monthly order counts are enough to build the partition. Daily data helps only when you are isolating a specific event window such as a facility move.

What breaks an OTIF tree first?

A denominator change. Switching from order-level to line-level counting mid-year leaves the tree reconciling inside each period and misleading across periods.

Closing: Count the Cells Before You Chase the Rate

The on-time rate and the in-full rate are both true, and neither is enough. The number that decides where the money goes is the count of orders in each of the four cells, because that count is the size of the prize for each fix.

Only 17 percent of organizations run fully driver-based models, according to the 2026 AFP FP&A Benchmarking Survey of 332 corporate finance practitioners, fielded in August and September 2025.⁷ The service scorecard is one of the easier places to close that gap, because the identity is a partition of counts and the data already sits in the order table.

Start with one month of orders and two flags. Build the four cells, check that they sum to the total, and compare cell D against what independence predicts. That single comparison usually changes which project gets funded next quarter.

Upload one order file to kpitree.io and split a single month of OTIF into its four cells.

Sources

• Fill Rate: Definition, Formula, and How to Calculate It
• SCOR Model: Perfect Order Fulfillment (RL.1.1)
• SCOR Version 14.0, Introduction and Front Matter
• How Walmart suppliers can meet 98% OTIF rule and avoid fines
• Walmart OTIF Requirements: Avoid Fines and Penalties
• Walmart Lowers Its Shipping Requirements, But Suppliers Still Struggle
• 2026 AFP FP&A Benchmarking Survey Report: Integrated Planning