Stripe to accounting: the reconciliation nobody warns you about

Most Stripe-to-accounting automations create an invoice per charge and stop there. It looks correct, the numbers appear in the accounting system, and then the bank reconciliation does not balance — because the amount that arrived in the bank is not the sum of the charges, and never was.

Stripe pays out in batches, net of fees, on its own schedule, with refunds and disputes netted in. Getting this right is mostly about understanding that shape, and the difference between an automation your accountant thanks you for and one they quietly work around is almost entirely in the details below.

What we'll cover

• Why charges do not equal deposits
• The payout is the unit that reconciles
• Fees are an expense, not a discount
• Building it with CodeWords
• Timing and the accounting period
• Refunds, disputes and chargebacks
• What your accountant actually wants
• Platforms, marketplaces and Connect
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why charges do not equal deposits

Fees are deducted before payout, so the deposit is always less than the gross.

Payouts are batched across many charges over a rolling window, not one per transaction.

Refunds are netted in, reducing a payout rather than appearing as a separate outgoing.

Disputes are deducted when raised and returned if won, which produces two entries at different times for one event.

Other adjustments appear — Stripe-side corrections, reserves, and account-level charges — which belong to no individual customer.

Currency conversion happens at Stripe's rate for cross-currency charges, so the settled figure differs from the charged figure by more than fees.

The payout is the unit that reconciles

One payout equals one bank deposit, which is what makes it the right anchor for the whole model.

Each payout decomposes into the charges, refunds, fees and adjustments that make it up, and that decomposition is available.

Reconcile at the payout level and the bank statement matches exactly, every time.

Post the detail underneath it, so revenue is recognised per charge while the bank line has a single matching counterpart.

Use the balance transaction, which is the record that carries gross, fee and net for every movement and is the correct source for the accounting figures.

A sync that never mentions payouts will produce a reconciliation your accountant does by hand, which is the thing the automation was meant to prevent.

Fees are an expense, not a discount

Record revenue gross and processing fees as an expense, which is what standard practice expects.

Netting them understates both, and it makes the fee invisible — which matters, because it is usually a significant line.

Fees vary by card, country and method, so an assumed percentage will drift from reality and the drift is the part you want to see.

Separate the fee types: processing, currency conversion, dispute fees, and platform fees are different expenses.

Disputes carry their own fee, usually retained even when the dispute is won, which is a detail people are surprised by at year end.

Report the effective rate monthly, since it is a number worth watching and almost nobody does.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so Stripe, your accounting system and the bank feed can meet in one automation.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: how payouts should be posted, how fees and refunds are recorded, and against which accounts.
3. Authorize the connections — Stripe and your accounting system.
4. Describe the exceptions: a disputed charge, a multi-currency payout, a negative payout, an account-level adjustment.
5. Run it against a closed month and reconcile the result against what was filed before trusting it forward.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Timing and the accounting period

A charge and its payout fall in different periods routinely, especially at month end.

Decide the basis deliberately — cash or accrual — because it determines which date each entry takes, and getting it wrong is a restatement rather than a correction.

Use the balance transaction's date consistently rather than mixing charge dates and payout dates, which produces a month that almost balances.

Handle the month-end boundary explicitly by reporting the in-transit amount, which is the gap between what was charged and what has settled.

Subscriptions add a third date. The period the revenue relates to is not the charge date, and if you recognise revenue over a term the automation needs to know that.

Freeze closed periods. Late-arriving adjustments should post to the current period with a reference, not reopen a closed one.

Refunds, disputes and chargebacks

A refund is not a negative sale in most accounting treatments — it reduces revenue, and the original fee is generally not returned.

Partial refunds need proportional handling of tax, which is the part most implementations get wrong.

A dispute has a lifecycle: raised, evidence submitted, won or lost. Each stage is a separate movement and the accounting should follow it rather than only recording the outcome.

The dispute fee is separate from the disputed amount and is usually retained regardless of outcome.

A won dispute returns the funds in a later payout, which appears as an increase with no corresponding sale.

Record the customer reference on every one, since the most common question about these entries is which customer they relate to.

What your accountant actually wants

Bank reconciliation that balances without manual adjustment, which is the whole point.

Revenue by the categories they report on, not by your internal product names.

Tax broken out correctly by jurisdiction, which for cross-border sales is the part with real consequences.

A clear audit trail from a bank line back to individual charges.

Consistency over precision. A method applied the same way every month is more valuable than a more accurate method applied inconsistently.

To be asked first. Ten minutes with them before building saves a month of rework, and the answers depend on your jurisdiction and your basis of accounting.

Platforms, marketplaces and Connect

If you collect money on behalf of other people, almost everything above changes, and it is worth knowing that before building the simple version.

The gross is not your revenue. Money that passes through to a seller is not yours, and treating it as revenue overstates the business by whatever the pass-through is.

Your revenue is the take rate, plus whatever fees you charge, and that is the number that belongs in the profit and loss.

Each connected account has its own payouts and its own fees, and reconciling them is a separate exercise from reconciling your own.

Liability matters. Funds held on behalf of sellers are a balance sheet item until paid out, not income.

Tax responsibility varies by structure and jurisdiction, including who is the merchant of record, which is a question for your accountant rather than a setting.

Settle the model before writing the integration, since retrofitting a platform structure onto a sync built for a straightforward merchant is a rebuild rather than an adjustment.

Making it survive

Make it idempotent on the Stripe object id, since webhooks are delivered at least once and a duplicated journal entry is a genuine problem.

Use the balance transaction as the source of truth rather than reconstructing figures from the charge.

Handle the negative payout, which happens when refunds exceed charges in a period and breaks assumptions in most implementations.

Alert on any unmatched amount rather than forcing a balance, because a silent plug is the worst possible failure here.

Report the outcome: payouts posted, entries created, and any difference between Stripe's reported payout and what was recorded.

Limits worth knowing about

Accounting systems have their own API limits and their own rules about editing posted entries.

Multi-currency handling differs between accounting packages enough that this is worth verifying specifically.

Tax is jurisdiction-specific and not something an automation should infer — it should carry through what Stripe recorded and let a person confirm the treatment.

Historic backfills are heavy and may hit rate limits on both sides.

This is bookkeeping, not advice. The treatments above are common practice and your accountant's instruction governs, particularly around revenue recognition and the basis of accounting.

What to build first

The payout reconciliation report: each Stripe payout, its decomposition into charges, refunds, fees and adjustments, and the matching bank deposit. It posts nothing and it immediately shows whether your current process actually balances — which, for most teams doing this manually, it does not.

Two habits make the difference. Anchor everything on the payout rather than the charge, since that is the only unit that corresponds to something in the bank. And alert on an unmatched amount rather than forcing a balance, because a difference that gets quietly plugged is the one that turns into a real problem at year end.

Frequently asked questions

Why does my Stripe revenue not match my bank deposits?

Because payouts are batched and paid net of fees, with refunds, disputes and adjustments netted in. The deposit is never the sum of the charges.

What should a Stripe accounting sync be anchored on?

The payout, since one payout equals one bank deposit. Post the charge-level detail underneath it so revenue is recognised per charge while the bank line has a single matching counterpart.

Should fees be netted against revenue?

No. Record revenue gross and fees as an expense. Netting understates both and makes a significant cost invisible, and fees vary enough by card and country that an assumed rate drifts.

What is the balance transaction and why does it matter?

It is the record carrying gross, fee and net for every movement, and it is the correct source for accounting figures. Reconstructing amounts from the charge object is where most implementations go wrong.

How should refunds be recorded?

As a reduction in revenue rather than a negative sale, remembering that the original processing fee is generally not returned, and handling tax proportionally on partial refunds.

What about disputes?

They have a lifecycle — raised, evidence submitted, won or lost — and each stage is a separate movement. The dispute fee is separate from the disputed amount and is usually retained regardless of the outcome.

What happens at month end?

Charges and their payouts routinely fall in different periods. Decide the basis of accounting deliberately, use the balance transaction date consistently, and report the in-transit amount at the boundary.

What should happen when the amounts do not match?

Alert. Never force a balance. A silent adjustment is the failure that becomes a real problem at year end, and it is exactly what an automated process makes easy to do.

What changes if I run a marketplace or platform?

Almost everything. Money passing through to sellers is not your revenue — your revenue is the take rate and your own fees. Funds held for sellers are a balance sheet liability, and each connected account reconciles separately.

Can automation decide the tax treatment?

No. Carry through what Stripe recorded and let a person confirm the treatment. Tax is jurisdiction-specific, and on a platform it also depends on who the merchant of record is.

Related reading

• Connecting Stripe to QuickBooks
• Automating Shopify orders to Google Sheets
• Xero and CodeWords