Cómo automatizar pedidos de clientes que llegan por email, Excel o PDF antes de introducirlos en el ERP

Leer el pedido no significa que esté listo para el ERP

La escena es habitual en empresas industriales B2B: administración comercial recibe pedidos por correo y cada cliente utiliza su propio formato. Uno envía una plantilla Excel con códigos propios; otro utiliza un PDF exportado desde su sistema; otro añade en el email que la tercera línea debe entregarse en otra dirección. La persona que procesa el pedido no se limita a transcribir. Interpreta, compara, corrige, pregunta y decide qué puede introducir en el ERP.

Por eso el reto no se resuelve con una cadena del tipo PDF → OCR → ERP. Un lector documental puede recuperar texto y tablas, pero no sabe automáticamente si el código del cliente corresponde a una referencia interna, si la unidad es correcta, si una dirección sigue vigente o si el pedido ya fue procesado ayer con otro nombre de archivo.

La automatización necesita distinguir dos preguntas. La primera es qué parece decir el pedido. La segunda es qué puede aceptar realmente la empresa como pedido de venta. La IA aporta mucho en la primera. La segunda depende de maestros, reglas comerciales, datos del ERP y controles de escritura.

Este enfoque profundiza un problema que ya aparece en la automatización de pedidos, albaranes y facturas hacia ERP. Aquí el protagonista es únicamente el pedido recibido de un cliente antes de convertirse en pedido de venta. No hablamos de órdenes de compra a proveedores, que pertenecen al proceso de compras y aprovisionamiento.

Una vez que el pedido ya está creado correctamente en el ERP, el recorrido continúa con preparación, salida, transporte y entrega. Ese tramo se desarrolla en la guía sobre automatización de expediciones y avisos de entrega.

Email, Excel y PDF necesitan tratamientos distintos

Forzar todos los pedidos por el mismo extractor suele añadir complejidad innecesaria. El formato determina qué información ya está estructurada y qué parte necesita interpretación.

Un Excel suficientemente estable debería leerse como hoja de cálculo. Si cada cliente utiliza una plantilla distinta, puede existir una capa de mapeo por cliente o una normalización posterior. Incluso entonces sigue siendo mejor aprovechar la estructura disponible antes de recurrir a visión o OCR.

Un PDF digital puede permitir extracción directa de texto y tablas. Un escaneado puede requerir OCR o un servicio de Document AI. Microsoft Azure Document Intelligence y Amazon Textract son ejemplos de plataformas capaces de extraer campos o estructuras tabulares de documentos. Eso resuelve la lectura, no las reglas de negocio.

Y cuando existe intercambio estructurado, la arquitectura cambia. Odoo documenta, por ejemplo, un flujo EDI donde una orden de compra del comprador en XML basado en UBL puede convertirse en un pedido de venta del vendedor. El interés del ejemplo no es Odoo, sino la idea: si el dato ya llega estructurado, no tiene sentido convertirlo primero en un problema documental.

Cinco controles antes de crear el pedido

Una vez interpretado el documento, el pedido debería atravesar una zona intermedia antes de escribir en ERP. Esa zona no es un segundo ERP: sirve para normalizar, comprobar y decidir si el pedido puede avanzar o necesita revisión.

El orden puede variar según la empresa. Algunas validaciones pueden hacerse en paralelo y otras depender de consultas previas. Lo importante es no saltar directamente de “he extraído cinco campos” a “he creado una transacción económica”.

Antes de validar, conviene convertir entradas distintas en un mismo esquema de pedido

Si cada formato conserva su propia estructura hasta el momento de escribir en el ERP, las reglas se multiplican. El Excel del cliente A puede llamar “Referencia” a una columna; el cliente B utiliza “Código material”; el PDF del cliente C no tiene columna de código y solo aporta descripción. La automatización necesita una representación común para poder aplicar después los mismos controles.

Ese esquema intermedio puede contener, por ejemplo, identificador externo del pedido, cliente candidato, dirección solicitada, líneas, referencia recibida, descripción, cantidad, unidad, fecha solicitada y observaciones relevantes. No es todavía el pedido del ERP. Es una versión normalizada que conserva lo que dijo el cliente y permite saber qué datos están resueltos y cuáles siguen pendientes.

La separación aporta una ventaja importante: evita sobrescribir demasiado pronto la información original. Si el cliente pidió “REF-874” y el sistema propone “SKU-4521”, conviene conservar ambos valores. El primero explica qué recibió la empresa; el segundo representa la correspondencia interna que se utilizará si supera la validación.

También debería mantenerse trazabilidad hacia la fuente. Cuando una persona revisa una excepción necesita saber si un dato salió del cuerpo del email, de la celda G18 del Excel o de una línea concreta del PDF. No hace falta mostrar coordenadas técnicas al usuario final, pero sí conservar suficiente contexto para poder reconstruir por qué el sistema propuso ese valor.

Esta capa es especialmente útil cuando interviene IA. El modelo puede convertir expresiones variables en una estructura común, pero cada campo puede conservar estado y procedencia. Así, “fecha solicitada” puede existir aunque todavía no sepamos si la empresa puede comprometerla, y “producto candidato” puede estar propuesto sin que la línea se considere validada.

Identificar correctamente al cliente antes de utilizar sus condiciones

El email del remitente puede ser una señal, pero no siempre identifica de forma suficiente a la entidad que realiza el pedido. Una misma persona puede comprar para varias sociedades, una dirección puede pertenecer a varios centros y un dominio corporativo puede tener múltiples cuentas de cliente.

La resolución puede apoyarse en datos como:

• Código de cliente cuando existe y es fiable.
• NIF u otro identificador empresarial incluido en el pedido.
• Razón social normalizada.
• Dirección de entrega o facturación cuando forma parte de la identificación.
• Número de contrato o acuerdo si el proceso lo utiliza.
• Referencias históricas entre remitentes y cuentas conocidas.

La IA puede ayudar cuando los nombres o direcciones llegan escritos de forma variable: “ACME Valencia”, “ACME S.L. Delegación Levante” o una dirección abreviada. Puede proponer candidatos y explicar por qué parecen coincidir. Una similitud textual no debería convertirse automáticamente en autorización para elegir una cuenta cuando varias opciones son posibles.

También debe existir un tratamiento explícito para el cliente aparentemente nuevo. No encontrar coincidencia no significa que la automatización deba crear un maestro de cliente. Esa creación puede requerir datos adicionales, controles de crédito, condiciones contractuales o un proceso separado.

La referencia del cliente puede no ser la referencia que utiliza el ERP

En relaciones B2B es normal que comprador y vendedor utilicen códigos distintos para el mismo producto. El pedido puede indicar “REF-CLIENTE-874”, mientras que el ERP trabaja con “SKU-4521”. También pueden existir variantes, packs, unidades de medida o presentaciones que obliguen a resolver algo más que un nombre.

Una tabla de equivalencias conocida es la opción más determinista. Cuando no existe, el sistema puede combinar descripción, histórico, atributos y contexto para proponer candidatos. La IA puede ser útil aquí, pero el resultado debería conservar un estado comprensible:

• Coincidencia exacta.
• Equivalencia conocida.
• Coincidencia ambigua.
• Referencia desconocida.
• Producto no válido para ese cliente o pedido según el sistema.

Una descripción parecida no basta cuando dos productos pueden encajar. “Cable 5 m negro” puede corresponder a varias familias, secciones o acabados. La automatización debería pedir revisión antes de crear una línea cuyo significado no esté suficientemente resuelto.

Las unidades también importan. Un cliente puede pedir 20 cajas y el ERP trabajar en unidades, o indicar una cantidad que no coincide con el formato de venta. Convertir unidades requiere una regla conocida. No es una tarea para improvisar con lenguaje natural.

El pedido del cliente expresa lo que solicita; no sustituye las condiciones del sistema

Un pedido puede incluir un precio antiguo, una referencia que ya fue sustituida, una moneda inesperada, una fecha solicitada que requiere revisión o una dirección que no coincide con la configuración actual. El documento recibido es una fuente de intención, no necesariamente la autoridad para cada dato.

Las comprobaciones dependen del negocio. Entre otras, pueden existir:

• Tarifa o precio vigente cuando la empresa deba validarlo antes de crear o confirmar.
• Descuento autorizado cuando haya límites o acuerdos específicos.
• Moneda e impuestos según configuración comercial y fiscal.
• Fecha solicitada frente a las reglas o compromisos que pueda aceptar la empresa.
• Cantidad mínima o formato de venta cuando exista esa condición.
• Bloqueos comerciales que el ERP u otro sistema deba confirmar.
• Disponibilidad cuando forme parte de la política previa a creación o confirmación.

No todas las empresas comprueban stock antes de crear un pedido. Algunas trabajan bajo pedido, otras crean primero y planifican después. Por eso la arquitectura debe representar las condiciones que esa empresa necesita antes de crear o confirmar, no imponer un checklist universal.

En determinados sectores también pueden existir requisitos sobre lote, vida útil residual, tolerancias de cantidad o características de suministro. Deben tratarse como condiciones específicas del proceso cuando el ERP o el sistema correspondiente las gestione, no como comprobaciones universales de cualquier pedido.

Pedido recibido, pedido creado y pedido confirmado son estados diferentes

Un error de diseño frecuente es utilizar “pedido procesado” para situaciones distintas. Conviene separar al menos recepción, interpretación, preparación, creación en ERP y confirmación al cliente cuando esa confirmación exista.

La creación técnica no implica necesariamente confirmación comercial. El ERP puede crear un pedido en estado preliminar, pendiente de revisión o sujeto a una condición posterior. La automatización debe respetar el significado real de los estados de cada sistema.

Cómo evitar pedidos duplicados cuando hay reintentos o fallos de comunicación con el ERP

Imaginemos que la integración envía el pedido al ERP. La operación tarda, se agota el tiempo de espera y la automatización no recibe respuesta. Hay dos posibilidades: el ERP no llegó a crear nada o sí creó el pedido, pero la respuesta se perdió. Repetir la misma escritura sin verificar puede generar un segundo pedido.

Para evitarlo conviene conservar un identificador externo fiable —por ejemplo, el número de pedido del cliente cuando sea adecuado— y registrar qué operación se intentó. Si existe incertidumbre, el siguiente paso puede ser consultar al ERP antes de reintentar.

A este comportamiento se le suele asociar el concepto de idempotencia: repetir una operación no debería producir un efecto adicional cuando el resultado deseado ya se consiguió. No hace falta convertir el proceso comercial en una clase de arquitectura distribuida; sí hace falta diseñar qué ocurre cuando la respuesta es incierta.

La entrada sobre integración entre CRM y ERP desarrolla con más detalle identificadores, reintentos, autoridad del dato y reconciliación. Aquí aplicamos esos principios al caso concreto de crear un pedido de venta.

Las excepciones deben indicar qué falta para poder continuar

No todos los pedidos podrán entrar automáticamente. El objetivo no debería ser ocultar ese hecho, sino conseguir que los casos que necesitan revisión lleguen con suficiente contexto.

Un pedido también puede mezclar líneas correctas y líneas problemáticas. La política de la empresa decidirá si se bloquea todo, se separan líneas o se solicita aclaración. No hay una respuesta universal. Lo importante es que el sistema no pierda qué pudo resolver y qué sigue pendiente.

Cuando se permite procesar parcialmente, la automatización debe evitar otra confusión: que una parte creada en ERP parezca representar el pedido completo del cliente. El estado debe indicar qué líneas entraron, cuáles quedaron fuera y si falta una decisión comercial antes de continuar. Si la política exige bloquear el pedido completo hasta resolver todas las líneas, esa regla debe ser explícita y no depender de una interpretación puntual del operador.

Las excepciones también pueden agruparse por causa. Si muchos pedidos de un mismo cliente fallan porque cambió su plantilla Excel, probablemente no estamos ante diez incidencias independientes, sino ante un cambio de formato que merece actualizar el mapeo. Si varias líneas fallan por una referencia nueva, puede existir una equivalencia pendiente de incorporar al maestro o a la tabla autorizada.

Una zona intermedia prepara el pedido antes de tocar el ERP

Para un decisor no técnico, la arquitectura puede entenderse en seis zonas:

SAP S/4HANA y Microsoft Dynamics 365 son ejemplos de ERPs que exponen mecanismos estructurados para trabajar con pedidos de venta desde sistemas externos. Odoo ofrece otro ejemplo mediante importaciones y flujos EDI. La herramienta concreta cambia; la necesidad de respetar el modelo de datos y los mecanismos soportados permanece.

La capa intermedia no debería convertirse por defecto en un segundo ERP con su propio catálogo paralelo de clientes, productos y precios. Puede conservar claves, mapeos y estado de procesamiento, pero los maestros necesitan una autoridad clara.

Después de la creación puede existir una comunicación al cliente, pero conviene tratarla como una acción posterior y condicionada. El mensaje no debería afirmar que el pedido está confirmado solo porque la integración terminó sin error técnico. Debe utilizar el estado que el proceso comercial haya definido como válido para comunicar aceptación, revisión, fecha o cualquier otra condición.

Ese detalle parece pequeño, pero evita que el canal de salida se convierta en una fuente de verdad paralela. Email, portal o EDI pueden comunicar el resultado; el estado que sustenta esa comunicación debe proceder del sistema autorizado.

Mover al ERP solo los datos que necesita el pedido

Los pedidos pueden contener nombres de contacto, teléfonos, emails, direcciones y comentarios comerciales. La automatización no necesita copiar indiscriminadamente todo el cuerpo del correo o todos los adjuntos en cada sistema participante.

Conviene mantener una separación entre el documento original, los datos extraídos necesarios y el registro definitivo en ERP. Esto facilita aplicar minimización, limitar accesos y evitar que información irrelevante termine replicada en herramientas auxiliares.

Las credenciales de correo y ERP también deben operar con los permisos necesarios para su función. Si el proceso solo necesita leer un buzón concreto y crear pedidos mediante una operación determinada, no hay motivo para entregar a la automatización permisos administrativos generales. Este criterio se desarrolla en permisos y credenciales en automatizaciones con IA.

Qué indicadores utilizar para medir la entrada de pedidos

Antes de atribuir mejoras a una automatización conviene medir el proceso actual con definiciones estables. El objetivo es saber dónde se concentra el trabajo y qué cambia después.

• Pedidos recibidos por canal y formato.
• Porcentaje procesado sin intervención humana.
• Porcentaje que necesita revisión.
• Tiempo desde recepción hasta creación en ERP.
• Tiempo dedicado a excepciones.
• Líneas con referencia de producto no resuelta.
• Pedidos bloqueados por identidad del cliente.
• Duplicados detectados o evitados.
• Escrituras fallidas o de resultado incierto.
• Retrabajo detectado después de crear el pedido.

El porcentaje automatizado no es suficiente. Un flujo puede procesar muchos documentos y seguir dejando demasiada revisión manual en los casos importantes. La entrada sobre KPIs de automatización explica cómo comparar resultado, excepciones, calidad y coste respecto a una línea base.

Preguntas frecuentes sobre automatización de pedidos de clientes

Antes de automatizar la escritura en ERP, conviene revisar cómo entra realmente cada pedido

Si administración comercial recibe pedidos por email, Excel y PDF y todavía necesita interpretar referencias, comprobar condiciones y copiar líneas manualmente, podemos analizar el proceso desde la recepción hasta la creación en ERP.

La revisión permite separar qué parte puede resolverse con lectura estructurada, dónde aporta IA, qué datos deben confirmarse contra maestros, qué excepciones necesitan una persona y cómo escribir en ERP sin perder trazabilidad ni crear duplicados.