Handling late-arriving supply chain data without rewriting history by hand

On Monday morning, I opened the weekly supply-chain review deck and watched last week’s OTIF move before the meeting started.

Supplier North sent a shipment confirmation two days late. Friday’s OTIF was published from the data available at close. Monday’s refresh pulled in the new event and the result moved. That is when a team either trusts a declared restatement contract or starts rewriting numbers by hand.

Problem

In supply-chain systems, late ASN and shipment events are normal, but many review workflows still treat the first weekly value as final.

When that assumption wins, every late confirmation becomes manual repair: patch the dashboard, explain the change in chat, then repeat the patch next week. The metric still moves, but the movement is hidden in ad hoc edits instead of a declared restatement policy.

I already define KPI boundaries before review in The supply chain numbers I define before they reach a business review. The next boundary I set is restatement: when a late event is allowed to move OTIF, and when the period becomes settled.

Default approach

I use one platform-agnostic restatement rule: rerun a fixed lookback window on every refresh and label the values inside that window as preliminary.

• Keep OTIF tied to one event contract: late ASN, late shipment confirmation, or late POD/receipt update can restate recent periods.
• Recompute a fixed 14-day window on each run using loaded_at as the restatement watermark.
• Mark every OTIF value inside the window as preliminary_within_window; mark values outside the window as settled_after_window.
• Publish the same labels to consumers so planners know exactly when a number can still move.
• Keep inventory snapshot settlement as a separate policy surface from transactional late events; do not blend them into one rule.

This is not a historical backfill-validation workflow like How I validate a metric after a backfill. It is the day-to-day restatement contract for routine late-arriving corrections.

Example: the restatement window policy card I run

Last week, Supplier North OTIF first landed at 91% on Friday close. A shipment confirmation arrived Sunday night with loaded_at = 2026-04-19 22:14:00, tied to orders shipped in the prior week. Monday’s run recomputed the 14-day window and that week’s OTIF moved to 88%.

Restatement window policy card
Metric: supplier_otif
Window duration: 14 days
Trigger event: late ASN, late shipment confirmation, late POD/receipt update
Preliminary label: preliminary_within_window
Settled label: settled_after_window

Before
- Weekly OTIF was frozen at first publish.
- Late confirmations triggered manual dashboard edits and one-off SQL updates.

After
- Every refresh reruns the latest 14-day window using loaded_at watermark.
- Supplier North late confirmations restate OTIF automatically inside the window.
- Periods older than 14 days stay settled unless a deliberate backfill is approved.

The behavior stays visible and predictable: last week’s OTIF can move when the supplier event arrives late, and the movement happens through the declared window, not analyst cleanup.

Tradeoffs

• Breaks when: the lookback window is shorter than real supplier latency patterns → Mitigation: set the window from observed late-arrival distribution and review it quarterly.
• Breaks when: downstream users read preliminary values as final → Mitigation: surface preliminary_within_window and settled_after_window in the same table used in the review.
• Breaks when: teams use this policy to hide structural source issues → Mitigation: keep planner-trust quality assertions separate and escalate recurring source defects as their own workstream.
• Breaks when: transactional events and inventory snapshots share one restatement rule → Mitigation: maintain independent settlement policies so each surface reflects its own timing behavior.

Close

Next step: Pick one supplier-facing KPI this week, publish its restatement window policy card, and mark which periods are still preliminary before the next business review.

If you want to compare latency patterns and choose a window that your planners will trust, bring one recent late-arrival example and we can pressure-test the policy together.