Two dashboards can use valid data and still report different answers.
One may count orders placed during the day. Another may count orders dispatched during the same period. Finance may subtract cancellations and credit notes, while operations keeps them visible because the work still reached the warehouse. Each result can be correct for its own question.
The argument begins when both numbers are labelled "daily orders" or "revenue" and presented as though they describe the same thing.
Buying another reporting tool will not settle that disagreement. The work starts with the decision the metric supports, followed by a shared definition that can survive beyond the meeting where it was agreed.
The dispute usually starts before the chart
Business terms often sound more precise than they are.
Consider "on-time delivery". Does the clock start when the customer submits an order, when it is accepted or when it is released to the warehouse? Is the promised time the first estimate, the latest estimate or the slot the customer selected? Does a refused delivery count as late, failed or completed?
The source data may contain every timestamp needed to calculate these versions. The dashboard still needs one agreed rule.
The level at which records are counted creates another difference. In data modelling this is called the grain. An order can contain several lines, split into multiple consignments and produce more than one delivery attempt. Counting order rows, order lines and consignments will produce different totals. Microsoft's star schema guidance explains that the keys in a fact table determine its dimensionality and their values determine its granularity.
Time rules matter as well. A midnight cut-off in UTC differs from midnight in London during British Summer Time. A live operations screen and a closed monthly account may also treat late corrections differently.
Before debating the visual, state which event, grain, time window and decision the number represents.
Write a measurement contract
A measurement contract is a short, owned description of a metric. It gives analysts, system owners and business users something concrete to test.
Record:
- the metric's business name and the question it answers;
- the grain, such as one row per order, line, consignment or customer;
- the formula and included statuses;
- the authoritative source for each field;
- the time zone, cut-off and treatment of late records;
- exclusions, cancellations, returns and manual adjustments;
- the person who owns the definition;
- the expected refresh time and acceptable quality thresholds.
Add a worked example using records the business recognises. If a cancelled order had three lines and one line was dispatched, show what the metric should return and why. Examples expose ambiguity more quickly than a long technical specification.
The owner is responsible for the meaning, not for producing every report. They decide whether a business rule has changed and bring affected teams into that decision. The ONS metadata policy provides a useful precedent: it assigns owners to glossary terms and expects definitions to be maintained and reviewed.
One metric can have several purposeful versions. "Orders awaiting warehouse action" and "orders recognised for financial reporting" can coexist. Give them names that make the distinction visible instead of allowing both to inherit the label "orders".
Match data quality to the decision
Data quality is not a single score. The UK Government Data Quality Framework describes six dimensions: completeness, uniqueness, consistency, timeliness, validity and accuracy. It also treats quality as fitness for the intended use.
That last point changes the conversation.
A warehouse supervisor deciding where to move labour may prefer a figure that is five minutes old and clearly marked as provisional. A month-end revenue report may accept a longer delay in exchange for processed credits and reconciled totals. Neither standard should be copied to every dashboard.
Set thresholds around the consequence of a bad decision. Useful checks might include the percentage of orders missing a promised date, duplicate shipment identifiers, status codes outside the approved list or the age of the latest successful load. Show a warning when a threshold fails. Hiding a stale timestamp creates false confidence.
Accuracy also needs a comparison point. Reconcile the metric against its authoritative operational or financial source at an agreed cadence. Investigate differences by category rather than repeatedly patching the total in a spreadsheet. A correction should lead to a source fix, a rule change or a documented exception.
Put the agreed definition into the workflow
A definition in meeting notes will drift. Put the measurement contract next to the data model, transformation code and dashboard that implement it.
Automated tests can check allowed statuses, missing keys and the relationship between totals at different stages. Lineage should show where a field came from and which reports will change if it is redefined. Version history should record the reason for a change and the date it took effect.
Make the definition visible to the people using the dashboard. A short description, owner, refresh time and link to the full contract will prevent users from guessing. If a metric is provisional, say so on the screen.
Changes need a small piece of governance. The metric owner, an operational user and the person responsible for the source system should review material changes. That group can decide whether history should be restated and which downstream reports need retesting. The process should be light enough to use whenever a real exception appears.
Start with one disputed decision rather than a programme to fix every report. Agree its contract, trace the required fields, measure their quality and rebuild the view around the action someone will take. The result becomes a pattern for the next metric.
ORBN's data strategy work follows that route from operational question to owned, tested information. We can help reconcile definitions across systems, improve the data flow and build reporting that makes its assumptions visible. When the root cause sits between ERP, WMS, ecommerce or finance platforms, our system integration team can address the hand-offs as well as the dashboard.
Photo by Luke Chesser on Unsplash. Photo ID: JKUTrJ4vK00.