How do I reconcile processor fees so net deposits tie to gross sales?

Why gross sales minus an estimated fee rate doesn't tie

A quick approximation — take gross sales for the period, subtract an assumed processing rate, expect that to equal the deposit — fails because a payout batch isn't only charges. It also includes refunds issued in that window (which reduce the payout and can affect fees differently than the original charge), and any disputes or chargebacks that settled in the same batch. An estimate based purely on gross charge volume and a flat fee percentage ignores all of that, which is exactly why it never quite ties to the cent, even when it's close.

What a balance transaction actually gives you

Stripe creates a balance transaction for every event that moves money through the account balance — a charge, a refund, a fee, a payout itself. Each one carries its own amount (the gross value), fee (what was deducted for that specific transaction), and a reporting_category that groups it (charge, refund, payout, fee, and so on). Reconciling isn't matching one number against another; it's summing every balance transaction that belongs to a specific payout's batch and confirming that sum equals the payout amount that actually landed in the bank.

Why the batch boundary matters more than the date range

A payout doesn't necessarily correspond cleanly to "everything that happened since the last payout" by calendar date — depending on the account's payout schedule and processing timing, a transaction that occurred right at a boundary can land in the next batch rather than the one its date might suggest. Reconciling by pulling transactions for a calendar period and comparing that sum to a payout dated within that period is a common source of small, persistent discrepancies; the batch itself, not the calendar window, is the actual unit that needs to tie.

What to do when it still doesn't tie

If summing an entire batch's net balance transactions still doesn't equal the payout, the next place to look is transactions with a reporting_category outside the obvious charge/refund set — a dispute fee, a reversed transaction, or an adjustment tied to a prior period's payout landing in this batch instead. Isolating the difference amount first, then filtering the batch's transactions for anything with that category, finds the specific line responsible faster than re-summing the whole batch repeatedly.