Wallet Collections and Bank Settlement: Matching Many Payments to One Deposit

Header image: conceptual illustration.

Hundreds of wallet collections may produce one merchant settlement deposit. Trying to match each customer payment directly to an individual bank credit will generate false exceptions, because the records describe different stages and different grains.

The right workflow matches customer collections to provider batch components, then the batch to bank movement. This guide focuses on inbound merchant collections, not a claim that personal wallets can be used as merchant collection accounts.

Establish authorized source records

Use the merchant's approved provider transaction report, settlement or balance report and bank statement. Confirm which account and business use the provider has authorized. Do not infer that a wallet supports aggregation, settlement exports or a particular business category merely because customers use it.

The bKash and Nagad merchant comparison discusses questions to ask about reporting and support. Actual settlement capability and batch information must come from the merchant's agreement and verified provider records.

Preserve provider identities, currencies and dates at import. A customer screenshot is not a replacement for the merchant-side collection record or the bank posting.

Model the many-to-one relationship

A collection record identifies a payment for an order. A settlement batch identifies a group of financial components. A bank deposit identifies actual movement into the merchant bank account. Maintain explicit links instead of duplicating a deposit value on every collection row.

Where a provider supplies batch membership, use it. Where it does not, use a documented balance-based reconciliation and mark the attribution limits. Do not invent a batch identifier from date alone and then present the resulting match as provider-confirmed.

Stripe's payout reconciliation guide illustrates the distinction between automatic-payout batch reports and balance-based alternatives. The same reporting question is useful when evaluating another provider, without assuming the same tools exist.

Work through a collection bridge

Verify customer collections independently before crediting orders: successful final provider status, merchant/order match, amount and currency, with an idempotent financial effect. Settlement receipt later is not permission to credit the same customer again.

For each batch, reconcile included gross collections and documented adjustments to expected net settlement. Then match the expected movement to the bank statement using available settlement references and dates. Keep bank deductions or currency conversion separate where documented.

Refunds can adjust a later batch even when the original collection belongs to an earlier day. Timing differences should remain visible, not be removed by forcing every refund into its original collection period.

Worked hypothetical batch match

Invented example: A fictional merchant has three verified BDT collections: BDT 1,000, BDT 1,500 and BDT 2,500. The provider's batch contains all three, giving BDT 5,000 gross. A documented BDT 100 fee and BDT 500 refund adjustment produce BDT 4,400 expected net.

The bank shows one BDT 4,400 credit with a matching supported batch reference. Finance links that deposit to the batch, not separately as BDT 4,400 received for each customer. Each original order remains credited only for its own verified payment.

If the bank credit is absent, the collection outcomes do not automatically become failed. The team investigates settlement status and the relevant reporting and posting dates. If the provider report is incomplete, the batch remains unresolved rather than manufacturing missing components.

Diagnose common false exceptions

First check whether the collection report and settlement report cover the same account and currency. Then check completeness, duplicated imports, delayed availability and excluded transactions. A calendar-day total can legitimately differ from a batch total.

If two batches share the same net amount, amount alone cannot prove which deposit belongs to which batch. Use provider and bank references where available, with reviewed supporting evidence when references are missing.

Avoid reconciling solely from opening and closing balances. A balance can agree while offsetting missing and duplicate transactions cancel each other numerically. The merchant reconciliation guide explains why operation-level exception handling remains important.

Inbound batch checklist

• Collection accounts and business use are authorized.
• Customer payment, batch and bank movement are separate records.
• Batch membership is provider-supported or its limits are stated.
• Gross, deductions and net reconcile per currency.
• Refund adjustments keep their actual reporting dates.
• Bank matches use references, not only identical amounts.
• A missing settlement does not trigger duplicate customer crediting.
• Unmatched batches have an owner and next action.

Frequently asked questions

Must every wallet collection appear as a separate bank deposit?

No. The provider may aggregate settlement, depending on the actual agreement and reporting model.

Can a settled bank balance prove every order was credited correctly?

No. Bank matching and customer-order crediting are separate controls. Both must reconcile without duplicate financial effects.