How to reconcile cross-border payments in Latin America

This content is provided for informational purposes only. It does not constitute financial, legal, tax, or regulatory advice. Each company should evaluate its implementation with its own internal teams and professional advisors. 

If your company pays or collects across several LATAM countries, you know the scene: the money arrived, but nobody knows when, through which rail, or where the proof is. At month-end, it turns into detective work.

Reconciling cross-border payments in Latin America comes down to one habit: every payment carries your own internal reference from the moment it is created, plus the tracking ID the local payment system assigns when it executes. With those two IDs and one central place for proof, any payment can be traced in seconds.

Below, you will find which ID to store in Mexico, Brazil and Colombia, a simple reconciliation sheet, and how to handle mass payouts and stablecoin legs.

What does it mean to reconcile a cross-border payment?

Reconciliation means confirming that three versions of the same payment tell the same story:

1. What you ordered: amount, currency, beneficiary and date.
2. What the rail executed: which system moved the money and its tracking ID.
3. What settled: the final status and proof you can show.

If answering those three points takes more than a minute per payment, reconciliation depends on chasing emails.

Why cross-border payments in Latin America are harder to reconcile

There is no single payment system in the region. Each country runs its own rail, with its own identifiers and receipts: SPEI in Mexico, Pix in Brazil and PSE in Colombia. Add more than one bank or PSP (payment service provider), FX conversions and recurring payout batches, and the moving parts multiply.

Every extra provider, currency and batch adds one more place where a reference can get lost. Connecting to those rails through one API with local rails reduces the number of sources, but the reconciliation logic inside your team still has to be consistent.

The two IDs every payment needs

Most reconciliation problems start before the money moves. Assign a unique internal reference when the payment is created, and store the rail's tracking ID as soon as it executes.

• Internal reference: your own ID, for example PAY-2026-000184. You control it, so it stays the same no matter which provider moves the money.
• Rail tracking ID: the number the local system assigns. It is what a bank or provider will ask for when something goes wrong.

Without both, matching turns into guesswork: "the amount looks similar" or "it happened the same day."

Which tracking ID to store in Mexico, Brazil and Colombia

Each rail uses a different name, but the rule is the same everywhere: one tracking ID per payment, stored next to your internal reference.

Mexico (SPEI)

SPEI is the real-time interbank system operated by Banco de México. Its operating rules, set out in Circular 14/2017, define the data that travels with every transfer, such as account identifiers and the payment concept. For reconciliation, the most useful fields are the clave de rastreo, the sending and receiving bank, the beneficiary's CLABE, the amount and the timestamp. With these fields, your team can download the CEP, the electronic proof that the funds were credited to the beneficiary's account.

Brazil (Pix) and Colombia (PSE)

Every Pix payment carries an End-to-End ID assigned within the Banco Central do Brasil's instant payment system. Reconcile by that ID, not by amount: two payments of the same value on the same day are common. In Colombia, PSE transactions return a CUS. Store the code your PSP reports, even if its dashboard labels it differently.

A minimum reconciliation template

You can start in a spreadsheet, as long as it works like a table: one row per payment. These five groups of columns cover most cases:

• Identification: internal reference, provider ID, rail and rail tracking ID.
• Money: amount and currency sent, fees, exchange rate applied, amount and currency received.
• Time: created, executed and confirmed timestamps. Gaps between them show where payments get stuck.
• Status: one internal status, plus an optional reason such as "invalid account."
• Proof and control: a link to the proof in central storage (never someone's inbox), who reconciled it, when, and notes on exceptions.

Keep statuses simple

Every provider reports its own statuses. Map them all to a short internal set: created, submitted, pending, confirmed, failed, returned and review. Anyone can read the sheet, and you can measure where payments stall.

How to reconcile mass payouts in Latin America

When you send payroll, seller or creator payouts in batches, checking one by one does not scale. Reconcile in three layers:

1. Check the batch: payments sent vs. confirmed, total amount, and the difference.
2. Touch only the exceptions: filter by failed, review, or pending for longer than expected.
3. Give every exception an owner: one person, an internal deadline, and the proof attached once.

The LATAM payroll guide shows how the same logic applies to recurring payroll cycles.

What changes when stablecoins are in the flow

Stablecoins for business payments can speed up settlement and conversion, but they do not remove reconciliation. They add a second leg to track, linked to the same internal reference.

For the stablecoin leg, store the network used, the tx hash (the public receipt of the digital movement), the token amount (for example, USDC), the timestamp, the origin and destination wallets, and the rate applied at conversion.

In Mexico, the key operational variable is USDC to MXN liquidity: how quickly and at what cost USDC converts into pesos. Recording the rate at each conversion explains why the settled peso amount differs from the invoiced one. The guide to stablecoins for business payments in LATAM covers the full flow.

What to look for in an API for cross-border payments in LATAM

Automation keeps reconciliation daily instead of monthly. When evaluating a provider, look beyond price and coverage:

• Does every transaction return a clear, unique ID?
• Are status updates sent automatically, for example through webhooks?
• Can you export daily reports without manual work?
• Is proof stored centrally and in a consistent format?
• Are statuses easy to map to your internal set?

FAQs

Should we reconcile daily or at month-end?

Daily, if volume allows it. Real-time rails like SPEI and Pix settle in seconds, so a failed or returned payment can be caught the same day. Month-end then becomes a review of open exceptions, not a full rebuild.

How do we record a returned payment or a refund?

Keep the original row and change its status to returned. Record the refund as a new row with its own tracking ID, linked to the original internal reference, so the history stays complete and batch totals still add up.

What if the provider's status and the bank's proof disagree?

Mark the payment as review and treat the rail's proof as the source of truth: the CEP in Mexico, the End-to-End ID record in Brazil, or the CUS in Colombia. Then ask the provider to update its status and log the resolution in the exception notes.

How long should we keep payment proofs in Mexico?

Mexico's Federal Tax Code (Código Fiscal de la Federación) generally requires companies to keep accounting records and supporting documents for five years. Store each proof under its internal reference and confirm the exact period with your tax advisors.

Does reconciliation work the same way for collections?

The logic is the same, but the reference must come from the customer, so your payment instructions have to ask for it. This piece on collecting revenue across LATAM explains how inbound payments and repatriation work.

 Connect to local rails across LATAM through one API 

*NVIO México enables direct access to SPEI and delivers payment services fully compliant with Mexican regulation. NVIO Pagos México, S.A.P.I. de C.V., IFPE (“NVIO México”) is authorised and regulated by the Mexican National Banking and Securities Commission (CNBV). Learn more at nvio.mx/terms.