El OCR es un problema ya resuelto, más o menos. Meter datos incompletos y con las cuentas mal en la única forma que tu ERP acepta, no lo es.
Puntos clave
- El documento se rechaza después de haberse leído — por un campo obligatorio, un total que no cuadra o un formato que no encaja, nada de lo cual arregla una mejor lectura.
- Hay cinco formas honestas de tratar documentos sucios; cada una es la correcta para algún flujo, y una de ellas es, sencillamente, más gente.
- Extracción con IA más RPA encaja en volúmenes altos de documentos no uniformes — y es la opción equivocada, y cara, por debajo de eso.
- En nuestro propio proyecto de retail, entre el 13 y el 15% de los documentos seguían pasando a revisión humana tras la puesta en marcha. Eso es normal, no un fracaso.
- La única forma de saber dónde está tu propia línea entre modelo y humano es medirla con tus treinta documentos más sucios.
Trabajamos con una cadena de retail que tenía una carpeta de un proveedor que llegaba cada mañana con más o menos el mismo aspecto.
Un Excel roto que no se abría a la primera. Un único PDF con cuatro documentos distintos escaneados dentro — un albarán, una factura, un certificado de calidad y una página que nadie sabía identificar. Una hoja impresa en una impresora de oficina ya cansada, firmada a mano y luego fotografiada con el móvil bajo un flexo.
Todo eso tenía que estar en el sistema contable antes de que acabara el día. Una persona lo leía, lo tecleaba, lo revisaba y le daba a guardar.
El sistema lo rechazaba.
Faltaba un campo obligatorio — un NIF que el papel nunca había llevado, para empezar. Un documento que un humano ya había "terminado" volvía directo para atrás.
No es un problema de lectura
La mayoría de las herramientas se equivocan en algo muy concreto: lo tratan como un problema de reconocimiento, así que compiten en lo bien que leen un escaneo malo.
Leer ya está suficientemente resuelto desde hace años. Un modelo moderno lee una foto torcida hecha con el móvil casi tan bien como un empleado cansado. El documento se sigue rechazando, y se rechaza después de que la lectura ya está hecha.
El sistema que recibe el documento no te puntúa por lo bien que has leído la página.
Comprueba si están todos los campos obligatorios, si las cuentas cuadran — los importes de línea contra el total, la base por el tipo contra la cuota — y si el formato encaja con su esquema hasta el último carácter.
A esto lo llamo la milla cero: meter un dato sucio en la forma exacta que un receptor estricto va a aceptar. Está después del reconocimiento, y es ahí donde vive el coste de verdad.
Una lectura perfecta de la página no te da un registro válido, porque el campo que falta nunca estuvo en la página. La propia documentación de un gran proveedor de ERP lo dice sin rodeos: activar la facturación electrónica cambia, a nivel estructural, cómo el sistema guarda y valida los datos de la factura, porque los campos que ahora exige el receptor pueden no tener ningún hueco en el modelo de datos del sistema de origen.
Un receptor estricto, por diseño
Un receptor estricto es exigente a propósito. En España, el SII (Suministro Inmediato de Información) es el ejemplo más claro: es un canal casi en tiempo real hacia la Agencia Tributaria (AEAT) que sustituye a los libros registro de IVA tradicionales para los grandes contribuyentes. Están obligadas a usarlo las empresas con una facturación anual superior a 6 millones de euros, las acogidas al régimen de devolución mensual (REDEME) y los grupos de IVA. Cada factura emitida debe quedar reportada a la AEAT en un plazo de 4 días naturales desde su emisión.
Si el NIF del cliente está mal formado o no consta en el censo de la AEAT, si el mismo registro se envía dos veces — el sistema toma como clave el NIF del emisor junto con la serie, el número y la fecha de la factura — o si la fecha de devengo no cuadra, el SII devuelve el registro. Da igual lo bien que se haya leído o escaneado la factura original: el rechazo llega después, sobre el dato, no sobre la imagen.
(Como contexto: a partir de 2027 entra en juego Verifactu, que exige que el propio software de facturación genere registros con huella encadenada — obligatorio desde el 1 de enero de 2027 para las empresas sujetas al Impuesto de Sociedades y desde el 1 de julio de 2027 para el resto de obligados. Es un mecanismo distinto: audita el software emisor, no valida cada factura al vuelo como hace el SII.)
E incluso los despachos que ya han automatizado parte del proceso siguen tocando a mano cerca de dos tercios de sus facturas; la tasa media del sector sin intervención humana ronda el 32% (Ardent Partners, 2024). Un equipo totalmente manual, por definición, toca cada una de ellas.
Cinco formas honestas de atacar esto
Hay cinco formas reales de atacar esto, y cada una es, en algún caso, la respuesta correcta. He entregado proyectos con más de una de ellas, así que también diré dónde se rompe cada una.
1. Contratar gente, o contratar para el pico
Con poco volumen, o para ese documento suelto que ninguna automatización va a aprender nunca, una persona es sencillamente la opción más barata y más rápida — no hay que construir nada, no hay que mantener nada.
Se rompe con la escala y, peor aún, con los picos que se repiten. El coste completo de procesar una factura ronda los 9,87 $ de media (Ardent Partners, 2024), y benchmarks más antiguos, de la cola rezagada del sector, sitúan a los equipos que aún trabajan casi todo a mano entre 18 y 26 $ (Aberdeen, 2010 — tómalo como tendencia, no como precio actual). Son costes de ciclo completo, no de pulsaciones de teclado.
En nuestros propios proyectos he visto un documento limpio llevar un par de minutos y uno malo comerse veinte — porque ante una página fotografiada, firmada a mano, donde los números no cuadran, la persona no está tecleando, está investigando. Multiplica eso por un pico estacional y estás contratando gente para tres meses al año.
2. OCR basado en plantillas
Cuando tus documentos son uniformes y estables — mismo proveedor, mismo formato, mes tras mes — una plantilla que lee posiciones fijas es rápida, barata y precisa.
Se rompe en cuanto el formato se mueve un milímetro. Es la trampa más habitual, así que le dedico más espacio.
La extracción por plantilla ancla cada campo a una coordenada o a una palabra clave cercana, y una página fotografiada de una impresora mala nunca es estable a nivel de píxel, así que el ancla se desvía y el campo vuelve mal o vacío. En el propio foro de la comunidad de una plataforma de RPA muy conocida, los usuarios lo describen tal cual: unas pocas centenas de facturas a la semana, "el formato de factura del proveedor no se arregla", y el lector deja de funcionar. Una librería de código abierto para leer facturas, usada junto a un ERP autoalojado, lo dice directamente en su mensaje de error — la factura en PDF no coincide con ninguna de las plantillas que trae de fábrica — cada vez que un documento cae fuera del conjunto instalado, un fallo que los usuarios llevan reportando años.
La cadena de retail con la que abría este artículo es la razón por la que esto importa. Esos proveedores daban el mejor precio y la calidad que el negocio quería, así que se les perdonaba cierto descuido en el papeleo — y ningún equipo de compras del mundo iba a obligar a cuarenta proveedores distintos a meterse en una sola plantilla de factura.
Con OCR de plantilla, la suciedad se queda contigo.
3. Soluciones enlatadas y específicas de sector
Si tu entrada ya llega limpia y ya encaja con lo que espera la caja, estas soluciones son excelentes — alguien ya ha hecho el trabajo de cumplimiento normativo por ti.
Se rompen porque asumen que la entrada es limpia. Una red de facturación electrónica homologada validará tu documento encantada, y lo rechazará encantada también, pero no va a arreglar el dato de origen que lo hizo inválido. Los errores que se repiten están todos aguas arriba: un proveedor que escribe "N/A" en un campo obligatorio, una línea vacía que quedó de convertir un PDF, una referencia de comprador que falta. La caja gestiona la emisión. La suciedad se queda aguas arriba, contigo.
4. Integración a medida completa, o sustituir el sistema de origen
Cuando eres dueño del sistema de origen, y tienes el tiempo y el presupuesto, una integración de verdad es la respuesta honesta a largo plazo — una API es un contrato estable, y todo lo anterior es un parche por no tener uno.
Se rompe con los sistemas que no controlas. Un ingeniero independiente con mucha experiencia lo resume como la primera pregunta que hace ante cualquier automatización: ¿hay API? Los sistemas legacy sin ella te obligan a manejar una pantalla, y la automatización de pantalla es frágil por diseño.
También se rompe con los proveedores, porque ninguna integración que construyas por tu lado puede obligar al ERP de un proveedor externo a emitir un formato válido — y hay un caso bien documentado de un ERP actual y bien mantenido que puso el esquema de identificador equivocado en un campo obligatorio y vio cómo le rechazaban su propia salida, así que "simplemente moderniza el origen" no es la cura limpia que parece. Estos proyectos se miden en trimestres, a veces en años.
5. Extracción con IA más RPA
Esta es la opción que encaja con volumen alto de suciedad no uniforme — exactamente el caso del retail. Tiene límites reales, el coste es el más afilado, y llegaré a ellos. Primero, cómo es en la práctica.
Cómo es el bucle en la práctica
El bucle tiene cuatro pasos, y el orden importa más que cualquier modelo concreto dentro de él.
Un modelo de visión lee el documento — cualquier formato, fotografiado o no — y devuelve los campos junto con una puntuación de confianza para cada uno. No una puntuación por página: una por campo, porque un documento puede ser legible al 95% en conjunto mientras el NIF concreto queda por debajo del umbral y necesita un ojo humano.
Luego, una segunda capa, código determinista normal y no el modelo, recomprueba las cuentas. Recalcula cada línea como cantidad por precio, suma las líneas contra el subtotal, aplica el tipo declarado para verificar la cuota, y confirma el total, con uno o dos céntimos de tolerancia de redondeo para no saltar en falso.
Esto tiene que ser código aparte, porque un LLM que predice un número está muestreando de texto que ha visto, no calculando — pedirle al mismo modelo que revise su propia aritmética solo añade una segunda suposición. La confianza va de la capa determinista hacia el modelo, nunca al revés.
El sentido de todo esto es el "no lo sé" honesto.
Un modelo de visión, cuando no puede leer un valor, se inventa uno que encaja con el aire general del documento y lo entrega con toda la confianza del mundo — y un importe seguro de sí mismo pero equivocado, que se cuela en la contabilidad, es mucho más peligroso que un campo marcado para que lo vea una persona. Así que un campo dudoso nunca llega en silencio al receptor. Va a una estación de revisión donde una persona lo resuelve.
La comprobación determinista solo pilla números que se contradicen entre sí; no puede pillar un valor equivocado que es internamente coherente, y por eso la persona sigue en el bucle, y por eso "100% sin intervención humana" es una diapositiva, no una realidad operativa.
Construimos este bucle sobre Primo AI Server para la extracción y la confianza por campo, con Primo RPA cerrando los dos extremos — sacando datos de un sistema legacy a través de su pantalla cuando no hay API a la que llamar, y tecleando el registro terminado en el receptor tal como lo haría una persona. Las mismas dos piezas cubren todo el camino, desde la carpeta de escaneos malos hasta el registro que el sistema estricto acepta.
En nuestro proyecto de retail, tras la puesta en marcha, entre el 13 y el 15% de los documentos pasaban a revisión humana — ni el 1%, ni cero. Un benchmark independiente del sector de cuentas a pagar sitúa la tasa media de excepciones en el 18,4% (Ardent Partners), así que esa cifra es normal, no un fracaso. El piloto duró dos meses y pasó directo a producción. La empresa se ahorró contratar a cuatro personas para esa carpeta.
Cómo elegir, y cuándo no usar IA
Yo vendo este bucle, así que escucha bien lo que viene ahora: en muchos flujos, no deberías comprarlo.
Meter IA en el bucle significa GPUs, y una GPU funcionando al 10% de su capacidad cuesta, por unidad de trabajo, unas diez veces más que una que se mantiene ocupada — y la entrada de documentos, con sus picos y sus semanas tranquilas, casi nunca mantiene una GPU ocupada.
Por debajo de mil o diez mil documentos al mes, más o menos, con un formato uniforme, el OCR de plantilla o incluso una persona ganan directamente, porque a ese volumen el coste real está en construir y vigilar el pipeline, muy por encima de la propia lectura.
Autoalojar tu propio modelo solo empieza a compensar en torno a las 50.000–100.000 páginas al mes de volumen estable, y solo si ya tienes en plantilla un ingeniero de ML dedicado — o al menos a tiempo parcial. Y en un desglose de ingeniería que he visto, la cola de revisión humana por sí sola era 0,75 $ de un coste total de 1,20 $ por documento — más que las capas de OCR y de IA juntas.
Así que las cuatro cosas que merece la pena medir antes de gastar nada: cuánto volumen tienes de verdad, cómo de uniformes son los documentos, si el sistema de origen tiene API, y cuánto aprieta el plazo.
Cuenta primero. Si los números dicen OCR de plantilla, el proveedor honesto te dice que compres OCR de plantilla.
La línea que solo puedes trazar tú
Dónde termina el modelo y empieza el humano es una línea real, y es distinta para cada flujo de documentos.
No puedo decirte desde una diapositiva si el tuyo cae en el 5% de revisión o en el 25%, y no me fiaría de nadie que dijera que sí puede.
La única forma que conozco de encontrarla es coger tus propios treinta documentos más sucios — el Excel roto, la firma fotografiada, la página escaneada cuatro veces — pasarlos por el bucle, y ver cuántos te devuelve la máquina.
Tráenos tus treinta documentos más feos
Esa prueba es exactamente cómo empezamos un piloto. Mándanos lo peor que te lanzan tus proveedores y tus sistemas, y lo pasaremos por el bucle en Primo AI Server y Primo RPA, te enseñaremos la confianza por campo, las excepciones y la tasa de revisión real — antes de que te comprometas a nada. Verás tu propio número, no el nuestro.
Solicitar un piloto / reservar una demo →
Alexey Nikolaev trabaja en Primo RPA, donde el equipo construye sistemas de automatización de documentos y RPA para operaciones financieras y de back-office. Primo RPA desarrolla Primo AI Server y la plataforma Primo RPA.