Payment Reconciliation: 6-Step Process for Stripe, PayPal, Square + Tools Compared (2026)

That $3,847.92 Stripe deposit in your bank feed is not $3,847.92 of revenue. It is $3,942.09 of gross charges, minus $94.17 in processing fees, minus $75.00 in refunds, minus a $0 chargeback. Post the deposit straight to revenue and your P&L is wrong before the month closes.

This guide is the 6-step process. Worked example with real numbers. Per-processor mapping (Stripe, PayPal, Square, Shopify). When the manual process breaks. What to do when it does.

Payment Reconciliation in 60 Seconds

Payment reconciliation is the process of breaking one processor payout back into the individual transactions inside it (charges, fees, refunds, chargebacks, and holds) and posting each component to the right general ledger account.

Five components live inside every payout:

1. Gross charges, total revenue collected before any deductions
2. Processing fees, the processor's cut (Stripe: 2.9% + $0.30/transaction)
3. Refunds, revenue you collected and returned
4. Chargebacks and disputes, forced reversals initiated by the cardholder's bank
5. Platform holds and reserves, rolling balance held by the processor

Six steps to reconcile:

1. Download the payout report from the processor.
2. Match the payout total to the bank deposit.
3. Split the components (gross, fees, refunds, disputes, holds).
4. Build the journal entry, one entry per payout, each component to its own GL account.
5. Post the entry dated to the deposit.
6. Zero the clearing account.

The clearing account is the bridge. It should net to zero after every matched payout. If it doesn't, something is unposted.

Payment Reconciliation vs. Bank Reconciliation

Two different jobs that get used interchangeably. They are not the same.

Bank reconciliation matches your bank statement to your general ledger. You're confirming the deposits and withdrawals the bank recorded match what's in the books. This is step two.

Payment reconciliation is step one. It takes one deposit (say, $3,847.92 from Stripe) and figures out what's inside it. 39 customer charges. 2 refunds from last week. $94.17 in processing fees. A chargeback that's still pending and hasn't hit the bank yet.

Get the decomposition right and bank reconciliation follows. Skip it and the books tie but the revenue line is wrong.

Most reconciliation problems aren't bank-rec problems. They're payment-rec problems. The clearing account won't zero because the components were never split. The GL doesn't match because fees got lumped into revenue. The month doesn't close because one payout absorbed a mid-cycle refund nobody caught.

Payment Reconciliation Example: Real Stripe Payout Breakdown

Here's a real $3,847.92 Stripe payout from last Tuesday, end-to-end.

Step 1: Download the payout report.

In the Stripe dashboard: Payouts → Reports → Balance summary. Export to CSV. The file lists every charge, fee, refund, and dispute that contributed to this payout.

For this payout:

• 39 charges totaling $3,942.09 gross
• 2 refunds totaling $75.00
• $94.17 in Stripe processing fees
• $0 in chargebacks or disputes
• $0 in platform holds

Step 2: Match the payout total to the bank deposit.

$3,942.09 gross − $75.00 refunds − $94.17 fees = $3,772.92. But the bank deposit was $3,847.92. The $75 difference? Stripe issued the refunds as separate debits, not netted from the gross. The actual deposit is gross minus fees ($3,942.09 − $94.17 = $3,847.92). The refunds posted to a separate Stripe ACH that day.

This is exactly the trap. Skip this step and the refund is double-counted (once as a reduction of revenue, once as a separate bank withdrawal).

Step 3: Split the components.

Step 4: Build the journal entry.

1DR  Stripe Clearing Account     $3,847.92
2DR  Processing Fees Expense        $94.17
3DR  Refunds (contra-revenue)       $75.00
4    CR  Revenue / Sales         $3,942.09
5    CR  Stripe Clearing            $74.17  (the refund debit that hits the bank separately)
Copy

The clearing account holds the payout amount until the bank deposit hits and clears it.

Step 5: Post the entry.

Date the entry to the deposit date if you're on cash basis. On accrual, gross revenue may need to be dated to the charge date, not the payout date. Know which method applies before posting.

Step 6: Zero the clearing account.

When the bank deposit hits and you match it to the clearing entry, the clearing account nets to zero. If it doesn't, there's an unmatched transaction, a refund posted twice, a fee in the wrong account, a chargeback that hit one period but cleared another.

That's the whole process. One payout, six steps, one journal entry. Repeat per payout, per processor.

The Five Components in Detail

Every payout, every processor, has the same five components. Each gets different GL treatment.

1. Gross charges. The total revenue collected before any deductions. Record as gross sales or revenue. Don't let the processor net this down before you see it. You want gross, not net.

2. Processing fees. The processor's cut. Stripe's standard rate is 2.9% + $0.30 per transaction. These are operating expenses, not a reduction of revenue. They get their own expense account, usually "Payment Processing Fees" or "Merchant Fees." Some bookkeepers book these as contra-revenue instead. Either is defensible as long as you stay consistent. See how to classify payment processor fees for the tradeoffs.

3. Refunds. Revenue you collected and returned. Book as a reduction of gross revenue, not as an expense. Some processors return the processing fee on a refund, some don't. Stripe returns the $0.30 fixed portion but keeps the 2.9%, make sure your journal entry reflects that, not the full fee reversal.

4. Chargebacks and disputes. A chargeback is a forced refund initiated by the customer's bank, not by you. It carries an additional dispute fee (Stripe: $15 per dispute). If you win the dispute, the $15 is returned; if you lose, it's not. These need their own GL account, separate from ordinary refunds, because the nature of the loss is different. Bank reconciliation later asks "where did this $15 debit come from" and the answer should not be "refunds."

5. Platform holds and reserves. Some processors hold a percentage of payouts as a rolling reserve, newer accounts, higher-risk categories, dispute history. This isn't lost money. It releases eventually. But it lives on the balance sheet as an asset (Stripe Reserve, PayPal Reserve), not as revenue. Missing this is exactly how payment processor float creates balance sheet errors.

Processor-by-Processor Mapping

Same five components, different column names per processor.

For Stripe-heavy clients, the Stripe bookkeeping guide goes deeper on Connect, multi-account, and standalone Stripe edge cases. For Shopify, see the Shopify QBO/Xero integration guide. For Square, the Square QBO/Xero integration. For Clover, the Clover QBO/Xero integration.

When the Manual Process Breaks

The manual process works. At low volume, with one processor, on a straightforward cash-basis client, it's fine.

It breaks when any of these hit.

Multiple processors. A client running Stripe for online, Square for in-person, and PayPal for international = three payout cycles, three CSV formats, three sets of timing differences. Each needs its own clearing account and its own reconciliation pass. Three times the work, three times the failure points.

High transaction volume. At 200+ transactions per month per processor, matching by hand stops being reliable. A $3,942.09 gross from 39 transactions is easy to verify. A $48,203.17 gross from 412 transactions is not. You're no longer catching errors; you're hoping none exist.

Mid-payout refunds. A refund issued one day before payout cutoff might land in this payout or the next, depending on timing. Don't track which payout absorbed it and the clearing account carries a phantom balance forever.

Currency conversion. International processors convert foreign charges to USD before paying out, at their rate, on their schedule. The USD deposit amount doesn't tie directly to the sum of transaction amounts in foreign currency. You need the processor's conversion detail, not the bank statement.

Delayed captures. Some businesses authorize a card at order placement but capture payment at shipment. If shipment is days later, the charge date and capture date differ, which matters for accrual-basis revenue recognition.

For the deposit-matching problem specifically, reconciling lump-sum deposits from payment processors covers the tactics in detail.

Three Signs It's Time to Automate

Three patterns say the manual process has hit its ceiling.

Sign 1: Your clearing account never zeros. A clearing account should net to zero after every matched payout. If yours carries a persistent balance (even a small one) you have unmatched transactions. A payout posted incorrectly. A refund unbooked. A dispute that landed in the wrong period. Finding the cause by hand gets harder as volume grows.

Sign 2: Month-end close takes two or more extra days per processor client. One client running 50 transactions per month adds maybe 30 minutes to close. A client running 400 across three processors adds two full days. That's not a workflow problem. That's a capacity ceiling.

Sign 3: You're matching by amount and hoping. When you start reconciling by matching deposit totals instead of by component, you've switched from verifying to assuming. Gross-in equals gross-out isn't reconciliation; it's an optimistic guess. The fees might be wrong. The refund timing might be off. A chargeback might be sitting unbooked.

Two of three true = manual is costing more than automation. The comparison is worth reading before you decide: automated vs. manual payment reconciliation.

What Automation Should Actually Do

Mechanics vary by tool. The correct approach does four things.

Payout-period grouping. Transactions are grouped by the payout they belong to, not by transaction date. The sum of transactions in each group ties exactly to the bank deposit. That's what makes the match reliable.

Automatic component separation. Gross, fees, refunds, and disputes are split into separate lines before any posting happens. Read directly from the payout report. You don't calculate.

Summary journal entries. One entry per payout summarizes the period. Gross revenue. Total fees. Net refunds. Deposit posts to clear the clearing account. Done. Not one entry per transaction (which becomes unmanageable).

Exception flagging. When a transaction can't be matched (unusual fee, mid-cycle dispute, currency hold) it gets flagged with a reason, not silently absorbed. You review the exceptions. The routine runs without you.

Outcome: a $3,847.92 Stripe deposit that used to take 45 minutes takes a few minutes. Not because there's less work in theory, the repetitive matching is handled and you only see what needs judgment.

Tools That Handle Payment Reconciliation

The right tool depends on processor count, transaction volume, and whether you need a workflow layer over QBO/Xero or an AI-native general ledger.

Getting Started

If you've been reconciling manually and want a more reliable process, start here.

Pick your highest-volume processor client. That's where the manual process hurts most and where better habits pay back fastest.

Map your fee accounts. Decide now, processing fees as contra-revenue or operating expense? Write it down. Apply it consistently. You can't reconcile correctly if the destination changes month to month.

Set up a dedicated clearing account per processor. "Stripe Clearing," "PayPal Clearing," and so on. These should net to zero after every reconciliation cycle. If they don't, something is off.

Download one payout report and work through it manually. Before you automate anything, do the six steps by hand once. Know what's in the CSV. Know how the components map to your GL. Automation built on misunderstanding produces the same errors faster.

The first month is the hardest. Not because the process is complicated, because you're building the habit and catching setup errors. Month two is faster. Month three, it's routine.

Every step in this guide happens automatically in Growthy. The gross/net deposit triage runs without building journal entries by hand: separating the $3,847.92 Stripe deposit into gross charges, refunds, and fees, each mapped to the right account. What lands in your queue is the difficult 20%. Payouts that crossed periods. Refunds that reversed weeks later. Fees that don't match any category in your COA. Built by a CPA firm partner. 85% first-import accuracy. You review and approve the rest. Stripe-heavy clients should also read the Stripe bookkeeping guide and the Stripe refunds and chargebacks accounting guide before month-end.

If you're managing payment reconciliation across multiple clients, get started with Growthy. Payout-period grouping and component separation run automatically. Worth seeing what it looks like before you commit to building the manual process out further.

Frequently Asked Questions

What is payment reconciliation?

Payment reconciliation is the process of decomposing a single processor payout into its component transactions (gross charges, processing fees, refunds, chargebacks, and platform holds) and matching those components to the corresponding bank deposit and general ledger entries. It runs before bank reconciliation, not as part of it.

What is the payment reconciliation process?

Six steps: (1) Download the payout report from the processor. (2) Match the payout total to the bank deposit. (3) Split the payout into gross charges, fees, refunds, and disputes. (4) Build a journal entry mapping each component to the correct GL account. (5) Post the entry dated to the deposit. (6) Zero the clearing account. Repeat per payout, per processor.

What is the difference between payment reconciliation and bank reconciliation?

Bank reconciliation matches the bank statement to the general ledger. Payment reconciliation runs the step before, it takes one batched processor deposit (one row on the bank statement) and breaks it back out into the individual charges, fees, refunds, and chargebacks that make up that deposit. If you skip payment reconciliation, the bank ties but the revenue line is wrong.

What goes into a payment reconciliation report?

A payment reconciliation report ties the processor's payout report to the bank deposit and to the journal entries posted in the GL. It shows gross revenue, processor fees, refunds, chargebacks, and platform holds as separate line items, with the deposit amount and the clearing account balance. The clearing account should net to zero after every reconciled payout.

What is payment gateway reconciliation?

Payment gateway reconciliation is the same process applied to gateway-only providers like Authorize.net or Braintree that pass funds to a separate merchant account. The reconciliation adds one step, match gateway transactions to the merchant account batch before matching the batch to the bank deposit. Stripe, Square, and PayPal handle both gateway and acquiring, so they need a single reconciliation pass.

How do you reconcile a Stripe payout?

Download the Stripe payout report (Payouts > Reports > Balance summary). The CSV lists every charge, fee, refund, and dispute in that payout. Sum each component. Post one journal entry per payout: debit Stripe Clearing for the payout total, credit Revenue for gross charges, debit Processing Fees for the fee total, credit Refunds for refunds issued in the payout window, and zero the clearing account when the bank deposit hits.

When should I automate payment reconciliation?

Three signs say the manual process has run out: (1) The clearing account carries a persistent non-zero balance month over month. (2) Month-end close takes two or more extra days per processor client. (3) You match payouts by total amount instead of by component. If two of three are true, the manual process is costing more than automation.

What is merchant payment reconciliation?

Merchant payment reconciliation is the same process applied from the merchant's bookkeeping side, matching what the merchant collected (gross sales) to what the processor paid out (net deposit), and posting the difference (fees, refunds, chargebacks) to the right GL accounts. The terminology varies; the work is the same.

Filed under: Payment Reconciliation · Bookkeeping Automation · Stripe Bookkeeping