Stripe payout cutoff dates at month end

The problem

Stripe pays out on a rolling schedule. For most US accounts the standard schedule is two business days after the funds become available, and the funds become available a day or more after the charge. So the last few days of every month produce charges that are charged in one month, available in the next, and in the bank in the next. Each of those charges has to land in exactly one month, by a rule that does not change.

Three dates, three answers

A $100 charge on September 30, fee $3.20, available October 2, paid out October 2, in the bank October 3.

Each is internally consistent. The months differ only in where the boundary falls. The errors come from mixing them: sales booked on the charge date because that is what the export shows, and the deposit then categorised as income on the bank date.

Fix the timezone

In Stripe's API, created and available_on are timestamps in UTC; the dashboard and its exports can show them in your account's timezone. A charge at 9 pm Pacific on September 30 is 4 am UTC on October 1. Use UTC, as Stripe's own data does, and keep it every month. ClearDeposits dates everything in UTC.

What to do with payouts in transit

At any month end some payouts have left Stripe and not reached the bank. They are not a difference; they are a list. Keep it as part of the close:

• Payouts dated on or before the last day of the month with no bank line in the month: in transit at month end.
• Bank lines in the month for payouts dated in the previous month: last month's in-transit list clearing.
• The bank check for the month is: payouts for the month, less this month's in-transit list, plus last month's, equals the Stripe deposits on the statement.

Under the bank basis the in-transit payouts are next month's revenue and nothing is booked for them yet. Under accrual and the Stripe 1099-K basis (available-on date; timing only) the revenue is booked and the clearing account carries the amount until the deposit.

Refunds and disputes across the boundary

A refund on October 2 of a September 28 charge is an October reduction of revenue under every basis; it is dated when Stripe processes it. A dispute opened in October on a September charge is dated in October, with its fee, and linked to the September charge. If the dispute is won in November, the reversal is dated in November. None of these reopen September.

The rule, written down

A cutoff policy fits on one line: the basis, the timezone, and the treatment of in-transit payouts. For example: "Revenue on the available date, UTC; payouts in transit at month end listed and cleared against the following month's statement." Apply it to every month, including the first one, and the year-end reconciliation to the 1099-K becomes a check rather than a search. Stripe 1099-K reconciliation shows why the available-date basis ties to the form; cash-basis revenue recognition for Stripe subscriptions works the choice through for a renewal.

How ClearDeposits applies it

The basis is one setting per company. Every charge, fee, refund, dispute and payout is dated by it, in UTC, and the period cutoff is enforced: revenue and the clearing asset land in the month they belong to, and the cash moves from clearing to bank in the month it arrives. Payouts in transit are shown as a future-period row on the reconciliation view, not summed into the month. A change of basis takes effect from a date you choose, after a preview of what moves.