📌 En resumen
Un OCR convierte la imagen en texto; un sistema de extracción documental inteligente decide además qué significa cada fragmento. Con pocos proveedores y PDF nativos estables, un OCR con plantillas y validaciones aritméticas es suficiente y más barato de depurar. Con muchos formatos, escaneos o líneas de detalle irregulares, mantener plantillas cuesta más que usar modelos. La decisión se toma midiendo con vuestras facturas.
Cuando una empresa se plantea automatizar la entrada de facturas, la conversación técnica se reduce casi siempre a esta elección. Y se suele resolver mal, en las dos direcciones: proyectos que se atascan manteniendo plantillas para ciento veinte proveedores, y proyectos que pagan un servicio de extracción avanzada para leer seis PDF idénticos al mes. Lo que sigue son los criterios para decidirlo con datos.
Qué hace un OCR y dónde se queda
Un motor de OCR recibe una imagen y devuelve texto con sus coordenadas. Es una tecnología madura y muy buena en lo suyo: con un escaneo decente, la transcripción de caracteres es fiable. Lo que no hace es entender el documento. No sabe que ese número de arriba a la derecha es el número de factura ni que esa tabla del centro son las líneas de detalle. Esa interpretación hay que dársela, y la forma clásica de hacerlo es con plantillas: para este proveedor, el total está en esta zona de la página.
El coste de ese enfoque no está en programarlo, está en mantenerlo. Cada proveedor nuevo es una plantilla nueva y cada rediseño de factura rompe la existente en silencio, normalmente descubierto porque un importe raro llegó al ERP.
Qué añade la extracción documental inteligente (IDP)
Los servicios de extracción documental incorporan modelos entrenados con muchísimas facturas, así que generalizan: identifican los campos habituales sin que nadie les diga dónde están, y manejan tablas con estructura variable. Los proveedores cloud más habituales en proyectos españoles ofrecen modelos preentrenados específicos de factura, además de la posibilidad de entrenar uno con vuestros documentos si tenéis un caso muy particular.
También resuelven un problema previo que el OCR no toca: clasificar. Si en el buzón entran facturas, albaranes, notas de abono y algún contrato, primero hay que separar cada documento por tipo. Ese paso de clasificación es exactamente el que resolvimos con modelos de lenguaje y OCR en el escenario tipo de back-office documental de una entidad financiera.
| Criterio | OCR + reglas y plantillas | IDP (extracción con modelos) |
|---|---|---|
| Nº de proveedores distintos | Cómodo hasta unas pocas decenas | Escala sin límite práctico |
| Formatos irregulares y escaneos | Frágil | Diseñado para eso |
| Líneas de detalle en tablas | Difícil si la tabla varía | Su mayor ventaja |
| Coste por documento | Prácticamente cero | Por página o por llamada |
| Coste de mantenimiento | Alto: una plantilla por formato | Bajo |
| Depuración cuando falla | Muy transparente | Menos transparente: hay que revisar confianza por campo |
| Datos fuera de vuestra infraestructura | No, si corre en vuestro entorno | Sí, salvo despliegue local |
Cómo medir el acierto sin engañarse
La cifra de precisión que aparece en un folleto comercial no sirve para decidir. Lo que hay que medir, con una muestra de vuestras propias facturas, es el acierto por campo y por tipo de documento. Un sistema que extrae el total correctamente en el 99% de los casos pero acierta las líneas de detalle en el 70% es perfectamente útil si no cotejáis contra pedido, e inservible si lo hacéis.
- 1Coged una muestra representativa: unas cien facturas del último trimestre, incluyendo los proveedores problemáticos, no solo los buenos.
- 2Etiquetad manualmente los campos correctos de esa muestra: es el trabajo aburrido que hace que todo lo demás sea medible.
- 3Pasad la muestra por las dos opciones y comparad campo a campo, no documento a documento.
- 4Calculad qué porcentaje iría a revisión humana con cada opción y cuánto tiempo cuesta resolver una excepción.
- 5Multiplicad por vuestro volumen mensual: ahí aparece el coste real de cada alternativa, mantenimiento incluido.
💡 Consejo
Un umbral de confianza bien puesto vale más que unos puntos de precisión. Si el sistema marca como dudoso lo que no está seguro de haber leído, una persona resuelve esa factura en segundos. Si no lo marca, el error entra en la contabilidad y se descubre en el cierre.
La decisión práctica, en tres escenarios
- Pocos proveedores, PDF nativos estables, sin cotejo de líneas: OCR con plantillas y validación aritmética. Barato y suficiente.
- Muchos proveedores, mezcla de formatos, cotejo contra pedido: extracción con modelos, más reglas de negocio y cola de excepciones.
- Documentos mezclados que además hay que clasificar (facturas, albaranes, abonos): clasificación con modelos primero, extracción después. El OCR solo no llega.
En los tres casos, la parte que no cambia es la de después: validar contra reglas duras, cotejar, volcar al sistema de gestión y dejar las excepciones en una cola con responsable. La tecnología de extracción decide el coste y el porcentaje de excepciones; el diseño del proceso decide si el sistema es fiable.
Preguntas frecuentes
¿Qué diferencia hay entre OCR e IDP?
El OCR convierte píxeles en texto: te devuelve las palabras y su posición, pero no sabe qué significan. El IDP (extracción documental inteligente) añade una capa de modelos que identifica qué fragmento es el número de factura, cuál el proveedor y cuáles las líneas de detalle, incluso si cada proveedor coloca esos datos en un sitio distinto. En la práctica, casi todos los sistemas útiles combinan las dos cosas y añaden reglas de negocio encima.
¿Cuándo basta un OCR con reglas?
Cuando los documentos son pocos, previsibles y estables: un puñado de proveedores que siempre mandan el mismo PDF nativo con el mismo diseño. En ese escenario, una plantilla por proveedor con posiciones fijas y validaciones aritméticas funciona muy bien, es barata y es fácil de depurar cuando algo falla. El problema aparece cuando el proveedor cambia el diseño de su factura sin avisar.
¿Cuándo hace falta IDP?
Cuando la variedad de formatos crece, cuando aparecen escaneos y fotos de móvil, o cuando hay que extraer líneas de detalle de tablas con estructura irregular. Mantener plantillas para cien proveedores distintos es más caro que usar un modelo que generaliza. También cuando el proceso incluye documentos mezclados: facturas, albaranes y notas de abono en el mismo buzón, que primero hay que clasificar.
¿Qué tasa de acierto es realista?
La pregunta correcta no es la tasa global, es la tasa por campo y por tipo de documento. Los campos de cabecera de un PDF nativo se extraen con una fiabilidad muy alta; las líneas de detalle de un escaneo torcido, bastante menos. Lo único que da una respuesta fiable es medirlo con una muestra de vuestras facturas reales antes de comprometer el alcance, y diseñar contando con que un porcentaje irá a revisión humana.
¿Es más caro el IDP?
El coste por documento suele ser mayor, porque estos servicios se facturan por página o por llamada, pero el coste total del proyecto no necesariamente: con muchos formatos, el mantenimiento de plantillas de un OCR clásico se come la diferencia. El cálculo hay que hacerlo con vuestro volumen mensual y vuestro número de proveedores distintos, no en abstracto.
¿Se pueden usar modelos de lenguaje generalistas para leer facturas?
Se puede, y para casos acotados funciona sorprendentemente bien, pero hay dos cosas que revisar antes: qué pasa con los datos que enviáis al servicio (una factura contiene datos de terceros) y qué garantía de formato tiene la respuesta. Para un proceso contable que debe cuadrar al céntimo, un modelo que ocasionalmente inventa un dígito es un riesgo distinto al de un motor que dice "no he podido leer esto". Por eso la validación aritmética y la cola de excepciones no son opcionales, sea cual sea la tecnología.
Siguiente paso recomendado
Automatización de facturas con OCR
Captura, extracción OCR, validación, cotejo con el pedido y volcado al ERP de las facturas recibidas, con cuadro de excepciones.
Sin compromiso · Respuesta en < 24h
Autor
Fundador y Consultor de Datos e IA
David Aldomar es fundador y consultor principal de MERIDIAN Data & IA, consultora especializada en ayudar a pymes y empresas medianas en España a tomar mejores decisiones con sus datos. Su trabajo se centra en cuatro áreas: diseño e implantación de plataformas de datos (data warehouses, pipelines ETL con dbt, integración de ERPs y CRMs), reporting y dashboards ejecutivos en Power BI, automatización de procesos de negocio con herramientas como n8n, y desarrollo de soluciones de inteligencia artificial aplicada — desde modelos de forecasting de demanda hasta copilots internos basados en RAG con LangChain y FastAPI. Ha liderado proyectos en sectores como logística y transporte, retail y distribución, servicios financieros, manufacturing y construcción, siempre con un enfoque pragmático: diagnóstico corto, entregables concretos y transferencia de conocimiento al equipo del cliente para que sea autónomo desde el primer día. Antes de fundar MERIDIAN, trabajó como ingeniero de datos y BI en entornos empresariales reales: arquitecturas Data Warehouse por capas (Bronze/Silver/Gold), pipelines ETL/ELT en AWS (S3, Glue, Redshift Serverless, Athena) y stacks Microsoft (SQL Server, Power BI, Azure), integrando fuentes tan dispares como ERPs, CRMs y bases de datos operacionales — PostgreSQL, MariaDB — en una única fuente fiable para negocio, finanzas y reporting. Tiene un Máster en Ciencia de Datos e Ingeniería del Dato en la Nube. Su filosofía es que un buen proyecto de datos no se mide por la tecnología que usa, sino por las decisiones de negocio que permite tomar. Escribe regularmente en el blog de MERIDIAN sobre reporting, gobierno del dato, automatización e IA aplicada, con guías prácticas orientadas a responsables de negocio y equipos técnicos de empresas que quieren sacar partido real a sus datos sin depender de grandes consultoras.
Fuentes