One Stripe payout, forty invoices: reconciling gross vs net in QuickBooks
The deposit never matches an invoice, because it was never meant to. The clearing-account method that makes batch settlements reconcile, and the shortcuts that quietly break your margin.

A deposit lands: £8,412.66. You have forty open invoices. None of them is £8,412.66, and no combination of them adds up to it either.
That is not an error. The deposit was never going to match an invoice, because it is not a payment against a sale — it is a settlement of a balance. Recording it correctly requires a different mechanism, and the shortcut most businesses reach for silently damages their margin figures.
What is actually in that number
A single payout typically contains:
- Many sales, each at its gross value
- minus processing fees on each
- minus refunds issued in the settlement window
- minus dispute amounts and dispute fees
- plus or minus adjustments — reserve releases, corrections, currency conversion effects
So the payout is a net figure over a period, not a payment. Trying to match it to invoices is trying to match one number against a calculation.
The shortcut, and what it costs
The common approach: record the deposit as income, categorise it to sales, move on. It reconciles in seconds and the bank agrees.
What it costs:
Revenue is understated by the fees. You did not sell £8,412.66. You sold roughly £8,700 and paid roughly £290 to be paid.
Costs are understated by the same amount. Your processing cost — often one of the larger line items in a payments-heavy business — does not appear anywhere. You cannot see it, benchmark it, or negotiate it, because as far as the books are concerned it does not exist.
Gross margin is wrong, and every percentage derived from it is wrong.
No invoice is ever marked paid. Receivables stay open against customers who settled weeks ago, and eventually someone chases one of them.
Refunds vanish into the deposit. Revenue quietly reduces with no traceable cause.
The profit figure at the bottom may look approximately plausible, which is what makes this durable. Every component of it is wrong in a consistent direction.
The method that works: a clearing account
One extra account, and the whole thing resolves.
Set up a clearing account — an ordinary bank-type account in QuickBooks called something like Stripe Clearing. It represents money that is yours, has been collected, and has not yet reached your bank.
Then three movements:
1 · When a sale is paid, record the payment into the clearing account, at gross. The invoice is marked paid — correctly, on the day the customer paid. Receivables are accurate. The clearing account balance rises by the full amount the customer was charged.
2 · Record the fee as an expense. A separate transaction reducing the clearing account and posting to a processing-fees expense account. Your cost of taking payments is now visible and countable.
3 · When the payout arrives, record a transfer from the clearing account to your real bank account for the exact deposit amount.
The clearing account should now sit at or near zero between settlements. That is the whole control: a clearing balance that drifts upward means fees are not being recorded; a balance that drifts negative means sales are missing.
The bank reconciles cleanly, because the deposit is one transfer matching one bank line. Invoices are individually settled. Fees are visible. Refunds are their own events.
Doing it without dying of data entry
At forty transactions a month, entering this by hand is tedious but fine. At four hundred it is somebody’s job, and at four thousand it is not happening.
Three routes, in order of preference:
A connector that imports the detail. Several tools pull each charge, fee, refund and payout from the processor and post them at transaction level. This is the right answer for most businesses at volume. Verify it handles refunds and disputes as separate events rather than netting them, and that it does not create duplicates against the bank feed — the two racing each other is the standard failure.
Summarised journals per payout. One journal per settlement: total gross sales, total fees, total refunds, net to bank. Far less data, and you lose invoice-level settlement — acceptable for high-volume, low-value e-commerce where invoices are not really the unit of account.
Manual, at low volume. Perfectly reasonable under a few dozen transactions a month.
Whichever you choose, the clearing account is the control. It is the only thing that tells you the method is still working.
The traps
Bank rules that categorise payouts straight to income. A rule matching STRIPE and posting to sales will reconcile perfectly forever while producing exactly the shortcut above. Balanced books, wrong numbers, nobody looking. This is the balanced-but-wrong failure in its purest form.
Doing it twice. The connector posts the payment and someone also marks the invoice paid by hand. Two records, one payment. The clearing account will show it, which is another reason the balance check matters.
Multi-currency. Sales in one currency settling in another add an FX difference that belongs in its own account, not absorbed into fees.
Reserves and holds. If the processor is withholding a portion, the clearing balance will not return to zero — legitimately. Know which is which, or you will chase a difference that is really a payout hold.
Why this is annoying in the first place
Because the payment and the record of the payment travel separately.
The customer pays an invoice. The processor knows exactly which sale that was. Then it aggregates thousands of them into one bank deposit, and the bank tells your accounting system a single number with a reference string designed for a bank statement rather than for matching.
Every bit of the work above is reconstructing a link that existed at the moment of payment and was discarded before it reached the ledger. The clearing account is a way of holding that link open long enough to put it back — which is exactly the point made in what an AI reconciliation agent actually does.
Where Fynex fits
Fynex keeps the link rather than rebuilding it. A payment carries the invoice it settles, the fee deducted from it and the settlement it will arrive in, so a batch payout is already broken down into its components when it lands.
The clearing account stops being a manual discipline and becomes a state that is either reconciled or has a named exception attached — a refund, a dispute, a reserve, a short payment — surfaced on the day rather than as a residual balance at month-end.
Gross stays gross, fees stay visible, and the deposit that matches nothing becomes a settlement whose contents you can list.