Formatos de facturas electrónicas en Latinoamérica: cómo procesarlos y verificarlos automáticamente

Todas son facturas electrónicas, pero ninguna se parece a otra: cambian el formato, los campos, la forma de identificar al proveedor y el diseño del PDF que acompaña al archivo. Procesarlas bien exige entender qué es cada una y qué información contiene.

¿Qué son los formatos fiscales de facturas electrónicas y por qué varían entre países?

Un formato fiscal de factura electrónica es la estructura que define una autoridad tributaria para que un comprobante sea reconocido: qué datos debe llevar, en qué formato de archivo se emite (normalmente XML), cómo se numera o identifica y qué pasos de firma, autorización o validación debe seguir. Cada país define el suyo, con sus propios nombres, códigos, plazos y versiones, y los va actualizando con el tiempo. Por eso no existe un formato único para toda Latinoamérica, y por eso conviene verificar siempre la normativa vigente de cada autoridad antes de dar por sentado un criterio.

Diferencia entre una factura electrónica fiscal y su representación en PDF

En los países que se describen en este artículo, el archivo XML es el que contiene la información fiscal estructurada del comprobante; el PDF es una representación legible de ese XML, pensada para que una persona lo lea, lo imprima o lo archive. Los datos pueden coincidir, pero no son el mismo documento, y para procesar una factura conviene saber cuál de los dos se tiene.

En la práctica, esta diferencia cambia la forma de procesar. Un XML ya trae los datos organizados en campos, de modo que puede leerse directamente, sin reconocimiento óptico. Un PDF, en cambio, exige interpretar un diseño visual: ubicar dónde está el número, el total o el impuesto. Cuando el proveedor envía ambos archivos, el XML sirve como fuente de los datos fiscales y el PDF como apoyo visual; cuando solo llega el PDF, o una imagen, toda la información debe extraerse del documento.

Principales documentos y formatos utilizados en Latinoamérica

Estos son cinco casos frecuentes en empresas con proveedores en la región. La descripción es general y, como se indicó, cada autoridad actualiza sus reglas.

Perú

La SUNAT regula los comprobantes de pago electrónicos —factura, boleta y notas de crédito y débito—, que se emiten en XML bajo el estándar UBL y se acompañan de una representación impresa en PDF. El proveedor se identifica con su RUC, y cada comprobante lleva una serie y un correlativo, por ejemplo: F001-123.

México

El CFDI (Comprobante Fiscal Digital por Internet) es un XML timbrado por un proveedor autorizado de certificación (PAC) ante el SAT. La versión vigente para emitir es la 4.0, aunque todavía circulan comprobantes de versiones anteriores. Su identificador es el UUID o folio fiscal, el proveedor se identifica con su RFC, y el PDF es una representación impresa con código QR. Según la operación, puede incluir complementos, por ejemplo, de pago.

Colombia

La factura electrónica de venta se emite en XML bajo el estándar UBL 2.1 y pasa por una validación previa de la DIAN antes de llegar al comprador. Se identifica con el CUFE, un código alfanumérico único que aparece tanto en el XML como en la representación gráfica en PDF, la cual incluye un código QR. El proveedor se identifica con su NIT.

Chile

Los documentos tributarios electrónicos (DTE) se emiten en XML con un folio autorizado por el SII, firma electrónica y un timbre electrónico que en la representación impresa aparece como código de barras bidimensional (PDF417). Existen varios tipos de DTE: factura electrónica, factura exenta, notas de crédito y débito, guía de despacho, entre otros. El proveedor se identifica con su RUT.

Ecuador

Los comprobantes electrónicos se emiten en XML siguiendo los esquemas que publica el SRI, e incluyen factura, notas de crédito y débito, comprobantes de retención, guías de remisión y liquidaciones de compra. Cada comprobante lleva una clave de acceso de 49 dígitos, que además funciona como número de autorización, y se acompaña de una representación impresa llamada RIDE. El proveedor se identifica con su RUC.

Diferencias entre los formatos fiscales de cada país

Las diferencias más relevantes para Cuentas por Pagar no son solo de nombre. Cambia dónde está el identificador único del comprobante, qué tipos de documento existen (por ejemplo, los comprobantes de retención ecuatorianos o las guías de despacho chilenas), cómo se escriben los impuestos y qué datos adicionales trae cada comprobante. Un proceso que asume una única estructura se desordena apenas llega un proveedor de otro país.

Facturas en PDF, XML y otros formatos: diferencias prácticas para procesarlas

• XML: datos ya estructurados. Se leen directamente, pero hay que reconocer la versión y el esquema de cada país, que cambian con el tiempo.
• PDF generado por sistema: contiene texto legible por software, aunque el diseño varía de un proveedor a otro y exige interpretar la posición y el significado de cada dato.
• Imagen, escaneo o fotografía: requiere OCR antes de poder leer cualquier campo, y su calidad afecta la precisión.
• Otros formatos, como hojas de cálculo, enlaces de descarga o documentos de proveedores del exterior fuera de un régimen de facturación electrónica, que suelen traer menos estructura todavía.

Las empresas reciben facturas con estructuras y diseños distintos por una razón simple: la normativa define qué datos debe llevar un comprobante, pero no cómo debe verse. Cada proveedor usa su propio software de facturación, que genera su propia representación en PDF, y los proveedores del exterior siguen reglas distintas o ninguna.

Extraer datos de facturas con OCR e inteligencia artificial, sin importar el formato

El OCR convierte el texto de una imagen o un PDF en texto que un sistema puede leer, pero no sabe qué representa cada dato. Procesar las facturas con inteligencia artificial agrega ese paso: reconocer cuál es el número de comprobante, cuál es la fecha de emisión y cuál el total, aun cuando el diseño cambie de un proveedor a otro. Esto permite extraer datos de facturas de distintos países sin definir una plantilla para cada emisor, algo difícil de sostener cuando la empresa tiene decenas o cientos de proveedores. Cuando el archivo es un XML, los datos se leen de su estructura, y la comparación con el PDF, si existe, sirve como control adicional.

Campos clave: RUC, RFC, RUT, NIT, número de comprobante, impuestos, moneda y total

• Identificación tributaria (RUC, RFC, RUT, NIT): cada país tiene su longitud y su formato; el RUT chileno y el NIT colombiano incluyen un dígito verificador, y el RFC mexicano tiene 12 o 13 caracteres según el tipo de contribuyente. Normalizarlos (sin puntos, guiones o espacios) permite compararlos con el maestro de proveedores.
• Número de comprobante: puede ser serie y correlativo, folio, UUID, CUFE o clave de acceso. Entender cuál es el identificador de cada país evita confundir, por ejemplo, el folio interno del proveedor con el identificador fiscal.
• Impuestos: el nombre, las tasas y la forma de desglosarlos varían (IVA, IGV, retenciones). Interpretarlos requiere reconocer cada impuesto y su base.
• Moneda y total: conviene identificar la moneda explícitamente y los separadores de miles y decimales (1.250,50 frente a 1,250.50), porque leerlos mal cambia el monto en órdenes de magnitud.

Facturas en distintos idiomas

Un proveedor del exterior puede emitir una factura en inglés o portugués, con etiquetas distintas (“Invoice No.” en lugar de “Factura N.°”), otro orden de fechas y otras convenciones numéricas. La lectura por contexto, en lugar de por etiqueta fija, permite reconocer el campo aunque cambie el idioma, pero los casos ambiguos, como una fecha escrita 03/04, siguen necesitando una regla o una revisión humana.

Validación de la información extraída

Una vez extraídos, los datos se revisan antes de registrarse: que el proveedor exista en el maestro, que el formato y el dígito verificador de su identificación sean coherentes, que la suma de las líneas coincida con el total, que los impuestos sean consistentes con los montos y que la factura no sea un duplicado. Estas validaciones son internas: comprueban que los datos son coherentes entre sí y con la información de la empresa.

Relación con la orden de compra y la recepción

Con los datos extraídos se busca la orden de compra referenciada y se comparan cantidades, precios y unidades; cuando existe información de recepción, también se compara con ella (conciliación 3 vías). Esta comparación detecta diferencias entre lo pedido, lo recibido y lo facturado, incluso cuando la factura y la orden usan unidades de medida distintas, lo que requiere una conversión.

Facturas incompletas o con un formato que el sistema no puede interpretar

No toda factura puede procesarse sin intervención. Si falta un dato obligatorio, si la imagen es ilegible o si un campo se extrae con baja confianza, lo recomendable es que el sistema detenga esa factura, la marque con el motivo y la derive a una persona, mientras las demás siguen su curso. Forzar el registro de una factura dudosa traslada el error al ERP, donde corregirlo cuesta más.

Interpretar un formato fiscal no es lo mismo que validar oficialmente un comprobante

Interpretar un comprobante es leer y organizar la información que contiene. Validarlo oficialmente es confirmar ante la autoridad tributaria (SUNAT, SAT, DIAN, SII, SRI u otra) que el comprobante fue autorizado y su estado es el que se espera. Son procesos distintos: un sistema que procesa información documental no reemplaza la consulta oficial.

Esa consulta se hace por los canales que cada autoridad dispone, y si debe hacerse, cuándo y cómo depende de la normativa del país y de la política de cada empresa. Lo que sí puede hacer el procesamiento automático es dejar los datos que esa consulta requiere (identificador del comprobante, proveedor, montos) listos y ordenados, para que la verificación, cuando corresponda, sea más sencilla.

Criterios para elegir un software que procese facturas de varios países

Para automatizar las cuentas por pagar de una empresa con proveedores en varios países, conviene revisar:

• Si exige una plantilla por proveedor. Un sistema que necesita configurar cada emisor se vuelve difícil de mantener, y obligar a los proveedores a usar un formato único rara vez es viable.
• Qué formatos acepta: XML, PDF, imagen y correo con adjuntos, y cómo trata el caso en que llegan juntos.
• Cómo maneja los casos que no puede interpretar: si los detecta, los explica y los deriva, o los registra igual.
• Qué validaciones hace: duplicados, coherencia de datos, comparación con la orden de compra y la recepción.
• Cómo se integra con el ERP y qué capacidades requiere de este.
• Qué no hace, en particular si realiza o no una validación oficial ante las autoridades tributarias, para no suponer una cobertura que no existe.

Breezefile: procesamiento de facturas de distintos países y formatos

Breezefile es una solución de automatización de facturas de proveedores que interpreta y procesa facturas de distintos países y formatos de Latinoamérica sin depender de una única plantilla documental. Recibe los documentos por correo o carga de archivos, extrae los datos con OCR e inteligencia artificial y valida la información: detecta facturas duplicadas, compara la factura con la orden de compra y, cuando existe, con la recepción (conciliación de 2 y 3 vías), incluida la conversión de unidades, y aprende las reglas específicas de cada empresa a partir de sus documentos y procesos.

Una vez confirmada, la factura se registra en el ERP mediante API, sujeto a las capacidades de integración del sistema de cada empresa. Su función es interpretar y procesar la información documental: no realiza la validación oficial de los comprobantes ante SUNAT, SAT, DIAN, SII u otras autoridades.

Para evaluar esta solución en un entorno real de trabajo se puede:

• Probar Breezefile de forma gratuita — permite procesar hasta 30 facturas de prueba. No se necesita tarjeta de crédito.
• Agendar una demostración — para revisar la compatibilidad con el ERP y el flujo actual de facturas en la empresa.

Conclusión

Las facturas electrónicas de Latinoamérica comparten una idea —un archivo fiscal en XML y una representación legible—, pero difieren en formato, identificadores y campos. Para una empresa con proveedores en varios países, el reto no es dominar cada norma, sino contar con un proceso capaz de leer esa variedad, validar internamente los datos y derivar las excepciones, sin exigir que todos los proveedores usen la misma plantilla. La validación oficial ante cada autoridad sigue siendo un paso distinto, que se define según la normativa y las políticas de cada empresa.

Redacción Editorial