07. CFDI México, DTE Chile, FE Colombia con IA
Anatomía del XML de cada país. Cuándo usar parsing directo vs OCR + LLM. Compatibilidad con SAT, SII, DIAN.
Bienvenido al Módulo 3. Hasta acá vimos cómo clasificar transacciones bancarias con LLMs. Ahora vamos a meternos con el documento más importante para cualquier contador o auditor tributario LATAM: la factura electrónica.
La buena noticia es que la región está, posiblemente, más avanzada que cualquier otra del mundo en facturación electrónica obligatoria. La (relativamente) mala noticia es que cada país tiene su propio formato, su propio organismo fiscalizador, y sus propias reglas de validación.
En esta lección vas a entender:
- La anatomía del XML por país (CFDI, DTE, FE, AFIP, NFe).
- Cuándo el XML por sí solo es suficiente y cuándo necesitás sumar OCR + LLM.
- Cómo hacer validación cruzada contra los sistemas oficiales (SAT, SII, DIAN, AFIP, SEFAZ).
- Casos típicos donde la IA aporta valor real.
La gran ventaja LATAM: los datos ya vienen estructurados
A diferencia de Europa o Estados Unidos, donde una factura B2B puede llegar como PDF, Word, Excel o foto de WhatsApp, en LATAM la mayoría de las facturas B2B vienen como XML firmado digitalmente por el organismo fiscalizador.
Esto cambia radicalmente el problema. Cuando tenés un XML válido, no necesitás OCR. Los datos ya están estructurados: RFC/RUT/NIT, fecha, monto, IVA, conceptos, etc. están en campos específicos.
💡 Punto clave para entender el módulo
XML válido y timbrado = datos confiables, no necesitás IA para extraerlos.
Foto, escaneo o PDF de factura = necesitás Document AI + LLM (lo vemos en la Lección 8).
La gran mayoría de tu volumen B2B debería ser XML. Lo "messy" (taxis, comprobantes menores, gastos de viaje) es donde la IA brilla.
Anatomía rápida del XML por país
México — CFDI 4.0 (SAT)
El Comprobante Fiscal Digital por Internet (CFDI) es el estándar mexicano desde 2014 (versión 4.0 vigente desde 2022). Lo regula el SAT (Servicio de Administración Tributaria).
Estructura básica relevante para contabilidad:
- Emisor:
Rfc,Nombre,RegimenFiscal - Receptor:
Rfc,Nombre,UsoCFDI,DomicilioFiscalReceptor - Conceptos:
ClaveProdServ(catálogo SAT),Cantidad,Importe,Descuento - Impuestos:
TrasladosImpuestos,RetencionesImpuestos - Timbre Fiscal Digital:
UUID(folio fiscal único de 36 caracteres),FechaTimbrado, sello digital del SAT
El UUID es la prueba de que el SAT validó y registró el CFDI. Sin UUID, el CFDI no es deducible.
<cfdi:Comprobante Version="4.0" Fecha="2026-05-10T10:23:14"
Total="11600.00" SubTotal="10000.00" Moneda="MXN">
<cfdi:Emisor Rfc="ABC123456XYZ" Nombre="PROVEEDOR SA DE CV"
RegimenFiscal="601"/>
<cfdi:Receptor Rfc="XAXX010101000" Nombre="CLIENTE SA DE CV"
UsoCFDI="G03"/>
...
<tfd:TimbreFiscalDigital UUID="A1B2C3D4-E5F6-..."
FechaTimbrado="2026-05-10T10:23:18"/>
</cfdi:Comprobante>
Chile — DTE (SII)
El Documento Tributario Electrónico (DTE) es el estándar chileno, regulado por el SII (Servicio de Impuestos Internos). Los tipos más comunes son 33 (factura electrónica), 34 (factura exenta), 61 (nota de crédito), 56 (nota de débito).
Estructura básica:
- Emisor:
RUTEmisor,RznSoc,GiroEmis,Acteco - Receptor:
RUTRecep,RznSocRecep,GiroRecep - Totales:
MntNeto,IVA,MntTotal - Detalle:
NroLinDet,NmbItem,QtyItem,MontoItem - Folio SII: número correlativo dentro del rango autorizado (CAF — Código de Autorización de Folios)
- Timbre Electrónico (TED): firma digital + folio autorizado
El folio del DTE es asignado dentro de un rango previamente solicitado al SII. Si el folio está fuera del rango autorizado, el DTE es inválido.
Colombia — FE (DIAN)
La Factura Electrónica de Venta (FE) colombiana sigue el estándar UBL 2.1. La regula la DIAN (Dirección de Impuestos y Aduanas Nacionales).
Estructura básica:
- AccountingSupplierParty: NIT del emisor, razón social, régimen
- AccountingCustomerParty: NIT del receptor
- LegalMonetaryTotal:
LineExtensionAmount,TaxExclusiveAmount,PayableAmount - InvoiceLine: detalle de productos/servicios
- CUFE (Código Único de Factura Electrónica): hash SHA-384 que identifica unívocamente la factura. Es validado por la DIAN.
Argentina — Factura Electrónica AFIP
La AFIP no usa un XML público al estilo CFDI/DTE/FE, pero exige solicitar un CAE (Código de Autorización Electrónico) antes de emitir cada factura. La consulta se hace por servicio web SOAP/REST.
Datos clave:
- CUIT emisor / receptor
- Tipo de comprobante: A, B, C, M, E
- Punto de venta + Número
- CAE + Fecha de vencimiento del CAE
- Monto neto, IVA, total
Muchos proveedores entregan al cliente un PDF con representación impresa + un JSON o XML interno. El CAE es el equivalente al UUID/folio/CUFE para validación.
Brasil — NFe (SEFAZ)
La Nota Fiscal eletrônica (NFe) brasileña es uno de los formatos más sofisticados del mundo, regulada por las SEFAZ estatales y la Receita Federal. Existen variantes: NFe (productos), NFSe (servicios — municipal), CTe (transporte), MDFe (manifiesto).
Estructura clave:
- Chave de Acesso: 44 dígitos que identifican univocamente la NFe
- Protocolo de Autorização: confirmación de SEFAZ
- emit / dest: emisor y destinatario con CNPJ
- det: detalle con NCM (clasificación arancelaria), CFOP, ICMS, IPI, PIS, COFINS
- infNFe: información completa, firmada digitalmente con certificado A1 o A3
🇧🇷 Nota sobre Brasil
La NFe es el documento más complejo de LATAM. Tiene cientos de campos, dependiendo del tipo de operación. Por eso es el caso donde más valor aporta el LLM: para normalizar, resumir, y traducir entre el XML de SEFAZ y el sistema contable interno.
¿Cuándo el XML es suficiente?
Cuando recibís un XML válido y timbrado, los datos críticos para contabilidad ya están. No necesitás IA para extraerlos: un parser de XML estándar (incluso en Excel con Power Query, n8n o Make) los lee directo.
| Tarea | ¿Necesita IA? |
|---|---|
| Extraer RFC/RUT/NIT del emisor | No (parser XML directo) |
| Obtener monto neto, IVA, total | No |
| Identificar UUID/folio/CUFE | No |
| Validar firma digital | No (validador del organismo fiscal) |
| Validar contra el SAT/SII/DIAN | No (consulta API oficial) |
Si tu workflow consume solo XMLs válidos, podés llegar muy lejos sin tocar un LLM. El LLM aporta cuando hay decisiones que tomar sobre los datos.
¿Cuándo SÍ necesitás OCR + LLM?
Hay varios escenarios donde el XML no alcanza:
1. La factura llega como PDF, imagen o papel
Muy frecuente con:
- Taxis y movilidad (Uber, Cabify a veces dan PDF, comprobantes de taxi en papel)
- Comercios pequeños (algunos boletos B chilenos, recibos colombianos POS)
- Gastos de viaje internacionales (facturas USA, Europa)
- Documentos antiguos pre-facturación electrónica obligatoria
En estos casos: Document AI o Textract extraen los campos → LLM normaliza y completa. Lo vemos en la Lección 8.
2. Necesitás clasificar contablemente el concepto
El XML tiene la ClaveProdServ del SAT o el detalle del DTE, pero no la cuenta contable de tu plan de cuentas. Esa traducción es exactamente el tipo de trabajo donde un LLM ayuda:
Concepto factura CFDI: "Servicio de hosting cloud mensual
Plan Business AWS - Mayo 2026"
ClaveProdServ SAT: 81112101 (Servicios de hospedaje)
→ LLM sugiere cuenta contable:
5202030 - Servicios tecnológicos / Cloud computing
3. El XML viene mal cargado o con errores del proveedor
Casos típicos:
- RFC/RUT/NIT del receptor mal escrito (típico cuando el proveedor digita a mano)
- Monto en moneda extranjera sin tipo de cambio aplicado
- Concepto genérico que no permite deducir el destino contable
- Uso de CFDI mal seleccionado (G01 cuando debería ser G03)
Acá el LLM puede flaggear inconsistencias y sugerir corrección al proveedor.
4. Necesitás combinar varios documentos relacionados
Una factura puede venir acompañada de:
- Orden de compra (PDF interno)
- Remito o guía de despacho (XML o PDF)
- Acta de recepción del bien o servicio (PDF firmado)
- Contrato marco (PDF largo)
Cruzar estos documentos es trabajo de razonamiento, no de extracción. LLM = motor de razonamiento.
Validación cruzada contra el organismo oficial
Tener un XML "que parece válido" no significa que lo sea. Cualquier persona puede generar un XML con estructura correcta. Lo que diferencia un comprobante real es la validación contra el sistema oficial.
| País | Endpoint de validación | Qué se valida |
|---|---|---|
| México | API SAT (consulta de UUID/CFDI) | Estado del CFDI (vigente, cancelado), coincidencia de RFC, monto, fecha |
| Chile | Portal SII (consulta de DTE por RUT + folio + tipo) | Folio dentro de rango autorizado, emisor activo, no caducado |
| Colombia | DIAN (validación de CUFE) | CUFE coincide con factura registrada, NIT emisor activo |
| Argentina | AFIP (consulta de CAE) | CAE válido, no vencido, montos coinciden con lo declarado |
| Brasil | SEFAZ por estado (consulta de chave) | Status: autorizada, cancelada, denegada |
⚠️ Por qué importa la validación cruzada
Sin validación contra el organismo oficial, podés estar deduciendo facturas:
- Canceladas por el emisor (común en CFDI: el proveedor cancela y vos no te enteraste).
- Apócrifas (especialmente riesgo en México: EFOS — Empresas Facturadoras de Operaciones Simuladas).
- Con datos diferentes entre lo que viene en el XML que te entregaron y lo declarado al fisco.
En auditoría tributaria, esto es hallazgo material según NIA 240.
Caso típico: el cliente sube CFDIs y querés validar 5.000 de golpe
El flujo típico que vas a armar (sin programar, con n8n o Make):
- Trigger: nueva carga de XMLs en una carpeta de Drive o S3.
- Parser XML: extraer UUID, RFC emisor, monto, fecha.
- Consulta al SAT: API oficial devuelve estado del CFDI.
- LLM: comparar XML local vs respuesta SAT, identificar diferencias.
- Reglas: rechazar canceladas, flaggear discrepancias en monto > 1%, marcar EFOS conocidas.
- Revisión humana: el contador revisa solo el subset flaggeado.
Resultado: en lugar de validar 5.000 facturas una por una, validás manualmente solo las 50-100 problemáticas.
Casos típicos en la práctica
Caso 1: factura emitida correctamente
CFDI v4.0 timbrado por el SAT, UUID válido, RFC del receptor correcto, ClaveProdServ alineada con el detalle. El XML pasa todos los validadores.
- Acción: ingresar al sistema contable automáticamente. Sin intervención humana.
- Rol del LLM: opcional. Solo si querés sugerir cuenta contable del plan interno.
Caso 2: factura con campos mal cargados por el proveedor
Te llega un CFDI donde el UsoCFDI es G01 (Adquisición de mercancías) pero el concepto es "Servicios de asesoría contable mensual". Inconsistencia clara: debería ser G03 (Gastos en general) o similar.
- Acción: el LLM detecta la inconsistencia.
- Rol del LLM: redactar un correo al proveedor pidiendo corrección y cancelación + re-emisión con UsoCFDI correcto.
Caso 3: DTE chileno cancelado por el emisor
Recibiste un DTE tipo 33 hace dos meses, lo registraste en la contabilidad. Hoy el emisor lo canceló (porque emitió en duplicado).
- Acción: monitoreo periódico contra el SII. Detectar cambio de estado.
- Rol del LLM: alertar al contador, sugerir asiento de reverso, redactar respaldo de la decisión.
Caso 4: factura AFIP con CAE vencido
El proveedor argentino emitió una factura cuyo CAE vencía 10 días después. La factura llega 15 días después por correo. Técnicamente, el CAE estaba vigente al momento de la emisión pero hay que documentar la situación.
- Acción: validar fecha de emisión vs fecha de vencimiento del CAE, no fecha de recepción.
- Rol del LLM: explicar al usuario por qué la factura sí es válida y documentar el caso para auditoría.
Caso 5: NFe brasileña con NCM inconsistente
Una NFe llega con un NCM que no corresponde al producto descrito en el detalle. Puede ser error del emisor o intento de evasión de tributos federales.
- Acción: cruzar NCM contra descripción del producto.
- Rol del LLM: identificar la inconsistencia, sugerir el NCM correcto, escalar a revisión tributaria.
El patrón ganador aplicado a facturación electrónica
Volviendo al meta-framework del curso, así se aplica a XML de facturación electrónica:
Parser XML → Validación oficial → LLM (clasificación/anomalías)
→ Reglas contables → Revisión humana (solo excepciones)
Los pasos no cambian. Lo que cambia es que el primer paso es parser XML en lugar de Document AI/OCR, porque los datos ya vienen estructurados. Solo cuando no hay XML disponible volvemos al pipeline OCR completo de la Lección 8.
🎯 Conclusión operativa
Si tu firma maneja clientes con alto volumen B2B, el 80-90% del trabajo de extracción de facturas es resolverlo con parser XML + consulta a SAT/SII/DIAN. El LLM se reserva para clasificación, normalización y manejo de excepciones.
Esto es importante porque te ahorra dinero: parsear un XML no cuesta nada. Pasar el XML completo a un LLM cuesta entre $0.001 y $0.01 USD por factura. A escala (decenas de miles de facturas/mes), la diferencia importa.
Próximos pasos
En la Lección 8 vamos al otro extremo del espectro: ¿qué hacés cuando la factura NO viene como XML? Facturas escaneadas, fotografiadas, taxis, gastos menores, recibos no estandarizados. Ahí entra Document AI, Textract, Mindee, Klippa y el pipeline OCR + LLM completo.
💡 Tarea opcional antes de continuar
Tomá una factura electrónica de un proveedor habitual (un CFDI, DTE o FE que tengas a mano). Abrila con un editor de texto y mirá el XML crudo.
Identificá:
- ¿Cuál es el folio fiscal único (UUID/folio/CUFE)?
- ¿Qué fecha y monto declara el emisor?
- ¿Está timbrada/autorizada por el organismo oficial?
Tener esta intuición sobre el XML te va a ayudar a entender mucho mejor las próximas lecciones, incluso si nunca vas a parsear uno a mano.
Próxima lección: 08. Procesar facturas físicas: Document AI + LLM
Checkpoint de comprensión
3 preguntas para verificar lo aprendido. No afecta tu nota del examen final.
Completaste esta leccion?
Marca esta leccion como completada. Tu progreso se guardara en tu navegador.