Reconciling Multi-Currency Transactions at Scale

At low transaction volumes, multi-currency reconciliation is an inconvenience — a few extra columns in your spreadsheet, some manual exchange rate lookups at month-end. At high volumes, across multiple currencies and corridors, it becomes one of the most operationally expensive activities in your finance team. Companies processing over R$10M per month in cross-border payments typically spend between 8 and 15 finance-team hours per week just on reconciliation. Most of that time should not be human work.

Why Multi-Currency Reconciliation Breaks Standard Tools

The core problem: most accounting systems were designed around a single functional currency. When you add multi-currency transactions, you are asking the system to do something it was not fundamentally built for — and the workarounds accumulate complexity over time.

The specific failure modes we see most often:

• Rate sourcing inconsistency: Different team members pull exchange rates from different sources (BACEN PTAX, Bloomberg mid-market, bank rate) for the same period. The FX gain/loss calculations do not match.
• Timing mismatches: The accounting entry uses one day's rate, SISBACEN registration uses the trade date rate, and the bank statement uses the settlement date rate. Three dates, three rates, one transaction.
• Partial settlements: A $50,000 wire sent in three tranches, each settling on different days at different FX rates. Standard invoice matching logic fails completely.
• Nostro reconciliation gap: The amount your bank says settled does not match what you initiated, due to correspondent deductions nobody told you about in advance.

The Three Data Sources That Must Stay In Sync

Good multi-currency reconciliation requires three data sources to be continuously reconciled against each other — in real time where possible, not as a month-end batch.

Data Source	What It Contains	Reconciliation Role
Payment Platform (API)	Initiation data: amount, currency, rate at execution, timestamp, status	Source of truth for what you intended to send and at what rate
Bank Statements	Settlement data: actual amount debited/credited, settlement date, any fees deducted	Confirms what actually moved and when
SISBACEN / Regulatory Records	Registered FX contracts: purpose code, counterparty, reporting amounts	Confirms what was reported to BACEN and at what rate

When all three data sources use the same transaction ID, the same rate source, and the same timestamp basis, reconciliation becomes a matching exercise rather than an investigation. When they diverge — which happens constantly with legacy infrastructure — reconciliation becomes detective work.

FX Gain/Loss Accounting: The Rate Question

Brazil's CPC 02 (equivalent to IAS 21) requires that foreign currency transactions be initially recorded at the spot rate on the transaction date, and that monetary items be retranslated at the closing rate at each balance sheet date. The difference goes to FX gain/loss in the income statement.

The operationally correct approach: use BACEN's PTAX closing rate as the authoritative rate for each transaction date and balance sheet date. This is the rate BACEN publishes daily, it is auditable, and it eliminates disputes between your team and your auditors about which rate source is "correct."

The practical challenge is that PTAX is published after market close (approximately 6pm Brasilia time). If your payment systems use intraday rates for execution, there will be a difference between the execution rate (what you paid) and the PTAX rate (what accounting uses). That difference is real FX gain or loss — it needs to be calculated and recorded, not ignored.

Automated Reconciliation: What Good Looks Like

In our experience with clients processing R$50M+ per month in cross-border payments, the reconciliation processes that actually work share a few characteristics. They are almost entirely automated. They run at transaction completion, not at month-end. And exceptions — transactions that do not match automatically — are a small percentage of volume, not the default.

Specifically, a well-designed reconciliation workflow for multi-currency payments:

1. Assigns a unique transaction ID at initiation that flows through to bank statements and regulatory records
2. Records the executed FX rate, PTAX rate, and the difference as a separate accounting entry at settlement
3. Automatically matches bank statement entries to payment platform records by transaction ID within 24 hours of settlement
4. Flags unmatched items or amount discrepancies exceeding a defined threshold for human review
5. Generates SISBACEN-ready reporting data as a byproduct of the payment process, not as a separate step

Steps 1, 3, and 5 should require zero human intervention. Steps 2 and 4 require configuration, not daily manual work.

"If your finance team is spending more than 2 hours per week on cross-border reconciliation, the problem is in your infrastructure — not in your team's processes."

— BackChannel Team