Cada pedido en una única línea de tiempo, desde la entrada hasta la factura cobrada.
Los procesos del pedido al cobro (order to cash), de la compra al pago (procure to pay) y de la solicitud de servicio a la factura atraviesan el ERP, el CRM, el comercio electrónico, el almacén, el transporte y las finanzas. Los conectamos con API y eventos documentados, damos a cada pedido un único estado en todos esos sistemas y enviamos cada excepción a un agente que prepara una solución para que una persona la apruebe.
Para empresas en España que venden, compran y facturan entre varios sistemas y deben preparar su ERP para Verifactu y la factura electrónica entre empresas.
Planificadores de la cadena de suministro y la logística
Equipos de cuentas a pagar y a cobrar
Integración y operaciones de TI
Flujo de trabajo ilustrativo
01Registrar el evento una sola vezSistema
02Distribuir mediante API y eventosSistema
03Construir una línea de tiempo por pedidoSistema
04Reunir el contexto y proponerAgente
05Aprobar dentro de los umbralesPersona
06Facturar, conciliar y liquidarSistema
07Revisar el flujo y corregir las causasPersona
Un pedido de venta, un pedido de compra o una solicitud de servicio se registra una sola vez en su sistema de registro y se distribuye a los demás sistemas mediante API y eventos documentados. Los eventos de estado forman una única línea de tiempo por pedido. Cuando un paso falla o queda fuera de tolerancia, un agente reúne el contexto y propone una solución, que una persona aprueba antes de que se ejecute en el sistema de registro. Las facturas se intercambian y se concilian como facturas electrónicas estructuradas, y los responsables de proceso revisan el flujo y el estado de las interfaces.
Antes y después
Qué cambia en las operaciones diarias
Hoy
Con el sistema
Hoy
Hoy: Se vuelve a teclear en cada traspaso
Un pedido recibido en la tienda en línea o por el equipo comercial se teclea de nuevo en el ERP, y los datos de entrega y de facturación se copian a mano en los sistemas de almacén, transporte y finanzas.
Con el sistema
Con el sistema: Se introduce una vez y se usa en todas partes
Cada pedido, entrega y factura se crea en el sistema al que pertenece y se publica como evento. Los demás sistemas se suscriben a él en lugar de volver a teclearlo.
Hoy
Hoy: El estado de ayer
Con interfaces por lotes nocturnas, atención al cliente, planificación y finanzas ven cada uno un estado distinto y desfasado del mismo pedido. Un cliente que pregunta dónde está su entrega tiene que esperar a que le devuelvan la llamada.
Con el sistema
Con el sistema: Un único estado actual
Cada pedido o solicitud tiene una única línea de tiempo construida con los eventos de todos los sistemas por los que pasa. Atención al cliente, planificación y finanzas ven los mismos hechos, y también puede verlos un asistente de atención que responde a preguntas sobre el estado.
Hoy
Hoy: Excepciones resueltas por correo
Las roturas de stock, las diferencias de precio, las entregas fallidas y las facturas electrónicas rechazadas se resuelven por correo electrónico y con hojas de cálculo, y después nadie sabe decir quién decidió qué.
Con el sistema
Con el sistema: Las excepciones llegan con una propuesta
Un agente reúne los datos de cada excepción y propone una solución. Una persona la aprueba, la modifica o la rechaza en una única bandeja de excepciones, y la decisión queda registrada.
Hoy
Hoy: Datos maestros que no coinciden
El mismo cliente, proveedor, producto o precio existe en varios sistemas con valores distintos, y nadie es responsable de cuál es el correcto.
Con el sistema
Con el sistema: Un responsable por objeto de datos
Clientes, proveedores, productos y precios tienen cada uno un sistema de registro acordado y un responsable designado. Los duplicados y los conflictos se comunican a ese responsable, en lugar de corregirse en silencio en los sistemas posteriores.
Hoy
Hoy: Cada cambio añade una interfaz
Un nuevo canal de venta, marketplace o sociedad supone otro enlace punto a punto. Las obligaciones nacionales de factura electrónica añaden además un formato estructurado y una red a cada proceso.
Con el sistema
Con el sistema: Las nuevas conexiones reutilizan los mismos contratos
Un nuevo canal, sociedad o red de factura electrónica se conecta una sola vez a API y eventos documentados, en lugar de a cada sistema por separado.
Flujo de trabajo
Cómo funciona el flujo de trabajo
Cuando los datos están limpios, la vía principal no necesita trabajo manual. Cuando un pedido, una entrega o una factura se desvía, el bucle de excepción lo lleva a una persona con las pruebas y una propuesta, y la corrección aprobada vuelve a circular por la misma capa de integración.
Flujo de trabajo ilustrativo
7 pasos · 1 control humano
Leyenda
Sistema
Agente
Persona
Control humano
Vía de excepción
Operaciones conectadas: flujo de trabajo ilustrativo con bucle de excepción
Leer el diagrama como texto
La vía principal va desde el registro de un evento de negocio, una sola vez y en su sistema de registro, pasando por su distribución a los demás sistemas mediante API y eventos y la construcción de una línea de tiempo por pedido, hasta la facturación, la conciliación y la liquidación. Termina con la revisión del flujo por parte de los responsables de proceso y la corrección de las causas de las excepciones.
Cuando un paso falla, se retrasa o queda fuera de tolerancia, la excepción sale de la vía principal después del paso de la línea de tiempo. Un agente reúne el contexto y propone una solución, y una persona la aprueba, la modifica o la rechaza. La acción aprobada se ejecuta en el sistema de registro y vuelve al paso de distribución como un nuevo evento.
El paso de aprobación es el punto de control humano: ninguna contabilización financiera, ningún cambio de precio o de límite de crédito y ningún compromiso con un cliente se produce sin una persona.
01
Paso 1: Registrar el evento una sola vezSistema
Un pedido de venta de la tienda en línea, un marketplace, EDI o el equipo comercial, un pedido de compra o una solicitud de servicio se crea en el sistema al que pertenece. Ese sistema publica un evento de negocio en un sobre CloudEvents, descrito en un contrato AsyncAPI. Los pedidos y las facturas de proveedores en papel o en PDF pasan antes por la inteligencia documental.
02
Paso 2: Distribuir mediante API y eventosSistema
La capa de integración entrega el evento a los sistemas de almacén, transporte, finanzas y CRM a través de sus API documentadas (OpenAPI). Los consumidores son idempotentes, de modo que un mensaje repetido nunca crea un segundo envío ni una segunda factura, y los mensajes que no pueden entregarse esperan en una cola de errores hasta que se reproducen.
03
Paso 3: Construir una línea de tiempo por pedidoSistema
Los eventos de estado de todos los sistemas (confirmado, preparado, expedido, entregado, facturado, cobrado) se correlacionan por la referencia de negocio en una única línea de tiempo. Las reglas de hitos y de tolerancia generan una excepción cuando un paso falla, se retrasa o no cuadra: una rotura de stock, un precio fuera de la tolerancia acordada, una entrega fallida o una factura electrónica rechazada.
04
Paso 4: Reunir el contexto y proponerAgente
Para cada excepción, un agente lee lo que necesita de los sistemas implicados: el pedido, los niveles de stock, el acuerdo de precios, el estado del transportista y las condiciones del cliente. Propone una solución con su razonamiento y los datos que ha utilizado, como un artículo sustitutivo, un precio corregido, una nueva fecha de entrega o una factura rectificativa.
Vía de excepción: Paso fallido o fuera de tolerancia
05
Paso 5: Aprobar dentro de los umbralesPersona
Una persona de atención al cliente, logística o finanzas ve en la bandeja de excepciones la excepción, las pruebas y la propuesta, y la aprueba, la modifica o la rechaza. La acción aprobada se ejecuta a través de la API del sistema de registro, que publica el cambio como un nuevo evento.
Vía de excepción: Paso fallido o fuera de tolerancia· Vuelve al paso 2
Control humano
Los agentes nunca contabilizan transacciones financieras, cambian precios o límites de crédito ni asumen compromisos con un cliente sin aprobación. Los umbrales por tipo de acción determinan quién aprueba, y cada propuesta y cada decisión quedan registradas.
06
Paso 6: Facturar, conciliar y liquidarSistema
Las facturas emitidas salen del ERP como facturas electrónicas estructuradas (Peppol BIS Billing 3.0, EN 16931) a través de un punto de acceso. Las facturas recibidas de proveedores se concilian con los pedidos de compra y las entradas de mercancía, y el estado de pago del banco o del proveedor de pagos cierra la línea de tiempo.
07
Paso 7: Revisar el flujo y corregir las causasPersona
Los responsables de proceso y el equipo de integración revisan con una periodicidad fija las excepciones por motivo, los fallos de interfaz y los conflictos de datos maestros. Corrigen la causa donde está, en un registro de datos maestros, una regla de tolerancia o un mapeo, en lugar de resolver otra vez la misma excepción.
Componentes
Qué construiríamos
01
Capa de integración basada en eventos
API y eventos diseñados a partir del contrato entre ERP, CRM, comercio electrónico, almacén, transporte y finanzas, especificados en OpenAPI y AsyncAPI con sobres CloudEvents, sobre su plataforma de integración actual o construidos de forma nativa en la nube.
Un sistema de registro y un responsable acordados por objeto de datos, reglas de correspondencia para clientes, proveedores y productos, e informes de duplicados y conflictos para las personas responsables de esos datos.
Un servicio que correlaciona los eventos en una línea de tiempo por pedido o solicitud, aplica reglas de hitos y de tolerancia, y muestra el flujo y las excepciones a los responsables de proceso.
Una cola de excepciones que muestra el contexto reunido y la propuesta del agente, con acciones para aprobar, modificar y rechazar, y umbrales de aprobación por tipo de acción que se aplican en el punto donde se ejecuta la acción.
Facturas Peppol BIS Billing 3.0 y EN 16931 en UBL, enviadas y recibidas a través de un punto de acceso, validadas antes del envío, con las facturas rechazadas derivadas a la bandeja de excepciones.
Supervisión del estado y alertas por interfaz, runbooks para el equipo de operaciones y reproducción controlada de los mensajes fallidos, desplegado con infraestructura como código en su tenant de cloud.
Solicitudes de servicio y partes de trabajo de campo
Eventos de seguimiento y de entrega de los transportistas
Facturas electrónicas Peppol y respuestas de estado
Extractos bancarios y avisos de pago
Núcleo de la solución
Operaciones conectadas
Sistemas con los que trabaja
Ventas, compras y finanzas de SAP S/4HANAPlataformaSAP
Salesforce Sales Cloud, Service Cloud y Commerce CloudPlataformaSalesforce
Ventas, inventario, compras y contabilidad de OdooPlataformaOdoo
Plataformas de comercio electrónico, marketplaces y API de transportistas
Sistemas de gestión de almacenes y de transporte
Punto de acceso Peppol, bancos y proveedores de pagos
Gestión de la información de producto y plataforma de datos
Controles
Controles integrados desde el diseño
Límites de acceso
Cada integración y el agente funcionan con su propia identidad de servicio en cada sistema, limitada a las operaciones de API que necesitan. El agente puede leer en varios sistemas para reunir el contexto, pero solo puede escribir mediante una lista corta de acciones aprobadas, que se ejecutan a través de la API del sistema de registro y nunca con acceso directo a la base de datos.
Revisión humana
Los umbrales de aprobación se fijan por tipo de acción con el responsable del proceso: qué puede solo proponer el agente, qué aprueba un miembro del equipo y qué necesita un segundo aprobador. Las contabilizaciones financieras, los cambios de precio y de límite de crédito y los compromisos con clientes siempre esperan a una persona. Las acciones de bajo impacto y reversibles, como reintentar un mensaje fallido, pueden ejecutarse sin aprobación si el responsable está de acuerdo.
Trazabilidad
Cada evento, propuesta, aprobación, rechazo y acción ejecutada se registra con la referencia del pedido o de la solicitud, junto con los datos que usó el agente, la versión del modelo y del prompt y la persona que aprobó. Una factura discutida o una queja de un cliente pueden rastrearse paso a paso.
Protección de datos
Los datos de contacto de clientes y proveedores solo llegan a los sistemas que los necesitan. La línea de tiempo guarda referencias de negocio y estados, no registros completos, y los registros de actividad siguen la conservación que usted fije. El tratamiento se mantiene en la región acordada.
Transparencia de la IA
Las propuestas del agente se marcan como tales en la bandeja de excepciones, con las pruebas y el razonamiento a su lado. Los sistemas de registro siguen siendo la referencia: la línea de tiempo muestra lo que comunican y nunca prevalece sobre ellos.
Indicadores
Qué mediríamos
Acordamos estas métricas con usted durante la fase de análisis y tomamos la línea de base de los registros actuales de sus sistemas e interfaces antes de cambiar nada.
Qué mediríamos
Indicador
Por qué importa
Cómo lo mediríamos
01Tiempo de ciclo del pedido
Por qué importaLa métrica que los clientes perciben primero, y la que muestra dónde esperan los pedidos.
Cómo lo mediríamosTiempo desde la recepción del pedido hasta la entrega y hasta el cobro, por canal y sociedad, a partir de los eventos de la línea de tiempo.
02Pedidos sin intervención manual
Por qué importaMuestra qué parte del flujo funciona con datos limpios y reglas acordadas.
Cómo lo mediríamosProporción de pedidos y solicitudes que llegan a la liquidación sin ningún paso manual ni excepción, a partir de la línea de tiempo.
03Excepciones por motivo y tiempo de resolución
Por qué importaIndica qué causas corregir primero y si la bandeja de excepciones da abasto.
Cómo lo mediríamosVolumen de excepciones por código de motivo, y tiempo desde la detección hasta la solución ejecutada, a partir de los registros de la bandeja de excepciones.
04Tasa de rechazo de facturas electrónicas
Por qué importaLas facturas rechazadas retrasan el pago y suelen apuntar a errores de datos maestros o de mapeo.
Cómo lo mediríamosProporción de facturas electrónicas enviadas y recibidas que se rechazan, por motivo, a partir de las respuestas del punto de acceso.
05Fallos de interfaz y tiempo de recuperación
Por qué importaMuestra si la capa de integración es fiable y si los fallos se detectan y se corrigen con rapidez.
Cómo lo mediríamosMensajes fallidos por interfaz, y tiempo desde el fallo hasta la reproducción correcta, a partir de la supervisión de la integración.
06Duplicados y conflictos en los datos maestros
Por qué importaLa mayoría de las excepciones se remontan a datos que difieren entre sistemas.
Cómo lo mediríamosDuplicados abiertos y valores en conflicto por objeto de datos y sistema, a partir de los informes de correspondencia.
No se fijan objetivos antes de disponer de una medición de referencia.
Despliegue
Cómo lo implantaríamos
Fase 01
Análisis y mapa del proceso
Un proceso, como el del pedido al cobro de un canal de venta, y un tipo de excepción. Trazamos los sistemas, las interfaces, los responsables de los datos y la forma en que se gestionan hoy las excepciones.
Criterios de salida
Proceso, sistemas y responsables de los datos identificados
Primer tipo de excepción y umbrales de aprobación acordados
Línea de base tomada de los registros actuales
Fase 02
Integración y línea de tiempo
API y eventos documentados para los sistemas incluidos, y la línea de tiempo funcionando junto a las interfaces existentes sin modificarlas.
Criterios de salida
Contratos de eventos publicados y versionados
La línea de tiempo coincide con los sistemas de registro en una muestra de pedidos
Reproducción y runbooks probados
Fase 03
Piloto de la bandeja de excepciones
El agente propone soluciones para el tipo de excepción elegido y las personas aprueban cada propuesta. Comparamos las propuestas con lo que habría hecho el personal.
Criterios de salida
La calidad de las propuestas cumple los criterios acordados
Umbrales y aprobadores fijados por tipo de acción
Registro de auditoría revisado por finanzas y control interno
Fase 04
Ampliar y retirar
Más tipos de excepción, canales, sociedades y procesos, como el de la compra al pago, todos sobre los mismos contratos. Las antiguas interfaces punto a punto se desactivan una a una.
Criterios de salida
Cada nuevo flujo sobre los mismos contratos y la misma supervisión
Pedidos de fabricación bajo pedido y de recambios, del ERP al almacén y a los transportistas, con las confirmaciones de proveedores y las facturas electrónicas conciliadas con los pedidos de compra.
Solicitudes de conexión y de instalación seguidas desde la orden de trabajo y la visita de campo hasta la factura, y materiales comprados con cargo a acuerdos marco.
Órdenes de trabajo de mantenimiento, pedidos a contratistas y sus facturas, seguidos desde la solicitud hasta el pago para los administradores de infraestructuras.
De la compra al pago con facturas electrónicas estructuradas hacia y desde organismos públicos, conciliadas con los pedidos y las recepciones antes del pago.
Ejemplo ilustrativo
Una empresa de mantenimiento de instalaciones
Situación
Una empresa de mantenimiento de instalaciones trabaja para ayuntamientos y empresas. Los avisos llegan por teléfono, por correo y por el portal de cada cliente, los técnicos cierran los partes en una aplicación que no está conectada con el ERP, y administración tarda semanas en facturar.
Sistema
Cada aviso se registra una vez como solicitud de servicio y circula como evento hacia la planificación, la aplicación de campo y el ERP, con una línea de tiempo por solicitud. El parte cerrado genera la factura desde un software de facturación adaptado a Verifactu, y la factura sale por el canal de cada cliente: FACe para las administraciones y el formato estructurado que exija la factura electrónica entre empresas.
Control humano
Los partes con materiales fuera de contrato, horas por encima de lo presupuestado o facturas rechazadas llegan a una bandeja de excepciones, donde un agente propone una corrección. El responsable del contrato la aprueba, y las facturas rectificativas necesitan además la aprobación de administración.
Qué mediríamos
Tiempo desde el cierre del parte hasta la factura, solicitudes sin intervención manual, excepciones por motivo y tasa de rechazo de facturas por canal.
España
Factura electrónica y procesos conectados en España
En España, el Real Decreto 238/2026 desarrolla la obligación de factura electrónica entre empresarios y profesionales de la Ley 18/2022 (Crea y Crece). Con la orden ministerial en vigor desde el 6 de octubre de 2026, se aplica desde el 6 de octubre de 2027 a quienes superan 8 millones de euros de volumen de operaciones y desde el 6 de octubre de 2028 al resto. Los requisitos de Verifactu para el software de facturación se aplican desde el 1 de enero de 2027 a los contribuyentes del Impuesto sobre Sociedades y desde el 1 de julio de 2027 a los demás, y las facturas a las Administraciones pasan por FACe.
Cada formato y canal es un conector más detrás de los mismos eventos. El Reglamento de Datos regula el cambio entre servicios de tratamiento de datos, por lo que mantenemos portables los contratos de eventos y las exportaciones.
No. Su ERP, su CRM, su tienda en línea y su sistema de almacén hacen cada uno su trabajo. Integramos alrededor de esos sistemas de registro, acordamos qué sistema es responsable de qué datos y damos al proceso una única línea de tiempo que los recorre todos. Cuando un sistema antiguo de pedidos o un ERP bloquea el cambio, la modernización de sistemas heredados lo sitúa primero detrás de API.
02¿Sustituyen nuestro middleware de integración?
No, si cumple su función. Construimos sobre la plataforma de integración o el broker de mensajes que ya utiliza, y añadimos contratos, supervisión y reproducción donde faltan. Si no hay ninguno, construimos de forma nativa en la nube. Más información sobre nuestro trabajo de integración.
03¿Pueden los agentes actuar por su cuenta?
Solo dentro de los umbrales que usted acuerde por tipo de acción, y solo en acciones de bajo impacto que puedan revertirse, como reintentar un mensaje fallido. Las contabilizaciones financieras, los precios, los límites de crédito y los compromisos con clientes siempre necesitan a una persona. Lea dónde necesitan los agentes de IA una aprobación humana.
04¿Cómo encajan las obligaciones de factura electrónica?
Las obligaciones nacionales de factura electrónica llegan en fechas distintas, y el paquete europeo «IVA en la era digital» hace de la factura electrónica estructurada la regla en las entregas B2B intracomunitarias a partir del 1 de julio de 2030. Tratamos la factura electrónica como un evento más del proceso: se emite desde el ERP, se envía a través de un punto de acceso y se gestiona en la bandeja de excepciones cuando se rechaza. Consulte nuestra guía sobre la factura electrónica con Peppol.
05¿Cómo evitan otra red frágil de enlaces punto a punto?
Los sistemas publican y consumen eventos y API documentados a través de una sola capa, no mediante enlaces directos entre ellos. Los contratos están versionados, los consumidores son idempotentes, los mensajes fallidos pueden reproducirse y cada flujo tiene un responsable designado. Un nuevo canal se suscribe a los eventos existentes en lugar de añadir un enlace con cada sistema.
06¿Cuál es un primer alcance razonable?
Un proceso y un tipo de excepción, por ejemplo el del pedido al cobro de un canal de venta, con las roturas de stock como primera excepción. Así se validan los eventos, la línea de tiempo y el flujo de aprobación antes de añadir más. Conozca nuestro método de trabajo.
Hablemos de sus flujos de pedidos y facturas
Elija un proceso y los sistemas por los que pasa. Trazaremos con usted las interfaces y las excepciones, y le propondremos una primera versión que ya tenga en cuenta la factura electrónica.