Stripe payout reconciliation: charges, fees, refunds and disputes

A Stripe transfer is a net figure covering a batch of balance transactions. Reconciling it means decomposing the transfer back into the charges, fees, refunds and dispute activity that produced it, then proving the components explain the deposit.

What sits inside a single transfer

• Charges, each with its own processing fee deducted at the transaction level.
• Refunds, which may relate to charges in a prior payout period.
• Disputes, where both the disputed amount and a dispute fee are deducted, often on a different date from the original charge.
• Adjustments and reversals, including a dispute later resolved in the merchant's favour.

One practical detail catches teams out repeatedly: Stripe's balance transaction exports express amounts in the currency's smallest unit. A charge of $570.90 appears as 57090. Any reconciliation built on those exports has to normalize units before comparison, and a normalization error there produces differences that look like real reconciliation problems.

Where the recurring exceptions come from

Most persistent Stripe clearing balances trace to three patterns. Refunds and disputes crossing a period boundary, so the reduction and the original sale sit in different months. Fees posted in aggregate rather than per transaction, so per-charge variances cannot be traced. And a second processor clearing through the same account, which makes the balance a composite.

Reconciling it deterministically

Each transfer is rebuilt from its balance transactions, normalized to a common unit, with refunds and disputes attributed to the payout that actually carried them. Residuals outside a defined tolerance become reason-coded exceptions rather than an unexplained balance.

For a worked demonstration on synthetic data, see the reference build.

Platform behaviour changes. Where specific gateway mechanics matter to a build, we verify them against current vendor documentation at implementation time rather than relying on general knowledge.

When standard software is enough

Standard connectors are often the right solution for standard workflows. If the connector posts activity correctly and the clearing account returns to zero without investigation, there is nothing here worth building. Keep the software you have.

When custom automation may be justified

The case for a custom reconciliation layer depends on recurrence, not on frustration. It is worth looking at when the same exception patterns return every close, several sources have to agree before the balance resolves, and meaningful staff time goes into work that follows repeatable rules.

If you want a structured answer rather than an opinion, the Fit Score scores one workflow against recurrence, effort, source complexity, rule repeatability and portfolio reuse. It runs in your browser and takes a couple of minutes.