That $3,847.92 Stripe deposit is not $3,847.92 of revenue. Here's how to split merchant deposits correctly: fees in the right account, refunds posted, chargebacks reconciled.
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.
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.
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.)
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.
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 for Growthy LLC and TracePrep, 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:
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 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)
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:
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.
If you are evaluating tools for payment reconciliation specifically, the comparison set is narrower than general AI bookkeeping.
Tool | What it handles | What to know |
|---|---|---|
QBO bank rules | Basic vendor matching | One account per rule. No deposit split without a workaround. Rules break on label changes. ~40% effective accuracy when split is the benchmark. |
A2X | Stripe, Amazon, and Shopify payout reconciliation | Purpose-built for e-commerce deposit splits. $19-$149/mo per store. Works over QBO or Xero. Does not handle the broader categorization workload outside of merchant payouts. |
Synder | Multi-processor sync for QBO, Xero, and standalone | Syncs transaction-level detail from Stripe, PayPal, Square, and Shopify into QBO or Xero. Strong on merchant payout reconciliation. Does not provide a triage dashboard for the broader transaction workload. |
Pilot | Outsourced bookkeeping | $600+ per month. Does the reconciliation for you. Replaces the bookkeeper rather than enabling them. |
Manual spreadsheet | Full control | Works. Takes 3-8 hours per processor per month on a mid-volume e-commerce client. Does not scale past a handful of clients. |
Growthy | Deposit split + full categorization | $149/mo billed annually. Pattern learning on deposits and on the broader transaction workload. Triage dashboard. Audit trail. Works over QBO or Xero (Mode 1) or as standalone GL (Mode 2). |
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.
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.
Scenario | Growthy accuracy | What drives the result |
|---|---|---|
Standard Stripe deposit split (returning client) | 90%+ | Stable fee rate, consistent payout schedule, patterns established by month 2 |
First import of a new Stripe client | 85% | Pattern not yet established. Fee rate confirmed. Refund and chargeback history unknown. |
Multi-processor client (Stripe + PayPal + Square) | 82-85% first import | Three pattern sets starting from scratch. Each trains separately. |
Chargeback resolution entries | Routes to triage | Low confidence by design. Chargebacks resolve unpredictably. Better to ask than to guess. |
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.
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%+.
What is payment reconciliation?
Payment reconciliation is the process of matching merchant deposits to the gross revenue that produced them. A $3,847.92 Stripe deposit represents $3,968.40 of gross sales minus $120.48 of processor fees. Reconciliation means those three numbers appear in the right accounts, not lumped together as a single revenue entry.
Why is net deposit different from gross revenue?
Payment processors net out their fees before sending the payout to your bank. Stripe, PayPal, Square, and Shopify Payments all do this. The deposit you receive is gross revenue minus fees minus any refunds or chargeback holds processed during that payout window. If you post the net deposit as revenue, you understate gross revenue and understate your merchant fee expense at the same time.
How do I reconcile Stripe deposits in QuickBooks?
The basic method: download the Stripe payout report for the period. Create a journal entry in QBO with gross revenue as the credit, merchant fees as a debit, and the net payout amount tying to your bank deposit. Alternatively, use A2X or Synder to automate the sync, or use Growthy's deposit-split pattern to handle Stripe and the rest of your transaction workload together.
What accounts should processor fees post to?
Merchant service fees typically post to a "Merchant Fees" or "Credit Card Processing Fees" expense account under Cost of Revenue or Operating Expenses, depending on your chart of accounts structure and how your accountant classifies them. Do not post processor fees to Cost of Goods Sold unless they are directly tied to a product cost. The IRS treats them as ordinary business expenses, not inventory costs.
How do refunds affect payment reconciliation?
Refunds reduce gross revenue. When a customer returns a product, the refund should reverse the original sale entry, not sit in a separate income or expense account. The timing problem: most processors process the refund into a future payout, so the refund and the original sale appear in different reconciliation periods. You need to track the refund back to the original transaction and post it in the right period.
What is a chargeback and how does it post?
A chargeback is a payment reversal initiated by the customer's bank, not by the merchant. It differs from a refund because Stripe or PayPal debits the disputed amount plus a dispute fee (typically $15) from your next payout before you have a chance to respond. The correct posting: debit a Chargeback Clearing account for the disputed amount plus the fee, credit the bank. If you win the dispute, credit the Chargeback Clearing account. If you lose, close it to an expense account. The clearing account should always return to zero when all open disputes resolve.
What is payout reconciliation?
Payout reconciliation is the narrower version of payment reconciliation focused on the payout itself rather than the underlying transactions. You are matching the payout amount your bank received to the payout report from Stripe, PayPal, or Square. Payout reconciliation confirms the math is right. Payment reconciliation goes further and splits the payout into its revenue, fee, and refund components for proper posting.
How does automated payment reconciliation work?
Automated payment reconciliation uses pattern learning to recognize deposit-split patterns by processor, amount range, and payout schedule. The first time you import a Stripe deposit, Growthy identifies the vendor string, applies the fee-split logic, and posts the components with a confidence score. You review and approve. Next cycle, the same pattern runs with higher confidence. After 30 days on a returning client, most deposit splits categorize at 90%+ accuracy without manual review.
Can I reconcile Stripe deposits without downloading payout reports?
Yes, if you connect Stripe via API. Growthy pulls the payout detail directly from the Stripe API and maps components automatically. The API connection also captures refund and dispute data in real time. If you prefer CSV imports, you can pull the Stripe payout CSV and upload it alongside your bank feed. Both methods produce the same split.
What is fee statement reconciliation?
Fee statement reconciliation is the process of comparing your processor's monthly fee statement to what posted in your books. Stripe, PayPal, and Square send monthly summaries that show total fees charged across all transactions. If your books show a different number, the discrepancy usually traces to a refund that reversed a fee, a dispute fee that was never posted, or a promotion credit that offset fees for a period. Reconciling the fee statement monthly catches these differences before they compound.
Related: SaaS Accounting Hub, Stripe Bookkeeping, Chart of Accounts.
Run a Stripe import. See the deposit split before you categorize anything manually.
Free during alpha. Read-only access. You review every sync.
Request Early Access
Stop chasing W-9s in January. Collect them before the first payment, track receipt, and handle the messy cases (refusal, foreign vendors, single-member LLCs).
Remittance advice tells you which invoices a payment covers. Here's how bookkeepers actually use it, and what breaks when it's missing.
Stripe sends one deposit for 47 transactions. Learn the clearing account method to reconcile lump-sum payment processor deposits with step-by-step journal entries.
Where do Stripe, PayPal, and Square fees go on the P&L? Operating expense, contra-revenue, or COGS — explained with journal entries and a QBO account structure.
Gross or net recording for Stripe, PayPal, and Square? Side-by-side journal entries, ASC 606 principal vs. agent rule, and when each method is actually correct.
Payment processor clearing accounts that never return to zero aren't a rounding issue. Learn why float accumulates, how to audit it, and how to prevent it.
Manual payment reconciliation fails at 8+ clients. Time cost, error rates, tool comparison (A2X, Synder, Growthy), and the ROI calculation for bookkeepers.
The $3,847.92 Stripe deposit in your bank feed is not $3,847.92 of revenue. Here's the 6-step process to split it correctly, every component, every account.