The bank statement says the Stripe deposit landed on June 3. Stripe says the payout was created, paid, or available on a different date. If you try to match those rows by date first, the reconciliation fails before you have tested the amount.
That failure is expected.
Stripe and the bank are not showing the same event date. Stripe is showing a payout lifecycle. The bank is showing when cash posted to the account. Those dates can differ because of timezone cutoffs, weekend processing, bank posting rules, and the gap between a customer payment and a payout deposit.
The fix is to stop treating the date as the primary match key. Match the bank statement to the Stripe payout by amount, payout reference, and a controlled date window. Then use the dates to explain timing, not to decide whether the payout exists.
The three dates that get mixed together
A Stripe payout reconciliation breaks when three different dates are treated as one field.
| Date | Where it appears | What it means |
|---|---|---|
| Transaction date | Stripe payment or balance transaction export | When the customer payment, refund, fee, or dispute happened |
| Payout date | Stripe payout export or payout reconciliation report | When Stripe grouped funds into a payout or marked the payout for transfer |
| Bank posting date | Bank statement CSV | When the deposit appeared in the bank account |
Only one of those dates belongs on the bank statement: the bank posting date.
The customer transaction date is not the cash deposit date. A payment accepted on May 30 can settle into a Stripe payout on June 2 and post to the bank on June 3. If the bank statement line is matched against the May 30 transaction date, the row looks missing. It is not missing. It is being compared to the wrong event.
The payout date is closer, but it still may not equal the bank date. Stripe can show the payout as paid or expected on one date while the bank posts the deposit on the next business day. That difference is a timing difference, not an accounting error.
For a deeper explanation of how Stripe timestamps create false date mismatches inside CSV exports, see why Stripe UTC timestamps mismatch bank statement CSV dates.
Start with the bank deposit, not the Stripe transactions
The bank line is the cash event. Start there.
Suppose the bank statement shows this:
| Bank date | Description | Amount |
|---|---|---|
| 2026-06-03 | STRIPE PAYOUT | 4,812.44 |
Stripe may show these payout rows:
| Stripe payout ID | Created | Arrival date | Status | Amount |
|---|---|---|---|---|
| po_1001 | 2026-06-01 | 2026-06-03 | paid | 4,812.44 |
| po_1002 | 2026-06-02 | 2026-06-04 | paid | 1,208.19 |
| po_1003 | 2026-06-03 | 2026-06-05 | paid | 3,441.70 |
The match is po_1001, even though the Stripe created date is June 1. The bank amount and Stripe payout amount agree. The Stripe arrival date lines up with the bank posting date. If the bank posts one day late, it would still be the right candidate.
This is the core rule: for bank-to-Stripe matching, use the payout amount and payout identity first. Use the date as a reasonableness check.
That means your first comparison table should look like this:
| Bank field | Stripe payout field | Match purpose |
|---|---|---|
| Amount | Payout amount | Primary match |
| Description or reference | Payout ID, if present | Strong supporting match |
| Bank posting date | Arrival date or paid date | Timing check |
| Currency | Currency | Required control |
| Account | Destination bank account | Required control when Stripe pays more than one account |
Do not match the bank line against individual Stripe charges. A payout is usually a batch. It can include many customer payments, refunds, fees, disputes, adjustments, and reserves. The bank receives the net payout, not the individual charge total.
Build a date window before you mark anything missing
The date window is the acceptable range between the Stripe payout date and the bank posting date. Without it, every one-day delay becomes a false exception.
For most small finance workflows, use this logic:
| Stripe payout timing | Bank statement timing | Treatment |
|---|---|---|
| Same date | Same date | Direct date match |
| Payout date one business day before bank date | Next-day bank posting | Timing difference, not missing |
| Payout before a weekend or holiday | Bank posts on next business day | Timing difference, not missing |
| Payout expected date differs from created date | Bank matches expected or arrival date | Use arrival date for bank matching |
| Bank date falls outside the expected window | Needs review | Possible missing payout, grouped deposit, wrong account, or bank delay |
The window should be tight enough to prevent lazy matching. Do not accept any Stripe payout within the same month because the amount happens to be close. That turns reconciliation into guessing.
A practical file-based rule is:
- Exact amount match first.
- Same currency.
- Same destination bank account, if available.
- Bank date within zero to three business days of Stripe arrival date.
- Payout reference or bank description confirms the link, where available.
If the amount is unique, this usually resolves the match. If several payouts have the same amount, the reference and date window matter more.
The phrase "match bank statement Stripe payouts dates don't line up" points to this exact issue: the date is visible, so it feels like the obvious match key. In reality, it is the weakest field in the pair.
Use payout-level data before transaction-level data
Stripe exports can show many different files. The right file depends on the question.
If the question is whether a bank deposit matches a Stripe payout, use payout-level data. If the question is why that payout amount is lower than gross sales, then open the payout transaction detail.
Those are different reconciliations.
| Question | Use this Stripe file | Compare it to |
|---|---|---|
| Did this Stripe deposit hit the bank? | Payout export or payout reconciliation report | Bank statement CSV |
| Which sales, fees, and refunds are inside the payout? | Payout transaction detail or balance transaction export | Ledger, sales report, or cashbook |
| Why does gross sales not equal cash received? | Balance transaction export | Sales, fees, refunds, disputes, adjustments |
| Why does a bank date differ from Stripe? | Payout export plus bank statement | Payout arrival date and bank posting date |
Trying to answer all four questions in one lookup is where the spreadsheet becomes fragile.
A clean workflow separates the layers:
- Match the bank deposit to the Stripe payout.
- Confirm the payout amount equals the bank deposit amount.
- Open the transactions inside that payout.
- Reconcile those transactions against the ledger or sales report.
- List any missing, duplicated, delayed, or adjusted items separately.
The bank statement should not be forced to explain every transaction inside the payout. It proves that the payout landed. The Stripe payout detail explains what made up that landed amount.
If you need the full payout-to-bank workflow, use how to match a Stripe payout CSV to your bank statement as the companion process.
What to do when the amount matches but the date does not
An amount match with a date mismatch is usually a timing issue. Do not change the source files to make the dates agree. Keep both dates and label the difference.
Your working table should carry both dates:
| Bank date | Stripe arrival date | Stripe created date | Payout ID | Bank amount | Stripe payout amount | Status |
|---|---|---|---|---|---|---|
| 2026-06-03 | 2026-06-03 | 2026-06-01 | po_1001 | 4,812.44 | 4,812.44 | Matched |
| 2026-06-04 | 2026-06-03 | 2026-06-02 | po_1002 | 1,208.19 | 1,208.19 | Timing difference |
| 2026-06-07 | 2026-06-04 | 2026-06-03 | po_1003 | 3,441.70 | 3,441.70 | Review timing |
That output is better than overwriting the dates because it preserves the audit trail. The client, accountant, or reviewer can see that the payout was found and that the difference is a posting-date difference.
Use these labels:
| Label | Use it when |
|---|---|
| Matched | Amount, currency, and payout identity agree; date is the same or within the expected window |
| Timing difference | Amount and identity agree; bank posted on a different date |
| Amount difference | Payout appears to be the same item, but amounts differ |
| Possible grouped deposit | One bank deposit may include more than one Stripe payout |
| Missing from bank | Stripe payout exists but no matching bank deposit appears in the expected window |
| Missing from Stripe | Bank line appears to be Stripe, but no matching payout is found |
The labels matter because they prevent a timing issue from being treated as missing cash.
What to check when the date window still does not resolve it
If the payout still does not match after using amount, reference, and date window, check the failure in this order.
The bank grouped more than one Stripe payout.
One bank line can represent more than one payout if deposits were batched or posted together. In that case, compare the bank deposit to the sum of several Stripe payouts within the date window.
| Stripe payout | Amount |
|---|---|
| po_1004 | 900.00 |
| po_1005 | 600.00 |
| Total | 1,500.00 |
If the bank line is 1,500.00, the match is a grouped deposit, not a missing payout.
The payout went to a different bank account.
Stripe can pay different balances or connected accounts into different destination accounts. If the amount exists in Stripe but not in the bank statement you are checking, confirm the destination account.
The bank date is outside the normal processing window.
Weekends, holidays, and bank cutoffs can move the posting date. This should be labelled as timing only if the amount and payout identity are still strong.
The amount is net of bank-side charges or adjustments.
Most Stripe payout matching should compare Stripe net payout to bank deposit. If the bank applies an extra charge or adjustment, the amount may differ. That becomes an amount difference, not a date difference.
The bank description is too vague.
Some bank exports show only "STRIPE" without the payout ID. When the description is weak, the amount and date window need to carry the match. If the amount is not unique, leave it in review until another field confirms it.
The Stripe report uses UTC and the bank uses local time.
A payout or transaction near midnight can appear on different calendar dates depending on the file. Keep both dates and use the payout arrival date for bank matching.
The report should explain the timing difference
The final reconciliation should not hide the date mismatch. It should show it cleanly.
A useful report has four parts:
| Section | What it proves |
|---|---|
| Payout match summary | Which bank deposit matches which Stripe payout |
| Date explanation | Whether the date difference is expected timing or an exception |
| Amount check | Whether bank amount and Stripe payout amount agree |
| Exception list | Which items are missing, grouped, delayed, or different |
For the June 3 example, the output could read:
| Bank date | Bank amount | Stripe payout ID | Stripe arrival date | Stripe amount | Difference | Explanation |
|---|---|---|---|---|---|---|
| 2026-06-03 | 4,812.44 | po_1001 | 2026-06-03 | 4,812.44 | 0.00 | Matched |
| 2026-06-04 | 1,208.19 | po_1002 | 2026-06-03 | 1,208.19 | 0.00 | One-day bank posting difference |
That is the answer the reconciliation needs. Not "Stripe dates do not match." Not "bank date wrong." The answer is that the payout and bank deposit agree by amount and identity, with a documented timing difference.
The matching rule to keep
When bank statement dates and Stripe payout dates differ, do not force the dates to agree. Match in this order:
- Currency and destination account.
- Exact payout amount to bank deposit amount.
- Payout ID or bank reference, if available.
- Bank posting date within a tight window around Stripe arrival date.
- Exception label for anything outside the window.
That order keeps the reconciliation anchored to cash while still explaining timing. The bank statement tells you what landed. Stripe tells you which payout created it. The date difference tells you how the cash moved through the settlement process.
Once those three facts are separated, the mismatch stops blocking the close. It becomes a line in the report: matched amount, different date, timing explained.
