Automatizar pedidos y albaranes con IA: leer, validar y escribir en el ERP

El proceso hoy: dónde se pierde el tiempo

Casi toda distribuidora repite la misma secuencia: el cliente manda el pedido por correo o WhatsApp, alguien lo mecaniza en el ERP, el reparto genera un albarán firmado y, días después, administración coteja albarán y pedido antes de facturar. Cada tramo parece pequeño, pero la suma pesa: datos tecleados dos o tres veces, discrepancias que se detectan tarde y facturas que esperan a que alguien tenga hueco.

Antes de plantear IA conviene medir la línea base: cuántos pedidos entran al día, cuántos minutos cuesta cada uno desde su llegada hasta estar registrado, cuántos errores de mecanización se corrigen al mes y cuántos días pasan entre albarán firmado y factura emitida. Sin esas cifras no habrá forma de demostrar mejora alguna.

Qué hace la IA y qué no debe hacer

En este flujo la IA tiene un papel acotado: leer documentos que hoy lee una persona. Un modelo de extracción puede recibir un PDF, la foto de un albarán firmado o el cuerpo de un correo, e identificar campos: número de pedido, cliente, referencia, unidades, precio, fecha, firma o sello del receptor. También puede cotejar automáticamente el pedido original con el albarán y marcar las líneas que no cuadran.

Lo que la IA no debe hacer es decidir. Si hay una discrepancia de unidades o de precio, el sistema la señala, pero la resuelve una persona con criterio comercial: quizá el cliente aceptó una merma, quizá hubo una sustitución acordada por teléfono. Dejar esa decisión al modelo sería trasladarle una responsabilidad que no puede asumir.

La validación humana, diseñada como una fase

El error habitual es tratar la revisión como un aviso genérico: «una persona siempre revisará». Funciona mejor diseñarla como una cola concreta. Tres decisiones bastan para definirla: quién revisa (una persona de administración, no cualquiera), cuándo (al inicio, en dos tandas al día o cada hora según el volumen) y con qué criterio de parada.

Un criterio razonable: los documentos con confianza alta y sin discrepancias pasan a la cola de aprobación rápida; los que presentan diferencias por encima de un umbral definido —por ejemplo, más de dos unidades por línea o cualquier desviación de precio— exigen revisión línea a línea; y los ilegibles o con campos faltantes vuelven al origen, a pedir el documento otra vez al cliente o al repartidor. La empresa fija los umbrales según lo que su negocio tolere.

Cada corrección es además señal para el proveedor: si el modelo falla siempre con la referencia de un mismo fabricante, hay que ajustar el ejemplo o la configuración. La validación no es un parche; es la fuente de mejora del sistema.

Conexión con el ERP: escribir por la puerta correcta

Extraer datos que luego alguien copia a mano al ERP elimina la mitad del problema y conserva la otra. La integración debe hacerse por la vía que ofrezca el sistema de gestión: API, si está disponible, o ficheros de importación con formato validado. La automatización de pantalla —simular los clics de una persona sobre la interfaz— suele ser la opción más frágil: puede fallar con cada actualización del software y deja un rastro difícil de auditar, así que conviene reservarla para lo que no tenga otra salida.

Cuando la cadena termina en facturación, la trazabilidad conviene diseñarla desde el principio y no añadirla después: conservar el documento original junto al dato extraído, dejar constancia de quién valida cada pedido y cuándo, y registrar cada corrección. No es un catálogo cerrado de requisitos, sino decisiones de diseño que permiten responder a una discrepancia con un cliente seis meses más tarde. Las obligaciones concretas de conservación y facturación que apliquen a cada empresa dependen de su normativa; revisa el diseño con tu asesor fiscal antes de cerrarlo.

Antes de firmar, comprueba que el proveedor contempla todo esto y no solo la precisión del modelo. Integración y tratamiento de datos son, además, dos de los tipos de valor propio que el documento del Plan IA360 prevé para los servicios que financiará el futuro bono empresarial de IA; la mera suscripción a una licencia, no.

Ejemplo hipotético: una distribuidora de 12 empleados

Imaginemos Distribuciones Álvarez, una empresa ficticia de alimentación con 12 empleados, dos furgonetas y unos 60 pedidos diarios por correo y WhatsApp. Hoy, una persona dedica cerca de dos horas al día a mecanizar pedidos y administración coteja cada lunes una pila de albaranes firmados; las facturas salen, de media, una semana después del reparto.

El proyecto se plantearía en tres fases. Primera: lectura de pedidos entrantes y cola de validación con umbrales de precio y unidades; objetivo, que la mecanización manual desaparezca en los pedidos limpios. Segunda: captura de albaranes firmados desde la foto tomada por el repartidor y cotejo automático con el pedido original. Tercera: generación del borrador de factura en el ERP, siempre con aprobación humana previa al envío.

Qué dejar fuera importa tanto como qué incluir: los pedidos con formatos excepcionales, las devoluciones y las sustituciones acordadas verbalmente pueden seguir gestionándose igual los primeros meses. Al medir, la métrica honesta no es un «ahorro total», sino horas por pedido mecanizado, errores detectados antes de facturar y días entre albarán y factura.

Qué comparte con el Bono IA y qué falta

Un proyecto de este tipo comparte rasgos con el diseño anunciado del Bono IA, el bono empresarial del Plan IA360: el plan prevé un diagnóstico previo de madurez, un caso de uso concreto y una medición posterior del impacto en productividad. Pero parecido no es elegibilidad. El documento del plan apunta a que el bono financie servicios y soluciones de IA aportados por empresas tecnológicas europeas con valor propio —desarrollo, integración, conocimiento sectorial, tratamiento de datos o rediseño de procesos—, y qué proyectos concretos podrán financiarse lo decidirán las bases.

La cifra de referencia es de hasta 24.000 euros por empresa, resultado de repartir los 600 millones anunciados entre las 25.000 empresas objetivo; no es un importe garantizado y el definitivo lo fijarán las bases y la convocatoria. El calendario previsto contempla un piloto controlado en el primer semestre de 2027 y una convocatoria general antes de final de 2027. Hoy no hay bases reguladoras, convocatoria, organismo gestor, requisitos ni lista de gastos subvencionables publicados, así que ninguna web puede tramitar una solicitud. Lo que sí está en tu mano es preparar el proyecto: línea base medida, caso de uso definido y trazabilidad clara.

No hay que confundir este programa con el Kit Digital de Red.es, con sus convocatorias ya cerradas entre diciembre de 2024 y octubre de 2025, ni con las ayudas autonómicas que comparten nombre, como las IA360 del IGAPE en Galicia: son programas distintos, con sus propias bases.

Errores a evitar antes de empezar

Tres fallos repetidos: empezar sin línea base y no poder demostrar la mejora; pedir al modelo que decida discrepancias que exigen criterio comercial; y conformarse con una integración por pantalla cuando existe API o fichero validado. Añade un cuarto: dejar la validación sin dueño. Si nadie tiene nombre y horario para revisar la cola, el sistema se atasca o, peor, se aprueba sin mirar.

La pregunta correcta para el proveedor no es si su modelo es bueno, sino qué pasa con los documentos mal leídos, cómo queda registrada cada corrección humana y qué rastro deja lo que acaba en factura. Con esas respuestas por escrito y una cola con responsable y horario, tienes decidida la mitad del proyecto; la elección del modelo es lo que viene después.