De la factura en PDF al dato en el ERP sin teclearla

En casi todas las empresas medianas hay alguien que dedica varias horas a la semana a mirar un PDF y teclear lo que pone en otra pantalla. Facturas de proveedor, albaranes, pedidos que llegan por correo, partes de trabajo firmados a mano. La extracción de datos de documentos —lo que muchos llaman simplemente "OCR de facturas"— consiste en que ese trayecto, del papel o el PDF al campo del ERP, deje de hacerse a mano. No es magia ni es nuevo: lo nuevo es que hoy funciona con documentos que no siguen una plantilla fija, que es justo donde fallaban las soluciones de hace diez años.

Este artículo cuenta cómo montarlo de verdad: qué documentos compensan, en qué se diferencia el OCR de la extracción, qué tasa de error es aceptable, cómo se diseña la validación humana para que no se convierta en el cuello de botella, y cómo se conecta al ERP sin romper el circuito contable que ya funciona.

¿Qué es la extracción de datos de documentos y en qué se diferencia del OCR?

Son dos capas distintas y confundirlas es el origen de la mitad de los proyectos que decepcionan.

• OCR (reconocimiento óptico de caracteres) convierte una imagen en texto. Te dice que en el documento pone "TOTAL 1.234,56 €", con sus coordenadas. Nada más. Un PDF nativo generado por un ERP ni siquiera necesita OCR: el texto ya está dentro.
• La extracción decide que ese 1.234,56 es el importe total de la factura, que el CIF que aparece arriba a la izquierda es el del emisor y no el tuyo, y que las doce filas del centro son líneas de detalle con su cantidad, precio unitario e impuesto.

El salto está en la segunda capa. Durante años se resolvía con plantillas: se dibujaba una zona en el documento del proveedor X y se leía siempre ahí. Funciona mientras el proveedor no cambie el diseño, no añada una página de portada y no tengas 400 proveedores distintos. Los modelos actuales de extracción trabajan sobre el layout y el contexto —entienden que "N/Factura" y "Nº doc." apuntan a lo mismo— y generalizan a documentos que no vieron durante el entrenamiento. Por eso hoy la pregunta ya no es "¿tenemos plantilla de este proveedor?", sino "¿qué hacemos con lo que el modelo no tiene claro?".

Hay una tercera capa que casi nadie menciona en la demo y que es la que da valor: la validación de negocio. Que el total cuadre con la suma de líneas más impuestos, que el CIF exista en el maestro de proveedores, que el número de albarán referenciado esté recibido, que la factura no esté ya contabilizada. Un dato extraído perfectamente pero que no cuadra con tu pedido sigue siendo un problema para contabilidad.

¿Qué documentos compensa automatizar primero?

El criterio no es cuál es más molesto, sino dónde se cruzan volumen, repetición y una comprobación automática posible. Esta tabla resume cómo lo priorizamos:

| Tipo de documento | Volumen típico | Dificultad | Validación automática disponible | Prioridad | |---|---|---|---|---| | Facturas de proveedor | Alto y recurrente | Media | Sí: casa contra pedido y albarán | Alta | | Albaranes de entrega | Alto | Media-alta (firmas, sellos, escaneos torcidos) | Sí: contra pedido | Alta | | Pedidos de cliente por email o PDF | Medio-alto | Media | Sí: contra catálogo y tarifa | Alta | | Tickets y gastos de empleado | Alto en número, bajo en importe | Alta (fotos, arrugas, térmicos) | Parcial | Media | | Contratos y anexos | Bajo | Muy alta | No | Baja (empezar por resumen, no por extracción) | | Partes de trabajo manuscritos | Variable | Alta | Sí, si hay orden de trabajo | Media | | Documentación de RRHH | Bajo | Media | No | Baja |

Dos lecturas de la tabla. La primera: empieza por donde hay contraparte. Una factura se puede casar contra un pedido y un albarán; si los tres números cuadran, el documento puede pasar solo. Un contrato no tiene contra qué cuadrarse, así que toda la responsabilidad recae en el modelo y en la persona que revisa. La segunda: el volumen manda. Automatizar 30 documentos al mes rara vez paga el mantenimiento; 3.000, casi siempre. Es el mismo criterio de priorización que aplicamos en cualquier proyecto de automatización de procesos con IA.

Si el documento no se puede comprobar contra nada de lo que ya tienes, no estás automatizando un proceso: estás trasladando el riesgo de la persona al modelo.

¿Cómo es el circuito completo, de la bandeja de entrada al ERP?

Un sistema que aguanta en producción tiene siete pasos. El proyecto se cae casi siempre en el 5 y el 6, que son los que no salen en las demostraciones.

1. Captura. Buzón de correo dedicado, carpeta compartida, escáner de oficina, subida desde el móvil o recepción por EDI. Aquí se decide algo importante: qué se hace con el email original y sus adjuntos, porque el correo suele ser la prueba de cuándo llegó el documento. 2. Normalización. Separar adjuntos, convertir a imagen o texto, partir los PDF que traen varias facturas seguidas, girar páginas y descartar hojas en blanco. Este paso aburrido resuelve una parte sorprendente de los errores de lectura. 3. Clasificación. Decidir si el documento es factura, albarán, extracto o publicidad. Sin este paso, el modelo de facturas intenta extraer un total de un catálogo comercial. 4. Extracción. Campos de cabecera (emisor, CIF, número, fechas, base, impuesto, total) y tabla de líneas. Cada campo sale con un valor y un nivel de confianza, que es lo que permite decidir después. 5. Validación de negocio. Cuadre aritmético, existencia del proveedor, casación con pedido y albarán, detección de duplicados, límites de tolerancia por importe o porcentaje. 6. Revisión humana selectiva. Solo los documentos que fallan alguna regla o bajan de un umbral de confianza. El resto pasa directo. 7. Volcado y trazabilidad. Alta en el ERP con el PDF original enlazado y un registro de qué se extrajo automáticamente, qué corrigió una persona y cuándo.

Ese punto 7 es innegociable si el proceso toca contabilidad. Cuando alguien pregunte dentro de un año por qué se contabilizó una factura con la fecha equivocada, la única respuesta aceptable es poder abrir el documento original, ver el valor leído, el valor final y quién lo tocó. Es la misma exigencia de trazabilidad que planteamos en gobierno del dato.

¿Qué tasa de error es aceptable y cómo se mide?

La respuesta honesta: depende del campo, y medir "precisión global del 95 %" no significa nada.

Un documento de factura tiene campos con consecuencias muy distintas. Equivocarse en el importe total o en el CIF genera un asiento mal hecho y una llamada del proveedor. Equivocarse en la descripción de una línea es cosmético. Por eso se mide por campo crítico, no en agregado:

• Precisión por campo: de las facturas procesadas, en cuántas el total, el CIF, el número de factura y las fechas salieron exactos.
• Tasa de automatización (straight-through): qué porcentaje de documentos pasa entero sin que nadie lo toque. Es el número que determina el ahorro real.
• Error que escapa: de los documentos que pasaron solos, cuántos llevaban un dato mal. Este es el importante y el que casi nadie mide, porque exige auditar una muestra periódica de lo que ya pasó.

Un sistema bien calibrado no maximiza la precisión: maximiza la automatización sujeta a un error que escapa cercano a cero en los campos críticos. Se consigue subiendo o bajando el umbral de confianza. Con el umbral muy alto, casi todo va a revisión y no ahorras nada; con el umbral muy bajo, ahorras mucho hasta que aparece la primera factura pagada dos veces.

La forma correcta de arrancar es sin umbral: durante unas semanas el sistema extrae y una persona revisa el 100 %, comparando su corrección con lo propuesto. Ese periodo te da tres cosas: la precisión real por campo con tus documentos, el umbral que puedes permitirte, y el ranking de proveedores problemáticos. No hay sustituto para esa medición; los porcentajes de los folletos se obtienen con documentos que no son los tuyos.

¿Cómo se diseña la validación humana para que no sea el cuello de botella?

Si la persona tiene que abrir el PDF, buscar el campo y compararlo mentalmente con la pantalla, no has automatizado nada: has añadido un paso. La revisión útil cumple tres condiciones.

• Vista única con resaltado. El documento a la izquierda, los campos a la derecha, y al pinchar un campo se ilumina de dónde salió en la página. Sin eso, la revisión tarda más que teclear.
• Solo lo dudoso, no todo el documento. Si únicamente el importe de un impuesto está por debajo del umbral, se pide confirmar ese campo, no los quince.
• La corrección alimenta el sistema. Cada dato corregido debe quedar registrado para reentrenar o para generar una regla específica de ese proveedor. Si a los seis meses seguís corrigiendo lo mismo del mismo emisor, el circuito de aprendizaje no existe.

Añade una cuarta condición organizativa: definir qué pasa con lo que nadie sabe resolver. Documentos ilegibles, proveedores nuevos sin alta, facturas sin pedido asociado. Necesitan una cola propia, un responsable y un plazo; si no, se quedan en un limbo que reaparece en el cierre del mes.

Sobre el reparto entre lo determinista y lo probabilístico conviene tener criterio: el cuadre aritmético y la casación con el pedido son reglas fijas y deben implementarse como reglas, no dejarse a un modelo. Es la misma distinción práctica que explicamos en RPA y IA: reglas donde hay reglas, modelos donde hay variabilidad.

¿Cómo se integra con el ERP sin romper el circuito contable?

La integración es donde el proyecto se hace real, y casi siempre es más trabajo que el modelo. Cuatro decisiones marcan el resultado.

Dónde entra el dato. Lo prudente es crear el documento en estado de borrador o prerregistro y dejar que el flujo de aprobación existente lo confirme. Insertar directamente asientos contables definitivos desde un proceso automático es pedir un problema el día que falle.

Qué pasa con los maestros. La extracción devuelve un nombre y un CIF; el ERP necesita un código de proveedor. Ese cruce falla con razones sociales parecidas, delegaciones y CIF mal impresos. Conviene resolverlo por CIF con normalización previa y dejar una excepción explícita cuando no hay coincidencia única, en lugar de dar de alta proveedores nuevos automáticamente.

Cómo se evitan los duplicados. La regla mínima es emisor más número de factura más ejercicio, comprobada antes de crear nada, y un hash del archivo para detectar el mismo PDF reenviado. Los duplicados son el error más caro de esta automatización.

Qué se hace cuando el ERP dice que no. Ejercicio cerrado, cuenta bloqueada, campo obligatorio vacío. Hace falta un tratamiento de errores que devuelva el documento a una cola con el motivo, no un log que nadie lee. Sobre patrones de conexión entre sistemas escribimos con más detalle en integración con herramientas.

Una nota de cumplimiento: si los documentos contienen datos personales —nóminas, partes con nombres, facturas de autónomos— el tratamiento entra en el ámbito del RGPD, y conviene decidir desde el principio dónde se procesan y cuánto tiempo se conservan las copias intermedias. Lo desarrollamos en RGPD e IA.

Preguntas frecuentes

¿Funciona el OCR de facturas con documentos escaneados de mala calidad?

Con escaneos torcidos, grises o de 150 ppp funciona peor, y ese es un problema de captura, no de modelo. Subir la resolución de escaneo, evitar fotos de pantalla y pedir el PDF original al proveedor cuando exista mejora los resultados más que cambiar de tecnología.

¿Cuántos documentos hacen falta para que un modelo de extracción funcione?

Los modelos actuales de extracción de datos ya vienen entrenados para documentos comerciales estándar y funcionan sin ejemplos previos en facturas y albaranes corrientes. Los ejemplos propios hacen falta para formatos específicos de tu sector o para campos que solo existen en tus documentos, y ahí unas pocas decenas por formato suelen mover la aguja.

¿Es mejor un producto especializado o desarrollarlo a medida?

Para facturas y albaranes estándar, un producto especializado sale a cuenta: el problema está resuelto y el coste está en la integración. El desarrollo a medida se justifica con documentos propios del sector, volúmenes muy altos o requisitos de dónde se procesa el dato.

¿Cuánto tarda en estar en producción?

Un alcance acotado —un tipo de documento, un circuito, un ERP— se puede tener funcionando en unas semanas si el acceso al sistema destino está resuelto. Lo que alarga los proyectos no suele ser la extracción, sino los permisos, los maestros sucios y decidir quién valida las excepciones.

Esta es una de las automatizaciones con retorno más fácil de comprobar, porque el antes y el después se miden en documentos procesados sin intervención y en errores que ya no llegan al cierre. Si quieres saber qué parte de tu papeleo es automatizable hoy y con qué garantías, en la auditoría revisamos una muestra real de tus documentos y tu circuito actual antes de proponer nada. Y si prefieres contrastarlo en media hora, hablemos.