Reconciliation: how to match your website payments with your bank statement and accounting

You have a website that takes payments online and, at month's end, the numbers don't add up: the payment platform shows one figure, the bank another, and your accountant emails you "the receipts don't match." It's one of the most irritating situations for a business owner, because it looks like a mistake — but usually it's nobody's mistake. It's just money reaching you along different routes, at different times.

Reconciliation means matching three things: what the customer paid on your site, what actually landed in your account, and what you recorded in your accounting. In this article I'll show you why the gaps appear and how to close them methodically, so you stop losing a whole day to a spreadsheet.

Why the numbers don't match: money arrives by three different routes

The first source of confusion: the customer's payment and the money in your account are not the same event. When someone pays by card on your site, the processor (Stripe, PayPal, Adyen, etc.) holds the funds for a few days, then sends you a batched transfer — several payments in a single amount.

That's where the gaps come from:

• The processor deducts its fee before sending you the money, so the bank shows less than the customer paid.
• The transfer happens in batches (payouts), not transaction by transaction.
• A Monday payment can land on Wednesday, so it shows up on a different day (sometimes a different month).
• Refunds and failed payments are subtracted from the payout, not visibly cancelled.

Once you accept there are three separate realities — site, bank, books — reconciliation becomes matching, not guessing.

The three documents you need

You can't reconcile from memory. For the same period, you need three exports:

• The transaction report from your site or processor — every order, with gross amount, fee, and payment date.
• The payouts report — what the processor actually sent you and when, with the fee withheld.
• The bank statement — what really entered your account.

The trick is that the payout is the bridge between the other two. A payout bundles several site orders and appears as a single line on the statement. So the correct flow is: site orders → grouped into a payout → one line in the bank. If you try to match order-to-bank-line directly, it will never work, because the bank never sees individual orders.

The concrete reconciliation steps

Do this monthly, over the same calendar period:

• Export all three reports for the same month (site, payouts, statement).
• Take each payout and check it against the matching line on the statement — amount and date must agree. Tick both.
• For each payout, open the list of orders it includes. The gross orders minus the fee must equal the payout exactly.
• Mark refunds and failed transactions separately — they explain the "missing" gaps.
• Whatever stays unticked on the statement (transfers, bank charges, other income) note one by one.

By the end, no line should be left unexplained. If one is, you've found exactly where to dig — no more searching everywhere.

What your accountant needs to see (and why they get frustrated)

Your accountant doesn't record a 900-euro payout as revenue — they record the invoices to customers, at gross value, plus the processor fee as a separate expense. This is where things get stuck most often.

To make their life easier (and cut your accounting bill), give them monthly:

• The list of invoices issued, with number and gross value.
• The report of fees withheld by the processor, so they can book them as expenses.
• The bank statement, to confirm the receipt.

Ideally, every order on your site automatically generates an invoice (via your invoicing tool). That way the number of invoices matches the number of orders, and the manual work of "which invoice does this payment belong to?" disappears.

How to prevent the chaos from the start

Painful reconciliation is almost always a symptom of a poorly set-up system. A few things that cut your monthly work almost to zero:

• One payment processor, not three in parallel — a single source of payouts.
• Automatic invoicing tied to orders, so the numbers match on their own.
• A shared identifier (the order number) that appears on the invoice, in the processor, and in the payment description.
• Monthly reconciliation, not quarterly — the longer you wait, the more lines to untangle.

At MPO Web Studio we build sites where the payment, the invoice, and the accountant's report are designed together from the start, not bolted on later. We work fully remotely, with transparent pricing, and we can show you a ready-made demo first so you see exactly how it looks. If you're wrestling with reconciliation right now, send us a WhatsApp message and we'll tell you, concretely, what can be automated in your case.