Reports that disagree, and which one is right

Conflicting business reports almost always stem from definitions, not lies: each system timestamps, filters and attributes the same events differently. The right number is the one whose definition matches the decision at hand, verified against a system of record. This guide gives you the diagnostic order, the tie-breakers, and the habits that stop the argument recurring.

Key Takeaways

• Definitions, not dishonesty, cause most report conflicts — each tool counts at a different timestamp with different filters.
• Match the report to the decision: cash to the ledger, pipeline to the CRM, traffic to analytics.
• Diagnose in order: definitions, time window and timezone, filters, then record-by-record tracing.
• Give every metric one source of truth and one named owner.
• A silent report, missing revenue or month-on-month drift means a defect, not a definition.
• A one-page metric dictionary settles more arguments than any new dashboard.

Why do two business reports show different numbers for the same thing?

Reports disagree because they measure different things under the same name. One counts a sale when the order is placed, another when the invoice is paid; one filters bots, another does not. Timezones, attribution windows and deduplication each shift totals further, so two honest systems can differ by double digits on identical data.

Five mechanisms do most of the damage, and not one of them involves anyone lying:

• Counting time. The analytics property runs on one timezone, the database stores UTC, the ledger closes at midnight local — so "Tuesday" is three different windows.
• Attribution. An ad platform may claim a sale days after the click; the CRM credits a salesperson the moment a lead is created.
• Filters. Bots, staff visits and test orders are excluded from some reports and silently included in others.
• Identity. The CRM merges three enquiries into one contact; analytics still counts three separate sessions.
• Refunds. A gross number and a net number are both correct, and rarely equal.

See our guide to setting up website analytics for your business for the timezone and filter settings behind most of these gaps.

Which report is right when the numbers disagree?

The right report is the one whose definition matches the decision you are making, confirmed against a system of record. Cash questions belong to the accounting ledger; pipeline questions belong to the CRM. If neither definition fits the question, fix the definition first — no amount of reconciliation rescues a metric that measures the wrong thing.

A report is only right for the question whose definition it shares. Every other argument is a meeting about words, wearing the costume of a meeting about numbers.

In practice, pick the tie-breaker before you need it: the system closest to the recorded event wins. Browser analytics measures intent, the CRM measures conversations, the ledger measures money. Quoting an intent number in a money meeting is how these arguments usually start.

How do you diagnose conflicting business reports in order?

Start with the definitions, because a mismatch there explains most gaps in minutes. Then align the time window and timezone, check filters such as bot traffic, and only then trace individual records back to the source system. Work in that order and each step either explains the gap or eliminates a whole class of causes.

1. Write down both definitions. Ask each report's owner what it counts, when, and what it excludes. Ten minutes, and it ends about half of these arguments outright.
2. Align the window. Make both reports cover identical dates in one timezone — check the property setting in Google's Analytics documentation and the ledger's cut-off first.
3. Compare the filters. List what each side excludes: bots, internal visits, test orders, staff contacts, cancelled invoices. An unfiltered report is not wrong; it is answering a different question.
4. Trace one record end to end. Pick a single order both systems should have counted, and follow it: click, lead, order, invoice. Where it vanishes is your answer.
5. Size what remains. A small, stable gap after definitions match is normal noise between honest systems. A gap that widens monthly is a defect — keep digging.
6. Name the decision number. Decide which system answers the question at hand, and record the choice so the next meeting does not relitigate it.
7. Re-check next cycle. A week later, confirm the gap behaved as predicted. Conflicts you understand are routine; conflicts that move are not.

The recurring causes, and the signal that identifies each one:

Cause	What you will see	How to confirm
Timezone difference	Day totals that nearly match but never quite	Set both reports to one timezone and re-run
Attribution window	Ads claim more conversions than the CRM ever saw	Follow one converted order through both tools
Bot and internal traffic	Web figures spike on launch days and weekends	Apply filters, then compare like-for-like weeks
Duplicate records	Leads exceed unique people in the CRM	Search for repeated emails and phone numbers
Refund timing	A great week that quietly reverses the next	Compare gross and net revenue across two periods

Which system should be the source of truth for each metric?

Every metric needs one authoritative system, chosen by whoever records the event first and most reliably. Traffic lives in the analytics platform, enquiries in the CRM, orders in the application database, money in the accounting ledger. Once a metric has an owner, every other report becomes a view on that source rather than a rival count.

Two habits make the map stick. Put a name next to each metric — a source of truth nobody owns becomes a suggestion within a quarter. And where reports read straight from the application database, encode the agreed definition once as a database view, so every tool runs the same query instead of four private ones.

When does a disagreement mean something is actually broken?

Some gaps are defects, not definitions. Investigate when one report stops changing overnight, when revenue drops out entirely, or when counts drift wider every month. Those patterns point to a failed import, a broken tracking tag, duplicate records or a timezone change — problems where reconciliation hides damage instead of catching it.

We have been burned by the quiet versions: a tracking tag dropped during a redesign, an import job failing silently after a credential change, a CRM migration that double-counted every contact. None of it announces itself. It surfaces as a surprisingly good month, or a gap that keeps widening — audit the plumbing before you celebrate.

How do you stop reports from disagreeing again?

Write the definitions down in a metric dictionary and make it the only place a number is defined. Record the source system, the filter rules, the timezone and the owner for each metric, then review it quarterly. New dashboards inherit definitions from the dictionary instead of inventing their own, and arguments get shorter.

Keep it where the team already looks; a wiki page beats a perfect tool nobody opens. One entry might read:

metric:    revenue_net
question:  How much money did we actually keep?
source:    accounting ledger
counts_at: invoice settlement, minus refunds
timezone:  Asia/Kathmandu (UTC+05:45)
owner:     finance lead

When a report and the dictionary disagree, the dictionary is correct until someone deliberately changes it. That single rule prevents most slow relapses.

What does trustworthy reporting cost to run?

The running cost is mostly people's time, not licences. Someone must own each metric, review the dictionary and answer "which number is right" quickly; unowned reports decay within months. Consolidation tools help, but a quarterly review habit and a single source of truth per metric deliver most of the value at a fraction of the effort.

Licences are the small part. The real line items are definition meetings, an owner per metric and the discipline of adding a new metric to the dictionary before quoting it. A warehouse does not remove that work; it moves it somewhere more technical.

Who should be able to see which numbers?

Reporting data is sensitive: a revenue dashboard shared loosely leaks payroll ratios, margins and customer names. Give each dashboard an owner, keep financial reports behind the same access rules as the accounting system, and check what third-party analytics scripts can see on your site. Reviews of who sees what belong in the same quarterly cycle.

Practically: expire links shared in chat, and remember that an analytics tag sees every page a customer loads. Reporting access belongs on the same quarterly checklist as passwords and backups.

Which mistakes keep conflicting business reports alive?

The most expensive mistake is averaging two disagreeing reports or quoting whichever number flatters the pitch. Close behind: merging systems before defining metrics, comparing a click-reported tool against a money-reported one without saying so, and letting every export carry its own filters. Each habit makes every future argument harder to settle.

A pattern we see often: two teams resolve a conflict by quietly changing one report's filter to match the other's, writing nothing down. The numbers agree for a month, drift apart again, and nobody remembers what was touched. Written definitions are the fix. Memory is not.

Should you merge everything into one dashboard?

Only after the definitions agree — a dashboard on top of conflicting definitions just hides the argument. Compare the options honestly: a metric dictionary costs almost nothing and fixes most cases; a reporting view over the production database needs an engineer; a data warehouse suits many sources but adds real operating overhead. Start simple and escalate only on evidence.

Concretely: a reporting layer over your production database guarantees one query behind one number — the kind of thing our team builds as custom software for internal systems. A warehouse earns its keep with many sources and real analytical volume, at the price of a system someone must operate. If you do consolidate, our business reporting dashboard guide covers what belongs on screen.

What does this look like in a real business?

Picture a Kathmandu retailer with three "sales" numbers from ads, the CRM and accounting, each defensible and each quoted in different meetings. The gap turned out to be definitions, not dishonesty: the ad platform counted checkouts started while the ledger counted paid invoices net of refunds. Each meeting then used the number that matched its decision.

The ad meeting quoted 200 checkouts; the ledger showed 168 settled invoices. Both were right: 20 checkouts were abandoned, 9 payments failed and 3 invoices were later refunded. Once marketing meetings used checkout starts and finance used settled invoices — both written into the dictionary — the weekly argument became a two-minute confirmation.

In short: conflicting business reports are usually a definitions problem, not a maths problem. Check definitions, windows, filters and then individual records; give each metric one source of truth and one owner; write the decisions down. The report that matches your decision, traced back to the system that recorded the event, is the right one.

People also search for

• What should a small business reporting dashboard include?
• Which metrics should a business track every day?
• How do I set up website analytics properly?
• What is user acceptance testing and why should every new report pass it?
• Why should the business own every account behind its reports?
• Can a customer portal end the arguments about order status?
• Should we buy off-the-shelf software or build custom reporting?

If two numbers are still fighting it out in your leadership meetings, our team can review your reporting setup, sit with whoever owns each metric to agree the definitions, and build the source-of-truth layer — a shared reporting view, a rebuilt dashboard, or a small internal system where the agreed query lives. You can see an example of our reporting and analytics work, then contact us for a review and a written plan you keep whether or not you hire us.