OCR para facturas de proveedores: extracción línea a línea sin plantillas

Qué es OCR aplicado a facturas de proveedores

OCR (Optical Character Recognition) es la tecnología que convierte imágenes de texto en texto digital legible por máquina. Aplicado a una factura PDF o escaneada, identifica los caracteres y los presenta como datos estructurables.

Dos enfoques compiten:

• OCR clásico con plantillas: el sistema aprende dónde están los campos (proveedor, fecha, importe) por la posición visual. Funciona si todas tus facturas tienen el mismo layout. Falla en cuanto cambias de proveedor.
• OCR con IDP (Intelligent Document Processing): el sistema entiende semánticamente qué es cada campo independientemente de la posición. Lee "Total: 1.230,00 EUR" o "Importe a pagar: 1.230,00" y entiende que es el mismo dato.

Para una pyme con 50-200 proveedores distintos, el OCR sin plantillas (IDP) es la única opción viable. Si tienes que entrenar plantillas a mano, no escala.

OCR vs IDP (Intelligent Document Processing): la diferencia que importa

El OCR puro extrae texto. El IDP extrae significado. Aquí lo explicamos en detalle, pero el resumen práctico para cuentas a pagar son ocho dimensiones donde se decide si una herramienta escala o no:

Dimensión	OCR clásico	IDP moderno
Lectura de texto desde imagen	Sí	Sí
Identificación de campos sin plantilla	No (requiere zona fija)	Sí (semántica del campo)
Extracción línea a línea (descripción, qty, precio)	Limitada o manual	Estructurada, validada
Tolerancia a layouts variables entre proveedores	Baja ( falla al cambiar de plantilla	Alta ) el modelo generaliza
Soporte multi-formato (PDF, FacturaE, Factur-X, UBL)	Solo imagen / PDF	Detecta formato y elige parser
Validación cruzada de la extracción (suma de líneas = base imponible)	Manual	Automática antes del matching
Cruce con pedido y albarán (three-way matching)	Fuera de alcance	Integrado en el mismo flujo
Mantenimiento operativo por proveedor	Plantillas nuevas cada layout	Cero plantillas, cero mantenimiento

ininvoice usa IDP. Cualquier factura de cualquier proveedor entra y sale con sus datos extraídos sin necesidad de configurar plantillas previas. Cuando una pyme procesa 100-200 proveedores distintos, mantener plantillas a mano deja de ser viable a partir del tercer mes.

El problema del OCR sin matching

Aquí es donde se rompe la propuesta de valor de las herramientas de OCR genéricas. Procys, Klippa, Parseur, Docparser y muchas otras son excelentes extrayendo los datos de un PDF. Pero ahí termina su trabajo.

Si tu pyme procesa 600 facturas al mes y un OCR te las extrae perfectamente, sigues teniendo que:

1. Buscar el pedido de compra correspondiente para cada factura.
2. Verificar que las cantidades facturadas coinciden con las recibidas en el albarán.
3. Verificar que los precios facturados coinciden con los precios del pedido.
4. Detectar si hay duplicados con facturas anteriores.
5. Decidir qué hacer con las que no cuadran.

Eso es el three-way matching. Y esa es la pieza que diferencia ininvoice de un OCR puro: extraemos y conciliamos en el mismo flujo. Aquí explicamos cómo funciona el three-way matching.

Multi-formato: PDF, FacturaE, Factur-X, UBL

El OCR clásico asume PDF o imagen. En 2026-2027, las facturas que recibes en España vendrán en cuatro formatos distintos:

• PDF tradicional: sigue siendo dominante. Necesita OCR.
• FacturaE 3.2.x: XML español con firma XAdES. No necesita OCR (datos ya estructurados), pero sí parser.
• Factur-X: PDF/A-3 con XML embebido. Doble vía: lee el XML primero, OCR como fallback.
• UBL y CII: XML internacional. Parser estructurado.

ininvoice detecta el formato automáticamente. Si llega XML, parsea. Si llega PDF, OCR. Si llega Factur-X, prefiere el XML embebido y usa el PDF visual como verificación. Esto es lo que las herramientas de OCR clásicas no resuelven, porque están diseñadas para imagen, no para datos estructurados.

Más contexto sobre los formatos en el pillar de recepción de factura electrónica obligatoria 2026.

Cómo funciona el OCR de ininvoice

1. Ingesta automática. Conectas Gmail u Outlook (OAuth solo lectura). ininvoice detecta los correos con factura adjunta y los captura sin que muevas un dedo.
2. Detección del formato. El sistema identifica si es PDF, FacturaE, Factur-X, UBL o CII y elige el motor correcto.
3. Extracción línea a línea. Cabecera (proveedor, fecha, número, base, IVA, total) más cada línea individual con descripción, cantidad, precio unitario, descuento e impuesto.
4. Validación cruzada. Cuadra que la suma de las líneas coincide con la base imponible declarada. Si no cuadra, levanta alerta antes de seguir.
5. Búsqueda del pedido. Fuzzy matching del PO por proveedor, fecha, descripciones e importes incluso si la factura no lleva número de pedido.
6. Conciliación. Cruce línea a línea con el pedido y el albarán. Cálculo de varianzas pre-impuestos.
7. Routing. Las que cuadran se exportan al ERP. Las que no se enrutan a la persona responsable.

Fórmulas de validación post-OCR

Extraer los datos no garantiza que sean correctos ni que cuadren con el pedido. ininvoice aplica tres bloques de validación automática sobre la salida del OCR antes de mover una factura al flujo de pago. Son fórmulas auditables, no cajas negras.

1. Varianza de precio (line-by-line, pre-impuestos)

Compara el precio unitario facturado contra el precio unitario del pedido para cada línea, multiplicado por la cantidad facturada:

price_variance = (inv_unit_price − po_unit_price) × inv_qty

Tolerancia por defecto: abs = 1,50 € o pct = 2% (combinador OR). Una línea cae en VARIANCE si cualquiera de las dos dimensiones se excede. La comparación es estricta (>), por lo que el valor exactamente igual al umbral está dentro de tolerancia. Nunca se comparan totales de cabecera: incluyen IVA, agregan inconsistencias y no detectan compensaciones entre líneas.

2. Varianza de cantidad (line-by-line, pre-impuestos)

Compara la cantidad facturada contra la cantidad pedida, valorada al precio unitario del pedido:

qty_variance = (inv_qty − po_qty) × po_unit_price

Una factura puede tener varianza de precio en una línea y varianza de cantidad en otra. El sistema las separa porque la decisión de aprobación es distinta: una subida de precio negociada se aprueba con el responsable de compras; una cantidad facturada por encima de lo pedido se aprueba con el responsable de almacén.

3. Hash de duplicados (multi-criterio)

El OCR es la puerta de entrada por la que más duplicados se cuelan: la misma factura reenviada en dos correos llega dos veces. ininvoice aplica dos firmas en paralelo:

• Hash binario: SHA-256 del PDF tal cual se recibe. Detecta reenvíos idénticos byte a byte.
• Fingerprint normalizado: SHA-256(supplier_tax_id ‖ invoice_number ‖ invoice_date ‖ total_amount). Detecta duplicados con metadatos distintos (reescaneo, resave del PDF, firma añadida) pero misma factura lógica.

Si cualquiera de los dos hashes coincide con una factura ya ingestada, la nueva entra como excepción de duplicado antes de evaluar matching ni pago. Más detalle operativo en cómo detectar facturas duplicadas antes de pagarlas.

El control completo del ciclo —extracción + validación + matching + routing— está descrito en control de facturas de proveedores.

Precisión: qué esperar de un OCR de facturas en producción

La precisión de un OCR moderno para facturas estándar (PDF nítido, layout legible) está en el rango del 95-98% en los campos de cabecera y del 92-96% en líneas individuales según benchmarks públicos del sector.

Las facturas que más errores generan:

• Escaneos antiguos de baja resolución.
• Facturas con sellos manuales encima de los datos.
• Tablas multi-página partidas a mitad de fila.
• Layouts atípicos de proveedores muy concretos.

Con factura electrónica obligatoria, este problema desaparece para los proveedores grandes (>8M EUR) en septiembre de 2026 y se generaliza en 2027. La transición de OCR sobre PDF a parsing de XML es uno de los mayores ahorros operativos del sector.

ininvoice vs OCR genéricos

Capacidad	OCR genérico (Procys/Parseur/Klippa)	ininvoice
OCR sin plantillas (IDP)	Sí	Sí
Multi-formato (PDF + XML)	Mayormente PDF	PDF + FacturaE + Factur-X + UBL + CII
Three-way matching nativo	No	Sí
Detección de duplicados	Limitada	Multi-criterio (proveedor + nº + fecha + importe + hash)
Score de riesgo	No	0-100 por factura
Routing de excepciones	No	Por tipo (precio, qty, duplicado, sin pedido)
Compatibilidad Verifactu	No	Sí
Exportación a ERP español (Holded, Sage, A3)	Variable	Sí
Foco	Extracción genérica de documentos	Cuentas a pagar para pymes ES

Preguntas frecuentes

¿Qué precisión tiene el OCR de facturas de proveedores en producción?

La precisión de un IDP moderno está en el rango 95-98% en campos de cabecera (proveedor, fecha, total) y 92-96% en líneas individuales (descripción, cantidad, precio unitario) sobre PDFs nítidos. Sobre escaneos antiguos baja al 80-90%. Por eso ininvoice valida la suma de líneas contra la base imponible antes de seguir.

¿Cuál es la diferencia entre OCR y IDP?

OCR (Optical Character Recognition) convierte imagen en texto. IDP (Intelligent Document Processing) añade comprensión semántica: identifica qué campo es proveedor, total o línea sin depender de la posición visual. Para facturas con cientos de layouts distintos, IDP es la única opción que escala.

¿Necesito entrenar el OCR con plantillas de cada proveedor?

No. ininvoice usa IDP sin plantillas. Cualquier factura de cualquier proveedor entra sin configuración previa. La precisión mejora marginalmente con uso pero no requiere entrenamiento explícito ni mantenimiento de plantillas por proveedor.

¿Qué pasa si la factura llega en XML (FacturaE, Factur-X, UBL)?

Cuando llega XML estructurado, no se usa OCR. Se parsea directamente y se obtienen los campos con precisión 100%. En Factur-X (PDF/A-3 con XML embebido) se prefiere el XML y se usa el PDF visual solo como verificación. Reduce errores y acelera el procesamiento.

¿Cómo se calcula la varianza de precio y cantidad tras el OCR?

Línea a línea, pre-impuestos: price_variance = (precio_unitario_factura − precio_unitario_pedido) × cantidad_factura. qty_variance = (cantidad_factura − cantidad_pedido) × precio_unitario_pedido. Nunca se comparan totales de cabecera porque incluyen IVA y arrastran inconsistencias.

¿Cómo detecta el sistema facturas duplicadas tras el OCR?

Hash multi-criterio: SHA-256 del PDF para idénticos binarios, más fingerprint normalizado (proveedor + número + fecha + total) para duplicados con metadatos distintos. Una factura reenviada en otro correo se marca como duplicada antes de entrar al flujo de pago.

¿Qué pasa cuando el OCR no consigue leer la factura?

Se marca como excepción de OCR y va a revisión manual. No se procesa con datos parciales ni se asume nada. La tasa típica en producción está por debajo del 2% del volumen total, concentrada en escaneos antiguos de baja resolución y facturas con sellos manuales sobre los datos.

¿Por qué OCR sin matching no resuelve el problema de cuentas a pagar?

Extraer datos es solo el primer paso. Sin three-way matching (cruce factura vs pedido vs albarán), el operativo sigue cuadrando 600 facturas/mes a mano. ininvoice integra OCR + matching + detección de duplicados + routing de excepciones en el mismo flujo, sin saltar entre herramientas. Ver control completo de facturas de proveedores.