# Automatizar pedidos B2B: del documento recibido al pedido validado en el ERP

> Cómo automatizar pedidos B2B desde email, PDF o EDI hasta el ERP, con validación de precios y stock, excepciones gobernadas y métricas de negocio.

- Canonical: https://arkatai.com/automatizar-pedidos-b2b/
- Site: Arkatai (https://arkatai.com) — agentic operations as a service
- Language: es
- Published: 2026-09-01

---


Automatizar pedidos B2B no consiste en copiar con más rapidez las líneas de un PDF al ERP. Consiste en sostener el recorrido completo desde que el cliente envía el pedido hasta que queda registrado, validado y preparado para servir. El caso feliz es fácil. El trabajo real está en reconocer al cliente, interpretar referencias, comprobar precios y condiciones, contrastar stock y decidir qué hacer cuando algo no cuadra.

Ese recorrido suele estar repartido entre buzones, hojas de cálculo, portales, EDI y pantallas del ERP. Una persona une las piezas porque conoce las abreviaturas del cliente, recuerda la última tarifa negociada y sabe a quién preguntar cuando falta stock. Para automatizarlo hay que convertir ese conocimiento operativo en reglas, datos y excepciones explícitas. El resultado no es un bot que teclea: es una operación medible que registra los pedidos normales y prepara los anómalos para una decisión humana.

En Arkatai tratamos esa operación como un servicio. El cliente conserva sus reglas comerciales, permisos y arquitectura operativa; Arkatai despliega, opera y mantiene el workforce que ejecuta el trabajo. El marco general está en [operaciones gestionadas con agentes](/operacion-gestionada-con-ia/). Aquí bajamos a la gestión de pedidos B2B.

## Qué significa automatizar la gestión de pedidos

El límite correcto no es “leer el documento”. Una automatización de pedidos completa debe cubrir, como mínimo, seis estados:

1. **Recepción.** Detectar el pedido en el canal acordado: email, portal, EDI, formulario o integración.
2. **Identificación.** Determinar qué cliente compra, qué sociedad vende y qué reglas contractuales aplican.
3. **Extracción y normalización.** Convertir referencias, unidades, cantidades, fechas y direcciones al modelo interno.
4. **Validación.** Contrastar tarifa, descuentos, crédito, stock, cantidades mínimas y condiciones de entrega.
5. **Registro.** Crear el pedido en el ERP de forma idempotente, sin duplicarlo si el sistema reintenta.
6. **Confirmación o escalado.** Comunicar el resultado o preparar una excepción con el contexto necesario.

Una automatización que solo cubre los tres primeros pasos reduce tecleo, pero deja intacta la parte más cara: perseguir diferencias y decidir qué hacer con ellas. Por eso el indicador principal no debería ser “documentos leídos”, sino pedidos correctamente registrados sin intervención y dentro del tiempo comprometido.

## Entradas que un sistema de pedidos debe entender

En B2B no existe un único formato. Un cliente manda un PDF generado por su sistema; otro adjunta una hoja de cálculo; un tercero escribe dos líneas en el cuerpo del correo; los clientes grandes usan EDI y algunos comerciales siguen trasladando pedidos telefónicos. Obligar a todos a usar un portal puede ordenar el problema, pero también introducir fricción comercial.

La operación debe aceptar únicamente los canales que se hayan incorporado y probado. No conviene prometer que “entiende cualquier documento”. Para cada canal se define un contrato de entrada: campos obligatorios, formatos conocidos, tolerancias y comportamiento cuando falta información. En los [pedidos recibidos por email](/automatizar-pedidos-recibidos-por-email/) intervienen además los adjuntos, los hilos, las firmas y el riesgo de procesar dos veces el mismo mensaje.

El sistema transforma esas entradas heterogéneas en un objeto de pedido común. Esa normalización permite que las reglas de validación no dependan del formato original y que cada decisión pueda reconstruirse después.

## Validar precio, stock y condiciones antes de escribir

Registrar primero y corregir después multiplica el coste. Antes de crear el pedido, la operación debe contrastar cada dato contra una fuente autorizada.

| Comprobación | Fuente habitual | Si no coincide |
|---|---|---|
| Identidad del cliente | Maestro de clientes | Detener y pedir identificación |
| Referencia | Catálogo o tabla de equivalencias | Proponer coincidencia y escalar |
| Precio y descuento | Tarifa y acuerdo comercial | Escalar según tolerancia |
| Stock disponible | ERP o sistema de almacén | Aplicar política de sustitución o fecha |
| Crédito | ERP financiero | Bloquear o pedir autorización |
| Dirección y fecha | Maestro y calendario logístico | Corregir dentro de regla o escalar |

No todas las diferencias merecen el mismo tratamiento. Una referencia antigua puede tener una sustituta inequívoca; un precio fuera de tarifa puede requerir aprobación; un cliente bloqueado no debería continuar bajo ninguna circunstancia. Los permisos se fijan por acción y riesgo, no por una confianza genérica en el modelo. Ese patrón se desarrolla en [permisos y controles de agentes](/permisos-y-controles-de-agentes/).

## Integrar los pedidos con el ERP sin crear otra isla

El ERP debe seguir siendo el sistema de registro. La automatización ocupa el trabajo que ocurre antes y alrededor: reúne la información, aplica las reglas, crea el registro mediante una interfaz controlada y verifica que la respuesta del ERP coincide con lo enviado.

La integración puede usar una API, una cola, una capa de servicios o, como último recurso, automatización de interfaz. La elección depende de lo que el sistema permita, pero hay tres invariantes. Primero, cada pedido debe llevar una clave que impida duplicados. Segundo, la escritura debe devolver un identificador verificable. Tercero, el sistema debe conservar qué datos leyó, qué reglas aplicó y qué respuesta recibió.

Conectar una API no resuelve por sí solo la semántica del proceso. El mismo campo puede significar “fecha solicitada” en el documento y “fecha confirmada” en el ERP. La integración necesita contratos de datos y reglas de transformación, como explica la guía de [integración de agentes con ERP](/integrar-agentes-con-el-erp/).

## Las excepciones son parte del diseño

Precio incorrecto, falta de stock, referencia desconocida, dirección nueva, crédito bloqueado o pedido duplicado no son fallos marginales. Son el trabajo que define la gestión de pedidos. Un diseño que solo automatiza pedidos perfectos y arroja el resto a un buzón común desplaza el problema, no lo resuelve.

Cada excepción necesita una clase, una causa observable, un responsable y una salida prevista. El sistema puede resolver algunas dentro de reglas: usar la referencia sustituta aprobada, proponer la siguiente fecha disponible o pedir al cliente un dato que falta. Otras requieren una decisión humana. En ambos casos debe entregar el contexto ya preparado. La guía de [excepciones de pedidos](/gestionar-excepciones-de-pedidos/) desarrolla esa arquitectura.

## Qué medir antes y después

La línea base se obtiene con una muestra representativa, no con impresiones del equipo. Durante varias semanas conviene medir:

- pedidos recibidos y líneas por pedido;
- minutos de trabajo humano por pedido;
- porcentaje registrado sin corrección posterior;
- errores por tipo y punto de detección;
- tiempo desde recepción hasta confirmación;
- porcentaje y causa de las excepciones;
- coste administrativo por pedido;
- incidencias aguas abajo atribuibles al alta inicial.

Después del despliegue se comparan las mismas unidades. “El agente procesó 8.000 documentos” no demuestra valor si aumentaron las correcciones o si las personas siguen revisando todos los casos. Una métrica defendible combina autonomía y calidad: porcentaje de pedidos completados sin intervención que además superan las comprobaciones acordadas.

## Cómo empezar con un alcance controlado

El primer lote debe tener suficiente volumen y variación para aprender, pero límites claros. Una buena frontera puede ser una sociedad, un buzón, una familia de clientes y un único ERP. Se excluyen al principio los pedidos con contratos especialmente complejos o canales todavía no instrumentados.

El despliegue empieza en modo observación: el sistema propone el pedido y una persona lo compara con el resultado correcto. Después pasa a escritura con aprobación, y solo cuando la evidencia es suficiente ejecuta sin revisión los casos dentro de umbral. Las excepciones mantienen siempre su ruta de escalado.

El proceso no termina al activar la automatización. Cambian tarifas, catálogos, clientes, formatos y sistemas. Por eso una operación gestionada incluye monitorización, evaluación y adaptación continua. Si el cliente tiene que detectar cada cambio y reparar el agente, ha comprado una herramienta más que mantener.

## Preguntas frecuentes

### ¿Se pueden automatizar pedidos que llegan en PDF o Excel?

Sí, si se definen los formatos, campos necesarios y comportamiento ante ambigüedades. El documento se transforma en un objeto normalizado y después se valida contra las fuentes internas. Extraer texto no basta: el valor aparece cuando el pedido correcto queda registrado y trazado.

### ¿Hace falta cambiar de ERP?

Normalmente no. El ERP continúa como sistema de registro y la operación se integra mediante la interfaz más segura que permita. Lo importante es controlar duplicados, verificar cada escritura y separar las reglas del proceso de las peculiaridades del conector.

### ¿Qué ocurre cuando el precio o el stock no coinciden?

Se aplica la política definida para esa excepción. Algunas diferencias pueden resolverse dentro de tolerancias; otras se bloquean y se entregan a una persona con pedido, cliente, regla incumplida y opciones disponibles. El sistema no inventa una política comercial.

### ¿Cómo sé si el proyecto compensa?

Compara el coste administrativo, el tiempo de ciclo y los errores actuales con el coste de la operación y la calidad obtenida. El volumen por sí solo no basta: también importan la complejidad de las excepciones y el daño que produce un pedido mal registrado.