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-idioma y multi-moneda	Limitado	Sí, sin configuración por proveedor
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.

Formatos de factura que vas a recibir en 2026-2027

El OCR clásico asume PDF o imagen. Con la factura electrónica, en España vas a recibir facturas en varios formatos distintos:

• PDF tradicional: sigue siendo dominante. Necesita OCR.
• Imagen y escaneo: foto del móvil, escáner de oficina. Necesita OCR.
• FacturaE 3.2.x: XML español con firma XAdES. Datos ya estructurados.
• Factur-X, UBL y CII: formatos con datos estructurados, español e internacional.

ininvoice trabaja hoy con PDF e imagen: extrae los datos con OCR sin plantillas y los normaliza. Lo que resuelve para ti como receptor no es el formato en sí, sino el control de lo que recibes: cruce con pedido y albarán, detección de duplicados, validación fiscal y trazabilidad. Ese control es el trabajo que hoy nadie hace a mano, llegue la factura en PDF o estructurada.

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 por OAuth. ininvoice revisa el correo en minutos, detecta los adjuntos con factura y los captura sin que muevas un dedo.
2. Lectura del documento. ininvoice procesa el PDF o la imagen con OCR sin plantillas y normaliza el texto (idioma, moneda, formato de fecha).
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 quedan aprobadas y listas para exportar. 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 es alta sobre facturas estándar (PDF nítido, layout legible) y cae en cuanto la imagen se complica. Ninguna extracción automática es perfecta, así que lo que importa es qué pasa después: ininvoice envía a revisión humana cualquier dato por debajo de un umbral de confianza configurable y nunca pasa un dato dudoso a la contabilidad.

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í
Formatos de entrada	Mayormente PDF	PDF, imagen y foto de móvil, sin plantilla
Three-way matching nativo	No	Sí
Detección de duplicados	Limitada	Multi-criterio (proveedor + nº + fecha + importe + hash)
Validación fiscal (IVA, IRPF, NIF)	No	Sí
Routing de excepciones	No	Por tipo (precio, qty, duplicado, sin pedido)
Historial de auditoría por factura	No	Sí
Exportación con audit trail	Variable	Sí (Excel con hoja de auditoría)
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?

Ninguna extracción automática es perfecta: la calidad es alta sobre PDFs nítidos y baja con escaneos antiguos, sellos manuales o layouts atípicos. Por eso ininvoice valida la suma de líneas contra la base imponible y envía a revisión humana cualquier dato por debajo de un umbral de confianza configurable, antes de pasarlo a la contabilidad. Nunca se aprueba un dato dudoso de forma automática.

¿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 un formato electrónico estructurado?

ininvoice trabaja hoy con PDF e imagen. Llegue la factura en PDF o en un formato estructurado, lo que ininvoice aporta como receptor es el mismo control: cruza la factura con su pedido y su albarán, detecta duplicados, valida los datos fiscales y deja trazabilidad. No promete validación estructurada del XML ni archivo legal del fichero.

¿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.