How do I handle payout timing / settlement lag between charge and deposit?

Standard Stripe payouts settle on a rolling basis, typically 2 business days after a charge is captured — so a charge near period-end can deposit in the following period. Assign revenue to the period the charge/capture actually happened in, not the period the bank deposit lands in; using deposit date as the recognition trigger systematically shifts late-period sales into the wrong period.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 16, 2026Last reviewed September 16, 2026Editorial policy

Part of the payment reconciliation and cash application guide.

Standard payout schedule	Rolling, typically 2 business days after a charge is captured ("T+2") for most established US accounts
First payout	Typically 7–14 days after the first live charge, longer in some countries/industries
The period-cutoff risk	A charge captured in the last 1–2 business days of a period can deposit into the next period
What should drive recognition	The charge/capture date — when the sale actually happened — not the bank deposit date
Weekend/holiday effect	A payout scheduled to land on a non-business day pushes to the next business day, extending the lag further

Why the lag exists at all

Most established Stripe accounts settle on a rolling schedule — charges captured today typically arrive in the bank account two business days later. This isn't a delay something went wrong to cause; it's the standard mechanism, driven by how card network settlement works, not a processing failure worth investigating on any individual payout. New accounts see a longer first-payout wait (commonly 7–14 days, sometimes longer depending on country and industry risk) before settling into the standard rolling cadence.

Why this becomes an accounting-period problem, not just a cash-timing one

A two-business-day lag is invisible most of the month — a charge on the 10th settling on the 12th doesn't cross any boundary that matters for reporting. The same lag becomes a real problem in the last few days of a period: a charge captured on the 30th (the last day of a 30-day month) settles on roughly the 2nd of the following month, two business days later. If revenue recognition is driven by when the deposit lands rather than when the sale actually occurred, that charge silently moves into next month's revenue, even though the sale itself happened within the period being closed.

Why the charge date should govern, not the deposit date

The economic event that matters for revenue recognition is the sale itself — the charge being captured — not the mechanical timing of when Stripe happens to batch and transfer the resulting cash. Using deposit date as the recognition trigger conflates "when did we get paid" with "when did the sale happen," which are genuinely different questions with genuinely different answers near a period boundary. Every charge captured within the period, regardless of when its corresponding payout lands, belongs in that period's revenue.

Why weekends and holidays make the lag worse, not just longer

A payout that would otherwise land on a Saturday, Sunday, or bank holiday pushes to the next business day instead — which means the exact lag between charge and deposit isn't a constant two business days, it varies depending on where in the week a period boundary happens to fall. A month that ends on a Friday has a meaningfully different charge-to-deposit lag around its close than one ending on a Tuesday, purely from calendar mechanics, which is one more reason charge date, not deposit date, needs to be the fixed reference point.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Worked example

A $2,300 charge captured on the last day of the month, deposited in the next

A $2,300 charge is captured on Friday, January 31 — the last day of the month. On a standard T+2 rolling schedule, that charge's corresponding payout would settle on Tuesday, February 4 (two business days later, since the intervening Saturday and Sunday don't count as business days). The bank deposit for that specific charge lands entirely in February.

If revenue were assigned by deposit date, this $2,300 sale — which genuinely happened on the last business day of January — would show up as February revenue instead, understating January by $2,300 and overstating February by the same amount. Assigning it correctly by charge/capture date keeps it in January, where the sale actually occurred, regardless of which month the resulting payout happens to land in. The correction isn't about the cash — the cash timing is exactly what it should be — it's specifically about which period's revenue the sale belongs to.

Frequently Asked Questions

Yes — the settlement lag applies to how a charge's cash moves to the bank regardless of how the charge was captured (online, in-person, or otherwise); the period-cutoff risk is about the gap between capture and deposit, not the channel the sale came through.

No — payout schedules vary by account, country, and risk profile; some accounts are on longer schedules (weekly, monthly) or a manual payout schedule rather than the standard rolling T+2 basis described here. The specific lag for a given account should be confirmed rather than assumed.

That's a materiality judgment specific to each close, but the risk compounds specifically at period boundaries every single period, not just occasionally — a small individual discrepancy that recurs every month end is a different risk profile than a one-off small error, worth weighing accordingly.

Sources

Topic

Payment Reconciliation & Cash Application

Payment reconciliation is the process of proving that every dollar that hit your bank account is accounted for somewhere in your books — matched to a deposit, a payout, an invoice, or an explained var…

Integration

Why don't my Stripe payouts tie to the NetSuite bank deposit?

A Stripe payout rarely equals one NetSuite deposit line: Stripe nets many charges, fees, and refunds into one transfer settled days later. Check, in order: the payout isn't unbundled into individual charges, the deposit date doesn't match the transaction date, fees are netted not booked separately, a partial capture created a variance, or the payout is still in Undeposited Funds.

Diagnostic

What breaks when pending Plaid transactions post after month-end lock?

A transaction Plaid shows as pending on the last day of the month can settle days later with a posted date that still falls before close. If a snapshot is taken while it's pending and never revisited, that transaction can be missing from the close entirely, or double-counted if it's picked up again next period without checking whether it was already included.