Article
Why on-time delivery reports disagree
Why can Finance and Power BI calculate different on-time delivery rates from the same orders?
They are counting different events at different levels of detail. Finance waits until the complete order reaches the customer; the existing Power BI measure counts each line when it leaves the warehouse.
- 01QuestionWhy do the reports disagree?
Finance shows 88.9%; the current Power BI calculation shows 91.4%.
- 02Source orderORD-0004001
Two lines; final customer receipt on 12 June, two days after the promise.
- 03Competing definitionsOrder and receipt · line and despatch
The calculations use different grains, event dates and populations.
- 04Agreed ruleOne eligible order at final receipt
Accepted partial cancellations reduce the quantity still owed; fully cancelled orders leave the population.
- 05Reporting consequenceUse the 88.0% rule consistently
The executed SQL and checked workbook agree; DAX remains subject to a Power BI Desktop run.
The workbook shows the disputed percentages beside the agreed rule and the split-order test case.
The retained Metric Dictionary dataset covers 120,000 orders, 250,000 order lines and 180,000 delivery events from 1 July 2024 to 30 June 2026. It reproduces three results from that one model: Finance at 88.9%, the current Power BI calculation at 91.4%, and the agreed order-level receipt rule at 88.0%.
The percentages answer different questions
Finance asks whether the customer received the complete order by the original promised date. The current Power BI measure asks whether each order line was despatched by that date. Both formulas can run correctly and still disagree because the event date, grain and population are different.
The denominator changes as well. Finance calculates 4,000 on-time orders from 4,500 completed orders. Power BI calculates 9,140 on-time lines from 10,000 delivered lines. The figures should not be compared until the business decides which event and level of detail belong in the service measure.
The agreed measure counts each eligible order once, assigns it to the original promise date and waits for final customer receipt. An accepted partial cancellation reduces the quantity still owed; a fully cancelled order leaves the population. That rule produces 4,224 on-time orders from 4,800 eligible orders, or 88.0%.
One split order exposes the difference
Order ORD-0004001 contains two lines. Both lines left the warehouse before the 10 June 2025 promise date, so the line-level despatch measure passes them. The customer received six units on 9 June and the remaining four units on 12 June.
The order was not complete until the second receipt. Under the agreed rule it belongs in the denominator once and fails the numerator because final receipt occurred two days late. Averaging the two lines would hide that customer outcome.
Agreement must reach every implementation
A definition record is useful only when the same rule appears in the SQL result, the Excel check and the Power BI measure. The metric catalogue records the population, event date, exclusions, treatment of partial and cancelled orders, owner, effective date and affected reports.
The retained DAX definition has been structurally checked, but it has not been run in Power BI Desktop. The published percentages therefore come from the executed SQL and checked workbook results, with the DAX execution limitation stated separately.
The five-report reconciliation answers a separate question
The related five-report reconciliation approves 38.81%, calculated as 3,898 on-time orders from 10,045 eligible orders in a different retained population. It compares five reporting routes and traces ORD-0000001; it is not a fourth result from the Metric Dictionary dataset used by this Article.
Keeping the examples separate matters. The Metric Dictionary decides which definition should govern Finance and Power BI for ORD-0004001. The reconciliation explains why five implementations in another model disagree before they bridge to their own approved result.
Comparison
Verified implementation comparison
Each percentage comes from the calculated output rather than being typed separately into the article.| Implementation | Event and grain | Numerator | Denominator | Result |
|---|---|---|---|---|
| Finance | Final customer receipt, one row per completed order | 4,000 | 4,500 | 88.9% |
| Current Power BI | Warehouse despatch, one row per delivered line | 9,140 | 10,000 | 91.4% |
| Agreed service measure | Final customer receipt, one row per eligible order | 4,224 | 4,800 | 88.0% |
Related project examples
See how the finding was calculated and checked
The linked projects show the records, calculations and checks used for the finding. Open one for the full project detail.Order ORD-0004001 has two lines despatched before promise, then two customer receipts; the final receipt is two days late and determines the agreed result.
View Order-to-Delivery Metric Dictionary →Separate five-report reconciliationWhy five reports show different on-time delivery ratesA different retained population bridges five implementations to 38.81%. It does not supply the three percentages used by this Article.
View Why five reports show different on-time delivery rates →Sources
Sources used to answer the research question
- Order-to-Delivery Metric DictionaryQuanta Meridian
Checked SQL calculations, a working Excel workbook, the metric catalogue and order ORD-0004001.
- Why five reports show different on-time delivery ratesQuanta Meridian
Separate five-route comparison using 10,045 eligible orders and ORD-0000001; its approved 38.81% result is not an input to this Article.
- Understand star schema and the importance for Power BIMicrosoft
Technical benchmark for consistent fact grain and dimension use.