A Stripe payout that does not match your sales records is usually being compared at the wrong level. The payout is a net settlement batch. Your sales report is often a gross activity report. Before changing a formula or searching individual orders, prove that the payout, period, and records belong to the same comparison.

Start with the payout event itself. Record its payout ID, amount, currency, status, expected arrival date, and the bank deposit it produced. Then open the transaction detail for that specific payout. Do not begin with the total sales figure for the day or month.

This first distinction narrows the failure quickly:

The correct investigation order is not “check every transaction.” It is to eliminate whole classes of causes before moving to row-level work.

1. Confirm the payout and bank deposit are the same event

The first number to prove is the net Stripe payout against the cash that reached the bank. This establishes whether Stripe-to-bank is correct before sales records enter the comparison.

Capture these fields:

If the payout and bank deposit agree, the cash event is sound. The remaining mismatch sits between the sales records and the contents of the payout.

If they do not agree, stop comparing sales. Check whether two payouts were grouped into one bank deposit, one payout was split, the bank converted the currency, or the deposit is still pending. The full Stripe payout-to-bank matching workflow covers that separate layer.

Do not force gross sales to equal the bank line. Gross sales are upstream of fees, refunds, disputes, reserves, and settlement timing.

2. Open the transaction detail for the exact payout ID

Once the bank event is confirmed, use the payout ID as the comparison boundary. A date range is weaker evidence because activity created on one day can become available and settle on another.

The payout detail should identify every balance transaction included in the batch. Depending on the account activity, that can include:

• Charges
• Refunds
• Disputes
• Processing fees
• Adjustments
• Transfers
• Reserve movements

Add the net effect of those rows. It should equal the payout amount.

For example:

A sales report showing $12,400 is not evidence that the $11,223 payout is wrong. It shows that the report contains gross charges while the payout contains the net effect of all eligible activity.

This is the first place to look when a Stripe payout doesn't match sales records. If the batch arithmetic works, Stripe has already explained the payout total. Your next task is to prove which parts of that explanation are present in the sales records or ledger.

3. Search by transaction ID before amount or date

Use the strongest identifier available. For Stripe activity, that is normally a charge ID, payment intent ID, balance transaction ID, refund ID, or another unique reference carried into your order or ledger export.

Search in this order:

1. Exact unique transaction reference
2. Exact amount and exact date
3. Exact amount across nearby dates
4. Surrounding orders or sequence gaps
5. Split totals, duplicate rows, and excluded records
6. Wrong report, period, account, or file version

Normalize the reference before declaring it missing. Remove leading or trailing spaces. Confirm that the sales export did not truncate the ID, convert a long value, prepend an apostrophe, or store one identifier while Stripe exposes another.

In a working helper column before the search:

=TRIM(SUBSTITUTE(UPPER(A2),CHAR(160)," "))

Column A is the reference column — charge ID, payment intent ID, or balance transaction ID. TRIM removes standard spaces; CHAR(160) covers the non-breaking space some exports add. UPPER removes case differences. If the export adds a prefix like pi_ or an apostrophe, strip it with a nested SUBSTITUTE before comparing.

One Shopify order number, for example, is not automatically the same as a Stripe charge ID. If the sales system stores an order ID and Stripe stores a payment reference, you need the field that connects them. Matching unrelated identifiers produces a list of false exceptions.

When the exact ID exists in both files, compare the amount, currency, and transaction type. When it exists only in Stripe, determine whether the sales export excluded that row. When it exists only in sales, find whether it settled in a different payout.

4. Separate fees, refunds, disputes, and adjustments

Most payout-versus-sales differences are not one missing sale. They are a collection of transaction types that the sales total does not include.

Build a bridge from gross sales to net payout:

Keep each category separate. A single “difference” line hides whether the amount is expected or requires correction.

Refunds need particular care. A refund processed this week may relate to a sale from last month. It can reduce the current payout without reducing the current-period sales report. Disputes can arrive even later. That is a timing relationship between two business events, not evidence that the payout omitted sales.

Fees also create a predictable gap. If sales records show gross revenue while the books record only net cash, both revenue and fee expense can be misstated even though the bank deposit is correct.

5. Check settlement timing, cutoff, and transaction status

Stripe does not pay out every sale according to the sale date. A charge moves through creation, payment, availability, payout creation, and bank posting. Those dates can cross reporting periods.

For every sale that appears missing, compare:

A completed sale outside the payout is often in a later batch because it was not yet available at the cutoff. A pending or failed payment should not be treated as payout activity. A payout date also should not be used as the sales date.

Timing items are carried. They remain on the open list until the later payout settles them. They are not corrected with a journal entry merely to make the current payout equal the current sales report.

Errors are handled differently. A missing ledger entry, duplicate sale, wrong amount, wrong currency, or misposted account needs correction or escalation now.

6. Test grouped amounts, duplicates, scope, and file integrity

If the mismatch survives the first five checks, widen the investigation carefully. Do not abandon the payout boundary.

First test whether one side is grouped differently. One payout row can represent many charges. One order can also be split across several payments, partially refunded, or settled in more than one currency. Search for combinations of rows that equal the unexplained amount.

Then check duplicates. Compare the count of unique references with the total row count. A duplicate can make the sales file higher than Stripe even when every legitimate sale is present.

Finally, verify the comparison baseline:

Check filters and export settings. Confirm that both files cover the intended account, currency, payment status, and period. If either file was opened, edited, re-saved, or re-exported during the investigation, obtain a fresh export and repeat the integrity checks. Repairing an uncertain source file in place leaves you with a result you cannot defend.

Turn the mismatch into a reconciliation result

The investigation is complete when every difference has a status and an action. “Stripe does not match sales” is not a usable result.

Your report should separate:

Keep the payout summary, gross-to-net bridge, matched rows, and exception list together. That gives the reviewer a direct line from the bank deposit back to the underlying sales activity. If the mismatch also affects the close, use the same evidence to work through the month-end books-versus-bank checks without combining timing items and posting errors.

The clean stopping point is a payout that agrees to the bank, a batch that adds to the payout, and a sales bridge in which every remaining difference is classified as timing, an expected deduction, or a specific error requiring action.