Payment Reconciliation: Matching Processor Settlements to Your Bank and Your Books

Payment reconciliation starts with a number that doesn't match. Sales for the day were $184,220. Three days later $178,431 arrived in the bank. Nobody could say where the other $5,789 went, and the answer took most of an afternoon.

It was four things. Processing fees of $5,321. Two refunds totalling $310 issued against sales from the previous week. One chargeback of $148 from a transaction in March. And $10 of currency conversion on a handful of non-dollar sales.

Every one of those is correct behaviour. Together they mean the number in your bank account will never equal the number in your sales report, on any day, ever.

Payment reconciliation is hard because a processor is not a bank

A bank account has a simple property: money in, money out, one line per event, and the balance is the sum. A payment processor doesn't work that way, and treating its balance as a bank balance produces a reconciliation that can't close.

Four differences do the damage.

Settlement is delayed. A card is authorised today and the money reaches you on a schedule, often days later, and the delay differs by transaction type and by risk.

Payouts are net. Fees, refunds, chargebacks, and adjustments are deducted before the money is sent, so one bank line represents dozens of separate events.

Events arrive out of period. A chargeback in June relates to a sale in March. A refund today relates to a sale last week.

Balances aren't all yours. Reserves, holds on suspicious transactions, and funds pending review are on the processor's report and are not available.

A new merchant account adds a fifth.

The first payout is held back while the processor establishes a risk position. Stripe, for example, tells new accounts to expect an initial payout completing within seven to fourteen days of the first live payment, longer depending on industry and country. So the opening period shows sales with no cash against them. It looks alarming and it isn't.

The payment reconciliation process has three sources, and none agree

The payment reconciliation process means holding three records in view at once.

The gateway or processor report. Every transaction: authorisations, captures, refunds, disputes, fees, and payouts. This is the most detailed record and it is not in your accounting system.

The bank statement. One line per payout, net, dated when the money landed.

Your ledger. Sales recorded when earned, which is usually neither the authorisation date nor the payout date.

The mistake that makes this permanently unreconcilable is booking the bank line as revenue.

Then $178,431 becomes the sales figure. Fees vanish into net revenue, refunds quietly reduce this month's sales instead of reversing last month's, and there is no longer anything the processor report can be tied to. Every subsequent month inherits the problem.

What is actually inside one merchant settlement

The last row is worth attention.

Every processor issues adjustments, they carry terse descriptions, and they are the residual that keeps a reconciliation from closing after everything else has been explained. Query them at the time.

Six weeks later nobody remembers.

Timing, which matters more than the amount

Most differences that look like errors are timing.

A sale on the 30th, captured on the 30th, settled on 2 July, is June revenue and a July bank receipt.

Both are correct. Between them sits a receivable from the processor, and a process that doesn't recognise that receivable will show a month-end gap exactly the size of the settlement lag, every single month, and someone will investigate it every single month.

That's why the reconciliation needs a balance sheet account rather than a set of adjustments to revenue. Money owed to you by the processor at period end is an asset, it's calculable to the cent from the processor report, and it should agree to the processor's own statement of pending balance.

How this fits into the wider close sequence is in month-end close.

Chargebacks land in the wrong period on purpose

A chargeback is a reversal initiated by the cardholder's bank, and by the time it reaches you the original sale can be months old.

The mechanics are structured, and the timings come from your processor rather than from a published network table. Stripe, for example, tells merchants to expect a response window of roughly 7 to 21 days depending on the network, and warns that missing it loses the dispute automatically with no way to retrieve the funds. It also says the issuing bank's review can take up to three months once a response is filed. Confirm both against your own acquirer's rules.

Visa organises disputes into four categories: Fraud, conditions 10.1 to 10.5. Authorization, 11.1 to 11.3. Processing Errors, 12.1 to 12.7. Consumer Disputes, 13.1 to 13.9. The category determines what evidence is worth submitting, which is why a generic response template performs poorly.

There's also a compliance route for cases where an issuer believes a transaction breached network rules. Contesting one carries a network cost on top of the usual dispute fees: Stripe, for instance, collects $500 for a contested Visa or Mastercard compliance dispute and refunds it if you win. Other processors set their own.

For reconciliation the important part is the shape rather than the rules.

A chargeback creates three separate events, potentially in three different months: the original sale, the deduction from a payout, and either a reversal if you win or nothing further if you lose. Modelling it as one event guarantees a difference you will then go looking for.

Practical constraints worth knowing before you build a response process, using Stripe's published limits as the example: evidence capped at 4.5 MB combined, and Mastercard evidence at 19 pages. Your own processor will publish its own.

Refunds are not negative sales

A refund reverses a specific earlier transaction. Recording it as a negative sale in the current period is convenient and wrong in two ways: it distorts current-period revenue, and it breaks the link to the original transaction, so nobody can answer which sale was refunded.

The fee treatment is the part people get wrong more often. On many processors the original processing fee is not returned when you refund, so a refunded $100 sale costs you the fee twice over: once on the sale, once as an unrecovered cost. That's a real expense with no matching revenue, and it needs somewhere to sit.

Multi-currency payouts

Selling in several currencies adds a layer, and the layer is where unexplained differences accumulate.

A sale in euros settled into a dollar account converts at a rate the processor applied at a moment you didn't choose. Your ledger holds the sale at whatever rate your policy specifies. The difference is a genuine foreign exchange gain or loss, and it needs a policy stating which rate applies and where the difference is booked.

Without that policy the difference goes to a suspense account.

By December there's a balance nobody can explain and no record of what it was made of.

The clearing account method for settlement reconciliation

One mechanism handles all of this, and it is the same one that works for outbound batches, described in bulk payments.

Open a settlement clearing account, and settlement reconciliation turns into bookkeeping rather than detective work. Every captured sale credits revenue and debits the clearing account at gross. Every fee, refund, chargeback, and adjustment posts to the clearing account with its own line. Each payout credits the clearing account and debits the bank for the net amount.

The clearing account balance at any moment should equal what the processor says it owes you. If it doesn't, the difference is a specific list of events rather than a number to hunt for.

Three things make it work in practice.

Import the processor report at transaction level, not summary level. Summaries hide the events you need.

Post fees as expenses at the time they arise, not as a reduction of revenue.

Reconcile the clearing account weekly. It's a five-minute job weekly and a half-day job monthly, and the difference is entirely in how far back you have to search.

What to check in payment reconciliation, and how often

The effective fee rate check is the one that repays the effort.

Divide total fees by gross sales and track it monthly. A shift in card mix, a new market, or a pricing change all show up in that ratio before anyone from the processor mentions them. The rail choice underneath it matters too, and the wider map of what each option costs is in payment rails.

When settlement happens on-chain

Companies receiving stablecoin payments face the same three-source problem in a different shape.

There's no processor taking a fee from the payout, and no settlement lag: the payment settlement process is the confirmation itself, and the funds are yours. What replaces the processor report is the chain itself, and the identifiers are different. There's no payment reference and no beneficiary name, so matching relies on the transaction hash, the address, and the token contract.

The break types that produce are specific and they recur, and they're set out in crypto reconciliation rather than repeated here. The record-keeping frame underneath both is in crypto bookkeeping.

The one structural advantage worth naming: an on-chain receipt arrives gross. Nothing is deducted in transit, which removes the entire category of differences this article has been about. What it introduces instead is the need to store the hash against the invoice at the moment of receipt, which is a discipline rather than a calculation. VaultNow keeps custodial and external wallets, invoicing, and payouts on one dashboard, so the wallet leg reconciles alongside the bank leg rather than after it.

Frequently asked questions

What is payment reconciliation?

Matching what a payment processor reports, what arrived in the bank, and what the accounting system records, and explaining every difference between them. The same work is called settlement reconciliation when the focus is the merchant settlement rather than the ledger. The differences are structural rather than errors: fees, refunds, chargebacks, reserves, currency conversion, and settlement timing.

Why doesn't my payout match my sales?

Because the payout is net and the sales figure is gross. Processing fees, refunds against earlier sales, chargebacks from previous months, dispute fees, reserve movements, and currency conversion are all deducted before the money is sent, and the payout also covers a different period than any single day of sales.

What is a settlement clearing account?

A balance sheet account that holds the amount a processor owes you. Gross sales debit it, fees and refunds and chargebacks post against it individually, and each payout credits it for the net amount received. Its balance should equal the processor's stated pending balance at any point you check it.

How long do you have to respond to a chargeback?

The window is short and set by the network and your acquirer. Stripe tells merchants to expect roughly 7 to 21 days depending on the network, and missing the deadline loses the dispute automatically with no way to recover the funds. Once a response is filed, the issuing bank's decision can take up to three months. Confirm the exact window with your own processor.

How should refunds be recorded?

As a reversal of the specific original transaction, not as a negative sale in the current period. Recording them as negative sales distorts current-period revenue and destroys the link to the transaction being refunded. Note also that the original processing fee is often not returned, which is an expense with no matching revenue.

How often should the payment reconciliation process run?

Payouts daily against the processor's own report, the clearing account weekly, and fee rates, reserves, and currency differences monthly. Weekly clearing account reconciliation turns a half-day monthly search into a short weekly check.

What causes unexplained differences in payment reconciliation?

Most commonly processor adjustment lines with terse descriptions that were never queried, currency conversion differences with no stated policy, and reserve movements nobody was tracking. All three accumulate quietly, which is why querying them at the time rather than at the year end matters.

Payment reconciliation stops being difficult once the payout is treated as a net result of many events rather than as a number that should have matched something. The clearing account does the work, and reconciling it weekly is what keeps the search short.

If part of your income arrives on-chain, it arrives gross and settles immediately, which removes most of what this article describes and adds a record-keeping requirement instead. VaultNow keeps wallets, invoicing, and payouts in one place so that leg closes on schedule.

General information, current as at 31 August 2026. Not accounting or legal advice. Dispute windows and network rules are as published by the operators named and vary by network and acquirer.