Transaction Reconciliation for cross-border commerce teams

Transaction reconciliation for cross-border commerce cards

Cross-border commerce teams need to reconcile three different layers: the platform wallet, the card ledger and the merchant or supplier record. Treating those layers as one balance makes refunds, failed payments and currency differences difficult to explain.

Reconciliation model

• Record blockchain or wallet deposits separately from card loads.
• Link each card load to one wallet debit and one card credit.
• Track merchant authorization, settlement, reversal and refund as separate card events.
• Keep supplier invoice currency, card currency and wallet currency visible.
• Attach refunds to the original settled supplier transaction.
• Flag unmatched settlements, aged authorizations and duplicate event IDs.

Worked commerce case

A commerce team credits 2,000 USDT to the platform wallet and loads USD 900 to a card for supplier tools. The remaining wallet balance stays unallocated. Later, a supplier refunds USD 120. The refund changes the card ledger and links to the original settlement; it does not recreate the blockchain deposit or become a new wallet top-up.

Daily review

Finance should compare supplier invoices, card events and wallet movements every day during active operations. Differences should be labeled as pending hold, delayed settlement, refund, reversal, FX difference, fee or manual adjustment. Manual changes need operator, reason and evidence.

Failure boundaries

Do not report a reversal as unrelated income, reuse funds before a pending authorization is resolved, or merge unrelated storefront and logistics spend on one card ledger. Do not ask support teams to solve reconciliation from screenshots alone.

Additional FAQ

Which balance matters for supplier spend?

The card ledger explains supplier spend. The platform wallet explains deposits and card loads. Both are needed, but they answer different questions.

How should currency differences be handled?

Store invoice currency, authorization currency, settlement currency and applied conversion separately so finance can reproduce the amount.

Frequently asked questions

What should be checked before the first transaction?

Confirm the displayed fees, available balance, supported use case, card status and merchant requirements. Start with a controlled amount and retain the resulting ledger entry.

Does a virtual card guarantee merchant acceptance?

No. Acceptance depends on the issuer program, merchant rules, geography, verification requirements and current risk controls.

How should teams evaluate operational quality?

Review fee disclosure, card controls, transaction detail, refund handling, support channels, API idempotency and incident procedures.