Cross-border payment investigations: trace the payment before sending a replacement

A cross-border payment investigation is the process of locating a delayed, rejected, held or disputed payment and determining its true status before the business takes another cash action. This guide explains the mechanics, evidence, failure points and controls a UK business should understand before relying on the process.

What this means in practice

A cross-border payment investigation is the process of locating a delayed, rejected, held or disputed payment and determining its true status before the business takes another cash action. The business should treat this as a live transaction issue rather than a specialist label, especially when material cash or contractual deadlines are involved.

The bank may use payment references, UETR tracking, intermediary status and beneficiary-bank enquiries to identify where the instruction sits and whether funds have settled, returned or remain on hold. The live agreement, bank specification or scheme requirement should therefore be the starting point rather than shorthand copied from another product.

How the process works

The operating sequence should move from identification to validation, approval, external action and then confirmation. For this topic, the critical mechanics are: The bank may use payment references, UETR tracking, intermediary status and beneficiary-bank enquiries to identify where the instruction sits and whether funds have settled, returned or remain on hold.

Timing should be planned backwards from the required result. Notice periods, value dates, processing windows and internal approval deadlines can make a correct instruction operationally late, so the workflow needs a repair margin.

The data and evidence that matter

The minimum decision pack is original payment, UETR, amount, currency, value date, latest status, intermediary bank information, beneficiary confirmation, investigation case and any return reference. These items connect the commercial need to the bank, lender, counterparty or accounting outcome that determines the next action.

The record should distinguish internal intention from external outcome. An approved request proves what the company intended; a bank acknowledgement, lender consent, statement entry or counterparty confirmation proves what actually happened.

Where the process can fail

Accounts payable can issue a replacement because the supplier reports non-receipt while the original payment is still moving through the banking chain. The problem usually becomes harder and more expensive to fix as the settlement, testing, maturity or payment date gets closer.

A second weakness is status confusion. Approved, submitted, accepted, processed and settled can represent different stages, and treating them as one state can distort both accounting and liquidity.

Worked example: test the mechanics

A €380,000 supplier payment is two days late. The supplier asks for immediate re-payment. Treasury opens an investigation and learns that the original transfer is on hold for additional information. Sending a second payment before cancellation would create a duplicate-exposure risk.

The figures are illustrative rather than universal terms. In a live case the team should replace every amount, date and threshold with current source evidence, then repeat the test before treating cash, consent or coverage as available.

Governance and control design

Do not replace a material payment until the original status is understood or the bank confirms a controlled cancellation or return path. Management should see unresolved items before the external deadline rather than only after they become failed payments, covenant breaches or aged reconciliation entries.

Management reporting should focus on open investigations by age and value, payments on hold, returned items and duplicate replacements avoided. That measure connects the technical rule to the financial exposure instead of reporting only volume.

Change management is part of the control environment. When the bank, facility, ERP or legal structure changes, this process should be retested from source data through the final bank or accounting outcome rather than assumed to survive unchanged.

Ownership should survive absence and staff turnover. The procedure for cross-border payment investigations should state who acts, who reviews, where evidence is stored and how unresolved items are escalated when the normal owner is unavailable.

Documentation should be short enough to use under pressure. A one-page operating checklist can point staff directly to original payment, UETR, amount, currency, value date, latest status, intermediary bank information, beneficiary confirmation, investigation case and any return reference while the full policy keeps the legal, technical or scheme background.

Reconciliation should close the loop between original payment, UETR, amount, currency, value date, latest status, intermediary bank information, beneficiary confirmation, investigation case and any return reference and the eventual financial outcome. The team should be able to prove not only that the instruction was prepared correctly but that the external result matched the intention.

If an exception occurs, the post-event review should determine whether the root cause was data, timing, authority, system design or misunderstanding of the external rule, then assign remediation that can be tested during the next cycle.