Why Your E-Commerce Revenue Does Not Match

Updated on

Your e-commerce revenue does not match your bank because the two numbers measure different things at different moments. The shop reports gross revenue when the order is placed. The bank shows a net payout days later, after the payment provider has deducted its fees and netted off refunds and chargebacks. Neither number is wrong, and no amount of staring at them will make them equal.

What reconciliation actually means is being able to explain the gap, position by position. This article covers the five places the gap comes from, how to locate yours, and the point at which the manual method stops working.

The five structural gaps

Almost every unexplained difference in an online store traces back to one of these five. They compound, which is why the total often looks inexplicable even though each part is simple.

SourceWhat happensTypical magnitude
Payment feesEvery provider deducts its fee before paying out, while your shop shows the gross amountBroadly 1.5 to 3 percent plus a fixed amount per transaction, actual terms per provider price list
Payout timingOrder on the 30th, money on the 2nd: revenue belongs to one month, the payment to the nextSeveral days per provider, and across month ends whole revenue blocks shift between periods
Refunds and returnsA refund reduces the next payout, not the original one, and needs its own correction entryRough guide by category: single digits to around 15 percent in electronics, up to roughly 50 percent in fashion
Chargebacks and reservesReversals arrive weeks later with an extra fee, some providers withhold balances as securityIndividually rare, but each one creates an unexplained difference plus a fee
Multiple payment providersShopify Payments, PayPal, Klarna and Amazon Pay each pay out on their own cycle and reporting logicThree to four parallel payout streams, each with its own format and timing

The last row is the multiplier. Reconciling one payment method is tedious but bounded. Reconciling three, each with different payout cycles, report formats and fee logic, is a process in its own right. That is where most setups quietly stop reconciling properly.

How to find your difference in an afternoon

Take one month and one payment provider, and work in this order. Doing this once, thoroughly, tells you more than three months of partial checks.

  1. Pull the payout report at payout level. Not the monthly summary. You need each individual payout, because that is the only granularity where the arithmetic can actually close.
  2. Break each payout into its parts. Gross revenue of the included orders, minus fees, minus refunds and chargebacks, equals the net amount. This has to balance exactly per payout.
  3. Match each net amount against the bank, with dates. Across a month end this step alone decides which period the revenue belongs to.
  4. Park the open items. Orders that are paid but not yet paid out belong on a clearing account. They are the reason shop revenue and bank balance are never identical at month end, and they are not an error.
  5. Give every remaining difference a named cause. A fee, a chargeback, a timing effect. "Book it to miscellaneous expense" is not a cause, it is a problem you have deferred.

Then repeat per provider. If the arithmetic closes for each one and you still have a gap, the gap is in a stream you have not looked at yet, which is usually marketplace payouts or a provider someone set up and forgot.

The differences that actually cost you money

Not all mismatches are equal. Three of them have consequences beyond a tidy ledger.

Fees that were never booked. When a payout is recorded as revenue at its net value, the fee vanishes. You understate revenue and you lose the expense entirely, which also means losing the input VAT deduction on it. This is the most common and most expensive single mistake.

Refunds booked against the wrong period or rate. A refund correction has to carry the tax treatment of the original sale. Netted off against the current payout instead, your VAT base drifts, and the error only surfaces at filing.

Timing treated as a discrepancy. Payout timing is not an error, it is a period allocation question. Treating it as a difference to be reconciled away produces a wrong monthly result in both directions, and it hides the real differences underneath the noise.

When the manual process has been outgrown

Up to roughly 100 orders a month through one dominant payment method, the process above is genuinely manageable: a few hours monthly, a clean spreadsheet, done. Spreadsheets are a legitimate tool at that stage and there is no reason to buy software.

The picture changes at a few hundred orders across three or four payment methods. Run the arithmetic: 500 orders means 500 payments, plus 25 to 200 returns depending on your category, each with its own correction entry, spread across several payout streams on different cycles. Each position needs payment matching, correct fee booking, the right tax rate for the destination country, and allocation to a payout. That is several thousand positions a month that all have to agree.

Two things typically happen at that point. Reconciliation quietly becomes a sampling exercise, and differences accumulate unnoticed. Or the raw data goes to the tax advisor unreconciled, where tens of thousands of individual entries turn into a cleanup that someone bills for at year end.

The honest test: if monthly reconciliation takes more than one working day, or you can no longer explain a month-end difference, the volume has outgrown the method. That is not a discipline failure, it is a threshold.

What to fix first

Fix the order of operations before you fix the tooling. Reconcile before the data reaches your accounting system, not after. Raw data that is supposed to be "clarified later" in the books does not get clarified later, in any organisation, ever.

Whatever you use, insist on three things. Traceability: any figure has to decompose back to the transactions it came from, or you have a black box and no starting point when something breaks. Reconciliation before export: verified numbers only. Completeness across payment methods: a solution covering one provider well just relocates the problem.

CONA is built around exactly this sequence. Orders, payments, fees, returns and VAT are reconciled in real time before anything is exported, identical bookings are aggregated into collective entries, and each stays traceable to the individual order through an activity log. Connected sources include Shopify, Amazon FBA and FBM across all EU marketplaces, plus Shopify Payments, PayPal, Klarna and Amazon Pay.

The step-by-step mechanics of matching payouts to your bank are in How to reconcile online sales with bank statements, and the software categories are compared in Accounting automation software for e-commerce in Germany. More guides are in the knowledge hub, and you can see the full path from order to booking with your own data in a free demo.

Frequently asked questions

Why are my e-commerce revenues not matching?
Because your shop reports gross revenue at the moment of the order, while your bank shows net payouts days later, after fees, refunds and chargebacks have been deducted. Both numbers are correct, they simply measure different things at different times. The difference almost always comes from five sources: payment fees, payout timing across period ends, refunds and returns, chargebacks and reserves, and running several payment providers in parallel. Reconciliation means explaining that difference position by position, not making the two numbers equal.
How do I reconcile online sales with bank statements?
Work per payment provider, never in aggregate. Pull the payout report for each provider, break every payout into gross revenue minus fees minus refunds and chargebacks, match the net figure against the bank entry by date, and park orders that are paid but not yet paid out on a clearing account. The reconciliation has to balance per payout, not approximately across the month, because that is the only level at which you can trace a difference back to a cause.
What are the most common causes of unexplained differences?
In order of frequency: payout timing across a month end, which moves whole revenue blocks between periods; refunds booked against the current payout instead of the original order; chargebacks arriving weeks later with their own fee; security reserves withheld by a provider; and fees that were netted off before the payout and never booked as expense at all. The last one is the most damaging, because it understates both revenue and cost at the same time.
What are the biggest challenges of manual accounting in e-commerce?
The volume multiplies faster than people expect. Five hundred orders mean five hundred payments, plus somewhere between 25 and 200 returns depending on your category, each needing a correction entry, spread across three or four payout streams with different cycles. That is several thousand positions a month that all have to agree. Manual work does not break because anyone is careless, it breaks because the volume has outgrown the method.
What does a good e-commerce financial close look like?
Monthly, not annual, and closed per payment provider before the numbers leave your hands. A workable close has four properties: every payout reconciled to the bank, every open item on a clearing account with a reason, every difference explained by a named cause rather than written off, and VAT split by destination country. If you cannot close a month within a few days, the problem is usually the data, not the calendar.
At what volume does manual reconciliation stop working?
The honest threshold is not a revenue number, it is an effort number. If monthly reconciliation takes you more than one working day, or if you can no longer explain a difference at month end, the method has been outgrown. In practice that lands somewhere around 200 to 300 orders per month once more than one payment provider is involved, and considerably earlier if you also sell on marketplaces.

Want reconciliation and DATEV export automated?

CONA reconciles orders, payments, fees and VAT from Shopify in real time, then exports clean, aggregated booking batches to DATEV. Every entry stays traceable down to the individual order, no black box. Setup in under a day, first month free, no credit card required. Book a 15 minute demo.

More articles