OCR de facturas de proveedores: por qué falla y cómo hacerlo bien

Cargar facturas de proveedores a mano es el trabajo administrativo más automatizable que existe: alto volumen, reglas claras, cero criterio creativo. Y sin embargo es donde más proyectos se caen a mitad de camino.

No se caen por el OCR. El reconocimiento de texto es un problema resuelto hace años. Se caen por todo lo demás.

Lo que rompe un pipeline de OCR en producción

Cada proveedor tiene su diseño. Y lo cambia sin avisar. Un sistema que aprende "el CUIT está arriba a la derecha" funciona hasta que llega la factura de una empresa que lo pone abajo del logo, y después hasta que ese mismo proveedor rediseña su plantilla en enero.

Los escaneos de verdad son horribles. La demo se hace con un PDF nativo. Lo que llega es una foto sacada con el celular, torcida, con sombra, con el sello de recibido tapando la mitad del número de comprobante, reenviada por WhatsApp y comprimida dos veces.

Las tablas. Extraer un total es fácil. Extraer los renglones de una factura con dieciséis ítems, donde una descripción ocupa dos líneas y hay un subtotal en el medio, es donde se pierde la mayoría del tiempo de desarrollo.

Los que no son facturas. En el mismo mail llegan remitos, notas de crédito, órdenes de compra y una imagen del logo del proveedor en la firma. El sistema tiene que clasificar antes de extraer, y equivocarse ahí contamina todo lo que viene después.

Los duplicados. La misma factura llega por mail, la trae el repartidor en papel, y el proveedor la vuelve a mandar porque no le contestaron. Sin detección de duplicados, terminás pagando dos veces — y ese es exactamente el error que la automatización debía evitar.

Cómo se construye uno que aguanta

Clasificar antes de extraer

El primer paso no es leer: es decidir qué documento es. Factura, nota de crédito, remito, otra cosa. Cada tipo tiene su propio extractor y sus propias reglas de validación. Mezclar todo en un único prompt gigante es la forma más rápida de tener un sistema que anda el 80% de las veces y nadie sabe por qué falla el resto.

Extraer con el layout, no solo con el texto

El OCR clásico devuelve texto plano y pierde la información espacial, que es justamente la que dice qué número corresponde a qué campo. Los modelos actuales de visión leen la página con su geometría: entienden que ese número está en la columna "Importe" y en la fila del ítem 3.

Esto es lo que hace que el sistema tolere que cada proveedor tenga su diseño, en lugar de necesitar una plantilla por proveedor.

Validar contra la realidad, no contra el modelo

Esta es la parte que separa un experimento de un sistema productivo. Cada campo extraído se verifica contra algo que ya sabés:

• ¿El CUIT existe y corresponde a un proveedor dado de alta?
• ¿Los renglones suman el subtotal? ¿El subtotal más el IVA da el total?
• ¿La alícuota es una de las posibles?
• ¿El número de comprobante ya lo procesamos?
• ¿El importe está dentro del rango histórico de ese proveedor?

Cuando la aritmética cierra, la confianza no depende de que el modelo diga que está seguro: depende de que los números cuadren. Es una verificación objetiva y es lo que permite aprobar automáticamente.

Definir el umbral y la cola de excepciones

Ningún sistema serio aprueba el 100% sin mirar. Se define un umbral: lo que valida limpio entra solo; lo que no, cae en una cola donde una persona ve el documento al lado de los datos extraídos y corrige en diez segundos.

El objetivo realista es 80–90% automático. Ese 10–15% restante no es un fracaso: es el diseño. Y prometer 100% es la señal más confiable de que quien te está vendiendo no puso nunca uno de estos en producción.

Cerrar el círculo

Cada corrección que hace la persona en la cola tiene que volver al sistema como señal. Si un proveedor siempre necesita el mismo arreglo, eso es una regla nueva, no una molestia recurrente.

Lo que aprendimos construyendo esto

En Fily procesamos documentos escaneados en producción, y las dos lecciones que más nos costaron son contraintuitivas.

La primera: el tamaño de una imagen sale de su rectángulo en la página, jamás de contar píxeles. Suena a detalle técnico menor y es la diferencia entre un documento reconstruido que se parece al original y uno que se parece a un rompecabezas mal armado.

La segunda: cuando un documento falla, el mensaje de error casi nunca dice la verdad. Hay que mirar el resultado del pipeline, no la excepción que quedó registrada. Un sistema de OCR sin buena observabilidad es un sistema que nadie puede arreglar.

El retorno

Los números que solemos ver en un área de cuentas a pagar que procesa varios cientos de facturas por mes: 60–75% menos de tiempo administrativo, y algo menos visible pero más valioso, la desaparición de los errores de tipeo en importes y CUIT — que son los que después cuestan una conciliación entera.

El proyecto típico son cuatro a seis semanas, y la parte lenta no es el OCR: es acordar qué se hace con los casos raros.

Si tenés el proceso de carga de comprobantes en la cabeza mientras leés esto, contanos cómo funciona hoy y te decimos qué porcentaje es realista automatizar en tu caso.