Every few months someone compares the analytics revenue figure to the finance one, finds a fifteen per cent gap, and concludes that analytics is broken. Usually it is not broken. It is measuring something different, in a way that cannot be complete.

The useful goal is not agreement. It is a gap you can explain and that stays roughly the same, because a stable known gap can be corrected for and an unstable unknown one cannot.

Where the difference comes from

Roughly in order of size, for a typical European business.

  1. Consent. If a visitor declines analytics cookies, the visit is not measured in the ordinary way. Depending on the market and the consent interface, that alone can be a double-digit percentage.
  2. Blocking. Ad and tracker blockers are widespread, and more so among technical audiences. Server-side collection recovers some of this and not all.
  3. Cross-device journeys. Someone researches on a phone and buys on a laptop. Finance sees one order. Analytics may see two unlinked sessions and attribute the sale to whichever channel touched the second device.
  4. Definitional differences. Does the revenue figure include tax, shipping, discounts? Does it net off refunds and cancellations, and if so, in which period? Analytics almost always records gross at the moment of purchase; finance records net, later.
  5. Timing. Analytics timestamps the transaction; finance may recognise it on despatch or on payment settlement. Around month boundaries this alone produces a visible gap.
  6. Failed collection. Tags that did not fire because of a JavaScript error, a slow page abandoned before the beacon sent, or an ad blocker on the confirmation page specifically.

Quantify it once, properly

Take a full month. Export transactions from both systems with their identifiers and match them line by line rather than comparing totals.

That produces three buckets: in both, in finance only, in analytics only. The third bucket is small and usually indicates duplicates or test transactions. The second is the real gap, and matching lets you characterise it – by device, by channel, by payment method, by time of day.

You now have a correction factor with a reason attached, instead of a discrepancy. Redo it every six months, or after any change to the consent banner, the checkout or the tag setup.

Use each system for what it is good at

Finance is authoritative for revenue. It is complete, reconciled and auditable. Do not use analytics to report revenue to a board.

Analytics is authoritative for behaviour and proportion. Which channels contribute, where in a funnel people leave, which templates convert better, how mobile compares to desktop. For those questions the absolute total does not matter, because the same collection loss applies across the comparison.

Most arguments about analytics accuracy are actually arguments about using the wrong system for the question.

What to fix, in order

Some of the gap is recoverable and some is not. The recoverable part is worth an afternoon.

  • Duplicate tags. Two containers, or a tag in both the template and the tag manager. This inflates everything and is the most common single fault we find.
  • Internal and supplier traffic, excluded by IP or by a persistent flag. Your own team browsing the site is not customer behaviour.
  • Campaign tagging consistency. Inconsistent UTM parameters send paid traffic into the direct bucket, which then looks like organic growth.
  • Cross-domain configuration, wherever the journey crosses a domain – a booking engine, a hosted checkout, a separate app.
  • Consent mode, configured so that modelled data is available rather than the visit vanishing entirely.
  • A documented event taxonomy. Every event, what triggers it, what it means. Undocumented tracking decays within a year as different people add things.

Start from the question, not the tool

Almost all bad analytics comes from working in the wrong direction: install the tool, accept the defaults, then wonder what the reports are for.

Write down the decisions you actually need to make – which channel to fund next quarter, which template to fix first, whether the new checkout is better. Derive the metrics that answer them, then the events that produce those metrics. Anything that survives that process gets implemented; anything that does not is a report nobody reads.

It also keeps the tag count down, and every tag is third-party JavaScript competing with your own for the main thread.