IDP vs OCR en facturas de proveedor: por qué el OCR clásico falla en España

Casi todos los proveedores de software contable hablan de "OCR de facturas" como si fuera una sola tecnología. No lo es. Hay dos generaciones y, en facturas españolas, la diferencia se nota cada día.

Si gestionas volumen serio de facturas recibidas (200, 500, 1.500 al mes) con proveedores reales, te has topado con el límite del OCR clásico: factura con IVA 21% y 10% en la misma cabecera, autónomo con retención IRPF, rectificativa en negativo, PDF escaneado desde un móvil.

Este artículo separa qué es OCR, qué es IDP y por qué las particularidades fiscales españolas hacen que el primero no baste para un flujo touchless real.

Qué es OCR (Optical Character Recognition)

El OCR es reconocimiento óptico de caracteres. Toma una imagen y devuelve texto. Punto. Tecnología madura, 30 años: ABBYY, Tesseract, Kofax, módulos integrados en ERPs. Hace lo que hace bien y solo lo que hace.

El pipeline clásico binariza la imagen, detecta zonas de texto, segmenta caracteres, clasifica cada uno contra un diccionario y devuelve cadenas de texto con coordenadas. Funciona bien para digitalizar libros, leer DNIs, capturar matrículas: tareas donde lo único que importa es transcribir caracteres.

Para llegar de "texto plano" a "campos de factura" hace falta una segunda capa: plantillas posicionales o reglas regex sobre el texto extraído. Esto es lo que muchos llaman "OCR para facturas". Técnicamente es OCR + plantillas.

Qué es IDP (Intelligent Document Processing)

La Intelligent Document Processing es la generación siguiente. No solo lee píxeles: entiende el documento. La capa de comprensión semántica usa modelos preentrenados sobre millones de facturas reales (LayoutLM, Donut, modelos multimodales LLM-based, motores comerciales tipo Google Document AI o Amazon Textract Invoices).

Un pipeline IDP combina OCR de base (para PDFs imagen) o parsing nativo (PDF con capa de texto), extracción de campos por contexto semántico (no por posición), comprensión de tablas (filas, columnas, líneas), validaciones cruzadas (suma de líneas = base; base + IVA - IRPF = total) y lectura de XML/FacturaE y QR Verifactu cuando están presentes.

El resultado no es texto plano. Es un objeto estructurado: proveedor con NIF, fecha, número, base, líneas (descripción, cantidad, precio unitario, importe), IVA por tipo, IRPF, total. Listo para ingresar en un ERP o cruzar con un pedido.

Por qué el OCR clásico falla en facturas españolas

España tiene cinco peculiaridades que rompen el OCR clásico más que en otros mercados.

1. IVA múltiple en la misma factura. Una factura de distribuidor de hostelería puede llevar IVA 21% (alcohol, refrescos), 10% (alimentos), 4% (pan, leche, fruta) y exento, en líneas distintas con subtotales. El OCR posicional saca el primer importe de IVA que ve o el total agregado, pero rara vez los tres tipos. La AEAT exige diferenciación por tipo en libros de IVA recibidas: si el OCR colapsa, el modelo 303 queda mal.

2. Retención IRPF en facturas de autónomos y profesionales. Un freelance, asesor o arquitecto emite con retención IRPF (15% general, 7% nuevos profesionales). El IRPF es línea negativa: Base + IVA - IRPF = Líquido. El OCR clásico, configurado para "total = base + IVA", se descuadra. Resultado: campo vacío o erróneo, y el modelo 111 no cuadra.

3. Descuentos pronto pago como línea separada. Distribuidores y mayoristas meten descuentos pronto pago como línea negativa antes del IVA, como descuento sobre total, o como nota a pie con condición ("2% si pagas en 10 días"). El OCR no distingue. El IDP, entrenado en este patrón, sí.

4. Facturas rectificativas. Las rectificativas (RD 1619/2012, art. 15) llevan datos de la factura original con signo negativo o diferencia. El OCR clásico que solo busca "total positivo" se cae. El IDP entrenado las detecta como credit note y maneja el signo.

5. Formatos ERP fragmentados. Conviven decenas de plantillas: Holded, Sage, Quipu, A3, Anfix, Contasol, ERPs verticales, hechas en Word por una microempresa. El OCR posicional necesita una plantilla por proveedor. El IDP generaliza por contexto semántico.

OCR clásico vs IDP: matriz de funcionalidades

Funcionalidad	OCR clásico	IDP
Extrae texto plano de PDF	Sí	Sí
Campos estructurados sin plantilla	No (necesita plantilla por proveedor)	Sí
Detección de líneas y tablas	Limitada	Sí (modelo entrenado)
IVA múltiple en una factura	Confunde tipos o agrega	Separa por tipo
Retención IRPF	Habitualmente vacío o erróneo	Detecta línea negativa de retención
Facturas rectificativas (RD 1619/2012)	Falla en signo	Detecta tipo credit note
Tablas complejas con subtotales	Pierde estructura	Mantiene jerarquía
Manuscritas / notas a mano	Bajo	Mejora con multimodal
FacturaE / XML estructurado	No (ignora XML)	Sí (parsing nativo)
QR Verifactu	No decodifica	Decodifica datos firmados
Validaciones cruzadas internas	No	Sí (base + IVA - IRPF = total)
Precisión media en facturas reales	80-85% [NEEDS-CONFIRM por proveedor]	95-98% [NEEDS-CONFIRM por proveedor]

Precisión real esperable por formato

Los rangos siguientes son orientativos y dependen del proveedor concreto. Márcalos como [NEEDS-CONFIRM] al evaluar tu caso.

Formato	OCR clásico (precisión campos)	IDP (precisión campos)	Nota
PDF generado digitalmente (capa texto)	85-92%	96-99%	El IDP parsea texto nativo, no necesita OCR
PDF escaneado limpio (300 dpi)	78-87%	92-97%	Aquí el OCR base trabaja para los dos
JPG foto móvil	55-72%	85-93%	IDP multimodal aguanta deformación y luz
FacturaE XML	0% (no lo lee)	99%+ (parsing directo)	El XML va firmado: más fiable que cualquier OCR
Factura manuscrita	20-45%	60-78%	Sigue siendo el peor caso, pero IDP gana márgen

Las cifras anteriores son rangos de mercado, no números de proveedor concreto. [NEEDS-CONFIRM] con benchmark sobre tus propias facturas. Marcos de referencia útiles: IOFM benchmarking.

Cuándo OCR clásico es suficiente

No todo proyecto necesita IDP. Hay casos donde el OCR clásico más plantillas resuelve bien:

• Volumen bajo: menos de 50 facturas/mes con plantillas estables.
• Pocos proveedores: 5-10 fijos que no cambian formato.
• Sin IVA múltiple: una sola tasa por factura.
• Sin IRPF: empresa que solo recibe facturas de sociedades, no de profesionales.
• Sin three-way matching: contabilidad pura sin cruce con pedidos ni albaranes.
• Sin presión regulatoria: Verifactu no se aplica todavía, no hay SII en la empresa.

Si tu caso encaja, no inviertas en IDP. Es overkill.

Cuándo necesitas IDP

Si reconoces tres o más de estos patrones, OCR clásico se queda corto:

• Volumen 100-2.000 facturas/mes.
• 50+ proveedores activos con formatos heterogéneos.
• Mezcla de sociedades y autónomos (IRPF en juego).
• Sectores con IVA múltiple en una misma factura: distribución alimentaria, hostelería, retail.
• Three-way matching línea a línea con pedido y albarán.
• Rectificativas habituales o descuentos por volumen y pronto pago.
• Verifactu activo en proveedores y/o SII en tu empresa.
• Mezcla de PDFs digitales, escaneos y FacturaE XML adjunto.

Este es exactamente el ICP de ininvoice: PYMES con 100-2.000 facturas/mes en distribución, construcción, hostelería multi-local, retail y manufactura ligera.

IDP y three-way matching

El three-way matching cruza factura, pedido y albarán a nivel de línea. La precisión línea a línea es crítica: si la línea de factura no se extrae bien (descripción, cantidad, precio unitario), el cruce con la línea de pedido es imposible.

El OCR clásico colapsa líneas con frecuencia: confunde líneas adyacentes, pierde la cantidad, mete el descuento dentro del precio. Resultado: el matcher dispara variances ficticios y el equipo termina contrastando a mano. Vuelta al re-keying.

El IDP entrega líneas limpias: descripción, cantidad, precio unitario pre-tax, importe. Sobre eso, el matcher calcula varianza de precio ((inv_unit_price - po_unit_price) * inv_qty) y varianza de cantidad ((inv_qty - po_qty) * po_unit_price). En ininvoice, tolerancia 2% relativo o 1,50€ absolutos por línea, modo OR. Detalle en three-way matching y conciliación de facturas y albaranes.

IDP, Verifactu y Peppol BIS

Hay un atajo que el OCR clásico no usa: cuando el dato viene firmado al origen, ya no hace falta extraerlo, basta con leerlo.

• Verifactu añade un código QR a cada factura emitida en modo verificable. El QR contiene NIF emisor, número, importe total, fecha. Datos oficiales firmados por la AEAT del proveedor.
• FacturaE XML entrega todos los campos estructurados firmados.
• Peppol BIS (más en EU/B2G internacional) entrega el mismo XML estructurado por la red Peppol.

El IDP moderno prioriza estos canales: si hay XML, se parsea; si hay QR, se decodifica; el PDF queda como fallback. Es lo opuesto a la lógica del OCR clásico, que parte siempre del píxel. Cubrimos el impacto en compliance en Verifactu y cuentas a pagar.

Checklist para evaluar tu stack actual

Diez preguntas que un DAF puede responder hoy mismo, sin pedir demos nuevas:

1. ¿Cuántos proveedores activos tienes? ¿Cuántos formatos distintos de factura llegan al mes?
2. ¿Tu sistema actual extrae el IVA por tipo cuando hay 21%, 10% y 4% en la misma factura?
3. ¿Captura la retención IRPF de facturas de autónomos sin tecleo manual?
4. ¿Detecta facturas rectificativas y pone el signo correcto en contabilidad?
5. ¿Lee FacturaE XML cuando el proveedor lo adjunta, o solo el PDF?
6. ¿Decodifica el QR Verifactu de las facturas que ya lo llevan?
7. ¿Saca líneas con descripción, cantidad y precio unitario, listas para three-way matching?
8. ¿Cuál es la tasa real de "factura aprobada sin tocar humano" en tu flujo? ¿30%? ¿70%?
9. ¿Cuántas horas/mes dedica el equipo administrativo a corregir extracciones?
10. ¿Cuándo fue la última vez que mediste la precisión del extractor sobre una muestra real?

Si la respuesta a las preguntas 2-7 incluye varios "no" o "no sé", estás pagando OCR clásico aunque la factura del proveedor lo llame "AI" o "Smart Capture".

Preguntas frecuentes

¿El OCR de mi ERP es suficiente para facturas españolas?

Depende del volumen y la mezcla. Para 30 facturas/mes de 5 proveedores estables, sí. Para 300 facturas/mes con autónomos, IVA múltiple y rectificativas, normalmente no. Si más del 20% necesita retoque manual, el OCR clásico se ha quedado corto.

¿Tesseract vale para facturas?

Tesseract es un excelente OCR open source para texto plano. Para facturas hace falta añadir encima detección de campos, comprensión de tablas, validaciones y parsing XML. Eso es ingeniería equivalente a un IDP propio. La mayoría de PYMES no puede permitírselo.

¿IDP requiere entrenar modelos con mis facturas?

No necesariamente. Los IDP modernos vienen preentrenados y generalizan bien sin fine-tuning específico. Para sectores muy verticales, el fine-tuning puede sumar 1-3 puntos de precisión. [NEEDS-CONFIRM con proveedor].

¿Funciona con facturas escaneadas de baja calidad?

Sí, con caveats. La precisión cae respecto al PDF digital pero queda por encima del OCR clásico sobre el mismo escaneo. Si tu flujo recibe muchos móviles, IDP marca la diferencia.

¿Y con facturas manuscritas?

Es el caso más difícil. Los IDP multimodales recientes suben respecto al OCR clásico, pero esperar 100% es irreal. Conviene mantener un revisor humano y reservar el touchless para formatos limpios.

¿Qué usa ininvoice exactamente?

IDP de invoice processing más parsing nativo de FacturaE/XML, decodificación de QR Verifactu y validaciones cruzadas (base + IVA - IRPF = total). Sobre la salida limpia, three-way matching línea a línea con tolerancia 2% / 1,50€ OR-mode. Exporta a Holded, Sage, A3. Detalle en funcionalidades.

¿Y Google Document AI o Amazon Textract?

Son IDP (no OCR clásico) y están entre los mejores motores de mercado. Son APIs: hace falta integrarlas con un flujo AP completo (ingesta, three-way matching, excepciones, exportación, conservación). Una PYME que no quiere construir software usa solución llave en mano.

Tres cosas para recordar

1. OCR clásico e IDP no son lo mismo. Uno extrae texto plano. El otro entiende el documento. Las facturas españolas (IVA múltiple, IRPF, rectificativas, FacturaE) son el caso donde la diferencia se nota.
2. OCR clásico ronda el 80-85% en datos de línea sobre facturas reales. IDP llega al 95-98% en formatos estándar y supera el 99% cuando hay XML/FacturaE adjunto.
3. Para three-way matching línea a línea, la precisión por línea es la métrica clave. Sin líneas limpias, variances falsos y vuelta al tecleo.

Si quieres ver el cambio sobre tus facturas, prueba ininvoice. También precio y funcionalidades.

Contenido relacionado

• Three-way matching: cómo cruzar factura, pedido y albarán línea a línea
• Touchless accounts payable: qué significa y cómo medirlo
• Conciliación de facturas y albaranes
• Verifactu y cuentas a pagar: por qué obliga a replantear la automatización
• Cómo detectar facturas duplicadas antes de pagarlas
• Funcionalidades de ininvoice