The purchase table looked excellent.

No missing values. Sensible formats. No duplicate transaction IDs. Definitions aligned. Daily loads completed on time.

Leadership still made the wrong call because the order_value field represented basket value before discounts, while everyone in the room thought it meant money actually collected.

The pipeline was healthy. The answer was wrong.

That is accuracy.

Accuracy asks whether the data matches reality. Not whether the table is tidy. Not whether the schema is enforced. Whether the value recorded corresponds to the thing the business believes it is observing.

This is the dimension people assume they are checking when they say the data "looks right." Usually they are checking whether the data is internally coherent. Accuracy is harsher than coherence. It demands an external reference point.

In the LLM era, this matters even more. AI can help clean, standardize, reconcile, and summarize. None of that guarantees contact with reality. A model can help you produce an immaculate explanation of an incorrect number.

Accurate compared with what?

Accuracy is impossible to assess in the abstract.

Compared with what?

  • Payment processor settlements?
  • Finance ledger?
  • Customer receipts?
  • Warehouse shipment records?
  • What the product UI showed the user?

Different operational systems capture different versions of reality. The source system is not automatically the truth system. A product database may record intended charge amount. Finance may care about collected amount. The customer may care about what actually appeared on the invoice.

One sharp opinion here: if you cannot name the real-world reference for a metric, you do not know whether it is accurate. You only know that it is formatted.

Source-system truth is not always business truth

Teams often treat upstream data as authoritative simply because it is closest to the event.

That is sometimes reasonable. It is also often wrong.

An app event may say a purchase happened when payment later failed. A CRM may say a customer belongs to a segment based on stale rules. An order system may record list price while finance recognizes net collected cash. All of these are "true" within their own systems and still inaccurate for the decision someone is trying to make.

Accuracy therefore requires more than trusting lineage. It requires understanding what each system is actually a system of.

Reconciliation, sampling, and reality checks

You do not prove accuracy by staring harder at a dashboard.

You prove it by comparison.

That might mean reconciling order totals against finance records, sampling rows against customer-facing receipts, checking refund treatment against payment processor data, or verifying a handful of real journeys end to end.

This sounds less elegant than writing a neat SQL test. It is less elegant. It is also how reality enters the conversation.

Analysts sometimes avoid this because reconciliation feels manual and domain-heavy. That is precisely why it is valuable. Accuracy lives at the boundary between data systems and the world they claim to describe.

Why confidence in a dashboard is not evidence

A stable dashboard can be wrong for months.

If every chart trends smoothly and every stakeholder has learned to trust it, confidence hardens into institutional belief. Then any contradictory signal from finance, operations, or customers gets treated as an exception rather than as a warning that the metric may not mean what everyone assumes.

This is how organizations end up very sure about numbers that were never reconciled to the business reality they supposedly represent.

The uncomfortable role of domain experts

Accuracy often requires people analysts wish they did not need.

Finance can explain revenue recognition. Support can explain why customer-visible outcomes differ from event logs. Operations can explain fulfillment timing. Product can explain what the UI actually told users at checkout.

That dependency is inconvenient for people who want analytics to feel purely technical. Too bad. Accuracy is a domain problem as much as a data problem.

If you exclude the people closest to the real-world process, you increase the odds of building a pristine representation of the wrong thing.

How analysts usually miss accuracy failures

They stop after internal quality checks.

Once the data is complete, valid, unique, consistent, and timely, it is tempting to declare victory. But those dimensions can all be satisfied while the measured value still fails to match the business event it claims to represent.

That is why accuracy belongs last in this series. It is not the simplest check. It is the final test of whether the other five dimensions produced something decision-worthy.

A practical reconciliation checklist

For any important KPI, verify agreement across systems and lived business experience.

  • Compare order totals in analytics against settled payment totals.
  • Check whether discounts, refunds, tax, and shipping are treated the same way everywhere.
  • Sample a handful of customer receipts and trace them through source tables.
  • Confirm the business definition with finance or operational owners.
  • Review exceptions explicitly instead of smoothing them away.

The point is not to build a cathedral around a spreadsheet. The point is to know which kind of wrong you are dealing with before you make a decision based on it.

That is the real lesson of data quality. It is not one hygiene task. It is six different ways analysis becomes convincing before it becomes correct.