Stripe cash timing guide

Why Doesn't My Stripe Revenue Match the Cash in My Bank?

Stripe can show sales or payment activity that does not equal the cash currently sitting in your bank. Revenue, customer payments, processor balances, fees, refunds, disputes, and payouts are different events that can happen on different dates.

Payment-to-cash path

Follow one payment from customer to bank

A payment can be visible before the related cash is available in the bank. Track the event through the processor and the payout rather than comparing unrelated totals.

  1. 01Customer paysPayment activity begins
  2. 02Stripe balanceFunds move through the processor
  3. 03AdjustmentsFees, refunds, or disputes may change the amount
  4. 04PayoutStripe sends an eligible amount
  5. 05Bank cashThe payout reaches the bank
Conceptual payment path. Actual availability and payout timing depend on the account, payment, adjustments, and Stripe configuration.
01

Payment activity is not the bank deposit

A successful customer payment records a commercial event. The funds may then sit in a processor balance before becoming eligible for payout. A payout is another event, and the bank receiving it is another. Comparing payment activity for one date range with bank deposits from another creates an apparent mismatch even when every event is accounted for.

Start with one payment or payout and follow its identifiers and dates. Do not assume the amount shown as revenue, payments, balance, payout, or bank cash is meant to be identical.

02

Fees, refunds, and disputes change the amount

Processor fees can reduce the amount ultimately paid out. Refunds and disputes may also affect a balance or later payout. The useful bridge begins with the relevant payment activity, shows each supported adjustment, and ends with the payout that actually reached the bank.

The exact treatment depends on Stripe records and the accounting basis used by the business. Avoid forcing every difference into one generic fee line.

03

Recognized revenue follows a separate question

Accounting revenue can be recognized on a different schedule from customer payment and payout. A subscription paid in advance may create cash now while revenue is recognized over the service period. An invoice may create accounting activity before cash is collected.

That is why a revenue report, Stripe activity, Stripe balance, payout report, and bank statement can all be accurate while showing different numbers.

04

Reconcile the event chain in a consistent period

Use the same time zone, date boundaries, currency, and status filters. Confirm whether the customer was charged, whether the payment settled, which payout included it, what adjustments applied, and when the bank recorded the payout. Explain any remaining timing difference instead of overwriting it.

Decision variables

What changes the comparison

Most mismatches become understandable once the event type, date, and status are aligned.

01

Payment status

A created, pending, failed, refunded, or disputed payment does not represent the same cash state.

02

Processor balance

Funds visible inside Stripe may not yet have reached the bank.

03

Payout grouping

One payout can contain multiple payments and adjustments from different dates.

04

Fees and reversals

Fees, refunds, and disputes can change the net amount transferred.

05

Revenue timing

Accounting recognition can differ from both payment and payout timing.

Worked hypothetical

Worked hypothetical: a $1,000 payment is not a $1,000 deposit

A customer pays $1,000 through Stripe. A hypothetical $30 of supported fees applies, and the resulting amount is included in a later payout. The company recognizes revenue under its own accounting policy.

Customer payment
$1,000The payment event appears first.
Net payout amount
$970Hypothetical payment less the stated fee, before any other adjustment.
Bank receipt
$970 laterCash appears when the related payout reaches the bank.

The figures are hypothetical and do not describe Stripe pricing or a guaranteed payout schedule. They show why payment activity, payout cash, and recognized revenue require separate labels.

Decision framework

Trace the mismatch without guessing

  1. 01

    Confirm whether the customer was charged and the payment settled.

  2. 02

    Identify the processor balance and payout that contain the payment.

  3. 03

    Review supported fees, refunds, disputes, and other adjustments.

  4. 04

    Match the payout date and amount to the bank receipt.

  5. 05

    Reconcile accounting revenue separately under the business's accounting policy.

Applying the decision in RunwayCal

Keep reviewed Stripe activity separate from realized bank cash

RunwayCal supports a review-first Stripe import workflow for supported Stripe data and linked events. Imported information remains reviewable before it becomes accepted financial reality.

RunwayCal does not create Stripe charges, write back to Stripe, provide a general bank feed, or perform automatic accounting reconciliation. A dedicated Stripe Treasury balance refresh is a narrow balance connection, not universal banking connectivity.

Related questions

Questions that usually follow

Does a Stripe payment mean cash is in the bank?

No. Payment activity, processor balance, payout, and bank receipt are separate events that may occur on different dates.

Why is a payout smaller than the related payments?

Supported fees, refunds, disputes, payout grouping, currency, or date boundaries may explain the difference. Reconcile the underlying events.

Should Stripe sales equal accounting revenue?

Not necessarily. Revenue recognition follows the applicable accounting policy, which can use different timing from payment or payout cash.

Weekly financial clarity

Get the Financial Clarity Newsletter

Practical notes on cash flow, runway, and financial decisions. Free, weekly, and written for people running the business.

Bring payment events into a reviewable cash workflow.

Keep source activity, accepted financial data, and realized cash clearly distinguished.

Explore Connected Cash Flow