Payment Reconciliation: Why Payouts Never Match Invoices

Your payment dashboard says you sold $12,400 last month. Your bank shows four deposits, none of which is $12,400, and none of which lines up with a single invoice you issued.

Nothing has gone wrong. Payment reconciliation for online businesses breaks in a predictable way, and it breaks for four reasons that you can name. Once you can name them, you can take any deposit in your bank account, trace it back to the sales that produced it, and say which part of that money was never yours to begin with.

This guide covers the reconciliation process step by step, the four deductions that break the match between your financial records and your bank statement, and the one most sellers miss: tax that somebody else already remitted.

What is payment reconciliation?

Payment reconciliation confirms that the money your business received is the money your business earned, and accounts for the gap between the two.

Most explanations stop at two sets of records, your books and your bank. For a business taking card payments online there are three, and the third is where the trouble lives:

• Your sales records. The invoices and receipts you issued, at full value, including any tax you charged.
• Your payment gateway's transaction data. Every charge, refund, dispute and fee the payment processor recorded across your transactions, in its own format and on its own clock.
• Your bank statement. The deposits that actually landed, already net of everything the processor took out.

A transaction is reconciled when you can follow it across all three and every difference has a reason. Discrepancies are normal. Unexplained discrepancies are what payment reconciliation exists to catch.

This is also what separates payment reconciliation from bank reconciliation, a distinction worth getting straight early. Bank reconciliation compares your ledger to your bank statement, two records. Payment reconciliation inserts the gateway between them, and the payment gateway is where the numbers change shape.

In a card-not-present business, the match almost always breaks in that middle layer. Not because anyone made an error, but because of how payouts are built.

Why one payout never equals one invoice

Two mechanics break payment reconciliation, and they are worth naming separately because different habits fix them.

• Batching. Payment processors settle on a schedule rather than per transaction. One deposit covers every sale in a settlement window, so a single line in your bank feed can represent dozens of invoices.
• Netting. Deductions come out before the money moves. Your invoices are gross figures, your deposit is a net figure, and they were never going to be the same number.

Put those together and the conclusion is uncomfortable but useful: there is no one to one relationship between an invoice and a deposit, so looking for one is looking for something that does not exist. The unit of reconciliation is the payout batch, not the invoice.

Timing adds a third wrinkle. A sale on the 31st can settle on the 2nd, which puts the revenue and the cash in different reporting periods. At month end that is an annoyance. At quarter end, when you are about to file, it is a reporting problem.

Payout schedules are set by the processor and vary by account, by country and sometimes by risk profile. It is worth looking yours up rather than assuming a two day rolling cycle, because every downstream habit in this guide depends on knowing it.

What comes out of a payout before it reaches your bank

Think of a payout as a subtraction the processor performs on your behalf, in a fixed order, before the money moves. Four things come out. Naming them in order is what makes a deposit legible.

Processing fees

Fees are deducted before the deposit lands, which means they never appear as an expense in your books unless you deliberately record them. This is the most common cause of understated expenses in a small seller's accounts, and it is invisible precisely because the money never arrives to be missed.

Fee structures are not uniform either. On the same gateway, different rates can apply to:

• A domestic card
• An international card
• A digital wallet
• A transaction that needed currency conversion

Apply one blended percentage across a month of transactions and it will not reconcile.

Worth being clear about where this work belongs. Recording processing fees as an expense is a bookkeeping job, and it lives in your general ledger: Xero, QuickBooks, or whatever you close the books in. Payment reconciliation tells you the fee was taken. Your ledger is where it becomes an expense.

Refunds and chargebacks

Refunds are netted against the same payout as new sales. A bad week can therefore produce a deposit smaller than that week's sales, or a negative balance that carries into the next payout.

Chargebacks are worse for reconciliation because they arrive late. A dispute raised weeks or months after the original sale lands in a completely different reporting period, usually with its own fee attached. It will not match anything in the period you are reconciling.

The accounting treatment matters here. A refund reverses both the sale and the tax you charged on it, which calls for a credit note rather than a deleted or edited invoice. Deleting the original leaves you with a tax report that no longer reconciles to anything. Where the reversal arrived as a dispute rather than a refund you chose to issue, chargeback vs refund covers what each one costs and how many correcting documents you owe.

Tax that somebody else already remitted

This is the deduction almost nobody accounts for, and it is the one that quietly corrupts a tax return.

When you sell through a marketplace or platform that acts as the deemed supplier, that platform collects the tax and remits it itself. The tax appears in your transaction data because it was charged on one of your sales. It was never your revenue and it is not your liability. Treat it as either and your financial records and your filings will disagree.

Two regimes produce this, so it is not a US only problem:

• US marketplace facilitator laws. In California, for example, the CDTFA states that a marketplace facilitator is considered the seller and retailer for each sale facilitated through its marketplace, and is generally the party required to collect and remit the tax. Nearly every state with a sales tax now has an equivalent rule, though the detail varies, so check the state level rules that apply to you. Our state-by-state guide to marketplace facilitator laws sets out where each one lands.
• EU deemed supplier rules. The European Commission confirms that online marketplaces and platforms facilitating supplies of goods are, in certain circumstances, deemed for VAT purposes to have received and supplied the goods themselves. We walk through what that means for sellers in online marketplace VAT rules.

If you want the mechanics of who carries the obligation and when, we cover that in merchant of record and marketplace responsibility.

Currency conversion

Cross-border sales settle at the processor's conversion rate on the settlement date, not the rate on the day of the sale. On almost every international transaction, the amount you recorded and the amount you received differ slightly. Those slivers accumulate across a month into a discrepancy large enough to look like an error.

A worked example, from gross sales to bank deposit

Descriptions of payment reconciliation only go so far. Here is one month for one seller, walked down line by line, so you can lay your own numbers alongside it.

Meet an illustrative online seller. They sell through their own checkout and also list on a marketplace. Round numbers, chosen for clarity rather than realism.

Line	Amount	Where it belongs in your books
Gross sales through your own checkout	$9,800	Revenue
Gross sales through the marketplace	$2,600	Revenue
Sales tax you collected	$735	A liability until you file
Sales tax the marketplace collected and remitted	$208	Neither revenue nor liability. Not yours
Refunds issued	-$420	Reduces revenue, via a credit note
Chargebacks	-$150	Reduces revenue
Chargeback fees	-$45	Expense
Gateway processing fees	-$389	Expense
Marketplace commission	-$390	Expense

Three numbers come out of that month, and none of them is interchangeable with another.

Your customers were charged $13,343, because the tax sits on top of the sale price.

Your gross sales were $12,400, which is the figure your dashboard shows and the one most sellers quote.

Just $11,741 arrived, across a payment gateway deposit and a separate marketplace deposit.

That $659 gap between gross sales and cash received is not missing money. It is fees, refunds, chargebacks and commission, all of which belong somewhere specific. The $208 of marketplace remitted tax is not in any of those three totals as your money at all, which is exactly the point.

There is a fourth number waiting for US sellers, and it will not match either. A Form 1099-K reports the gross amount. The IRS defines that as the total of reportable payment transactions "without regard to any adjustments for credits, cash equivalents, discount amounts, fees, refunded amounts, shipping amounts, or any other amounts". Every deduction in the table above is invisible to it by design.

If the difference between gross sales, taxable sales and cash received is where you get stuck, it is worth reading what gross sales actually includes before you go further.

The payment reconciliation process, step by step

The example above is the destination. This is the repeatable route to it, and it works whether you reconcile weekly or monthly.

Step 1: Pull the three records for the same window

Gather the payment gateway payout report, the bank statement and your own financial records, aligned to the payout period rather than the calendar month.

Aligning to the calendar month is the single most common mistake in this whole process, and it guarantees a mismatch at both ends of every month. A payout that straddles the 31st will never reconcile against a report that stops on the 31st.

Step 2: Match at the payout level, not the invoice level

Take each deposit and identify which payout report produced it. Reconcile the batch total first, then work into the transactions inside it.

Going invoice by invoice feels more thorough. It is actually slower and it cannot succeed, for the reason covered above.

Step 3: Account for each deduction in order

Work down the four in sequence: processing fees, then refunds and chargebacks, then tax remitted by somebody else, then currency conversion. In that order, most balances resolve before you reach the end.

Step 4: Investigate what is left

Whatever survives step three is the real work, and it is usually one of a short list:

• A payout spanning a period boundary
• A chargeback from an earlier month arriving now
• A transaction settled in a currency you do not hold
• A duplicate charge, or a customer who paid twice by different routes

Most of these are timing differences rather than errors. The test is simple: a timing difference resolves itself in the next period, an error does not. If a discrepancy appears in two consecutive reconciliations, stop treating it as timing.

Step 5: Record the result and keep the trail

Write down what you reconciled in your financial records, what you adjusted and why. Keep the transaction level detail, not just the period summary.

This last point matters more than it sounds. If a return is ever questioned, a tax authority wants to see the tax charged on individual transactions behind the figure you filed. A reconciled bank balance does not answer that question.

What changes when you run more than one gateway

Everything above holds for one processor. Add a second and the difficulty does not double, it compounds, because almost nothing transfers between them.

Each payment gateway arrives with its own payout schedule, fee structure, refund behavior, report format and tax treatment. The process you built for the first one has to be rebuilt for the second.

What differs	Why it breaks a shared process
Payout schedule	Two clocks mean the same month closes at two different points, so one cutoff is always wrong for one gateway
Fee structure	A blended rate that works for one gateway misstates the other, and the error grows with volume
Refund handling	Some net refunds against the next payout, others debit your account separately
Report format	Different field names and date conventions, so no single spreadsheet template fits both
Tax treatment	The same product sold to the same customer can carry different tax obligations depending on the route it took

That last row is the one that surprises people. Say one route is your own checkout and the other is a marketplace acting as deemed supplier. Two identical sales then produce two different tax outcomes, and only one of them is yours to report.

The workable answer is not one bigger spreadsheet. It is a single transaction level record that every gateway feeds into, reconciled per gateway and consolidated afterwards. Reconcile each processor against its own payouts, then combine the results. Combining first and reconciling second is how a discrepancy becomes untraceable.

Types of payment reconciliation

Payment reconciliation covers several distinct jobs, and only some of them apply to businesses selling online. General guides tend to give all six equal weight, which is how a reader ends up studying cash handling they will never do.

Type	What it matches	Does it apply to you?
Bank reconciliation	Your ledger against your bank statements	Yes. The foundation every business does
Card and gateway reconciliation	Gateway payout reports against bank deposits	Yes. Where the batching and netting above actually bite
Digital wallet reconciliation	Wallet settlements against your own records	Yes, if you accept wallets. Different clock and format from card rails
Accounts receivable and payable	Invoices issued and bills received against payments made and collected	Only if you invoice on terms rather than charging at checkout
Cash reconciliation	Physical cash counted against recorded takings	No, if you are card-not-present
Intercompany reconciliation	Transfers between entities you own	Only if you run a group structure

The two at the bottom are the ones to skip. Everything above them is your actual scope.

Best practices for reconciliation that scales

The habits below are what keep payment reconciliation from becoming a two day job at quarter end. None of them is complicated. All of them are easier to adopt now than after a year of accumulated drift.

1. Reconcile on the payout cycle, not the calendar month. The rule from step one, adopted as a routine rather than remembered each time.
2. Reconcile per gateway before consolidating. Never the other way round, or you lose the ability to trace a difference back to its source.
3. Keep the transaction level record, not just the summary. Summaries cannot be re-reconciled once a late chargeback or refund arrives, and something always arrives late.
4. Split tax you collected from tax somebody else remitted at the moment you record it. Reconstructing that split months later, across two gateways, is materially harder than capturing it once.
5. Automate the matching, review the exceptions by hand. This is the honest division of labor. Automation resolves the routine matches at volume and surfaces what does not fit. It does not decide what an exception means.

That last one is where a lot of finance automation projects promise more than they deliver. If you are building out the wider stack, automated accounting for SaaS covers what to connect and in what order, and reconciliation frequency shows up as one of the accounting mistakes that quietly compound.

What reconciliation does not tell you

A reconciled payout proves that the money is accounted for. That is a narrower claim than it sounds, and the gap is worth understanding before you rely on it.

Payment reconciliation is a completeness check, not a correctness check. It confirms that the amounts in your financial records agree with the amounts in the gateway's. It says nothing about whether those amounts were right in the first place.

You can reconcile a month perfectly while having:

• Charged the wrong tax rate on every transaction in a jurisdiction
• Charged tax in a country where you had no registration obligation
• Failed to charge tax in a country where you did
• Reported marketplace remitted tax as tax you collected

In all four cases the arithmetic still balances, because reconciliation compares your records against the gateway's, and both records contain the same wrong figure.

Payment reconciliation also cannot tell you that you have crossed a registration threshold. A threshold is a cumulative fact about sales across a period, often measured in a currency and a definition specific to that jurisdiction. Payment reconciliation is a periodic check on cash. The two never intersect, which is why sellers routinely discover a threshold breach months after it happened.

Where Quaderno fits

Quaderno sits at the transaction level. For every sale, across every connected gateway, it produces the tax correct record of what that transaction should have been. That means the right rate for the customer's location and the product type, with tax broken out and a compliant invoice or receipt attached.

That record is the thing you reconcile a netted payout against. Specifically:

• A compliant invoice or receipt for every transaction, with the tax shown separately
• Credit notes for refunds, so a reversal keeps its audit trail instead of erasing it
• Tax collected by jurisdiction in one report, regardless of which gateway took the payment
• Threshold monitoring, which is the exact gap reconciliation structurally cannot cover

One thing Quaderno is not, and it is worth saying plainly: it is not your general ledger. It does not book your processing fees or replace bank reconciliation in Xero or QuickBooks. It connects to them and supplies the tax layer they need. Reconciliation tells you the money arrived. Quaderno tells you the tax on it was right.

Quaderno builds that record for every transaction, across every gateway you run, before anything reaches a payout. See how it works with your payment gateways.