Facturación electrónica en LATAM 2026: el mapa para developers (MX, AR, BR, CO, CL)

Argentina acaba de mover la fecha: la RG 5824 es obligatoria el 1 de julio de 2026

Si vendes en Argentina, marca el calendario: la RG 5824/2026 termina con las últimas excepciones a la factura electrónica. Desde el 1 de julio de 2026, las operaciones de los sujetos que faltaban tienen que emitirse como comprobante electrónico, sin vuelta.

¿A quién suma la resolución? A los directores de SA, socios gerentes de SRL, profesionales independientes y entidades del rubro financiero, de seguros, de medicina prepaga y de educación. Además introduce una liquidación electrónica mensual para consolidar operaciones con un mismo cliente, y obliga a identificar al comprador en operaciones desde $10.000.000 ARS. Detalle en la alerta de EY sobre la RG ARCA 5824.

Aquí viene la parte que importa si construyes producto: Argentina no es la excepción, es la última ficha del dominó. Cada país grande de LATAM ya te obliga a emitir facturas validadas por el gobierno. México lo tiene desde hace años con CFDI; Chile desde 2018; Colombia desde 2019; Brasil desde mucho antes (las fechas exactas varían por tipo de documento). Lo que estás viendo en Argentina es el mismo patrón llegando al último grupo que quedaba afuera.

Así que este post es el mapa para developers de un SaaS que cobra y factura cruzando la región. No es un how-to por país a detalle (para México tengo aparte el de facturación CFDI automática con Stripe y Mercado Pago); es el mapa de integración: autoridad, formato, modelo y los cambios 2026 que tienes que alcanzar a tiempo.

Aviso honesto antes de seguir: soy ingeniero, no asesor fiscal transfronterizo. Esto es el mapa de integración para que sepas qué construir. Confirma las reglas vigentes por país y trabaja con un proveedor fiscal/PAC local más un contador en cada jurisdicción.

¿Por qué es lo mismo en todas partes? El modelo de clearance

Cuando ves los cinco países juntos, salta el patrón: todos corren un modelo de clearance. Eso significa que la factura es un XML estructurado que la autoridad fiscal valida y autoriza — muchas veces en tiempo real — antes o al momento de entregarla al cliente. No emites primero y reportas después: el fisco interviene al momento de emitir.

Contrasta esto con el modelo post-audit que se usa en otras regiones, donde simplemente guardas tus registros y el fisco los revisa si te audita. En LATAM no: sin la autorización de la autoridad, el documento no existe legalmente.

La consecuencia práctica para quien escribe el código es directa: el documento legal es el XML validado por la autoridad, no tu PDF. El PDF es la copia legible para humanos. Tienes que guardar ese XML, indexado, como tu fuente de verdad, y reconciliarlo contra el pago que lo originó.

Entonces, ¿qué es lo MISMO en los cinco países? El clearance, un XML estructurado y un paso de autorización del gobierno. ¿Qué CAMBIA? El formato, la autoridad, quién está obligado y cuál es el cambio de 2026. Vamos a esos cuatro ejes.

Referencia rápida por país: autoridad y formato

Esta es la tabla que vas a marcar como favorita. Una fila por país:

• México: CFDI 4.0 (XML), autorizado por el SAT a través de un PAC (el timbrado devuelve un UUID). Obligatorio desde hace años. No puedes timbrar directo con el SAT: pasas siempre por un PAC. Portal oficial: SAT.
• Argentina: comprobantes electrónicos vía ARCA (ex-AFIP); solicitas un CAE (Código de Autorización Electrónico) a través del web service WSFE (u otro web service de ARCA según el tipo de comprobante).
• Brasil: NF-e (mercancías), NFC-e (recibo a consumidor), NFS-e (servicios) y CT-e (transporte) vía SEFAZ — XML con autorización en tiempo real. Obligatorio desde hace años.
• Colombia: factura electrónica vía DIAN en UBL 2.1, prevalidada por la DIAN antes de la entrega. Obligatorio desde 2019. Portal oficial: DIAN.
• Chile: DTE (Documento Tributario Electrónico) vía el SII (XML). Obligatorio desde 2018. Portal oficial: SII.

La nota para developers de México: el resto de los países los alcanzas a través de proveedores regionales de e-invoicing que envuelven SEFAZ/DIAN/SII/ARCA. México es el caso especial donde la ley te obliga a usar un PAC.

Los hitos de 2026 que tienes que alcanzar a tiempo

El modelo es estable, pero 2026 trae una tanda de cambios concretos. Ordenados por fecha, esto es lo que tienes que sacar a producción a tiempo (confirma cada regla vigente con la autoridad antes de codear):

• Brasil, 1 de enero de 2026: el sistema nacional de NFS-e pasó a ser obligatorio. 4 de mayo de 2026: ya no puedes emitir una NFC-e a un receptor identificado con CNPJ (el tax ID de empresa) — para ese caso usas NF-e modelo 55. Ojo: esta fecha se postergó desde enero por el Ajuste SINIEF 43/2025.
• Brasil, durante 2026: la reforma del impuesto al consumo (nuevos tributos IBS, CBS, IS) obliga a nuevos layouts de factura y recibo — campos y validaciones nuevos. Este es el cambio más pesado de la región: no es una excepción más, es rediseño de payload.
• Colombia, 2026: una resolución borrador de la DIAN para regularizar incumplimientos, más requisitos de recibo electrónico POS.
• Argentina, 1 de julio de 2026: la RG 5824 — el deadline titular, que cierra las excepciones que quedaban.
• Chile, 1 de noviembre de 2026: el SII postergó a esta fecha las nuevas obligaciones de guía de despacho/transporte (ID de transportista y vehículo, clasificación de la transacción, reporte de la nota de entrega), vía la Resolución Ex. N°52/2026 que modifica la RES 154/2025.
• México, rolling: actualizaciones de catálogo y nuevos complementos — Hidrocarburos desde el 24 de abril de 2026; Carta Porte 3.1 (tengo el detalle en la guía de Carta Porte para developers).

Nota de transporte para quien opere en Perú: la SUNAT tiene la GRE — guía de remisión electrónica “por evento”, R.S. 000108-2026/SUNAT vigente desde el 1 de junio de 2026.

Mismo modelo, cinco formatos: qué cambia de verdad

Pongámoslo crudo para decidir la arquitectura. Lo que es igual en toda LATAM:

• El modelo de clearance.
• Un XML estructurado validado por el gobierno.
• Un paso de autorización en el momento de la emisión.
• La regla de que el XML validado es el documento legal (no el PDF).

Lo que cambia:

• El formato: CFDI 4.0 / comprobante con CAE / familia NF-e / UBL 2.1 / DTE.
• La autoridad: SAT / ARCA / SEFAZ / DIAN / SII.
• La taxonomía de documentos: Brasil por sí solo parte mercancías vs. consumidor vs. servicios vs. transporte (NF-e / NFC-e / NFS-e / CT-e). Los demás son más planos.
• Quién queda obligado y cuándo: la expansión de la RG 5824 en Argentina es el ejemplo más claro de 2026.
• Cómo llegas a la autoridad: México exige un PAC; el resto pasa por proveedores regionales que envuelven SEFAZ/DIAN/SII/ARCA.

La implicación de ingeniería es la clave de todo el post: modelas el patrón común de clearance una sola vez, y parametrizas formato + autoridad + proveedor por país. No replicas la lógica cinco veces.

Cómo un SaaS multi-LATAM rutea una factura

El anti-patrón es tentador y lo he visto matar roadmaps: armar a mano cinco generadores de XML. No lo hagas. Te vas a ahogar en actualizaciones de catálogo y nunca vas a mantener al día las validaciones de cinco autoridades distintas a la vez.

El patrón correcto es de ruteo: detectas el país del cliente → mapeas al formato + autoridad de ese país → llamas a un proveedor/PAC local que valida → guardas el XML validado específico de ese país. Una sola tubería conceptual, adaptadores intercambiables por país.

Así se ve un router ilustrativo. Los nombres de campos y la forma del SDK del proveedor son ilustrativos — confírmalos contra la documentación de tu proveedor real por país:

// Ilustrativo. Usa el SDK real del proveedor/PAC por país.
const adapters = {
  MX: emitirCFDI,      // SAT vía PAC → timbrado (UUID)
  AR: emitirComprobanteARCA, // ARCA WSFE → CAE
  BR: emitirNFe,       // SEFAZ → familia NF-e
  CO: emitirFacturaDIAN, // DIAN UBL 2.1 (prevalidada)
  CL: emitirDTE,       // SII → DTE
};

async function emitirFactura(venta) {
  // venta.pais viene del país fiscal del emisor/receptor, no de la IP
  const emitir = adapters[venta.pais];
  if (!emitir) throw new Error(`País sin adaptador fiscal: ${venta.pais}`);

  // Cada adaptador llama al proveedor local y devuelve el XML VALIDADO
  const { xml, idAutoridad } = await emitir(venta);

  // El XML validado es el documento legal: guárdalo indexado y reconcílialo
  await guardarComprobante({
    paymentId: venta.paymentId,
    pais: venta.pais,
    idAutoridad,   // UUID (MX) · CAE (AR) · chave de acesso (BR) · CUFE (CO) · track ID/folio DTE (CL)
    xml,           // fuente de verdad legal
  });

  return idAutoridad;
}

Mantente neutral en proveedores: México lo cubre un PAC; el resto, proveedores regionales de e-invoicing. Elige por DX y por cobertura real de países, no por marketing. Y guarda el XML validado indexado por el identificador de la autoridad (UUID en México, CAE en Argentina, la chave de acesso en Brasil, el CUFE en Colombia, el track ID/folio del DTE en Chile), siempre reconciliado contra el paymentId. Si quieres ver el lado de pagos de vender en la región, está la guía de pasarelas de pago en México y el resto en integraciones.

Preguntas frecuentes: CAE vs timbrado, proveedores y qué guardar

¿El CAE es lo mismo que el UUID del timbrado? Misma idea, distinto nombre. En Argentina el CAE (Código de Autorización Electrónico) vía el WSFE de ARCA (u otro web service según el tipo de comprobante) es el código de autorización; en México el SAT (a través de un PAC) devuelve un UUID. Los dos son el sello de validez del gobierno sobre tu comprobante.

¿Guardo el PDF o el XML? El XML validado — ese es el documento legal en cada uno de estos países. El PDF es solo la copia legible para humanos. Si te quedas con el PDF y pierdes el XML, perdiste el documento que cuenta.

¿Un solo proveedor para toda LATAM? Seguido no. México lo atiende un PAC; el resto, proveedores regionales que cubren SEFAZ/DIAN/SII/ARCA. Algunas plataformas agregan varios países en un solo SDK — verifica la cobertura país por país antes de casarte con uno.

¿Me afecta la RG 5824 si en Argentina solo vendo a consumidores? La resolución amplía quién debe emitir — directores de SA, socios gerentes de SRL, profesionales y ciertas entidades reguladas — así que revisa si tu entidad emisora argentina queda recién obligada desde el 1 de julio de 2026, sin importar a quién le vendas.

¿Qué tan vigente es esto? Las reglas y fechas regulatorias cambian. Como referencia, todo aquí está verificado a mediados de 2026, pero confirma la regla vigente por país contra la autoridad fiscal y tu proveedor antes de sacarlo a producción.

Cierre: rutea, no reconstruyas

El patrón en una línea: detecta el país → mapea a formato + autoridad → un proveedor local valida → guarda el XML específico del país. Modelas el clearance una vez y parametrizas el resto.

En lo inmediato: libera el camino de la RG 5824 de Argentina antes del 1 de julio de 2026, y deja en el roadmap la reforma de layouts de Brasil y las obligaciones de Chile del 1 de noviembre. México lo manejas con sus catálogos y complementos rolling.

Y lo repito porque importa: soy ingeniero, no asesor fiscal transfronterizo. Esto es el mapa de integración. Confirma las reglas vigentes por país y empareja un proveedor fiscal/PAC local con un contador en cada jurisdicción. Tú construyes la tubería; ellos te confirman que el XML que sale es el correcto.