Why £400 of payments can become a £361 deposit

Which total should agree with which?

The sales dashboard says £400, but the bank has received £361. Before looking for £39 of missing money, find out which records each total describes. Customer payments and a net settlement are allowed to differ. Fees, refunds and the transactions included in this particular payout can explain the gap, but the reconciliation has to retain that explanation rather than merely persuade the two totals to agree.

Reconciliation starts by deciding which two things ought to agree and why. Matching orders to payment outcomes is one question. Matching a provider’s balance movements to a payout is another. Matching that payout to a bank entry is another again. A single green “payments healthy” status can hide which boundary has actually been checked.

Consider a synthetic settlement batch in pounds: three payments of £120, £80 and £200; £9 of fees; and a £30 refund associated with an earlier sale. The net batch is £361. Today’s payments total £400. The difference is not £39 of missing money. It is an explanation the reconciliation must preserve at transaction level.

This example connects engineering records; the finance colleague still interprets them under the business’s accounting and tax policies. Give them the payment, fee, refund and payout relationships so they can examine the actual settlement. A subtraction between today’s sales and today’s bank credit produces a number immediately. It leaves the more useful question unanswered: which transactions was this transfer supposed to settle?

The source export needs a completeness check as well. Record whether all pages were fetched and whether the provider marked the report ready. An incomplete file can produce a convincing partial total. Keep fetch completion separate from financial matching so the system cannot certify a batch merely because every row it happened to receive was explained.

The settlement batch needs an identity, currency and membership rule. A provider may associate transactions with an automatic payout, while a balance report covers activity over a time period. Those are different populations. Stripe’s documentation explicitly distinguishes its balance summary from its automatic-payout reconciliation report; the former does not associate individual payments with payouts.

For batch B-18, retain the provider’s transaction identifiers and payout reference. Each payment, fee and refund should appear once under the relevant category. Keep gross, fee and net amounts separate rather than repeatedly deriving them from rounded display values. Use the documented units and currency for each source, then normalise deliberately at the comparison boundary.

Currency deserves its own column. £361 and €361 are not equal because their digits happen to match. If conversion occurs, retain the source currency, settlement currency and the provider’s conversion evidence where applicable. Do not invent an exchange rate from the eventual bank deposit. That deposit may already include other adjustments or bank-side effects.

A refund for last month’s sale may settle in B-18, while a payment accepted today may not yet be available. Follow the payout’s transaction population instead of filtering every source to the same calendar date. Otherwise the integration can remove the exact refund needed to explain the bank amount, then report the discrepancy it created. Keeping event date and settlement membership distinct makes that history intelligible.

Reconcile in layers and keep the residual visible

For the illustrative B-18 batch, the gross payments total £400. Subtract £9 fees and £30 refund to get £361. Suppose the provider’s payout record is also £361. The transaction-to-payout residual is zero. That is a useful result at a defined boundary. It does not yet prove the bank received the transfer.

Now suppose the bank statement contains a £361 credit with the corresponding reference, posted the next business day. Matching that entry closes the payout-to-bank boundary for this example. The posting date differs from the sales date without creating a mismatch. If the reference is incomplete, the matching rule may need an additional check rather than accepting every same-value credit.

If the bank credit is £356 instead, leave the £5 residual open. There may be a legitimate adjustment, but it needs a source and a finance decision that explains it. Adding a balancing row would make the screen tidier while telling the business nothing about the missing £5. Preserve the unmatched amount until the evidence supports a particular resolution, so the next person can still see what needs investigating.

Record the matched records, the comparison rule and the unresolved remainder. A total of zero can also conceal offsetting errors, so inspect transaction membership and duplicate identities as well as the sum. A missing £80 payment and an extra unrelated £80 payment produce a reassuring total with the wrong story underneath it.

Timing differences should age into investigations

Some mismatches are expected temporarily. A payout may be recorded before the bank posts it, or report data may not yet be available. Stripe’s payout-report documentation notes that reporting availability and payout arrival follow different schedules. Treat that as a reason to track pending evidence, not as permission to mark every late item harmless indefinitely.

Give each pending case an expected next observation, a review time and an owner. The appropriate delay depends on the provider, payout method and business calendar. An illustrative rule might recheck an expected transfer after its documented arrival window. Avoid presenting a generic number of days as a banking guarantee when the actual contract differs.

When new evidence arrives, rerun the relevant comparison against a recorded source revision or export. Preserve why a case changed from pending to matched or from pending to investigation. If a corrected report changes batch membership, the old result should remain explainable. Replacing yesterday’s CSV without recording that it changed makes later disagreements unnecessarily mysterious.

A missing report is not the same problem as an unmatched payout. If retrieval fails, the job has not yet compared the transactions and cannot know whether the money matches. Show the failed fetch and the incomplete observation, then offer the route to obtain the report. A colleague should not have to investigate a financial discrepancy only to discover that the supposed comparison never had its source data.

Repair needs more authority than detection

Finding a duplicate local record does not automatically justify refunding a customer. Finding a missing bank match does not authorise creating a new payout. The reconciliation process should identify the boundary and evidence, then route the case to a supported repair. A repair that moves money needs its own permission and external-state checks.

For B-18, a case record could include the payout identity, all constituent transaction identities, expected £361, observed bank entry and current residual. A colleague can then investigate a specific gap without collecting screenshots from several systems. Keep sensitive customer details out of the default diagnostic view unless they are necessary to resolve that case.

Make repeated reconciliation safe. Importing the same report twice should not double the local ledger. A corrected source row should be handled under an explicit revision policy rather than appended as though it were an unrelated transaction. The identity of the source record and the identity of a reconciliation run serve different purposes; retaining both makes replay and correction easier to explain.

A practical acceptance pack should contain a normal payout, a prior-period refund, a delayed bank posting, an incomplete report and an equal-value wrong transaction. The last case is particularly useful because it defeats a totals-only check. Add a duplicated source export and confirm that rerunning the process does not create a second set of movements.

There is a sensible limit to automation. A clean reference and complete report can support automatic matching. Ambiguous equal-value credits or unexplained adjustments may need a person. The objective is to shrink the uncertain part of the work and preserve its evidence, not to obtain a zero residual at any cost.

B-18 can tell a straightforward story: £400 in payments, less £9 in fees and a £30 earlier-sale refund, followed by a separately matched £361 bank credit. Keep the transaction identities and bank reference with that result. If one part is missing, leave that boundary open. Finance can then investigate the specific gap instead of trying to reconcile two attractive totals that happen to describe different groups of records.