E-invoicing Across LATAM in 2026: The Developer's Map (MX, AR, BR, CO, CL)

Argentina just moved the deadline: RG 5824 is mandatory July 1, 2026

If you sell into Argentina, mark July 1, 2026: that’s when RG 5824/2026 from ARCA (ex-AFIP) ends the remaining exceptions to electronic invoicing and pulls new subjects into the net. Treat it not as a one-country scramble but as the same LATAM-wide clearance pattern you already owe four other countries.

That resolution drags in a new set of subjects: directores de SA (board members of a corporation), socios gerentes de SRL (managing partners of a limited-liability company), professionals, and financial, insurance, prepaid-medicine and education entities. It also introduces a monthly electronic liquidación to consolidate same-client operations, and it requires identifying the buyer (DNI/CUIL/CDI) on operations from $10,000,000 ARS. One nuance worth tracking: professional councils (e.g. CPCE CABA) have filed to postpone the July 1 date, so confirm it held before you hard-code it. (EY analysis of RG 5824.)

Here’s the thing though: Argentina isn’t the exception. It’s the latest domino. Every major LATAM country already forces government-validated e-invoicing — Argentina was just one of the last to close its loopholes. So instead of treating this as a one-country fire drill, I want to give you the developer’s map for a SaaS that sells across the region: what’s the same everywhere, what differs, and the concrete 2026 dates you have to ship before.

One honest caveat up front, and I’ll repeat it at the end because it matters: I’m an engineer, not a cross-border tax advisor. This is the integration map — the shape of the systems and where they connect. Confirm the current rules per country, and pair a local fiscal/PAC provider with a contador (an accountant) in each market. Don’t ship a tax engine off a blog post, mine included.

Why is it the same everywhere? The clearance model

The reason this map is even drawable is that all five countries run the same underlying architecture: a clearance model.

In a clearance model, the invoice is a structured XML document that the tax authority validates and authorizes — often in real time — before or as you deliver it to your customer. The government is in the loop at issuance time. You can’t just print something and reconcile later.

Contrast that with the post-audit model common in much of the US and parts of Europe: you issue whatever invoice you like, keep your own records, and the tax authority only looks if it audits you. LATAM doesn’t work that way. The authority signs off at the moment of issuance, and that signature is what makes the document real.

The practical consequence for engineers is the single most important takeaway in this post: the legal document is the authority-validated XML, not your PDF. Your nicely formatted PDF is a human-readable courtesy copy. The XML — stamped, sealed, authorized — is the thing the tax authority recognizes. You must store that XML, indexed and queryable, as your source of truth. If you only keep the PDF, you don’t actually have the invoice.

So what’s the same across all five: clearance, a structured XML, and a government authorization step at issuance. What differs: the format, the authority, who is obligated, and the specific 2026 change. Let’s go country by country.

Per-country quick reference: authority and format

This is the lookup table you’ll bookmark. One row per country, authority plus format plus the identifier you store.

Mexico — CFDI 4.0 (XML), authorized by the SAT through a PAC (an authorized certification provider). The PAC does the timbrado (stamping) and returns a UUID. Mandatory for a long time. You can read the full how-to in auto-invoicing CFDIs from Stripe or Mercado Pago.

Argentina — comprobantes electrónicos via ARCA (ex-AFIP). You request a CAE (Código de Autorización Electrónico — an electronic authorization code) through the WSFE web service. The CAE is ARCA’s stamp of validity.

Brazil — a family of documents: NF-e (goods), NFC-e (consumer receipt), NFS-e (services) and CT-e (transport), authorized via SEFAZ (the state tax authority) as XML with real-time authorization. Mandatory for a long time. Brazil alone splits the taxonomy four ways, which is its own complexity.

Colombia — factura electrónica via DIAN in UBL 2.1, pre-validated by DIAN before delivery. DIAN returns a CUFE (the unique invoice code) — that’s your stored identifier. Mandatory since 2019.

Chile — DTE (Documento Tributario Electrónico — electronic tax document) via the SII (the tax authority), as XML. Each DTE carries a folio assigned from an SII-authorized range (CAF). Mandatory since 2018.

A note for Mexico devs specifically: you cannot timbrar directly with the SAT. You go through a PAC, always. The others you typically reach through regional e-invoicing providers that wrap SEFAZ/DIAN/SII/ARCA. Same idea — a layer between you and the authority — different name and different coverage.

Which 2026 milestones must I ship before?

Now the part that should sit on your roadmap. Here are the concrete 2026 changes, ordered by date. Treat every date as time-sensitive — confirm the current rule per country before you ship, because they move (some already did).

Brazil, January 1, 2026 — the national NFS-e standard entered its mandatory phase. Scope and phase-in vary by municipality and tax regime, so confirm yours rather than assuming a blanket cutover.

Brazil, the CNPJ-on-NFC-e rule — watch this one, it flipped. A rule (SINIEF Adjustment 11/2025) was set to block issuing an NFC-e to a recipient identified by a CNPJ (a company tax ID) from January 5, 2026. That restriction was then repealed by SINIEF Adjustment 12/2026, effective April 9, 2026 — as of mid-2026 you can again issue an NFC-e to a CNPJ recipient. This is the perfect example of why you confirm current text before shipping: a hard restriction became a non-restriction inside a single quarter. Verify the live SINIEF text for your go-live date.

Brazil, ongoing through 2026 — the consumption-tax reform introduces new taxes (IBS, CBS, IS), which forces new mandatory invoice/receipt layouts — new fields and new validations across the document family. The new-layout obligation begins in 2026 for most taxpayers, but Simples Nacional and MEI taxpayers phase in during 2027, and 2026 tax values are largely for testing. This is a schema migration, not a flag flip. Budget real engineering time and confirm your regime’s date.

Colombia, 2026 — a DIAN draft resolution to regularize non-compliance, plus POS electronic-receipt requirements. Watch the final text before you assume scope.

Argentina, July 1, 2026 — RG 5824, the headline deadline, ending the remaining exceptions and adding new obligated subjects. Note the pending postponement request from professional councils — re-check the date holds.

Chile, November 1, 2026 — the SII delayed new dispatch-guide/transport obligations (carrier and vehicle ID, transaction classification, delivery-note reporting) to this date. It moved once, so re-check it doesn’t move again.

Mexico, rolling — catálogo updates and new complementos: Hidrocarburos since April 24, 2026, and Carta Porte 3.1. Mexico’s changes don’t come on one big date; they trickle, and your PAC rejects stale catalog keys. The freight side is covered in my Carta Porte 3.1 developer guide.

And a transport-side note for Peru, if you touch logistics there: SUNAT GRE — the guía de remisión electrónica “por evento” — under R.S. 108-2026, effective June 1, 2026.

Same model, five formats: what actually differs

Step back and the architecture clarifies. Here’s the contrast that drives every design decision.

Same across LATAM: the clearance model, a government-validated structured XML, an authorization step at issuance, and the rule that the validated XML is the legal document. Internalize those four and you understand 80% of every country’s system.

Differs — the format: CFDI 4.0 (Mexico) · comprobante authorized by a CAE (Argentina) · the NF-e family (Brazil) · UBL 2.1 (Colombia) · DTE (Chile). Five different schemas, none interchangeable.

Differs — the authority: SAT · ARCA · SEFAZ · DIAN · SII. Different web services, different credentials, different error codes.

Differs — the stored identifier: UUID (Mexico) · CAE (Argentina) · access key (Brazil) · CUFE (Colombia) · folio (Chile). Each authority hands back its own proof-of-validity, and that’s what you index on.

Differs — the document-type taxonomy: Brazil alone splits goods vs consumer vs services vs transport into separate document types. The others are closer to one core document with variations.

Differs — who is newly obligated and when: Argentina’s RG 5824 expansion is the clearest 2026 example, but each country has its own subject list moving on its own calendar.

Differs — how you reach the authority: Mexico mandates a PAC; the others go through regional providers wrapping SEFAZ/DIAN/SII/ARCA.

The engineering implication falls right out of this: you model the common clearance pattern once, then parameterize format + authority + provider per country. You don’t write five systems. You write one pattern with five adapters.

How do you build one e-invoicing layer for five countries?

So how do you actually build this? Let me show you the anti-pattern first, because I’ve watched teams fall into it.

The anti-pattern: hand-building five XML generators. Don’t. You will drown in catálogo updates, you’ll never keep five authorities’ validations current, and the day Brazil’s tax reform changes a layout you’ll be patching raw XML in production. It does not scale and it does not stay correct.

The pattern: detect the customer’s country → map to that country’s format + authority → call a local provider/PAC to validate → store the country-specific validated XML. That’s the whole architecture. A router and a set of adapters.

Here’s an illustrative country-router. The field names and the per-country SDK call shapes are illustrative — use a real provider SDK per country and confirm the exact request/response against its docs. The shape is what matters: one entry point, country-specific dispatch.

// Illustrative only — use a real provider SDK per country.
// MX = a PAC; the others via regional e-invoicing providers.
async function issueInvoice(sale) {
  const country = sale.sellerCountry; // "MX" | "AR" | "BR" | "CO" | "CL"

  const adapters = {
    MX: () => pac.timbrarCFDI(toCFDI40(sale)),        // SAT via PAC -> UUID
    AR: () => arca.solicitarCAE(toComprobante(sale)), // ARCA WSFE  -> CAE
    BR: () => sefaz.authorize(toNFe(sale)),           // SEFAZ      -> access key
    CO: () => dian.validate(toUBL21(sale)),           // DIAN       -> CUFE
    CL: () => sii.send(toDTE(sale)),                  // SII        -> folio
  };

  const adapter = adapters[country];
  if (!adapter) throw new Error(`No e-invoicing adapter for ${country}`);

  const result = await adapter(); // provider validates with the authority

  // Store the VALIDATED XML — it is the legal document.
  await invoices.store({
    paymentId: sale.paymentId,
    country,
    authId: result.authId,    // UUID (MX) · CAE (AR) · key (BR) · CUFE (CO) · folio (CL)
    xml: result.validatedXml, // source of truth, indexed by authId
  });

  return result;
}

Stay vendor-neutral about who fills those adapters. Mexico is a PAC. The rest you reach through regional e-invoicing providers that cover SEFAZ/DIAN/SII/ARCA — some platforms aggregate several countries, some don’t. Choose on developer experience and country coverage, not on marketing. Verify the provider actually covers every country you sell in today.

And store the validated XML indexed by the country’s identifier — the UUID in Mexico, the CAE in Argentina, the access key in Brazil, the CUFE in Colombia, the folio in Chile — and reconcile it back to the payment id, so every charge has a provable legal document attached. That reconciliation is what saves you in an audit. For the payments side of selling across the region, see payment gateways in Mexico and the rest of the integrations guides.

FAQ: CAE vs timbrado, providers, and what to store

Is a CAE the same as a timbrado UUID? Same idea, different name. In Argentina the CAE (Código de Autorización Electrónico) from ARCA’s WSFE is the authorization code. In Mexico the SAT — through a PAC — returns a UUID after timbrado. Both are the government’s stamp of validity on the document. If you understand one, you understand the other. Colombia’s equivalent is the CUFE; Chile’s is the DTE folio.

Do I store the PDF or the XML? The validated XML. That is the legal document in every one of these countries. The PDF is the human-readable copy you email the customer. If you only keep the PDF, you don’t have the legal invoice — full stop.

Can one provider cover all of LATAM? Often no. Mexico is served by a PAC; the rest by regional providers covering SEFAZ/DIAN/SII/ARCA. Some platforms aggregate several countries — but verify country coverage for each market you actually sell in before you commit.

Can I still issue a Brazilian NFC-e to a company (CNPJ)? As of mid-2026, yes. A rule was set to block it from January 5, 2026, but it was repealed (SINIEF Adjustment 12/2026, effective April 9, 2026), so NFC-e to a CNPJ recipient is allowed again. This one flipped inside a quarter — confirm the current SINIEF text for your go-live date before you wire branching logic around it.

Does RG 5824 affect me if I only sell to consumers in Argentina? It expands who must issue — directores de SA, socios gerentes de SRL, professionals and certain regulated entities. So the question isn’t who you sell to; it’s whether your Argentine seller entity is newly obligated from July 1, 2026. Check the entity, not the customer.

How current is this? Regulatory rules and dates change — Chile pushed its transport obligations to November, and Brazil repealed a CNPJ restriction weeks after it took effect. Confirm the current rule per country against the tax authority (SAT, ARCA RG 5824 in the Boletín Oficial, DIAN, SII) and your provider before you ship.

Closing: route, don’t rebuild

The pattern in one line: detect country → map to format + authority → local provider validates → store the country-specific XML. Build that once, parameterize it five ways, and you’ve got a cross-LATAM e-invoicing layer that survives the next catálogo update instead of breaking on it.

On the calendar: ship the Argentina RG 5824 path before July 1, 2026 (and watch the postponement petition), keep the Brazil layout reform and Chile’s November 1 obligations on your roadmap, and don’t hard-code Brazil’s short-lived CNPJ-on-NFC-e rule — it’s already been repealed. Mexico’s rolling complementos you handle continuously through your PAC.

And the caveat one more time, because correctness here is the whole value: I’m an engineer, not a cross-border tax advisor. This is the integration map — the systems and where they connect. Confirm the current rules per country, and pair a local fiscal/PAC provider with a contador in each market. Route, don’t rebuild — and let the people who do tax for a living tell you exactly what each XML must contain.