Pedidos por email al ERP: cómo dejar de teclearlos a mano

Si tu empresa recibe pedidos por email, alguien pasa parte del día abriendo PDF, buscando al cliente en el ERP, localizando cada referencia y tecleando cantidades. Es lento, se equivoca de vez en cuando (un 8 que era un 3, una caja que eran unidades) y se atasca justo cuando más pedidos entran.

Hoy se puede automatizar casi todo ese recorrido, pero “casi” importa: ninguna herramienta lee el 100 % de los pedidos sin fallar, y lo que separa una solución útil de una abandonada es qué pasa con los pedidos que no salen bien. Esta guía explica las opciones reales, cómo es una solución bien hecha, cuándo compensa y qué preguntar antes de contratar a nadie (a mí incluido).

Primero, mira qué te llega de verdad

Antes de hablar de herramientas, coge una semana de pedidos y sepáralos en tres montones. Es gratis y decide más que cualquier demo.

1. Ficheros estructurados: Excel con columnas fijas, CSV, XML o EDI. No necesitan IA, se importan con reglas (en Odoo, por ejemplo, los XML no gastan créditos de digitalización, documentación).
2. PDF generados por el programa del cliente: cada cliente tiene su formato, siempre el mismo. Aquí la lectura con IA suele funcionar bien.
3. Texto libre y fotos: “mándame 4 cajas de lo de siempre y 2 del nuevo”. Lo más difícil, porque falta información que solo sabe tu comercial.

Si el 70 % de tu volumen está en el primer montón, lo que necesitas es un importador, no un proyecto de IA. Si está en el segundo y el tercero, sigue leyendo.

Las tres vías y sus límites

1. Lo que trae (o no trae) tu propio ERP

Es lo primero que hay que mirar, porque si tu ERP ya lo hace bien, no tiene sentido pagar otra cosa.

• Business Central es, de los que cito aquí, el que más lejos llega de serie. Su Sales Order Agent vigila un buzón de Microsoft 365, lee asunto, cuerpo y adjuntos PDF, PNG o JPG, identifica al cliente, busca los artículos y crea una oferta que puede convertir en pedido, con un usuario que revisa los mensajes antes de que salgan al cliente. Figura como disponible de forma general, el español está entre sus idiomas validados y se paga con créditos de Copilot (resumen, configuración). Límites: reconoce al cliente solo por el email del remitente (un pedido reenviado por tu comercial no lo reconoce solo, hay que vincularlo a mano) y por defecto procesa 100 emails al día, un tope que se puede cambiar. Más en Business Central.
• Odoo digitaliza de serie sobre todo facturas de proveedor (y, ajustando la configuración, facturas de cliente y abonos), a un crédito por documento; esa página de la documentación no trata los pedidos de venta (Odoo 19). Para pedidos de cliente hay módulos de terceros, como el de automaited, que lee y revisa en su propia plataforma y cobra pasada una cuota gratuita (ficha). Más en Odoo.
• Sage 200: en una respuesta marcada como verificada en el foro oficial de Sage, se explica que un PDF no se integra directamente; hay que convertirlo a Excel o XML para el gestor de importaciones, o preguntar al partner por un módulo de captura (el hilo no precisa cuál) (hilo). Más en Sage 200.
• a3ERP: Wolters Kluwer ofrece Link API, un integrador para conectarlo con otras plataformas, que según su ficha permite crear, leer y actualizar datos como clientes, artículos y documentos de compra y venta (producto); la lectura del pedido la hace otra pieza. Más en a3ERP.
• Holded: su escáner con IA está pensado para facturas y recibos (escáner), no para pedidos de cliente, pero su documentación de API incluye un endpoint para crear pedidos de venta (API). Más en Holded.

Resumen: de los que he revisado, salvo Business Central ninguno anuncia que lea pedidos de cliente por sí solo, pero todos tienen una puerta de entrada (importador, API o módulo de terceros) por la que meter el pedido ya leído. Conviene confirmar qué trae tu versión concreta.

2. Herramientas de captura de documentos con IA

Son servicios en la nube que leen el documento y devuelven los datos estructurados. Las más conocidas, con lo que dicen sus páginas oficiales en octubre de 2026:

Herramienta	Cómo cobra	Lo que conviene saber
Parseur	Por páginas: desde 49 €/mes (100 páginas); 499 €/mes por 10.000; plan gratis de 20 al mes	Un email o una hoja de cálculo cuentan como una página. Se conecta por webhooks, Zapier, Make o API (en todos los planes)
Nanonets	Créditos: 100 USD/mes por 100 créditos tras 50 USD de regalo	Cobra por cada paso del flujo; las integraciones con ERP están en el plan Growth, a presupuesto
Rossum	Desde 18.000 $ al año (la página no indica la moneda), contrato mínimo de un año	Lista los pedidos de venta entre sus tipos de documento; la página no da cifras de volumen
Klippa	A presupuesto, sin precios públicos	Extrae pedidos de compra (número, fechas, líneas, importes) por API, buzón o FTP

Su límite común no es leer, que en general hacen bien, sino lo que pasa después. Te devuelven “Tornillo M8 inox, 200 uds”, pero no saben que en tu ERP eso es la referencia T-M8-INX-C100 y se vende en cajas de 100. Esa traducción, la comprobación de precios y el alta en el ERP hay que montarlas aparte. Por eso la licencia casi nunca es el coste real.

3. Desarrollo a medida

Consiste en montar el flujo con piezas conocidas: un buzón, un servicio de IA para leer (cuestan céntimos por página; Amazon Textract cobra 0,01 USD por página en su análisis de facturas y recibos (primer millón de páginas al mes, región de Oregón), precios), la validación contra tus datos y la conexión con el ERP. Tiene sentido cuando tus pedidos tienen particularidades (referencias del cliente, tarifas especiales, varios almacenes) o quieres que todo quede a tu nombre. El riesgo es que se eternice si no se acota bien.

Las tres vías se combinan: es frecuente usar una herramienta de captura para leer y una capa a medida para validar y meter el pedido en el ERP.

Cómo funciona una solución bien hecha

Da igual qué herramienta uses: si falta alguna de estas piezas, el sistema acabará generando más trabajo del que quita.

1. Un buzón dedicado. Los pedidos llegan a pedidos@tuempresa.es o se reenvían ahí con una regla.
2. Clasificación. No todo lo que llega es un pedido: hay consultas, reclamaciones, condiciones generales adjuntas. Hay que separar antes de leer.
3. Lectura. Se extraen cliente, número de pedido del cliente, fecha de entrega, dirección y líneas (referencia, descripción, cantidad, unidad, precio).
4. Validación contra los datos maestros del ERP. Es la pieza que más valor aporta y la que más se olvida:
   • ¿El cliente existe? ¿Por email, por CIF, por nombre?
   • ¿Cada referencia existe? Si el cliente usa sus propios códigos, hace falta una tabla de equivalencias que crezca con el uso.
   • ¿La unidad cuadra? Cajas frente a unidades es la fuente de error más típica.
   • ¿El precio del pedido coincide con la tarifa del cliente?
   • ¿Ese número de pedido ya entró? Si el cliente lo reenvía, no puede crearse dos veces.
5. Bandeja de excepciones. Lo que no pasa la validación no se pierde ni se carga mal: va a una lista donde una persona ve el PDF junto a lo leído, corrige y aprueba. Corregir un campo marcado suele ser mucho más rápido que teclear el pedido entero.
6. Alta en el ERP como borrador o como pedido, según la confianza. Microsoft crea primero una oferta, que no afecta a stock ni a planificación, y la convierte después en pedido (configuración). Es un buen patrón para cualquier ERP.
7. Registro. Qué llegó, qué se leyó y quién lo corrigió. Sin eso no puedes medir si funciona.

Cuándo vale la pena

No hay un número mágico, pero sí tres preguntas que lo deciden:

• ¿Cuántos pedidos y cuántas líneas? Diez pedidos de 3 líneas al día no son lo mismo que diez de 40.
• ¿Cuántos formatos distintos? Cinco clientes que suponen el 80 % del volumen son un caso ideal: se afinan esos cinco formatos y el resto pasa a la bandeja.
• ¿Qué hace la persona con el tiempo que se libera? Las horas ahorradas solo son dinero si se dedican a otra cosa (atender clientes, vender, controlar stock) o si evitan una contratación.

Ejemplo de cálculo (con supuestos explícitos)

Este ejemplo es ilustrativo, no un resultado medido. Cambia los supuestos por los tuyos o, más rápido, pon tus números en la calculadora del coste de los pedidos manuales.

• Coste por hora: 22,32 € por hora pagada, coste laboral medio de todos los sectores en el segundo trimestre de 2026 según el INE (ETCL 2T 2026). Es una media nacional que incluye cotizaciones; en comercio el coste mensual por trabajador es menor (2.939,88 € frente a 3.388,15 €), así que tu cifra puede ser algo más baja.
• Supuesto: 8 minutos por pedido tecleado a mano. Cronométralo tú; es el dato que más cambia el resultado.
• Supuesto: tras automatizar, el 80 % de los pedidos pasa la validación y se revisa en 1 minuto; el 20 % restante va a la bandeja y lleva 4 minutos.
• Supuesto: 100 € al mes de coste de funcionamiento (licencias, IA y alojamiento).
• Supuesto: un proyecto de 6.000 €. Es una cifra redonda para el ejemplo, no un presupuesto.

	600 pedidos al mes	100 pedidos al mes
Horas tecleando ahora	80 h	13,3 h
Coste actual	1.785,60 €	297,60 €
Horas después (revisión y excepciones)	16 h	2,7 h
Coste después	357,12 €	59,52 €
Ahorro neto al mes (menos 100 € de funcionamiento)	1.328,48 €	138,08 €
Meses para recuperar 6.000 €	unos 4,5	unos 43

Con 600 pedidos al mes el proyecto se paga en menos de medio año; con 100 tardaría más de tres años y probablemente no compense, salvo que los errores te cuesten dinero (devoluciones, portes repetidos), algo que este cálculo no incluye. A ese volumen, una herramienta de captura sencilla o un buen importador desde Excel suelen ser mejor opción que un desarrollo.

Errores típicos

• Creerse el “99 % de precisión”. Suele ser precisión por campo, no por pedido. Un pedido de 10 líneas con 5 datos por línea tiene 50 campos; si cada uno acierta al 99 %, solo unos 6 de cada 10 pedidos saldrían perfectos (0,99 elevado a 50 da 0,605). Por eso la bandeja de excepciones no es opcional.
• Cargar directo en el ERP sin validar. Un pedido mal leído que entra confirmado reserva stock, sale en la ruta del almacén y se factura. Es peor que no automatizar.
• No prever las referencias del cliente. Si piden con sus códigos, la tabla de equivalencias es el corazón del sistema.
• No medir antes. Si no sabes cuánto tardáis hoy, no sabrás si ha mejorado.
• Olvidar los datos personales. Los emails de pedidos llevan nombres y direcciones; quien los procese por ti es encargado del tratamiento y necesitas un contrato u otro acto jurídico con él (RGPD, artículo 28).
• Quedarte atado. Si las cuentas y el código están a nombre del proveedor, cambiar de proveedor es empezar de cero.

Cómo elegir proveedor

Sea una herramienta, un partner de tu ERP o un desarrollador independiente, pídele esto antes de firmar:

1. Una prueba con tus pedidos reales, no con los de su demo. Veinte o treinta de tus clientes más habituales bastan.
2. Qué pasa con lo que falla. Que te enseñe la bandeja de excepciones, no solo los pedidos que salen bien.
3. Cómo valida contra tu ERP: clientes, referencias, unidades, precios y duplicados.
4. Coste total: licencia, consumo por documento, mantenimiento y lo que cuesta añadir un formato nuevo.
5. De quién es todo: las cuentas, el código y los datos. En mis proyectos el código queda en un repositorio tuyo y las cuentas a tu nombre, sin permanencia.
6. Qué ocurre si el ERP se actualiza o si cambia el formato de un cliente.

Si no tienes claro por dónde empezar, el diagnóstico de procesos sirve para eso: mirar tus pedidos reales, medir el tiempo actual y decir qué vía te encaja, aunque la respuesta sea “con tu volumen, no compensa”. Si ya lo tienes claro, la automatización de un proceso monta el flujo completo con alcance y precio cerrados.