Open five tabs on the same Tuesday: the shop's analytics, the raw orders export, the payment provider's payout page, the bank account and the ad manager. Ask each one what the day earned and you will get five different numbers, sometimes far apart, and none of them is lying. Each report measures a different event, on a different clock, with a different definition of a sale, and once you can name the definition each one uses, every gap between them has a boring, checkable cause. This post walks the five reports, the definition gaps and the clocks, and ends with a reconciliation you can run on any single day in about an hour. The goal is not to make the numbers match; it is to know, for every pair, exactly why they do not.
- No report is wrong; each answers its own question: what was ordered, what was settled, what arrived, what an ad platform claims, what the law recognises.
- Most gaps are definitions: VAT in or out, discounts and shipping in or out, gift cards counted as revenue or as a liability, test and cancelled orders included or dropped.
- The rest are clocks: order day, refund day, payout day and spend day rarely coincide, and a UTC-based report shifts every late-evening order into tomorrow.
- Reconciling one finished day takes about an hour with the exports, and the gaps repeat: learn them once and every future mismatch is recognisable on sight.
Five reports, five questions
| Report | What it actually measures | Its clock |
|---|---|---|
| Shop analytics | orders as placed, in the dashboard's own definitions | order date, store timezone |
| Orders export | the raw order rows, before any dashboard definition | order date |
| Payout report | what the gateway settled, net of its own fees | payout date |
| Bank account | what arrived and left, from every source at once | settlement date |
| Ad manager | spend, plus the revenue the platform claims credit for | spend date, platform timezone |
Read the table twice and the mystery is mostly gone before a single number is checked: not one row measures the same event as any other row. The analytics measures promises, the payout report measures settlements, the bank measures arrivals, the ad manager measures claims. Expecting them to agree is expecting a departure board, a boarding list and a baggage carousel to show the same passengers at the same moment.
The definition gaps: the same word means different sales
The largest definitional gap is tax. Customer-facing figures include VAT because the customer pays it; a profit calculation must exclude it because it was never revenue. The top line most dashboards lead with is closest to gross merchandise value, the full ticket price of everything ordered, before discounts do their work and before the tax comes out, and at 19% the VAT alone puts the gross figure a sixth above anything profit can be computed on. Two reports where one strips tax and the other does not will disagree by the tax rate forever, and neither is wrong.
Discounts and shipping each move numbers between reports. A dashboard may show sales before or after discount codes; a price cut made by lowering the price is invisible to both, while the same cut made with a code is a visible discount line, so two identical promotions read completely differently. Shipping charged to the customer is revenue in some views, a pass-through in others. None of this is subtle once named, but until it is named it reads as error.
Then the special cases. Selling a gift card looks like revenue and is not: it is a liability, money held until the card is redeemed, and its redemption later is just a payment method. Test orders and cancelled orders sit in the raw export and are dropped, or not, by each report's own filter. Refunds are the sharpest of all: some views net them out of the period silently, some ignore them, and the refund's own economics, what a return really costs, are considerably bigger than the refunded amount, which no revenue report even attempts to show.
The clocks: every system books to its own day
An order placed Monday, refunded the following Friday, settled to the bank on Wednesday, and driven by an ad that ran the previous Thursday touches four calendars, and each system books the event it can see to the day it saw it. Over a month the edges blur; on any given day, or across a month boundary, the same euro can legitimately sit in two different periods in two different reports. Monthly totals disagreeing by a few edge days' worth of orders is not corruption, it is cutoffs.
Timezones add a quieter shift. A store in Berlin sells at 23:30 on the 31st; a system reporting in UTC books that order at 21:30, still the 31st, but a store in a summer timezone further east, or a platform reporting in Pacific time, can move the same order a whole day. Every evening order near midnight is a candidate to change months in one report and not another. The only defensible convention is the store's own timezone, applied everywhere, and any report that cannot say which timezone it uses should not be trusted with a month boundary.
The payout gap: fees leave before the money arrives
The payout report never matches the day's sales, by design. It arrives days later, bundles several days together, and is net of the gateway's fees: a percentage of each gross amount plus a fixed fee per transaction, both taken before the money moves. So the bank receives sales minus fees minus refunds in transit, on a lagged schedule, and comparing it to the day's gross sales is comparing two different quantities on two different days. A Shopify payment fees calculator turns your gateway's rate into the exact per-order wedge, and the payout report's own transaction list itemises where every missing cent of a given payout went.
The ads gap: every platform claims the order
Ask each ad platform what revenue it produced and the answers, added together, routinely exceed what the store took. Each platform counts the conversions its tracking can plausibly see, the same customer saw ads on two platforms before buying, and both claim the order in full. Nothing reconciles because nothing could: the platforms are answering 'what did we touch', not 'what did the store earn'. The clean way out is to stop asking them: divide the store's actual revenue by the total actual spend, the blended MER, and the platforms' overlapping claims stop mattering, because both sides of the ratio come from systems that cannot double-count.
The accountant's gap: invoice logic against operating logic
The accountant's numbers follow the law: invoices, ledger dates, the tax calendar, and a duty to be correct for the year rather than informative for the day. An operating statement follows the trade: per order, per day, costs matched to the sales that caused them. The two produce different monthly figures from the same store and are both right. Trouble comes only from cross-reading, an operator steering the ads by figures that arrive with invoice dates two months later, or an accountant asked to say whether Tuesday made money from a ledger that has no concept of Tuesday.
| These two disagree | The usual cause | Check first |
|---|---|---|
| Analytics vs orders export | dashboard definitions: test orders, cancellations, edits | row counts for the day, with test and cancelled filtered |
| Analytics vs payout report | fees and the clock: payouts land later and net of fees | the payout's transaction list against the day's orders |
| Payout report vs bank | transfer lag, reserves, refunds and chargebacks in transit | the payout schedule and any held reserve |
| Ad manager vs shop revenue | attribution: each platform claims the conversions it saw | blended spend against blended revenue for the same days |
| Everything vs the accountant | recognition rules and period cutoffs | which day each system books orders, refunds and fees to |
Reconcile one day in an hour
- Pick one finished day at least two weeks old, so its refunds have been issued and its payouts have landed.
- Pull the orders export for that day in the store's timezone, drop test and cancelled orders, and strip the VAT. This is the reference figure everything else is read against.
- Tick the day's orders off against the payout report's transaction list. The difference should be exactly the gateway's fees plus anything not yet settled, itemisable to the cent.
- Take the day's spend from each ad platform's billing page, never from the attributed-revenue screens, and note it beside the reference figure.
- Book any refund issued that day to that day, whatever day its original order was placed, and resist every report that nets it backwards.
- Name whatever gap remains using the map above. A named gap is a definition or a clock; an unnameable rest is a genuine error, and now it is small enough to chase.
Three questions that always come next
Should the numbers ever match to the cent? Within one system, yes: a payout must itemise exactly, an export must count exactly, and a gap inside a single system is a real error every time. Across systems, no: the honest goal is gaps you can name and predict. A store that knows its analytics will exceed its net revenue by the tax rate, and its bank will lag its sales by the payout schedule, has numbers that 'never match' and a reporting setup that is completely under control.
Which number is the true one, then? For its own question, each of them. For the question that decides decisions, what did the store keep, none of the five: that number has to be constructed, from the raw orders with tax stripped, costs matched on, refunds on their issue day and spend on its spend day. That construction is exactly the subject of the guide on how to calculate true profit from the raw exports, and every definition in this post is one of its ingredients.
When is a mismatch a genuine error? When it survives the map: a duplicated order, a refund booked twice, an import that dropped a day, a fee rate that quietly changed. And one non-error deserves its own mention, because it sends more operators chasing ghosts than any bug: a store can be genuinely profitable on paper while its account falls for weeks, which is not a discrepancy between reports at all but a set of timing calendars, and worth ruling out before auditing anything.
One statement instead of five tabs
The hour-long reconciliation is worth doing once, because afterwards no dashboard can gaslight you again. What it does not scale to is every day, and every day is the cadence on which decisions actually get made. That is the job nouz does with the same rules this post used by hand: orders on their order day in the store's timezone, refunds on their issue day, spend on its spend day from the billing side, fees per gateway rule, VAT out of everything, rebuilt nightly so the statement and its history hold still.
Five reports that disagree are not a crisis; they are five instruments measuring five things. The crisis is only ever steering by the wrong one. Learn each report's question, keep one statement whose question is yours, and the Tuesday that used to produce five arguments produces one number and four footnotes.