Payment Reconciliation

Payment Reconciliation: How to Match Merchant Deposits to Gross Revenue in 2026

That $3,847.92 Stripe deposit in your bank feed is not $3,847.92 of revenue. It is $3,968.40 of gross revenue minus $120.48 in processor fees, minus a $0 refund that posted yesterday, minus a $0 chargeback that is still pending on the Stripe side but has not hit the bank yet. Post the deposit as revenue and your P&L is wrong before you close the month.

Payment reconciliation is where most small business books go quietly sideways. The revenue line looks reasonable. The bank ties. Nobody checks the gap until a tax return or an audit forces the comparison. By then, processor fees are sitting in revenue, refunds are unposted, and chargebacks are floating in a clearing account that has not returned to zero in six months.

This page covers how payment reconciliation actually works for Stripe, PayPal, Square, and Shopify Payments. It walks the net-vs-gross mechanics, the fees and refunds that fall through the cracks, and how pattern learning handles deposit splits at 85% accuracy on a first import.

Get Started with Growthy

What is payment reconciliation?

Payment reconciliation is the process of matching merchant deposits to the gross revenue that produced them. When Stripe sends a $3,847.92 deposit, the reconciliation breaks that deposit into its components: $3,968.40 of gross sales, a $120.48 processor fee, and any refunds or chargebacks that reduced the payout. Each component posts to the right account. Gross revenue lands in revenue. Processor fees land in merchant fees. Refunds reduce the revenue line directly. Most tools post the net deposit as revenue and stop there. That method is wrong in two ways: it understates fees and it misstates gross revenue, which matters for sales tax, 1099-K matching, and any ratio analysis your accountant runs. Growthy splits deposits automatically at 85% accuracy on a first import and routes the difficult cases to triage.

Key Takeaways

• Net deposit is not gross revenue - A $3,847.92 Stripe deposit represents $3,968.40 of gross sales and $120.48 of processor fees. Posting the net as revenue understates fees and misstates revenue simultaneously.
• Processor fees belong in their own account - Stripe, PayPal, Square, and Shopify Payments all net fees out of payouts. The fees should post to a merchant fees expense account, not disappear into the deposit line.
• Refunds and chargebacks need their own workflow - Refunds reduce gross revenue directly. Chargebacks add a fee on top of the reversal. Both need to post before the deposit ties to the bank.
• Multi-platform books multiply the problem - Running Stripe and PayPal simultaneously means two different fee schedules, two different payout cycles, and two different formats for the statements you reconcile against.
• Pattern learning handles 85% on first import - Growthy recognizes deposit-split patterns by merchant processor, amount range, and payout schedule. The difficult 15% routes to triage with a confidence score instead of posting a wrong entry.
• Clearing accounts that never zero out are the tell - "The tell is always the same: clearing accounts that never return to zero." (Viktor Pettersson, TieOut). Payment reconciliation done right closes clearing accounts every cycle.

The Net-vs-Gross Problem on Stripe, PayPal, and Square

Every major payment processor nets fees out of your payout before the money hits your bank account. The mechanics are similar across platforms. The details vary.

Stripe sends a single ACH deposit that represents 2-7 days of gross sales minus a 2.9% + $0.30 per-transaction fee, minus any refunds processed during that window, minus any active chargeback holds. The deposit arrives without a line-item breakdown. You have to pull the payout report from the Stripe dashboard to see the components.

PayPal batches differently. It holds a rolling reserve for high-risk sellers and releases payouts on a schedule that may not match your bank's posting date. PayPal's fee structure changed in 2024 for goods and services payments. Domestic transactions now run 3.49% + $0.49 for invoiced payments. International transactions add a currency conversion fee on top.

Square sends daily payouts by default. The fee is 2.6% + $0.10 per card-present transaction, 3.5% + $0.15 per manual entry. Square's gross-to-net math is cleaner than PayPal's because payouts align to calendar days, but Square refunds can cross payout cycles, which means a refund posted today reduces a future payout, not the payout it originally came from.

Shopify Payments runs on the Stripe infrastructure for US merchants. The fee schedule is 0.5% to 2.0% depending on your Shopify plan tier, plus card network pass-through. Shopify's payout report lives in the Payments section of your admin, not your bank statement.

All four platforms produce the same reconciliation problem: the deposit your bank receives is net of fees, refunds, and holds, but your revenue should be gross. The gap between net payout and gross revenue is not a rounding error. On a business doing $50,000 a month in card volume at 2.9%, that gap is $1,450 every month in fees alone, before refunds.

"QBO's categorization accuracy is... optimistically random." (Natalia P.)

Where Payment Reconciliation Usually Breaks

Most bookkeeping errors in payment reconciliation fall into four patterns. They are quiet errors. The books look fine until someone compares the merchant statement to the P&L.

Fees lost in the deposit line. The most common failure. The bookkeeper creates a bank rule that posts "Stripe Deposit" to Sales. The rule matches on the vendor string. The net deposit lands in Sales. No fee account. No split. The P&L shows $3,847.92 of revenue when the gross was $3,968.40. The missing $120.48 is just gone. Repeat that across 12 months and your annual revenue is understated by thousands, your merchant fees expense is zero, and your effective gross margin calculation is wrong.

Refunds hitting the wrong period. A customer returns a product on March 28. The Stripe refund processes on March 29. The bank sees the charge-back on March 31, after the payout cycle closes. The refund reduces an April payout, not March. If you only reconcile deposits and ignore the refund detail, March revenue is overstated and April is understated. The error self-corrects over time, but the month-by-month numbers are wrong in a way that compounds during tax season if the 1099-K does not align.

Chargebacks orphaned in clearing. A chargeback starts as a hold. Stripe pulls the disputed amount plus a $15 dispute fee from your next payout. If you win the dispute, the amount comes back (minus the fee, which you never recover). If you lose, it stays out. Most bookkeepers create a clearing account for chargebacks with the intention of resolving it after the dispute closes. Then they forget. The clearing account never returns to zero. Viktor Pettersson's line captures it: "The tell is always the same: clearing accounts that never return to zero."

Multi-currency transactions mixed with domestic. Any business with international customers gets PayPal or Stripe payouts in USD that include currency conversion fees. The conversion fee is separate from the transaction fee and often embedded in the exchange rate rather than called out explicitly. Posting a foreign-currency payout as a straight USD deposit creates an invisible loss on every international transaction.

How Growthy Splits Deposits

The deposit-split workflow is one of the original problems Growthy was built to handle. Bobby Huang, who built Growthy and runs it on Mode 2, had the same problem every bookkeeper hits: the Stripe deposit in the bank feed is a single line, but the accounting needs three to five lines.

Growthy's approach on first import:

1. Identify the processor. The vendor string on the bank feed usually contains "STRIPE," "PAYPAL," "SQ*," or "SHOPIFY." Growthy recognizes these by pattern and flags the deposit for deposit-split treatment instead of direct posting.
2. Match the payout report. If you connect Stripe or PayPal via API, Growthy pulls the payout detail automatically. If you import a CSV, the system prompts for the corresponding payout report and maps columns.
3. Split the components. Gross sales land in the revenue account you specify. Processor fees land in merchant fees expense. Refunds reduce the revenue line. Chargebacks go to a chargeback clearing account that the system tracks until it resolves.
4. Post with a confidence score. The first time Growthy sees a Stripe deposit for a client, it categorizes the split at about 85% confidence on the fee amounts and posts the rest to triage. By month three, as the payout pattern repeats, confidence climbs to 90%+ and the deposit split runs without review.

On a client running $50,000 a month in Stripe volume, the difference between a net-posting rule and a proper deposit split is $1,450 in correctly categorized fees and accurate gross revenue every month.

Bank Rules vs Pattern Learning for Payment Reconciliation

Bank rules can handle a simplified version of payment reconciliation. The limitation is that bank rules post to one account. A single "Stripe Deposit" rule sends the entire net payout to Sales. There is no split. The fee disappears.

You can work around this with multiple rules. Create a rule for Stripe deposits under a certain dollar amount. Create another for deposits over that threshold. Add a rule that catches deposits with a specific memo field. This gets unwieldy fast, especially when the processor changes their deposit labeling format, which happens more than most bookkeepers expect.

In our experience, bank rules handle payment reconciliation at roughly 40% auto-categorization when you count the correct split as the benchmark. The other 60% requires a manual adjustment or a multi-step rule chain that breaks when the input changes.

Pattern learning works differently. Instead of matching vendor strings against rules you wrote, it learns from the corrections you make. Move a Stripe deposit to the deposit-split entry template once. Growthy records that the $3,847.92 deposit should become three lines: $3,968.40 revenue, $120.48 merchant fees expense, net of $0.00 variance. The next Stripe deposit in the same range follows the same split. The pattern is per-client, not global. What you did for one client does not bleed into another client's books.

The practical outcome: first-import accuracy on payment reconciliation runs at 85%. After 30 days of returns on the same merchant processor, accuracy climbs above 90%. And unlike bank rules, the pattern holds when the processor changes its deposit label format, because the match is on amount range and vendor string pattern, not exact string match.

"AI handles exception transactions, not rules." (Dave Sweas)

The Multi-Platform Case

Running Stripe and PayPal simultaneously is the normal state for most e-commerce businesses. Add Square for in-person sales and Shopify Payments for the online store, and you have four fee schedules, four payout cycles, and four formats for the reports you need to reconcile.

The challenge multiplies because each processor handles refunds and chargebacks differently. A Stripe refund during an active payout cycle reduces the next deposit. A PayPal refund hits immediately and may or may not align to a payout date. Square refunds cross payout cycles by default. Shopify Payments refunds follow the Stripe schedule on the back end but display in the Shopify admin, not the Stripe dashboard.

Multi-platform reconciliation without a deposit-split workflow produces a P&L where:

• Revenue includes processor fees from all four platforms mixed into the deposit lines
• Refunds appear in a separate "Refunds" line in the bank feed without tying to the original revenue entry
• Chargebacks sit in clearing indefinitely because matching each dispute to a payout requires comparing four different report formats

Growthy handles multi-platform books by treating each processor as a separate pattern set. Stripe deposits train on Stripe's payout structure. PayPal deposits train on PayPal's. The per-client, per-processor memory means that a correction you make to a PayPal chargeback entry does not change the logic applied to the next Stripe dispute.

For a bookkeeper managing 10 e-commerce clients each running 2-3 processors, the alternative is reconciling 20-30 payout reports per client per month by hand. That is the math that drives bookkeepers into the 15-client ceiling. Deposit-split pattern learning is where the ceiling moves fastest.

Vs The Alternatives

If you are evaluating tools for payment reconciliation specifically, the comparison set is narrower than general AI bookkeeping.

A note on A2X and Synder. Both tools do one thing well: merchant payout reconciliation. If your client runs a single Shopify store and nothing else, either tool is a reasonable standalone choice. If the same client also has payroll, contractor payments, software subscriptions, and a physical inventory, you still need the broader categorization solved. Growthy covers the deposit split and the rest of the transaction workload in one triage workflow.

Honest Accuracy Claims for Payment Reconciliation

Payment reconciliation is harder than standard expense categorization. The inputs are less clean. Payout reports change format. Refunds cross periods. Chargebacks resolve on a different timeline than the original transaction.

The 85% on first import includes the difficult cases in the denominator. We do not measure accuracy on the easy transactions and exclude the edge cases. If a Stripe deposit cannot be split at 85% confidence, it routes to triage with a confidence score so you know exactly what to look at.

What To Read First

This hub has related spokes. Where you start depends on what is broken.

Just discovered your P&L is wrong because of merchant fee handling? Start with the payment reconciliation guide. It walks the common errors step by step with specific fix instructions for Stripe and PayPal.

Trying to understand how pattern learning differs from bank rules? Start with AI vs bank rules. The 40% plateau and how deposit-split patterns train faster than general expense categorization.

New to AI bookkeeping generally? Start with what is AI bookkeeping. The foundational explainer before you evaluate tools for a specific workflow.

Trying to understand confidence scores before trusting the deposit split? Start with confidence scores explained. The math behind the 0-100 score and how to set your triage threshold.

Already running Growthy and want to improve deposit-split accuracy? The fastest path is completing one full payout cycle with manual corrections. Growthy learns from each correction. After 30 days on a returning client, accuracy climbs to 90%+.

Get Started

Run a Stripe import. See the deposit split before you categorize anything manually.

Get Started with Growthy