Payment reconciliation proves that money a business earned through a processor or payment app arrived in the bank and was recorded correctly. It ties three records together: the sales in the ledger, the processor's payout report with its fees and refunds, and the deposit on the bank statement. When all three agree, the cash and the revenue are both right.
What does payment reconciliation tie together?
Payment reconciliation ties together three records that describe the same money at different stages. The ledger says what was sold. The processor report says what the processor collected, kept and paid out. The bank statement says what actually arrived. Each record can be right on its own while the three still disagree.
A bank reconciliation compares only two of those records, the statement and the books. That works well when each deposit is one check or one transfer from one customer. It breaks down when a deposit is a processor payout, because a single bank credit can hold dozens of card sales, a few refunds, a dispute and the processor's fees, all netted into one figure.
The three legs, and what each one proves
- Ledger sales prove what the business says it earned. They come from invoices, a point-of-sale system or an ecommerce platform.
- The processor report proves what happened inside the processor: which charges succeeded, which were refunded, what fees were taken and which payout each item went into.
- The bank deposit proves the cash arrived. It is the only leg outside the business's own systems and the processor's systems, which is why auditors weight it so heavily.
A payment is reconciled when it can be followed from the sale, through the payout that carried it, to the bank line that received that payout. A sale that cannot be placed in a payout, or a payout that cannot be found in the bank, is an open item.
Processor reports behind each payment reconciliation
The processor report is the bridge between sales and the bank. The report you want lists every transaction inside each payout, with the gross amount, the fee and the net, so the sum of the nets equals the bank deposit. A summary that shows only payout totals is not enough to reconcile.
Each processor names this report differently. Stripe's documentation, for example, describes a Stripe payout reconciliation report that groups the transactions settled in each automatic payout and offers an itemized download of every payment, refund, dispute and fee in it. The same page warns that Stripe cannot say which transactions an instant payout contains, so those have to be reconciled against the transaction history instead.
Columns that matter for the tie-out
Whatever the processor calls it, look for these columns in the itemized export:
| Column | What it is used for |
|---|---|
| Payout identifier or payout date | Groups transactions into the bank deposit they became |
| Transaction type | Separates charges, refunds, disputes, adjustments and fees |
| Gross amount | Matches the sale recorded in the ledger |
| Fee | Becomes the processing fee expense |
| Net amount | Sums to the payout and to the bank deposit |
| Order or invoice reference | Links each charge back to the sale |
The steps for each processor are covered on their own. Stripe payout reconciliation to the bank and ledger walks through Stripe's reports in detail, and reconciling PayPal transactions each month covers PayPal, which behaves more like a bank account that holds a balance than a processor that sweeps everything out.
Why a processor payout and the bank deposit land on different days
Processor payouts and bank deposits land on different days because three clocks run at once. A sale happens on one date, the processor makes the funds available after a settlement delay, and the bank posts the transfer a day or more after the processor sends it. Month-end falls between those dates more often than not.
These gaps are timing differences, not errors, but they have to be named. A card sale on the 30th might sit in the processor balance on the 31st and reach the bank on the 2nd of the next month. The ledger shows the revenue in the old month. The bank shows the cash in the new month. Both are correct.
How to carry a payout that is still in transit
At month-end, list every payout the processor has sent or scheduled but the bank has not yet posted. Treat that list the way you would treat deposits in transit on a bank reconciliation: it explains the difference between book cash and bank cash, and it should clear in the first days of the next month.
Many teams book the processor balance to a separate clearing account in the ledger, often called something like "processor clearing". Sales post into it at gross, fees and refunds post out of it, and each payout moves the net to the bank account. At month-end the clearing balance should equal the money still sitting at the processor plus anything in transit. If it does not, something inside the processor was not recorded.
Weekends and bank holidays stretch the gap. A Friday payout may not post until Monday or Tuesday. Before calling a payout missing, check the processor's expected arrival date against the bank's posting calendar.
The three-way payment tie-out, worked for one week
A three-way tie-out lines up ledger sales, the processor's payout report and the bank statement for the same period, then explains every difference between them. The worked example below uses invented figures for a small online shop's first week of March. Every number is illustrative.
Step 1: ledger sales for the week
The shop's ledger shows 4,820.00 of card sales between March 1 and March 7. Two orders were refunded during the week for a total of 210.00.
Step 2: the processor's payouts
The processor sent five payouts that, between them, carried every sale of the week. Its itemized report for those payouts shows:
| Payout date (example) | Gross charges | Refunds | Fees | Net payout |
|---|---|---|---|---|
| Mar 3 | 1,150.00 | 0.00 | 36.40 | 1,113.60 |
| Mar 4 | 980.00 | -85.00 | 31.10 | 863.90 |
| Mar 5 | 1,240.00 | 0.00 | 39.20 | 1,200.80 |
| Mar 6 | 760.00 | -125.00 | 24.30 | 610.70 |
| Mar 7 | 690.00 | 0.00 | 21.90 | 668.10 |
| Total | 4,820.00 | -210.00 | 152.90 | 4,457.10 |
The gross charges agree with ledger sales at 4,820.00, and the refunds agree at 210.00. That is the first leg of the tie-out done: every sale in the ledger is inside a payout.
Step 3: the bank statement
The bank statement shows four processor credits in the week: 1,113.60 on March 4, 863.90 on March 5, 1,200.80 on March 6 and 610.70 on March 7. The March 7 payout of 668.10 is not on the statement yet. It posts on March 8.
Step 4: explain the difference
| Item | Amount |
|---|---|
| Net payouts per processor report | 4,457.10 |
| Less: payout sent Mar 7, posted by bank Mar 8 | -668.10 |
| Deposits per bank statement, Mar 1 to Mar 7 | 3,789.00 |
The only difference between the processor and the bank is one payout in transit, and it has a date it should arrive. The fees of 152.90 are an expense the ledger needs to record, and the refunds are already booked. Nothing is unexplained, so this week is reconciled.
Had the bank shown 3,750.00 instead of 3,789.00, the 39.00 gap would point to a specific payout to look at. Compare each bank credit to each payout and the line that does not match shows itself.
Payment reconciliation mistake: booking processor deposits at net
The most common payment reconciliation mistake is recording each processor deposit as revenue at the net amount the bank received. The bank line ties perfectly, so the error looks like success. Underneath it, revenue is understated by every fee and refund, and the fee expense never appears on the income statement.
In the example above, net recording would put 4,457.10 into sales for the week instead of 4,820.00 of sales, 210.00 of refunds and 152.90 of fees. Over a year that gap becomes the entire processing cost of the business, invisible in the books. Sales tax filings built from net deposits will also be wrong, because tax is usually owed on the gross sale.
Signs a ledger has been booked at net
- Sales in the ledger match bank deposits to the cent, every month.
- There is no merchant fee or processing fee expense account, or it is nearly empty.
- Refunds appear only as smaller deposits, never as their own entries.
- Sales per the ledger are lower than sales per the point-of-sale or ecommerce platform.
Fixing it means re-recording the period from the processor's itemized report: sales at gross, fees and refunds as their own lines, and the payout as a transfer from the clearing account to the bank.
Outgoing payments in a payment reconciliation
Payment reconciliation also runs in the other direction, for money leaving the bank. Vendor payments, payroll and tax deposits each have their own source record that should agree with the bank debit and with the ledger. The question is the same: does each debit trace to an approved payment that was recorded once, at the right amount?
Outgoing payments are usually easier to match because they leave one at a time and the business started them. The harder cases are batch debits, such as a payroll provider pulling net pay, taxes and fees in separate debits on different days. Each debit has to be matched to its part of the payroll register, and the liability accounts have to end at the right balance. Reconciling payroll liabilities in QuickBooks shows how to tie those tax debits back to the liability balances.
For vendor payments, compare the bank debit to the payment record in accounts payable, not just to the invoice. A payment that clears for a different amount than it was recorded, or a debit with no payment record behind it, is worth asking about the same day you find it.
Where does automated payment reconciliation help, and where does it stop?
Automated payment reconciliation helps most with volume: grouping hundreds of processor transactions into payouts, matching payouts to bank credits by amount and date, and listing whatever is left. It stops at judgment. Deciding whether a missing payout is late or lost, or whether a refund was legitimate, still needs a person.
Work that matching handles well
- Pairing each net payout with a bank credit of the same amount within a few days.
- Summing itemized processor rows by payout and comparing the total to the deposit.
- Flagging bank credits from a processor that match no payout at all.
- Spotting the same payout recorded twice in the ledger.
Work that stays with you
- Reading a dispute or chargeback and deciding how to record it while it is open.
- Choosing an accounting policy for reserves, holds and instant payout fees.
- Following up with a processor when a payout never arrives.
- Approving write-offs of small differences that cannot be traced.
Before any of this, the bank statement itself has to be complete, since a matching tool can only pair the lines it has. PreciseBankFlow checks that each statement foots from opening to closing balance, then matches statement lines to your ledger or register and lists the deposits that do not clear. The processor report and the clearing account remain yours to build. If you want to try that on a client's statements, request a spot with PreciseBankFlow.