Separate four records before adding totals
An order is the merchant's promise to supply goods at an agreed price. A successful payment is the provider's record of collecting money. A balance transaction records the movement in the provider account, including amounts that may later be available for payout. A payout is a transfer from the provider balance to a bank destination; the bank statement is evidence of the credit that actually arrived. These are connected, but they are not interchangeable. Stripe explains that an automatic payout can contain funds from multiple transactions, and its balance transaction object separates gross amount, fee and net. The shop should reconcile identifiers across layers, then explain expected differences such as fees, refunds and timing. Comparing one day's order total directly with one day's bank credit is rarely a meaningful first test.
Retain stable links across systems
At checkout, record the merchant order ID alongside the payment provider's payment or charge identifier, its currency, amount and current status. Do not rely on a customer name, email address or rounded amount to join records; several orders can legitimately share them. When a provider exposes a balance transaction, retain its ID and source relationship to the underlying payment, refund or adjustment. For each payout, keep the payout ID, currency, expected amount, status and bank reference if available. Use a controlled mapping table when data arrives from separate exports. A missing link is an exception to investigate, not an invitation to guess from proximity in a spreadsheet. Keep the original provider IDs even if internal labels change after a migration or customer service correction.
Choose a period and currency basis
Decide whether the reconciliation is by order creation date, successful payment date, balance availability date or payout date. Each answers a different question. Use the provider's timezone and the bank's statement date carefully; a transaction near midnight can appear on adjacent local dates. Keep currencies separate until an actual conversion record and rate are available. Stripe's balance transaction amount and fee are in the smallest unit of that transaction's currency, while its payout object states the destination amount in a smallest currency unit. Do not add unlike currencies or infer an exchange rate from a rounded display alone. Document the period, timezone, currency and included statuses at the top of every working paper so another staff member can reproduce the result.
Work from the payout backwards
For a Stripe automatic payout, the documented routes include the Dashboard payout view, the payout reconciliation report and API retrieval of balance transactions filtered by payout ID. Stripe notes that retrieving the payout object alone does not list its constituent transactions. A filtered API response can be paginated, so a process that reads only the first page may silently understate the sum. Check whether the payout's reconciliation is complete before treating an incomplete list as final. Manual payouts need a different method: Stripe says it cannot identify which individual transactions are included because the merchant controls timing and amount. Reconcile those against the broader transaction history and opening and closing balance instead of claiming an exact per-payout membership the provider does not supply.
Use gross, fee and net without hiding adjustments
A worked example can make the relationship clear without posing as a real merchant result. Assume two settled customer payments of HK$200 and HK$150, provider fees of HK$6 and HK$5, and a HK$50 refund included in the same reconciliation set, with no other movement. Gross payments are HK$350; subtract HK$11 of fees and HK$50 of refund to obtain HK$289 net. If the provider's transaction records classify or time the refund differently, the payout set may differ; the example is a calculation, not a claim about a provider's fee schedule. Compare the actual sum of the included balance transaction nets with the provider's payout amount, then match that payout with a bank credit. Investigate any difference using the underlying rows, not by forcing a balancing entry.
Classify exceptions before correcting records
A paid order with no linked provider payment may be a mapping defect, an incorrectly marked order, or a payment through another channel. A provider charge with no order may be a lost callback, an abandoned order record or a manual payment. A payout difference may involve a refund, dispute, reserve, adjustment, currency conversion or timing. A bank amount that differs from the provider payout requires examination of destination, bank charges and whether the credit has actually arrived. Create an exception queue with the record IDs, amount, currency, relevant dates, owner and next evidence to obtain. Do not change a customer-facing paid status merely to match a bank statement; payment and fulfilment decisions need their own verified source. Escalate unexplained money movements with the provider or bank using the exact identifiers.
Keep review and correction auditable
Separate preparing the reconciliation from approving material adjustments where staffing permits. Preserve source exports or report versions, the matching rules used, and a dated list of exceptions and resolutions. A corrected mapping should show the old and new identifier and why it changed; it should not erase the original transaction. Check that a refund is represented once in the provider records and once in the merchant ledger, not deducted twice from sales and again from cash. Reconcile the opening provider balance plus movements to the closing balance as an independent completeness check. This control is especially useful when a payout spans several business days or when a report is regenerated after late adjustments. The process should be repeatable by another staff member, not depend on one person's memory.
Set a practical monthly close rule
Write the close rule before chasing a discrepancy: identify the provider accounts and bank destinations in scope, the cut-off date, currencies, required report versions and the person who signs off unresolved exceptions. Match order to payment, payment to balance movement, balance movement to payout and payout to bank credit in that order. Mark items still pending at the cut-off as timing differences with a follow-up date, not as cash already received. Reopen a closed period only through a documented correction that explains the new evidence. This is an operational control, not tax or accounting advice for a particular legal entity; the shop's accountant should decide the ledger treatment. The editorial answer is that trustworthy reconciliation depends on traceable identities and explicit timing, not a single equal grand total.
A payout status is not a bank receipt
Stripe's payout object has a status and an expected arrival date. Those fields are useful for tracking, but an expected date is not the same as a bank statement entry. A payout can be created, later fail, or be delayed; staff should retain the provider state and separately record whether the destination account actually received the credit. If the bank entry is not yet present, classify the item as outstanding and schedule follow-up instead of modifying the order payment status. Match the amount and currency, then use the payout reference and destination details available to the business. When several payouts land close together, do not assume their statement order matches creation order. This final bank leg closes the cash trail.
Place refunds on the right side of the trail
A refund may relate to an earlier order but affect a later balance or payout. Preserve the original sale and link the refund ID to it; do not replace the sale amount with the final net cash as if the initial purchase never happened. Check whether the provider reports a separate refund balance transaction and when it becomes available or deducted. For a partial refund, the order can still have fulfilled goods and a reduced amount retained; the commercial explanation and the cash movement should agree without being collapsed into one field. If a refund is initiated but still pending, report that state truthfully. The reconciliation should follow the provider's actual transaction records, not assume every refund is in the same payout as its sale.
Sample the links, not just the sum
A balanced grand total can conceal two mistakes of equal size. Select a sample that includes ordinary payments, a refund, a high-value order, a transaction near the period boundary and an unresolved exception. Starting from each order, follow its payment identifier, provider source, balance transaction, payout and bank credit; then reverse the direction for a sampled provider charge to find the merchant order. Verify currency and amount at each step. Investigate any record that joins solely because the numbers happen to match. For a small shop, a brief monthly sample and a complete exception list may be more sustainable than a complex dashboard nobody reviews. The sample is a control on the mapping itself, while the balance roll-forward tests completeness.
Before release
- Each order maps to a provider payment ID
- Automatic payout contents are complete, including paginated rows
- Bank credit is matched to a provider payout, with timing differences recorded
