Stripe Payout

A payout is a boundary, not a sale

The single most expensive mistake in Stripe bookkeeping is treating the payout as the income event. It is an easy mistake to make, because the payout is the first thing that shows up in a bank feed, and bank feeds are where a lot of small businesses do their accounting.

But every dollar in a payout was already earned. The customer paid days ago. The sale, the tax on it, and the Stripe fee that came out of it all happened at charge time, in the Stripe balance, before any bank was involved. The payout just relocates the leftover.

So a payout is a boundary between two asset accounts: money Stripe holds for you, and money your bank holds for you. Crossing that boundary changes where the money is, not how much you have. In double-entry terms, both sides of a payout are asset accounts, and a correct payout entry never touches an income account at all.

This is also why net deposits cause trouble. If you record the $8,412.19 as revenue, you have understated sales by the fees and refunds Stripe already took out, overstated nothing to compensate, and lost the fee expense entirely. The gross-versus-net problem is not a rounding issue. It is the difference between books that support a tax return and books that do not.

What decides the amount and the date

Two settings and one constraint.

The first setting is your payout schedule. By default Stripe pays out automatically, and you can change the interval or turn automatic payouts off entirely. If you turn them off, Stripe says, "you must manually send funds to your bank account," through the Dashboard or the API. Manual payouts are "available in all regions except Brazil and India, where payouts are always automatic and daily."

The second is the destination bank account, which is what a payout is aimed at and what the failure codes are usually about.

The constraint is availability. A payout can only include funds that have become available in your balance, which is why the payout amount rarely matches any tidy figure from your sales reports. Card payments sit in the pending balance for a period that depends on your country and account before they can be paid out, so a payout on Thursday is generally settling Monday's business, not Wednesday's.

On top of that, Stripe's arrival date is a forecast rather than a promise. The API describes it as the "date that you can expect the payout to arrive in the bank," and notes that it "factors in delays to account for weekends or bank holidays." Money leaving Stripe on schedule and money appearing in your bank on schedule are two different events, and the gap between them is an ordinary in-transit item rather than a problem.

The five statuses and what each means for your books

Stripe documents the path a payout takes: "A payout is `pending` until it's submitted to the bank, when it becomes `in_transit`. The status changes to `paid` if the transaction succeeds, or to `failed` or `canceled` (within 5 business days)."

**pending** and **in_transit** are pre-arrival states. Nothing has reached your bank, and nothing belongs in your bank account in QuickBooks yet.

**paid** is the state that should produce a record. Note the word Stripe attaches to the matching event: `payout.paid` fires when a payout is "expected to be available in the destination account," which is a forecast of arrival rather than a confirmation of it.

**failed** and **canceled** mean the money came back. Stripe reverses the original balance transaction through a field called `failure_balance_transaction`, which "returns the funds from the failed payout back in your balance." Because the money never moved, there is nothing to record, and the correct number of QuickBooks entries for a failed payout is zero.

One wrinkle deserves attention at close: Stripe warns that "some payouts that fail might initially show as `paid`, then change to `failed`." A payout can therefore be booked and then fail afterwards, which is the one case where a real record is left behind for something that did not happen.