QuickBooks and Stripe, tied to the payout.
Stripe is a settlement system, not a ledger. The mismatch between how it pays out and how your books record revenue is the entire problem, and it is worth understanding before choosing a tool.
Why the stock connector isn’t the end of it.
Stripe pays you in batches, net of fees, on a rolling schedule. Your accounts need revenue recognised per transaction, gross, in the period it was earned, with fees as a separate expense. Almost every reconciliation problem people have with Stripe and QuickBooks traces back to that single structural difference.
Tools that simply import the bank deposit produce books that look plausible and are wrong in a specific way: revenue is understated by exactly the fee total, and there is no expense line to show for it. It reconciles against the bank, which is why it survives review, and it misstates the P&L every month.
Where it breaks.
Each of these is something we have had to unpick on live systems.
The deposit is not the revenue
A $50,000 month at roughly 2.9% plus 30c is about $48,300 in deposits. Booking the deposits understates revenue by $1,700 and hides the processing cost entirely. Over a year that is a materially wrong picture of both the top line and cost of sales.
Payouts batch across period boundaries
One payout covers many charges, and the settlement window rarely aligns to a calendar month. Charges from the 30th and 31st settle in the next period. Without transaction-level detail beneath each payout, month end becomes an exercise in manual apportionment.
Refunds, disputes and chargebacks each behave differently
A refund may or may not return the processing fee depending on when it happens. A dispute withholds funds and adds a separate fee, then either releases or does not. Treating all three as negative revenue loses the distinction your finance team needs and misstates the fee expense.
Multi-currency settles at Stripe's rate, not yours
Charging in one currency and settling in another introduces a conversion Stripe performs at its own rate, plus a conversion fee. QuickBooks applies its own exchange handling. Reconciling requires recording the actual settled amount rather than a recomputed figure, or you accumulate small permanent differences.
Subscription billing is not a series of one-off charges
Stripe Billing generates invoices, proration, credits and failed-payment retries. Proration in particular does not map cleanly onto a single revenue line, and if you have any deferred revenue obligation the charge date is often the wrong recognition date.
How we approach it.
The integration has to work from Stripe's balance transactions rather than the bank feed. That is the only view containing gross amount, fee, net and the payout each transaction belongs to — everything needed to produce an entry that both reflects reality and ties to the deposit.
We then decide recognition timing with whoever owns your accounting policy. For most transactional businesses charge date is fine. For subscriptions and anything with a delivery obligation it is often not, and that decision should be made deliberately rather than inherited from a connector's default.
The output is a reconciliation report per payout: gross, fees, refunds, disputes, net, and the matching bank line. If those do not agree, the pipeline says so rather than writing an entry that silently absorbs the difference.
Questions people actually ask.
There is a Stripe-published app and several third-party connectors. They work for simple, single-currency, non-subscription use. The common failure is that they book the payout rather than decomposing it, so revenue is understated by the fee total and processing costs never reach the P&L.
As an expense, separately from revenue. The correct entry recognises gross sales as income, processing fees as an expense, refunds against the original revenue, and nets to the deposit that hits the bank. Anything that goes straight from deposit to a single income line is losing the fee.
Because a payout is a settlement batch, not an invoice. It groups charges across a rolling window that does not respect your accounting month, then subtracts fees and any disputes. Matching requires reconciling at the balance-transaction level underneath the payout, not at the deposit.
Stripe retries on a schedule, so a single subscription period can produce several attempts and one eventual success. Booking each attempt creates phantom revenue; ignoring them loses the dunning picture. We record attempts as events and revenue only on success, which keeps both views intact.