Meter facturas y albaranes de proveedor en el sistema sin teclearlos parece un problema de IA, pero se gana o se pierde en la validación. Te cuento el proceso completo, paso a paso.
Un proveedor te manda cuarenta facturas al mes. Alguien de administración las abre una a una, lee el número, la fecha, la base, el IVA y el total, y los teclea en el ERP. Cuando el volumen sube, o esa persona se va de vacaciones, el trabajo se acumula y los errores de tecleo también. La automatización de procesos administrativos empieza casi siempre por aquí: por meter facturas y albaranes de proveedor en el sistema sin que nadie los escriba a mano.
No voy a explicarte qué es la automatización en general; eso lo tienes en mi visión general de la automatización de procesos con IA. Aquí bajo a un caso concreto, el de cuentas por pagar, porque es donde más gente tropieza con la misma piedra: montan una demo que lee una factura bonita en PDF, funciona en la reunión, y tres semanas después descubren que una parte nada despreciable de los documentos reales rompe el flujo. Te cuento cómo lo abordo yo, paso a paso y sin adornos.
El objetivo no es "leer una factura". Es que un documento que llega por donde sea acabe como un asiento correcto en tu sistema, casado con su pedido y su albarán, y que lo que no esté claro caiga en una bandeja para que un humano decida en diez segundos en lugar de teclear durante diez minutos.
Eso son cinco piezas encadenadas: ingesta (por dónde entran los documentos), extracción (sacar los datos del papel o del PDF), validación (comprobar que esos datos cuadran con lo que ya sabes), decisión (qué se aprueba solo y qué pasa a revisión) y trazabilidad (qué guardas para poder auditar después). Si falta cualquiera de las cinco, tienes una demo, no un sistema. La demo impresiona; el sistema es el que aguanta un martes de cierre de mes con el proveedor que factura raro.
La diferencia entre las dos la marca una idea sencilla: un sistema fiable asume que va a recibir basura y decide qué hacer con ella, en vez de suponer que todo llega perfecto.
Antes de leer nada hay que recoger el documento, y aquí es donde más se subestima el trabajo. Las facturas entran por tres vías, casi nunca por una sola:
[email protected] al que los proveedores mandan el PDF adjunto. Hay que distinguir el adjunto que es factura del que es el logotipo de la firma del correo, y quedarse con el bueno.La regla que aplico: la ingesta guarda el documento original tal cual llegó, sin tocarlo, y le pone un identificador antes de que nadie intente leerlo. Si más adelante la extracción se equivoca, quiero poder volver al original exacto, no a una versión ya manipulada. El original es la prueba; todo lo demás es interpretación.
Aquí hay una confusión que cuesta dinero. Mucha gente cree que "automatizar facturas" es sinónimo de OCR, y no es lo mismo.
El OCR clásico (reconocimiento óptico de caracteres) convierte una imagen en texto. Te da las letras y los números que hay en el documento, pero no entiende qué son. Sabe que pone "21" en algún sitio; no sabe si eso es un tipo de IVA, una cantidad o parte de un código postal. Funciona bien con documentos limpios, de buena resolución y estructura estable. Se rompe con el escaneo torcido, la foto hecha con el móvil bajo la luz de un almacén, el sello encima del número o la factura de baja calidad. Y cuando se rompe, lo hace en silencio: te devuelve un texto plausible pero equivocado.
Los modelos multimodales (los que "ven" la imagen además de leerla) entienden el documento como un todo. Les puedes pedir directamente "dame la base imponible, el tipo de IVA y el total" y te lo devuelven interpretado, aunque el diseño sea nuevo, esté ligeramente torcido o el proveedor coloque las cosas donde le da la gana. Aguantan mucho mejor la variabilidad, que en facturas de proveedor es enorme: cada uno usa su plantilla.
¿Cuál uso? Depende, y el criterio es este:
| Situación | Herramienta |
|---|---|
| Documentos limpios, formato fijo, alto volumen del mismo proveedor | OCR clásico, más barato y rápido |
| Formatos variados, escaneos de mala calidad, fotos de móvil | Modelo multimodal |
| Necesito interpretar (qué línea es qué), no solo transcribir | Modelo multimodal |
| Coste por documento crítico y calidad de entrada garantizada | OCR clásico con reglas |
En la práctica combino los dos. El OCR me da el texto crudo y las coordenadas; el modelo multimodal me da la interpretación estructurada. Y para la factura escaneada torcida, antes de leer nada la enderezo y la limpio con un preprocesado de imagen, porque un documento inclinado degrada a cualquiera de los dos. La calidad de entrada manda: ningún modelo arregla lo que el escáner destrozó.
Este es el paso que separa una demo de un sistema, y es justo el que nadie cuenta. Si le pides a un modelo "extrae los datos de esta factura" y te devuelve texto libre, tienes un problema: cada vez te lo formatea distinto, a veces se inventa un campo, a veces se salta otro, y no hay forma limpia de comprobar la salida. Un texto libre no se valida; se lee.
La solución es forzar al modelo a devolver una estructura fija y tipada. Se hace con JSON Schema o function calling: le das al modelo el molde exacto de lo que esperas y el modelo rellena ese molde, sin desviarse. En lugar de un párrafo, obtienes algo así:
{
"proveedor": { "nif": "B12345678", "nombre": "Suministros Levante SL" },
"factura": { "numero": "2026/0451", "fecha": "2026-06-30" },
"lineas": [
{ "descripcion": "Cajas cartón 30x20", "cantidad": 200, "precio_unitario": 0.85, "tipo_iva": 21 }
],
"totales": { "base": 170.00, "cuota_iva": 35.70, "total": 205.70 }
}
Con la salida tipada gano tres cosas. Que el campo fecha sea siempre una fecha y no "30 de junio" unas veces y "30/06" otras. Que si falta la base imponible lo detecte de inmediato, porque el hueco está vacío, en vez de perderme entre líneas de prosa. Y que pueda pasar ese JSON directamente al siguiente paso sin adivinar nada. El esquema es un contrato: el modelo no me entrega un relato, me entrega datos que encajan en un molde que yo controlo.
Ojo con un error frecuente: pedir al modelo que además calcule o "cuadre" los totales. No. El modelo extrae lo que ve; los cálculos y las comprobaciones los hago después, con código determinista. Un modelo es bueno leyendo y malo garantizando aritmética. No le doy un trabajo que no sabe hacer con certeza.
Tengo un JSON bonito. No me fío de él todavía. Un dato extraído no es un dato correcto: es una hipótesis. Ahora viene la parte que casi nadie desarrolla, y es la que de verdad evita meter basura en el ERP: la validación determinista, con reglas de código, sin IA de por medio.
Compruebo, en este orden:
La clave conceptual: la IA lee, el código decide. La extracción puede equivocarse; la validación es aritmética y reglas de negocio, y esa parte tiene que ser tan predecible como una calculadora. Cuando alguien me dice que su sistema de facturas "es todo IA", sé que le falta justo esta capa, que es la aburrida y la que salva el cierre de mes.
Ninguna extracción es fiable al cien por cien, y quien te diga lo contrario te está vendiendo humo. La pregunta correcta no es "¿cómo consigo que no falle nunca?", sino "¿qué hago con lo que no estoy seguro de haber leído bien?".
La respuesta es un umbral de confianza más una cola de revisión humana, lo que se llama human-in-the-loop. Cada factura, tras pasar la validación, cae en una de tres cajas:
Lo importante es que el corte se calibra y se puede mover. Al principio soy conservador: mando a revisión más de lo necesario, para ver dónde acierta y dónde falla el sistema con tus documentos reales. A medida que veo que una categoría se aprueba bien de forma consistente, subo el umbral y dejo que pase sola. El sistema no nace confiando; se gana la confianza con tus datos. Y el humano nunca desaparece: pasa de teclear cuarenta facturas a revisar las seis dudosas.
Estos son los que no aparecen en la demo y arruinan el cierre de mes. Conviene buscarlos a propósito:
Ninguno de estos es un fallo de la IA. Son reglas de negocio que hay que conocer antes de tocar código, y son justo lo que separa a quien ha hecho esto de quien acaba de descubrir que los modelos leen facturas. La tecnología es la parte fácil; el dominio es la difícil.
Si automatizas la entrada de facturas, en algún momento alguien, una inspección, una auditoría, tú mismo, preguntará "¿de dónde salió este asiento?". La respuesta tiene que estar guardada desde el principio, no reconstruida a posteriori.
Por cada factura procesada guardo, como mínimo: el documento original intacto, la salida estructurada que produjo el modelo, qué versión del modelo y del prompt se usó, si la aprobó el sistema o una persona y quién, y un hash del original para probar que no se ha alterado. Esto no es burocracia: es lo que te permite explicar una discrepancia meses después.
Hay un riesgo que casi nadie menciona: el modelo cambia de versión sin avisar. Si dependes de un modelo en la nube y el proveedor lo actualiza, tu extracción puede cambiar de comportamiento de un día para otro y empezar a leer mal un campo que antes leía bien. Por eso versiono el modelo y el prompt igual que versiono el código: si algo cambia en los resultados, quiero poder señalar exactamente qué versión los produjo. Un sistema de facturas que no sabe con qué modelo procesó cada documento no es auditable.
Sobre la ley española, y aquí no te doy consejo legal, para eso está tu asesoría, solo el impacto técnico. Dos frentes:
Lo relevante para este flujo es que cuando la factura llega ya estructurada, el problema de leerla desaparece: no hay que interpretar un PDF torcido porque los datos vienen en un formato definido. Pero durante toda la transición vas a recibir las dos cosas, facturas estructuradas de unos proveedores y PDF o papel de otros, así que el proceso de extracción no sobra: convive con el formato nuevo. Quien monte hoy la ingesta de facturas debería diseñarla ya para las dos vías.
Automatizar la entrada de facturas y albaranes no es "poner una IA a leer". Es encadenar cinco piezas y respetar el reparto de trabajo: la IA lee, el código valida y decide, la persona resuelve lo dudoso, y todo queda trazado. La parte vistosa, el modelo que interpreta el PDF, es la más fácil y la que menos problemas da. Los problemas viven en la casación a tres bandas, en el IVA por líneas, en los duplicados y en el albarán que llega antes que la factura. Ahí es donde se gana o se pierde.
Mi forma de trabajar es empezar conservador, dejar que el sistema se gane la confianza con tus documentos reales y subir el listón de lo que se aprueba solo a medida que demuestra que acierta. No prometo un cien por cien automático desde el primer día, porque no existe; prometo un sistema que mete solo lo seguro, aparta lo dudoso y no esconde ni un error.
Trabajo estas cosas en Laravel, Node y Python, y siempre con la validación en código propio, no delegada al modelo. Si quieres ver cómo aterrizo esto en tu caso, qué proveedores tienes, cómo llegan tus facturas, qué ERP usas, el análisis funcional inicial y la primera consulta no los cobro: puedes contarme tu proceso o mirar antes cómo trabajo y a qué precios. Y si lo tuyo es una agencia, esto mismo lo hago en marca blanca, bajo tu identidad.
Una cadena de piezas, no una sola herramienta. Para leer el documento combino OCR (reconocimiento óptico de caracteres) con modelos multimodales que interpretan la imagen. Fuerzo la salida a una estructura tipada mediante JSON Schema o function calling, para poder validarla. Después, código determinista comprueba que los datos cuadran con el pedido, el albarán y el maestro de proveedores. Y una persona revisa solo lo que el sistema marca como dudoso. La IA lee; el código valida y decide.
Depende de la calidad y la variedad de tus documentos. El OCR clásico es más barato y rápido, y va bien con facturas limpias, de buena resolución y con un formato estable. Los modelos multimodales aguantan mucho mejor la variabilidad: un diseño distinto por proveedor, escaneos torcidos o fotos hechas con el móvil. En la práctica suelo combinarlos: el OCR da el texto crudo y el modelo lo interpreta. Ninguno arregla un escaneo destrozado, así que la calidad de entrada manda.
Con un control de duplicados basado en la combinación de proveedor (NIF) más número de factura, comprobado antes de dar de alta nada. Es imprescindible porque la misma factura llega a menudo por dos vías, correo y papel, o como reenvío del proveedor, y sin ese control se paga dos veces. Es uno de los errores que más dinero cuestan y que no aparece en una demo, porque en la demo solo se prueba una factura.
Es lo normal en almacén: la mercancía y su albarán entran hoy, y la factura llega semanas después. El sistema tiene que aceptar el albarán, dejarlo en espera y casarlo con la factura cuando esta aparezca, sin que uno bloquee al otro. Esto es parte de la casación a tres bandas entre pedido, albarán y factura. Si el flujo se diseña asumiendo que factura y albarán llegan juntos, se rompe con el primer proveedor real.
Todavía no de forma general, pero va a serlo: la Ley Crea y Crece introdujo la factura electrónica obligatoria entre empresas, y su calendario depende del desarrollo reglamentario. Aparte va Verifactu, que afecta a las facturas que emites: tras el Real Decreto-ley 15/2025 la adaptación se exige antes del 1 de enero de 2027 para quienes tributan por el Impuesto sobre Sociedades y del 1 de julio de 2027 para el resto. No doy consejo legal: confirma con tu asesoría qué plazo te aplica.
Sí, y suele ser lo sensato al empezar. Un buen sistema se calibra: al principio se aprueba automáticamente solo lo más seguro y se manda a revisión humana todo lo dudoso. A medida que demuestra que acierta con tus documentos reales, se sube el umbral y pasa sola más proporción. La persona no desaparece: deja de teclear facturas para revisar solo las que el sistema aparta. No hace falta ir del cero al cien de golpe.
Si tienes un problema parecido y quieres una opinión técnica, cuéntamelo. Te respondo en menos de 24 h laborables.