Match a Stripe payout without losing the fees and refunds

Choose the report that fits the payout

This example starts with a business using Stripe automatic payouts in one currency. Finance checks each deposit manually. The payout reconciliation report groups activity by the automatic payout it settles, giving the match a more useful starting point than a daily sales total.

Manual and instant payouts have different reconciliation constraints. Stripe documents that its automatic-payout report doesn't cover every payout mode in the same way. Confirm the actual account setup before building the match.

An invoice, a payment and a payout are different records. A paid invoice may not have settled into the bank yet; treating that timing difference as missing revenue creates unnecessary investigation.

Keep the transaction detail

Import payout ID, balance transaction ID, reporting category, currency and signed net amount. Retain gross and fee fields where supplied. Preserve source precision and documented units rather than converting every currency through a two-decimal assumption.

Match by payout reference and currency before using amount or date. Amount-only matching can pair the wrong deposit when two payouts happen to be equal. A missing bank reference goes to a candidate-match review, not an automatic match.

Store import watermark and report availability. A report that isn't ready yet should remain pending rather than be treated as a zero-value batch.

Plan the surrounding finance controls ↗

A fictional batch that balances

For illustration, suppose one USD batch contains 1,000.00 in gross payments, 30.00 in fees and a 100.00 refund, with no other adjustments. Its expected net is 870.00 USD. The worksheet makes that arithmetic explicit; it is not a real payout or an assumed fee schedule.

In a real report, categories and signed amounts should come from the itemized data. Disputes, reserves, foreign exchange and other adjustments can affect the result. Don't force a difference into fees merely to balance the worksheet.

A match can be proposed without posting a journal

The workflow proposes the batch-to-bank match and records the difference. Finance reviews ambiguous matches and determines the accounting treatment. Writing a ledger entry is a separate authorized step with its own reference and duplicate protection.

If the accounting API times out after accepting a write, look up the external reference before retrying. Keep the reconciliation record pending posting until the destination confirms it. A successful match and a failed ledger write need different statuses.

Reconcile the unsettled balance separately from settled payouts. Otherwise, a transaction that belongs in the next batch may be mistaken for an error in the current one.

Start with a difficult but bounded period

Pilot one currency and one payout mode. Include a refund, a delayed bank deposit and a failed payout. Compare the workflow's decisions with finance's reviewed result.

Track unresolved differences and time to explain them, including manual review. A faster import is useful only if the month-end totals still reconcile.