Financial reconciliation across settlement dates starts with a familiar mismatch: the payment report shows activity in one month, while the bank statement shows the cash in another. A team can spend hours looking for missing money when it has actually grouped two different kinds of records by the same date.

The useful question is which payment activity belongs to a payout, and which bank receipt belongs to that payout. Those are two separate matches. Stripe’s documentation makes the distinction visible through its Payout reconciliation report ↗ and Bank reconciliation report ↗. This article uses those documented reports as a concrete example, with their product limits kept in view.

Match activity to a batch, then the batch to a receipt

A customer payment is one event in the processor’s balance. Refunds, disputes, fees and adjustments can also affect that balance. The eventual payout is a net amount drawn from the resulting activity.

Stripe’s payout report groups the transactions included in an automatic payout and offers an itemized export. That export lets the team identify payments, refunds, disputes, fees and other balance transactions within the settlement batch.

The second match concerns cash received by the bank. Stripe’s bank report uses a common matching key between a payout and the bank statement deposit. It shows the payout amount, amount received, bank receipt date and reconciliation status.

A total can match without the underlying records matching. Two deposits with identical values are not interchangeable evidence. Keep the payout identifier or matching key and the supporting transaction list with the bank receipt you have matched.

Record Question it answers Date to keep
Payment and balance activity What changed the processor balance? Activity timestamp and reporting timezone
Payout batch Which activity was included in this payout? Payout record and estimated arrival date
Bank deposit What cash reached this account? Actual bank receipt date
Reconciliation record Which records have been matched? Match status and evidence reference

The table is an operational model drawn from Stripe’s documented report structure, rather than a prescription for how every business recognizes revenue.

One payment can cross a month-end

Consider this hypothetical batch, expressed in US dollars. The amounts and dates are invented to demonstrate the reconciliation, not taken from a merchant account.

Illustrative activity Amount
Customer payments recorded in October $1,000
Refunds included in the same payout batch −$20
Fees included in the same payout batch −$30
Net payout $950

The arithmetic is $1,000 − $20 − $30 = $950. Suppose the payout has an estimated arrival date of October 31, but the bank records the $950 deposit on November 2.

The October activity can therefore be matched to a $950 payout while the bank receipt belongs to November. Forcing the bank receipt into October would conceal the actual cash date. Removing the October payment activity because the bank received it in November would lose the activity’s original period.

At the October close, the operational reconciliation should identify that payout and its receipt status. At the November close, it should connect the actual receipt to the existing payout record. The appropriate accounting entries depend on the business’s accounting policy; the matching exercise supplies evidence for those entries.

If the bank instead records $940, a date explanation alone does not resolve the mismatch. Check the payout amount and deposit evidence and investigate the remaining $10. Labeling every difference “settlement timing” can hide a genuine amount exception.

Estimated arrival is not the bank’s posting date

Stripe says its payout reconciliation report groups a payout by the estimated arrival date, rather than the date the bank posts the deposit. The report’s date selector therefore needs a range containing that estimate. If the payout is missing from a chosen range, widening the range is a sensible diagnostic step before declaring it absent.

The bank report separately defines payout_date as the date the payout is expected to arrive and bank_receipt_date as the actual receipt date obtained from bank deposits. The fields may hold different dates while referring to the same payout.

This distinction also matters when a team exports data into its own system. A column renamed simply “date” discards the meaning the source gave it. Keep the original field name or document its meaning in the import mapping.

The reporting timezone is another part of that mapping. Stripe says its bank report prepares summaries using the account timezone and UTC. A transaction close to midnight may belong to different calendar dates under those two views. Choose a consistent period definition before comparing totals, and retain enough timestamp information to explain the difference.

Stripe’s bank report includes an example of a payout marked Paid while its reconciliation status is Unreconciled. The statuses describe different stages: the payout’s state and whether it has been matched to the bank deposit.

A finance interface that collapses those values into one green “complete” badge can send a team to the wrong conclusion. It is more useful to show both states and the evidence behind them.

An unreconciled item needs investigation, but the label does not by itself prove loss. It may reflect a deposit that has not arrived, a matching problem or incomplete report data. Stripe explicitly warns that data rendering can be delayed and that users remain responsible for accuracy and completeness.

Give an exception an owner and a next check. “Await bank statement for the named account” is an actionable record. “Payment missing” is too broad when the payment, payout and deposit each have their own evidence.

Choose the report that fits the payout method

The bank reconciliation feature described here is currently limited to direct US-based Stripe accounts with an automated payout schedule. Stripe says it is not available for Connect accounts, users outside the United States, or manual and instant payouts. An international team should not read these instructions as a promise that the same bank matching feature exists in its Dashboard.

The payout reconciliation report has a different scope. Stripe documents it for automatic payouts and for platforms on manual payouts whose connected accounts use automatic payouts. For other manual payout arrangements, it points users toward the Balance report.

Instant payouts need particular care. Because the user controls their timing and amount, Stripe says it cannot identify the transactions included in each instant payout. The user is responsible for reconciling them against the transaction history.

That limitation changes the work required. A team cannot assume it will receive a preassembled settlement batch for every payout method. Decide how transaction history and payout evidence will be retained before using the method at scale.

A close checklist that preserves the dates

A useful close process separates an amount mismatch from a timing difference and a missing match. It does not make every outstanding item disappear by changing a date.

  1. Establish the report, account, currency, date range and timezone being compared.
  2. Export the itemized activity included in the payout, including refunds, fees and adjustments.
  3. Confirm that the net activity agrees with the payout amount.
  4. Match the payout to the actual bank receipt using its identifier or common matching key.
  5. Retain both the estimated arrival date and the actual bank receipt date.
  6. Record unresolved amounts and unmatched payouts with an owner and supporting evidence.
  7. Recheck outstanding items against the following period’s bank receipts.

Keep the evidence linked to the reconciliation record. A screenshot of a total is less useful than the itemized report and deposit reference when someone later asks why a payout crossed the month-end.

The same record discipline appears in webhook signature and duplicate-event checks: receiving an event and completing the business operation are distinct facts. For the payment product around that operation, see how payments change the product experience.

Reporting & Sources

Documentation read October 8, 2026. The worked example and close checklist are editorial analysis based on the report structure, not a claim of testing an account.