DATA CLARITY REVIEW / SAMPLE 001
Why don’t our sales
and finance totals agree?
A small, inspectable example of the findings, evidence and next steps a focused data review could provide.
FICTIONAL BUSINESS & DATA · June 2026 sample period · GBP · VAT-exclusive figures
This is an illustrative deliverable, not a customer case study, an audit or an assessment of a real business. Actual review scope and outputs are agreed separately.
The finding, at a glance.
7 rows, including a repeated export row
6 sales postings and 1 refund
£120 repetition + £100 refund
One £120 order appears twice in the sales export. Finance also includes a £100 refund that the sales export leaves out. Counting each order once and applying the refund brings the sales figure to £900, matching finance in this sample.
FROM SOURCE TO FINDING
Follow the difference.
Two supplied exports show different totals. First check the records behind them.
The question and boundaries.
The decision
Which sales figure should this sample management report display, and what checks should run before it is shared?
The agreed comparison
Compare order sales less recorded refunds for the fictional June period. Use GBP and VAT-exclusive values on both sides. This definition is specific to the example.
The inputs
Sales export: 7 rows for 6 distinct order IDs.
Finance export: 6 corresponding sales postings and 1 refund.
Coverage: all 14 fictional rows are included below and in the downloadable CSV.
Outside the example
No bank statement, payment processor, tax calculation, costs or other accounting records are supplied. Matching these two exports does not prove the completeness or correctness of a real set of accounts.
The evidence behind the answer.
| Source row | Order | Record | Amount | Review note |
|---|
S02 and S07 contain the same order ID, date, amount and record type. S07 is excluded from the aggregation only; both source rows remain visible. F07 is a separate refund against O-105.
The calculation.
| Step | Evidence | Adjustment | Running total |
|---|---|---|---|
| Sales export as supplied | S01–S07 | — | £1,120 |
| Count the repeated order once | S02 matches S07 | −£120 | £1,000 |
| Include the recorded refund | F07 against O-105 | −£100 | £900 |
| Compare with finance | F01–F07 total £900 | Remaining difference | £0 |
What we would recommend next.
| Priority | Action | Suggested owner | Acceptance check |
|---|---|---|---|
| First | Agree the report’s sales definition and period. | Finance and operations | The definition explicitly includes recorded refunds and consistent date boundaries. |
| Next | Investigate the repeated export row and make the aggregation repeatable. | Data/process owner | This sample produces 6 unique orders. Repeated imports do not increase the total. |
| Then | Add a comparison check before publishing the report. | Reporting owner | The sample comparison is £900 versus £900. New mismatches are visible for review. |
These are proposed actions for the fictional scenario. Production implementation, monitoring, access and ownership would need a separately agreed scope.
What the evidence cannot tell us.
- Why the repeated export row appeared. The sample demonstrates the symptom, not its root cause.
- Whether any sales or refunds are missing from both exports.
- Whether the same issue exists in other periods or systems.
- Whether a different reporting definition would be more appropriate for a particular business.
How the example is calculated
The interactive graphic and source table use the same fictional record set. Exact repeated order/date/type/amount signatures are counted once in the sales aggregation. Refund amounts from finance are then included. This simple rule is suitable for this controlled example; ambiguous real records require review rather than automatic merging.
What would your question be?
A Data Clarity Review starts with a defined question, selected sources and agreed acceptance criteria. Share the problem first; confidential records can follow through an agreed access arrangement.
Discuss a review ↗