Quick Answer
Map each financial flow and its owner first. Reconcile provider movements to itemized business records, bank debits or credits, and the appropriate GL effects. Create required accounting entries when due, while keeping unmatched timing and exceptions visible. Use durable business-effect guards so imports and retries cannot post twice.
Reconcile the direction of money before automating the match#
A processor paying collected sales into your bank is an incoming settlement. Your company paying a contractor is an outgoing disbursement. They can share identifiers and reconciliation tools, but they do not share the same accounting chain. Define the entity, funds owner, provider account and financial effect first; then match the relevant source populations to bank movements and GL entries.
For each flow, preserve the business obligation, provider movement, settlement or attempt reference, currency, gross amount, fees, net amount and accounting period. Match both transactions and totals. A net balance can agree while a fee is missing, a refund is duplicated or a payment is assigned to the wrong supplier.
Use two maps instead of one universal payout chain#
| Flow | Source population | External movement | Accounting interpretation |
|---|---|---|---|
| Incoming processor collection | Customer charges, refunds, fees and other processor balance movements | Provider balance settlement into the company’s bank | Clear the relevant processor asset into cash; recognize revenue/receivable and fees under the actual policy |
| Outgoing supplier payment | Approved payable, funded provider balance, payment attempt and any return | Company bank/provider debit and recipient outcome | Settle the payable when the obligation is discharged under the policy; distinguish funding, in-transit assets and returns |
| Marketplace seller funds | Seller entitlement and platform fee allocation under the program | Provider/holding-account activity and seller disbursement | Ownership and principal/agent accounting determine liabilities and platform revenue; gross collection is not automatically platform revenue |
Stripe’s payout reconciliation report matches payouts received into a bank with the underlying automatic settlement batches. Its manual and instant payout workflows need different reconciliation treatment. This report is useful evidence for the incoming processor chain; it is not a universal report mapping every contractor instruction to a merchant bank deposit.
Within Stripe Connect, a transfer moves funds to a connected account. It is distinct from that account’s payout to an external bank. Preserve both legs where they are in scope. A successful platform transfer is not by itself proof that a seller’s bank was credited.
Build a canonical movement record without flattening evidence#
Keep the provider account and legal entity alongside every external ID so similar references cannot collide across tenants or environments. Normalize amount units and currency explicitly: an API amount in minor units and a report amount in dollars are not interchangeable. Retain the raw source and its timestamp so a normalized record can be reconstructed.
| Field group | Examples | What it prevents |
|---|---|---|
| Business | Invoice/payable ID, supplier or seller ID, installment ID | Matching another client’s obligation because amount and date look similar |
| External | Provider account, balance-transaction ID, payment/transfer/payout ID, bank reference | Losing the link between status, financial movement and the actual account |
| Money | Original currency/amount, settlement currency/amount, fee and net | False matches from hidden FX or double-counted charges |
| Time | Event time, effective/value date, posting date, timezone and period | Treating normal timing differences as unexplained cash |
| Control | Financial-effect ID, mapping version, match status, exception owner | Duplicate postings and undocumented corrections |
Stripe’s balance-transaction object exposes amount, currency, fee, net, source and reporting category. Use the documented category and source relationship as inputs to your accounting mapping. A provider status is external evidence; it does not decide whether your company is principal or agent or which recognition policy applies.
Worked incoming example: gross sales are not the bank deposit#
Assume a hypothetical company selling its own services, with USD functional and settlement currency. The approved policy recognizes the service revenue in this period; ignore taxes. It collects USD 1,000 through a processor, incurs a separate USD 20 processor fee, and has a USD 60 refund before settlement. There is no reserve, FX or other activity. The provider asset available for settlement is USD 920.
| Event | Illustrative entry | Provider asset after entry |
|---|---|---|
| Recognized collection | Debit processor receivable 1,000; credit revenue 1,000 | USD 1,000 |
| Fee charged | Debit processor-fee expense 20; credit processor receivable 20 | USD 980 |
| Refund recognized and paid from balance | Debit sales refunds/contra-revenue 60; credit processor receivable 60 | USD 920 |
| Net bank settlement | Debit bank cash 920; credit processor receivable 920 | USD 0 |
The bridge is USD 1,000 − USD 20 − USD 60 = USD 920. Match the itemized movements to the settlement reference and the USD 920 bank credit. Do not record that bank credit as another sale. If revenue was recognized earlier through a receivable, clear that receivable instead of recognizing it again. A seller-funds program needs its own liability and fee-allocation policy rather than copying this own-service example.
If a provider reserve were also withheld, identify whether the amount remains an asset due from the provider and whether it is restricted. It is not automatically an expense or lost revenue. Explain opening balance, new activity, amounts settled, amounts pending/restricted and ending balance, with the reserve’s later release linked to the same history.
Worked outgoing example: funding, partial payment and return#
Now assume a separate USD 1,000 supplier bill for services already received. The company funds USD 1,000 into an eligible payment-provider balance. A USD 900 payment completes and a USD 5 fee is charged to that balance; the remaining USD 100 bill amount is unpaid. Later, the USD 900 payment returns and the fee is not refunded. Ignore taxes and FX in this illustration.
| Event | Illustrative entry | Result |
|---|---|---|
| Recognize bill | Debit service expense 1,000; credit accounts payable 1,000 | Expense and obligation exist before the bank payment |
| Fund provider | Debit provider cash/balance 1,000; credit bank cash 1,000 | Funding is an asset transfer, not another expense |
| USD 900 payment completes | Debit accounts payable 900; credit provider balance 900 | Payable USD 100; provider balance USD 100 |
| USD 5 fee | Debit payment-fee expense 5; credit provider balance 5 | Provider balance USD 95 |
| USD 900 returns and obligation is reinstated | Debit provider balance 900; credit accounts payable 900 | Provider balance USD 995; payable USD 1,000 |
The return restores the affected obligation and funds after their actual financial effect is established; it does not erase the service expense or refund the fee. A rejection before any debit or discharge may require no settlement reversal. If a debit occurs before completion, use the approved in-transit/clearing treatment and keep the payable status consistent with the legal discharge point. Do not force every provider’s “failed” label into one journal rule.
Posting readiness and reconciliation readiness are different controls#
Create required accrual, invoice, clearing or provider-balance entries when the accounting policy requires them. Full bank matching is not a prerequisite for every journal. An open bank timing difference can coexist with a valid recorded liability. Keep journal status, external payment status and reconciliation status separately visible.
Automatic matching should require the right entity/account, currency, reliable reference and consistent amount bridge. Date and amount alone are candidates for review, not sufficient identity. For a many-to-one settlement, compare the expected itemized population and net total. Define narrow approved tolerances and their reason; unexplained differences should not disappear because an arbitrary percentage threshold was met.
A difference can be caused by timing, fee treatment, FX, omitted source records or a wrong posting. Route it according to the cause. Finance owns accounting interpretation; payment operations obtains external status; engineering repairs missing or duplicated data. Keep the case’s amount, affected IDs, evidence, proposed correction and reviewer. Do not delay unrelated obligations unless the funds or restrictions genuinely affect them.
Keep the financial effect stable across retries#
Persist and authenticate event receipts before acknowledgement, then process them through a durable queue. Distinguish receipt deduplication from business-effect deduplication: two different events can describe the same settlement. Within your database, commit the financial-effect guard, journal and processing result atomically. Preserve the same effect identity through import or connector retries.
Do not include a mutable amount in the only uniqueness key: correcting that amount could create a second effect. Link amendments, refunds and returns as distinct effects to the original transaction, with reviewed correction entries rather than deleting prior journals. A bank feed and a provider connector must not independently post the same cash movement.
For external payment calls, use a durable outbox and the original provider idempotency key within its documented scope. Stripe’s idempotency reference allows pruning after keys are at least 24 hours old; that is not a universal provider rule or permission to create a fresh payment when an old result is unknown. Resolve the original attempt before fallback, with a permanent guard on the underlying obligation.
A bank CSV is evidence, not automatically a journal import#
Bank statements describe credits and debits. GL imports need the chart, entity, debit/credit balance, accounting dates and required dimensions. Preserve a mapping step with a version and reviewer instead of renaming statement columns and assuming they are posting-ready. Validate totals and source links before import and record which financial effects were already posted.
At close, produce the movement bridge for each provider account and currency, bank-to-provider timing items, payable or seller-entitlement exceptions, and any unresolved posting differences. Include the cutoff and report availability: provider reports can arrive later than a bank movement. An aged difference still needs an owner and investigation; a complete-looking dashboard is not proof that the underlying populations agree.
Frequently Asked Questions
Is an incoming processor payout the same chain as an outgoing contractor payout?
No. Incoming processor settlement clears collected balances into the company’s bank. Outgoing disbursement funds and settles an approved obligation to a recipient. Use separate populations and accounting mappings, even when the same platform supplies identifiers or reports.
Must every bank movement match before any journal is created?
No. Required accruals, invoices, clearing and provider-balance entries follow the accounting policy and can precede final bank settlement. Keep recognition separate from reconciliation status, with reviewed timing differences and exceptions.
How should a failed or returned payout be posted?
Establish its actual prior financial effect. A rejection before movement may require no settlement reversal. A return after payment can restore funds and the affected obligation through linked entries. Do not erase the original expense or assume every fee was refunded.
Does a matching net bank amount prove reconciliation is complete?
No. Match the itemized source population, references, currency and gross/fee/refund bridge as well as the total. Missing and duplicated movements can cancel numerically while leaving customer or supplier allocations wrong.
What stops connector retries from creating duplicate GL effects?
A durable business-effect identity and an atomic commit of the guard, journal and processing result. Event IDs alone are insufficient when separate events describe the same movement. Keep corrections linked and ensure bank feeds and provider connectors do not each post the same effect.
Researched and edited by the Gruv editorial team. Gruv builds cross-border billing, payouts, and finance-operations software for global businesses.
Sources
Educational content only. Not legal, tax, or financial advice.
Related Posts
The Freelance Payment Penalty: A Modeled Audit of Platform Fees, FX Spreads, and Payout Delays
The money rarely disappears through a single, easy-to-spot fee. The real loss is stacked. A marketplace takes its commission, a processor adds a charge for international cards, a bank or payment company converts the currency at a spread, a platform holds the funds before release, and a wire sheds a little to intermediaries on the way in. Each layer looks defensible on its own, but the worker feels the combined result as a smaller deposit and a later payday.
How to Respond to a Subpoena for Business Records
Move fast, but do not produce records on instinct. If you need to **respond to a subpoena for business records**, your immediate job is to control deadlines, preserve records, and make any later production defensible.
A US Expat's Guide to Investing in UCITS ETFs to Avoid PFIC Issues
The real problem is a two-system conflict. U.S. tax treatment can punish the wrong fund choice, while local product-access constraints can block the funds you want to buy in the first place. For **us expat ucits etfs**, the practical question is not "Which product is best?" It is "What can I access, report, and keep doing every year without guessing?" Use this four-part filter before any trade: