Batch Deposit Matching: Why Bank Rules Can't Solve Math Problems

Your client's bank feed shows a $3,847.92 deposit from Stripe. You open their QBO, and there's no matching transaction. Just a pile of individual sales from the past two weeks. You know what happened: Stripe batched 47 charges, subtracted processing fees, and dropped a single payout. The math is there. The bank rule isn't going to find it.

This is the deposit matching problem, and it's one of the most time-consuming parts of e-commerce bookkeeping. It doesn't matter how good you are at building bank rules. It's not a text-matching problem. It's a math problem. Bank rules don't do math.

What is batch deposit matching in bookkeeping?Batch deposit matching is the process of reconciling a single bank deposit against multiple underlying transactions that were grouped and paid out together. Payment processors like Stripe, PayPal, and Square batch individual charges into a single payout, often after deducting fees. The bank deposit doesn't match any single invoice or sale. It matches a combination of them, minus fees. Standard bank rules fail here because they match text patterns, not arithmetic combinations. Matching engines solve this by testing combinations of open invoices against the deposit amount until they find the set that equals it.

Key Takeaways

• The 3-to-1 problem is arithmetic, not admin. Three invoices paid at different amounts combining into one deposit can't be matched by a rule that looks for text patterns.
• Stripe deposits land net of fees. The gross charges in QBO don't equal the bank amount until you account for 2.9% + $0.30 per transaction.
• Subset-sum matching tests combinations. A proper matching engine finds which group of open charges sums to the deposit, something bank rules structurally cannot do.
• E-commerce clients have this every week. For any client running Shopify, WooCommerce, or Stripe billing, this is a recurring reconciliation gap, not a one-off.
• Manual matching takes 15-30 minutes per payout. For a client with weekly Stripe deposits, that's 60-120 minutes monthly on one repetitive task.
• Automated bank reconciliation that handles subset-sum matching cuts this to near zero.

The 3-to-1 Problem Every Bookkeeper Knows

Picture a consulting client who invoices three clients in a week: $1,200, $875, and $450. All three pay by credit card through Stripe. Stripe batches the payouts and drops $2,525 into the bank (assuming zero fees for simplicity).

You've got three open invoices in QBO and one bank transaction. The bank rule you set up looks for transactions labeled "Stripe" within 5% of each invoice amount. It finds nothing, because none of the three invoices equals $2,525. The rule fails. You're now matching manually.

This is the 3-to-1 problem: three inputs, one output, with the relationship defined by addition, not by text similarity. Every bookkeeper who works with e-commerce or subscription clients has lived this. The frustration isn't that it's complex. It's that it's completely mechanical but still somehow requires a human every time.

The reason is simple: bank rules aren't calculators. They look at labels, amounts, and date ranges. They match one transaction to one rule. They don't test whether a combination of open invoices sums to a given amount. That requires a different kind of logic entirely.

For small batches (two or three invoices) you can spot the right combination quickly. But Stripe doesn't batch two or three charges. It batches 20, 47, 150. At that scale, manual matching isn't slow. It's impossible without software support.

Why Bank Rules Fail at Deposit Matching

Bank rules work great for predictable, one-to-one transactions. A $2,400 ACH from "Acme Corp" every 15th of the month? Rule handles it in a second. That's pattern matching: find a label, find an amount range, apply a category. Done.

Deposit matching breaks that model in three ways.

The amounts never match directly. A rule that looks for a transaction "within 5% of invoice amount" finds nothing when the deposit is an aggregate of 12 invoices. There's no single invoice it's close to.

The labels are generic. "Stripe" and "STRIPE TRANSFER" don't tell you which charges are included. Every Stripe payout looks the same from the bank's perspective. The rule has no information to differentiate this week's payout from last week's.

The relationship is additive. Finding the right match requires testing whether combinations of open invoices sum to the deposit. A rule engine that processes transactions one at a time has no framework for that kind of combinatorial check.

This isn't a limitation of any specific accounting software. It's structural. Rules are filters. Deposit matching requires search: specifically, searching through possible combinations of open transactions to find the one that adds up.

The Stripe/PayPal Version (47 Charges, 1 Payout)

The 3-to-1 problem is manageable when it's literally three invoices. E-commerce makes it orders of magnitude harder.

Your client runs a Shopify store. They had 47 orders last week ranging from $12 to $380. Stripe batched the payouts, took its 2.9% + $0.30 per transaction (the standard US card rate, confirmed current as of 2026), and deposited $3,847.92 into the business checking account. The gross sales were $4,021.14. The difference ($173.22 in fees) is missing from the picture unless you account for it explicitly.

This creates two problems at once. First, the subset-sum problem: which 47 of the store's QBO sales records correspond to this payout? (It may not be all 47. Stripe's payout timing doesn't always align perfectly with QBO's order dates.) Second, the net-versus-gross problem: even if you identify all 47 charges, they sum to $4,021.14, not $3,847.92. The fee has to land somewhere, usually Merchant Account Fees or a similar expense account.

Standard automated expense categorization tools handle the second part reasonably well. The fee is a known structure (2.9% + $0.30), so once you identify the charges, you can calculate the expected fee and book it to the right account. We net it correctly, which means the gross sales and the fee entry together reconcile to the bank deposit.

The first part (identifying which charges belong to this payout) is the hard problem. Stripe's payout documentation explains that by default, Stripe batches charges on a daily schedule and transfers the net amount after fees, meaning the bank deposit will never equal any single charge or invoice. Getting that breakdown into QBO without manual entry requires either a native Stripe integration or a matching engine that can work backward from the deposit amount.

For bookkeepers managing five or more e-commerce clients, this calculation runs every week. Monthly, that's potentially hours spent on a single reconciliation task across your client base.

How Matching Engines Solve Subset-Sum Problems

The technical name for what deposit matching requires is subset-sum matching. Given a set of open transaction amounts and a target number, find the subset that sums to the target. It's a well-understood computational problem, and it's exactly what a purpose-built matching engine does.

Here's how it works in practice. The system holds a list of open receivables or sales transactions (let's say 47 e-commerce orders). When a $3,847.92 Stripe deposit appears, the matching engine doesn't look for a single transaction close to that amount. It tests combinations. It accounts for the expected fee structure (2.9% + $0.30 per charge) and works backward to find the gross amount that, after fees, equals $3,847.92. Then it searches for the combination of open charges that sums to that gross amount.

When it finds the match, it proposes: "These 47 transactions, totaling $4,021.14, correspond to this deposit. Fees of $173.22 to Merchant Fees." You confirm. Done.

Pattern learning makes this faster with repetition. After seeing your client's Stripe payout patterns for a few weeks, the system learns the timing: Stripe pays out Monday for the prior week's transactions. It learns the fee rate. It learns which QBO category the fees go to. The confirmation step gets shorter because the proposals get more accurate.

This is categorically different from a bank rule. A rule is a static filter you configure once. A matching engine is doing active search, accounting for arithmetic relationships and adjusting based on what it's seen before.

The result for e-commerce bookkeepers: a task that took 20-30 minutes per client per week drops to a 30-second confirmation step.

What This Means for E-Commerce Bookkeepers

If you have even two or three e-commerce clients, you've already done this math. Twenty minutes per Stripe payout, four payouts a month per client, three clients: that's four to five hours monthly on deposit matching alone. Hours you're not billing for because you quoted a flat monthly rate before you understood how often the 3-to-1 problem would show up.

The clients most affected are running Stripe or Square with weekly payouts, PayPal with irregular batch timing, multi-currency stores where exchange rates create additional reconciliation gaps, or any business collecting through a payment aggregator. That's most e-commerce clients.

What changes with proper batch deposit matching:

Reconciliation closes on time. No more waiting for a human to work through payout breakdowns before the books can close. The matching engine proposes, you confirm, the period closes.

The fee tracking is accurate. When fees get missed or lumped into "Uncategorized," the P&L is wrong. Gross revenue looks lower than it is, or the expense line is inflated. Netting correctly means the income statement reflects actual performance.

You scale without proportional time growth. Adding a fourth e-commerce client doesn't add another four hours of monthly reconciliation if the matching is automated. The economics of your practice change.

Scope creep disappears from e-commerce quotes. When you know deposit matching takes 5 minutes instead of 25, you can price e-commerce clients accurately from the start.

The bookkeeping automation landscape in 2026 has tools that handle one-to-one matching well. Subset-sum matching for batch payouts is the gap that still catches bookkeepers off guard, especially when they're onboarding a new Shopify client mid-month and the first payout reconciliation takes twice as long as expected.

You already know the problem. Bank rules aren't the answer. Pattern learning that does the arithmetic is.

Growthy is bookkeeping software, not a CPA firm. This content is educational, not professional advice. Full disclaimer.

Get Started with Growthy