La demo siempre usa el mismo documento: un PDF nativo, generado por otro sistema, bien maquetado, en un idioma, con las tablas cuadradas y el logotipo arriba a la izquierda. La herramienta lo lee en dos segundos y devuelve todos los campos. Aplausos. Y es verdad, no hay truco: ese documento lo resuelve hoy cualquier producto decente del mercado, y lo resuelve barato. El problema es que ese documento no es el tuyo. O más exactamente: es el 85 % del tuyo, y el 85 % nunca fue el proyecto.
La tesis en una frase: en extracción documental, el presupuesto y el calendario no los fija la parte fácil, los fija el 15 % de documentos raros que ninguna demo enseña —el escaneo torcido, la tabla partida entre dos páginas, el albarán manuscrito con un sello encima, el proveedor que cambió su plantilla en julio sin avisar a nadie—. Y la cifra con la que te lo venden, la tasa media de acierto, es precisamente la métrica diseñada para que ese tramo no se vea.
Los errores al extraer datos de documentos con IA no se reparten por igual
Cuando un proveedor te dice «97 % de acierto», lo que estás oyendo es una media. Y una media, por definición, reparte: sugiere que de cada cien documentos hay tres con algún problema menor, repartidos al azar, como quien pierde tres calcetines al año. No funciona así. Los errores de extracción no caen espolvoreados sobre el conjunto: se concentran, y se concentran siempre en los mismos sitios. El mismo puñado de proveedores, el mismo tipo de escaneo, el mismo campo maldito.
Esa concentración es lo que convierte un número bonito en un proyecto largo. Si el 3 % de fallo estuviera repartido, lo absorbe el proceso: alguien corrige tres cosas sueltas y sigue. Si el 3 % son siempre los documentos de los mismos catorce proveedores, no tienes un 3 % de errores: tienes catorce proveedores que siguen entrando a mano, con su flujo paralelo, su persona dedicada y su hoja de cálculo. El ahorro que habías presupuestado se evapora ahí, no en el modelo.
La lógica general —por qué un porcentaje de acierto no basta en producción y cómo se fija el umbral según el coste del error— la contamos aparte. Aquí vamos a lo concreto: qué son exactamente esos documentos, por qué rompen y qué tienes que exigir antes de firmar nada.
Los cinco documentos que se comen el proyecto
No son cinco casos exóticos. Son los cinco que aparecen en cualquier operación real en cuanto llevas dos semanas mirando la bandeja de entrada de verdad y no la carpeta de ejemplos que preparó alguien para la reunión.
| Qué llega | Por qué rompe | Lo que cuesta de verdad |
|---|---|---|
| La foto de móvil y el escaneo a 150 ppp | Texto torcido, sombra en media página, resolución por debajo de lo que el reconocimiento necesita para distinguir un 3 de un 8 | El error no se ve: el importe entra, es plausible y nadie lo caza hasta el cierre |
| La tabla partida entre dos páginas | El sistema lee cada página como una unidad; la última línea de la primera y la primera de la segunda se pierden o se duplican | Cuadra el total y no cuadran las líneas, que es justo lo que necesita contabilidad analítica |
| El manuscrito, el sello y la anotación a boli | La cantidad recibida corregida a mano sobre el albarán es el dato bueno, y es el único que no está impreso | El sistema devuelve la cifra impresa con total confianza: error silencioso, el más caro de todos |
| El proveedor que cambió su plantilla en julio | Lo que funcionaba con plantilla deja de funcionar sin que nadie toque nada, y el sistema no avisa porque sigue encontrando campos | Semanas de datos malos antes de que alguien note el patrón; el coste no es reprocesar, es desconfiar |
| El documento ambiguo: abono, copia, proforma | El problema no es leerlo, es decidir qué es. La forma es idéntica a la de la factura y el significado es el contrario | Un abono contabilizado como factura se paga dos veces; se detecta en la conciliación, meses después |
Fíjate en la tercera columna, que es la que nadie mira en la fase de compra. Ninguno de los cinco falla ruidosamente. Un sistema que se cae y devuelve un error es barato: lo ves, lo mandas a la cola manual y sigues. Los cinco de arriba devuelven un dato: plausible, con formato correcto, con la confianza de siempre. Ese es el modo de fallo que de verdad fija el calendario del proyecto, porque no lo arreglas con un modelo mejor —lo arreglas con validaciones, con reglas de negocio y con alguien mirando en el sitio correcto—.
Por qué la tasa media de acierto oculta justo el tramo caro
La aritmética de por qué una precisión por campo del 95 % puede ser una tasa de documentos válidos del 60 % ya la desmontamos al comparar OCR clásico y modelos multimodales para leer documentos: se mide por campo y se cobra por documento, y el campo que falla nunca es el código postal. Lo que nos interesa aquí es la consecuencia, que es de presupuesto y no de medición: esa diferencia entre las dos cifras no es ruido estadístico, es la cola de documentos difíciles convertida en trabajo manual permanente.
Y esto no es una intuición de despacho: es el cuello de botella que la investigación del sector lleva años midiendo. En su informe The State of ePayables 2025, Ardent Partners sitúa la tasa media de excepciones en facturas en el 18,4 % —casi una de cada cinco facturas se sale del flujo automático y acaba en manos de una persona— y afirma explícitamente que las excepciones son la mayor causa aislada de que el resto de indicadores del departamento no mejoren. En la misma medición, las organizaciones del primer cuartil no procesan facturas distintas: tienen una tasa de excepciones un 47 % más baja y procesan 1,8 veces más facturas de forma desatendida que el resto. La diferencia entre un departamento bueno y uno mediocre no está en el documento fácil. Está entero en la cola. (Ámbito: muestra de profesionales de cuentas a pagar mayoritariamente norteamericana; el dato dimensiona el problema, no es un resultado nuestro.)
Traducido a presupuesto: si dimensionas el proyecto por el 85 % que sale solo, estás presupuestando la parte que ya era barata. La factura real te la pasa el otro tramo, y te la pasa en forma de semanas de calendario, no de licencia.
Qué preguntarle al proveedor antes de firmar
Cinco preguntas. Ninguna es técnica y las cinco son incómodas, que es exactamente la señal de que sirven. Un proveedor que las responde bien vale más que uno que enseña una demo impecable.
- «Dadnos vuestra tasa sobre nuestros doscientos documentos peores, no sobre vuestro benchmark.» Es la única pregunta que importa. Escoges tú la muestra: los escaneos malos, los proveedores raros, los manuscritos. Si la respuesta es que necesitan primero entrenar con ellos, es una respuesta válida y honesta —pero entonces ya sabes que hay una fase de proyecto que no estaba en el presupuesto—.
- «Dadme la precisión desglosada por campo, no la global.» Global es marketing. Por campo se ve enseguida si el importe y el identificador fiscal aguantan o si la media la sostienen la fecha y el código postal.
- «¿Qué hace el sistema cuando no está seguro?» La respuesta correcta es que lo marca y lo manda a revisión. Si el sistema siempre devuelve un valor, no tiene incertidumbre: tiene la misma confianza para lo que sabe y para lo que se inventa, y eso es el error silencioso de la tabla de arriba.
- «¿Cómo me entero de que un proveedor ha cambiado su plantilla?» Busca una respuesta con un mecanismo concreto —una alerta por caída de confianza o por desviación de la distribución de valores—. Si la respuesta es «lo verías en los datos», la traducción es que lo verás tarde.
- «Quién paga el reproceso y con qué plazo.» No para castigar a nadie: para saber si el coste del 15 % se queda en tu lado de la mesa. Casi siempre se queda. Mejor saberlo antes de firmar que en el segundo cierre.
Una advertencia sobre la primera pregunta: prepara la muestra antes de la reunión, no después. Doscientos documentos elegidos por ti, con su verdad anotada a mano. Es un día de trabajo aburrido y es lo único que convierte una decisión de compra en una medición.
Cómo se presupuesta esto para que llegue a producción
La forma que funciona es contraintuitiva: se presupuesta el tramo difícil primero y el fácil casi no se presupuesta. En la práctica eso significa tres decisiones tomadas antes de escribir una línea. Uno, qué campos son críticos y cuáles son cómodos —el importe se valida contra el pedido, el código postal no se valida contra nada—. Dos, dónde se pone la persona: no revisando todo, que mata el ahorro, sino exactamente sobre los documentos que el sistema marca como dudosos y sobre los campos que cuestan dinero. Es el diseño del humano en el bucle de una automatización aplicado al caso más literal que existe. Y tres, qué pasa aguas abajo con un documento que no se pudo leer, porque un proyecto de extracción que deja un agujero en el paso siguiente no ha automatizado nada: ha movido el cuello de botella, que es la trampa clásica de automatizar un proceso de punta a punta con IA.
Con esas tres decididas, la elección de tecnología se vuelve casi secundaria —y cuando toque, la comparativa entre OCR clásico y modelos multimodales para leer documentos está contada aparte—. Nosotros montamos exactamente esto en los dos casos en los que más se repite: extraer los datos de las facturas y clasificar los documentos que entran para que cada uno acabe en su sitio. En los dos, el trabajo serio no es leer el PDF bonito. Es decidir qué se valida, quién mira lo dudoso y qué pasa cuando llega el documento feo.
La conclusión, sin adorno
La pregunta con la que casi todo el mundo compra —«¿qué precisión tiene?»— es la pregunta equivocada, y no porque el número sea falso, sino porque describe la parte del trabajo que ya estaba resuelta. La pregunta útil es qué hace tu sistema el día que le llega el albarán manuscrito, la tabla partida y la plantilla nueva del proveedor grande. Si la respuesta es «lo marca, lo aparta y avisa», tienes un proyecto. Si la respuesta es un porcentaje, tienes una demo.
No compres precisión media. Compra comportamiento ante el documento feo.