08. Procesar facturas físicas: Document AI + LLM

En la lección anterior vimos el escenario ideal: factura electrónica con XML estructurado y firmado por el organismo oficial. Pero la realidad operativa de cualquier firma contable LATAM tiene también el otro extremo:

El comprobante del taxi del lunes pasado.
Una factura escaneada que llegó por WhatsApp.
El recibo de un restaurante para un gasto de representación.
La factura del proveedor pequeño que todavía no se digitalizó.
Facturas de proveedores extranjeros (USA, Europa, Asia).

Acá es donde el pipeline OCR + LLM se vuelve indispensable.

El escenario: 500 facturas escaneadas

Imaginemos un caso real. Un cliente PYME te entrega, al final del mes, una caja con 500 comprobantes físicos: facturas A, facturas B, boletos de honorarios, tickets de máquinas POS, comprobantes de transporte. Algunos están bien escaneados; otros son fotos de WhatsApp tomadas en ascensores con poca luz.

Tu objetivo: digitalizar todo, ingresarlo al sistema contable, y conciliar contra el libro mayor antes del cierre del mes.

Forma tradicional: un junior contable ingresa cada uno a mano. Tiempo estimado: 15-25 horas, con tasa de error humano de 2-5%.

Forma 2026: pipeline automatizado con OCR + LLM, revisión humana solo de los casos dudosos. Tiempo estimado: 1-3 horas humanas, costo de procesamiento $10-30 USD, tasa de error humano <0.5% (porque revisás solo los flaggeados).

Veamos cómo se arma.

Los players de OCR / Document AI en 2026

Hay cinco proveedores que dominan el procesamiento de documentos contables. Cada uno tiene fortalezas y precios distintos.

1. Google Document AI

Especializaciones: procesador específico para facturas (Invoice Parser), también para gastos, recibos, contratos.
Idiomas LATAM: español, portugués brasileño, español mexicano — buena cobertura.
Pricing: por documento procesado (consultar pricing actual en cloud.google.com — generalmente en el rango de centavos de dólar por página).
Fortaleza: integración nativa con Gemini 3 para post-procesamiento.
Ideal para: firmas que ya viven en Google Workspace.

2. AWS Textract

Especializaciones: AnalyzeExpense para facturas y recibos, AnalyzeDocument general, soporte de formularios y tablas.
Idiomas LATAM: español y portugués sólidos.
Pricing: tarifa por página (consultar pricing actual — varía según uso de features).
Fortaleza: ecosistema AWS, fácil integrar con S3, Lambda, etc.
Ideal para: firmas con stack AWS o que ya usan Amazon Bedrock.

3. Azure Form Recognizer (Document Intelligence)

Especializaciones: modelos pre-entrenados para facturas, recibos, identificaciones, tarjetas de crédito.
Idiomas LATAM: cobertura muy buena en español.
Pricing: por documento procesado (consultar Azure pricing actual).
Fortaleza: integración nativa con Azure OpenAI (GPT-5.5), favorito en clientes Big Four que ya tienen Microsoft enterprise.
Ideal para: firmas con Microsoft 365 enterprise.

4. Mindee

Especializaciones: APIs específicas para facturas, recibos de gastos, pasaportes, RIB bancarios. Fuerte en formatos europeos y latinoamericanos.
Idiomas LATAM: español y portugués bien soportados.
Pricing: por documento, con tiers (consultar mindee.com — generalmente competitivo).
Fortaleza: API muy fácil de usar, sin curva de aprendizaje cloud-provider.
Ideal para: PYMES y firmas pequeñas que quieren empezar rápido sin Azure/AWS/GCP.

5. Klippa DocHorizon

Especializaciones: facturas, recibos, comprobantes de gastos. Empresa europea con buen soporte LATAM.
Idiomas LATAM: español, portugués.
Pricing: por documento, con planes según volumen (consultar klippa.com).
Fortaleza: pensado específicamente para automatización de gastos y AP (cuentas por pagar).
Ideal para: equipos de cuentas por pagar y automatización de reembolsos.

💰 Costo aproximado por documento (mayo 2026)

El rango general de mercado está entre $0.01 y $0.05 USD por documento, dependiendo del proveedor, volumen y tipo de procesamiento. Para procesar 500 facturas, hablamos típicamente de $5 a $25 USD en OCR.

Comparalo con el costo de un junior contable que ingresa esos 500 documentos a mano durante 15-25 horas. El ROI es evidente.

¿Qué precisión esperar realmente?

Esta es la conversación honesta que tu proveedor no siempre te va a dar. Los benchmarks publicados por los proveedores muestran 95-99% en condiciones ideales. La realidad LATAM:

Tipo de documento	Precisión típica
Factura electrónica impresa, buena calidad	96-98%
Factura escaneada en escáner profesional	94-97%
Foto de factura con luz buena	90-95%
Foto de factura con luz mala o ángulo	80-90%
Foto de WhatsApp comprimida	75-88%
Ticket de POS de máquina térmica	70-90% (la tinta se borra)
Documento manuscrito	50-75% (no confiable)
Fotocopia de fotocopia	60-80%

Estos porcentajes son por campo extraído. Si una factura tiene 10 campos clave y la precisión es 95%, en promedio un campo sale mal por cada dos facturas. Por eso la revisión humana de los low-confidence sigue siendo crítica.

⚠️ Realidad del OCR LATAM

Si tu cliente te manda facturas como fotos de WhatsApp tomadas dentro de un cajón, ningún OCR del mundo te va a dar 99% de precisión. La parte humana del pipeline existe justamente para estos casos.

Lo importante: el OCR no falla "silenciosamente". Devuelve un confidence score por campo. Tu workflow filtra automáticamente lo low-confidence y solo eso va a revisión.

El pipeline completo: OCR → LLM → validación humana

Veamos paso a paso el flujo para esas 500 facturas físicas del caso inicial. Asumimos que las facturas ya están digitalizadas (escaneadas o fotografiadas) y subidas a una carpeta de Drive o S3.

Paso 1: OCR extrae datos crudos

El OCR (Document AI, Textract, Form Recognizer o el que elijas) procesa cada documento y devuelve un JSON estructurado:

{
  "supplier_name": "FERRETERIA INDUSTRIAL XYZ SAS",
  "supplier_tax_id": "8001234567",
  "invoice_number": "FE-2026-04812",
  "invoice_date": "2026-05-03",
  "subtotal": 142000,
  "tax_amount": 26980,
  "total": 168980,
  "currency": "COP",
  "line_items": [
    {
      "description": "Tornillos hex 1/4 caja x 100",
      "quantity": 5,
      "unit_price": 12400,
      "total": 62000,
      "confidence": 0.94
    },
    ...
  ],
  "confidence_global": 0.91
}

Notá los confidence scores. Son tu sistema de alarma temprana.

Paso 2: LLM normaliza y completa

El OCR extrae lo que ve. El LLM agrega razonamiento contable encima.

Cosas que el LLM hace bien acá:

Normalizar formatos de fecha: 03/05/2026, 2026-05-03, 3 de mayo 2026 → todos a 2026-05-03.
Normalizar montos: 1.234,56 (formato europeo/LATAM) vs 1,234.56 (US) → unificar a un solo formato interno.
Identificar moneda implícita: si el RUT es chileno y no dice moneda, asumir CLP.
Completar campos faltantes: si el OCR no encontró "tipo de documento" pero el número es "FE-2026-...", inferir que es Factura Electrónica colombiana.
Sugerir cuenta contable: como vimos en el Módulo 2, sobre el detalle de las líneas.
Flaggear inconsistencias: monto total ≠ subtotal + IVA, fecha futura, RUT mal formado, proveedor desconocido.

Un prompt típico para este paso:

Sos un asistente de un contador colombiano. Te paso el JSON crudo 
extraído por OCR de una factura. Tu trabajo:

1. Normalizar fechas a formato ISO (YYYY-MM-DD).
2. Normalizar montos a punto decimal y sin miles.
3. Validar que subtotal + IVA = total (tolerancia $1 COP por redondeo).
4. Sugerir cuenta contable de mi plan adjunto.
5. Devolver confidence_global = min(OCR confidence, tu confianza).
6. Marcar issues como array si hay inconsistencias.

JSON OCR: { ... }
Plan de cuentas: { ... }

Devolveme JSON estructurado con los campos normalizados + 
'issues' + 'cuenta_sugerida' + 'confianza_clasificacion'.

Paso 3: Reglas de negocio

Sobre la salida normalizada del LLM se aplican reglas específicas de tu firma o de tu cliente. Esto NO es trabajo de IA: es lógica determinística que tu sistema (n8n, Make, un script) ejecuta.

Ejemplos de reglas típicas:

Si el monto es > $X y no hay orden de compra asociada → flag para CFO.
Si el proveedor no está en el maestro → flag para alta de proveedor.
Si la cuenta sugerida es "gastos de representación" y el monto > límite mensual → flag para revisión gerencial.
Si la factura es de retención de IVA y no se aplicó la retención → flag urgente.
Si la factura es duplicada (mismo proveedor + número) → rechazar.

Paso 4: Routing inteligente para revisión humana

Aquí está la clave de la eficiencia: no todas las facturas van a revisión humana. Tu sistema rutea según confidence + reglas:

Escenario	Acción
Confidence global > 95% + sin flags	Auto-ingreso al sistema contable
Confidence global 80-95% sin flags	Ingreso con marca de "low confidence — revisar muestra"
Confidence < 80% o cualquier flag	Cola de revisión humana
Factura ilegible (OCR confidence < 50%)	Rechazo automático, pedir nueva foto al usuario

🎯 Resultado típico

De 500 facturas físicas procesadas:

~350 ingresan automáticamente sin intervención humana.

~100 ingresan con marca "low confidence" (muestra a auditar después).

~45 van a revisión humana detallada por baja confianza o flags.

~5 se rechazan porque son ilegibles o duplicadas.

Tu junior contable revisa los 45 dudosos (15-30 minutos) en lugar de los 500 originales (15-25 horas).

Manejo de casos especiales

Notas de crédito

Las notas de crédito son una pesadilla del OCR genérico porque:

A veces vienen con el mismo formato que una factura, pero deberían restar.
Otras veces tienen leyendas como "NOTA CRÉDITO" o "CRÉDITO FISCAL" que el OCR puede no marcar como tipo de documento.
Suelen referenciar una factura original que tenés que cruzar.

Cómo ayuda el LLM:

Si el documento contiene alguna de estas frases ("NOTA DE CRÉDITO", 
"NOTA CRÉDITO", "CRÉDITO FISCAL", "DEVOLUCIÓN") en el texto extraído, 
clasificalo como tipo = "credit_note" y aplicá monto negativo. 
Si referencía una factura previa, extraé el número en 
'related_invoice_number'.

Esto es una reglilla simple pero el LLM la aplica con contexto. Un parser regex se rompe; un LLM razona.

Recibos POS / tickets sin formato estándar

Tickets de restaurantes, supermercados, gasolineras: cada cadena tiene un formato distinto.

Estrategia: usar un OCR genérico (no el modelo "factura") + LLM que reconoce el patrón.

Los datos clave a extraer:

Nombre del establecimiento + tax ID (si lo tiene)
Fecha y hora
Monto total
IVA (si se discrimina)
Concepto general inferido por el LLM ("combustible", "restaurante", "supermercado")

Para gastos menores, a veces la cuenta contable la decide el LLM directamente ("Mucho/poco probable que sea gasto deducible", "Gasto de representación / Movilidad / Insumos").

Facturas en otros idiomas

Si tu cliente tiene operaciones internacionales (compra software a USA, paga proveedores en Europa), vas a recibir facturas en inglés, portugués, francés.

Los OCR mencionados manejan español/portugués/inglés sin problema. El LLM además traduce conceptos y convierte moneda si tiene el tipo de cambio del día.

Facturas degradadas (la verdad incómoda)

Si la factura está realmente mala — tinta corrida, foto borrosa, ángulo imposible — ningún proveedor del mundo te la va a leer bien. Hay tres caminos:

Rechazo automático: si OCR confidence global < 50%, el sistema responde al usuario "no se pudo procesar, por favor enviar mejor foto".
Revisión humana directa: el junior la ingresa a mano.
Recuperación del original: si el proveedor todavía existe, pedir el XML/CFDI/DTE original.

🔑 Política clave para tu firma

Definí umbrales explícitos: confidence X → auto-ingreso. Confidence Y → revisión. Confidence Z → rechazo.

No los dejes "implícitos". Tu equipo (y tu auditor externo, si lo tenés) debe poder explicar exactamente qué hizo la IA en cada caso. Esto es trazabilidad — exigencia de NIA 315 y de cualquier auditoría seria.

Comparativa rápida para elegir proveedor

Si tu firma...	Probá primero
Vive en Google Workspace	Google Document AI
Vive en Microsoft 365 / Azure	Azure Form Recognizer
Vive en AWS o tiene devs AWS	AWS Textract
Quiere empezar rápido sin cloud-pro	Mindee
Tiene volumen alto de cuentas por pagar	Klippa DocHorizon

En la práctica, podés combinarlos. Hay firmas que usan Document AI para invoices CFDI mexicanas (calidad alta, ya optimizado) y Mindee para tickets de gastos (más flexible con formatos variados).

💡 Recomendación honesta

No empieces eligiendo proveedor. Empezá por definir tu workflow y volumen. Después probá 2 o 3 proveedores con una muestra de tus documentos reales (50-100 facturas). El que dé mejor precisión sobre tus documentos gana — no el que tenga mejores benchmarks en marketing.

El patrón ganador aplicado a facturas físicas

Document AI (OCR)  →  LLM (normaliza + clasifica)  →  Reglas 
                   →  Routing por confidence  →  Revisión humana 
                                                  (solo flaggeados)

Notá que el patrón es el mismo que vimos en el Módulo 1 y en la Lección 7. Solo cambian las herramientas concretas. Si entendés el patrón, entendés cualquier caso contable asistido por IA.

Próximos pasos

Hasta acá tenés los datos extraídos y limpios. Pero la pregunta crítica todavía no la resolvimos: ¿coinciden con el libro contable?

En la Lección 9 vamos a cerrar el loop. Vas a aprender a conciliar las facturas procesadas con IA contra tu libro contable existente: detectar montos diferentes, fechas movidas, RUT/RFC mal cargados, y armar el reporte de excepciones para el contador senior o auditor.

💡 Tarea opcional antes de continuar

Buscá 5 facturas escaneadas que tengas a mano (puede ser de tus gastos personales del mes). Subilas a un OCR gratuito (Google Document AI tiene tier de prueba, Mindee también).

Compará lo que el OCR extrajo vs lo que vos leerías. ¿Qué campos salieron bien? ¿Cuáles fallaron? ¿Por qué?

Hacer este ejercicio en chico te da intuición real sobre qué esperar en escala.

Próxima lección: 09. Conciliar OCR con libro contable