Every order on one timeline, from intake to paid invoice.
Order to cash, procure to pay and service request to invoice run through ERP, CRM, e-commerce, warehouse, transport and finance systems. We connect them with documented APIs and events, give every order one status across those systems, and send each exception to an agent that prepares a resolution for a person to approve.
For organisations that sell, buy and invoice in several EU Member States, each with its own systems, carriers and e-invoicing rules.
An order, purchase order or service request is recorded once in its system of record and distributed to the other systems through documented APIs and events. Status events build one timeline per order. When a step fails or falls outside tolerance, an agent gathers the context and proposes a resolution, which a person approves before it is executed in the system of record. Invoices are exchanged and matched as structured e-invoices, and process owners review flow and interface health.
Before and after
What changes in daily operations
Today
With the system
Today
Today: Keyed in again at every hand-off
An order taken in the webshop or by the sales team is typed again into the ERP, and delivery and invoice details are copied by hand into the warehouse, transport and finance systems.
With the system
With the system: Entered once, used everywhere
Each order, delivery and invoice is created in the system that owns it and published as an event. Other systems subscribe to it instead of retyping it.
Today
Today: Yesterday’s status
Nightly batch interfaces mean customer service, planning and finance each see a different, outdated state of the same order. A customer who asks where a delivery is gets a call-back.
With the system
With the system: One current status
Every order or request has one timeline built from the events of all the systems it passes through. Customer service, planning and finance look at the same facts, and so can a service assistant answering status questions.
Today
Today: Exceptions handled in inboxes
Stock shortages, price mismatches, failed deliveries and rejected e-invoices are resolved by email and spreadsheet, and nobody can say afterwards who decided what.
With the system
With the system: Exceptions arrive with a proposal
An agent collects the data behind each exception and proposes a resolution. A person approves, edits or rejects it on one exception desk, and the decision is recorded.
Today
Today: Master data that disagrees
The same customer, supplier, product or price exists in several systems with different values, and no one is responsible for which one is right.
With the system
With the system: One owner per data object
Customers, suppliers, products and prices each have an agreed system of record and a named owner. Duplicates and conflicts are reported to that owner, not fixed silently downstream.
Today
Today: Every change adds an interface
A new sales channel, marketplace or legal entity means another point-to-point link. National e-invoicing mandates add a structured format and a network to each process on top.
With the system
With the system: New connections reuse the same contracts
A new channel, entity or e-invoicing network connects to documented APIs and events once, instead of to every system separately.
Workflow
How the workflow runs
When data is clean, the main path needs no manual work. When an order, delivery or invoice deviates, the exception loop brings it to a person with the evidence and a proposal, and the approved fix flows back through the same integration layer.
Illustrative workflow
7 steps · 1 human checkpoint
Legend
System
AI agent
Person
Human checkpoint
Exception path
Connected operations: illustrative workflow with exception loop
Read the diagram as text
The main path runs from recording a business event once in its system of record, through distributing it to the other systems by APIs and events and building one timeline per order, to invoicing, matching and settlement. It ends with process owners reviewing the flow and fixing the causes of exceptions.
When a step fails, runs late or falls outside tolerance, the exception leaves the main path after the timeline step. An agent gathers the context and proposes a resolution, and a person approves, edits or rejects it. The approved action is executed in the system of record and loops back to the distribution step as a new event.
The approval step is the human checkpoint: no financial posting, price or credit-limit change, or commitment to a customer is made without a person.
01
Step 1: Record the event onceSystem
A sales order from the webshop, a marketplace, EDI or the sales team, a purchase order or a service request is created in the system that owns it. That system publishes a business event in a CloudEvents envelope, described in an AsyncAPI contract. Paper and PDF orders and supplier invoices pass through document intelligence first.
02
Step 2: Distribute through APIs and eventsSystem
The integration layer delivers the event to the warehouse, transport, finance and CRM systems through their documented APIs (OpenAPI). Consumers are idempotent, so a repeated message never creates a second shipment or invoice, and messages that cannot be delivered wait in an error queue for replay.
03
Step 3: Build one timeline per orderSystem
Status events from every system (confirmed, picked, shipped, delivered, invoiced, paid) are correlated on the business reference into one timeline. Milestone and tolerance rules raise an exception when a step fails, runs late or does not match: a stock shortage, a price outside the agreed tolerance, a failed delivery, a rejected e-invoice.
04
Step 4: Gather context and proposeAI agent
For each exception, an agent reads what it needs from the systems involved: the order, stock levels, the price agreement, carrier status and the customer’s terms. It proposes a resolution with its reasoning and the data it used, such as a substitute item, a corrected price, a rescheduled delivery or a corrected invoice.
Exception path: Step failed or out of tolerance
05
Step 5: Approve within thresholdsPerson
An employee in customer service, logistics or finance sees the exception, the evidence and the proposal on the exception desk, and approves, edits or rejects it. The approved action is executed through the API of the system of record, which publishes the change as a new event.
Exception path: Step failed or out of tolerance· Returns to step 2
Human checkpoint
Agents never post financial transactions, change prices or credit limits, or commit to a customer without approval. Thresholds per action type decide who approves, and every proposal and decision is logged.
06
Step 6: Invoice, match and settleSystem
Outgoing invoices leave the ERP as structured e-invoices (Peppol BIS Billing 3.0, EN 16931) through an access point. Incoming supplier invoices are matched to purchase orders and goods receipts, and payment status from the bank or payment provider closes the timeline.
07
Step 7: Review flow and fix causesPerson
Process owners and the integration team review exceptions by reason, interface failures and master data conflicts on a fixed rhythm. They fix the cause where it sits, in a master data record, a tolerance rule or a mapping, rather than resolving the same exception again.
Components
What we would build
01
Event-driven integration layer
Contract-first APIs and events between ERP, CRM, e-commerce, warehouse, transport and finance, specified in OpenAPI and AsyncAPI with CloudEvents envelopes, on your existing integration platform or built cloud native.
An agreed system of record and owner per data object, matching rules for customers, suppliers and products, and reports on duplicates and conflicts for the people who own them.
A service that correlates events into one timeline per order or request, applies milestone and tolerance rules, and shows flow and exceptions to process owners.
A queue of exceptions showing the gathered context and the agent’s proposal, with approve, edit and reject actions and approval thresholds enforced per action type at the point where the action executes.
Peppol BIS Billing 3.0 and EN 16931 invoices in UBL, sent and received through an access point, validated before sending, with rejected invoices routed to the exception desk.
Health monitoring and alerting per interface, runbooks for the operations team and controlled replay of failed messages, deployed with infrastructure as code in your cloud tenancy.
SAP S/4HANA sales, procurement and financePlatformSAP
Salesforce Sales, Service and Commerce cloudsPlatformSalesforce
Odoo sales, inventory, purchase and accountingPlatformOdoo
E-commerce platforms, marketplaces and carrier APIs
Warehouse and transport management systems
Peppol access point, banks and payment providers
Product information management and the data platform
Controls
Controls designed in
Access boundaries
Each integration and the agent run under their own service identity per system, limited to the API operations they need. The agent may read across systems to gather context, but it can only write through a short list of approved actions, executed by the system of record’s API and never by direct database access.
Human review
Approval thresholds are set per action type with the process owner: what the agent may only propose, what a team member approves, and what needs a second approver. Financial postings, price and credit-limit changes and commitments to customers always wait for a person. Low-impact, reversible actions, such as retrying a failed message, can run without approval where the owner agrees.
Auditability
Every event, proposal, approval, rejection and executed action is logged against the order or request reference, with the data the agent used, the model and prompt version and the approver. A disputed invoice or a customer complaint can be traced step by step.
Data protection
Customer and supplier contact data flows only to the systems that need it. The timeline stores business references and statuses rather than full records, and logs follow the retention you set. Processing stays in the agreed region.
AI transparency
Proposals from the agent are marked as such on the exception desk, with the evidence and reasoning shown next to them. Systems of record stay authoritative: the timeline shows what they report and never overrides them.
Measures
What we would measure
We agree these measures with you during discovery and take the baseline from your current system and interface logs before anything changes.
What we would measure
Metric
Why it matters
How we would measure it
01Order cycle time
Why it mattersThe measure customers notice first, and the one that shows where orders wait.
How we would measure itTime from order receipt to delivery and to payment, per channel and entity, from timeline events.
02Orders without manual touch
Why it mattersShows how much of the flow runs on clean data and agreed rules.
How we would measure itShare of orders and requests that reach settlement without any manual step or exception, from the timeline.
03Exceptions by reason and time to resolve
Why it mattersTells you which causes to fix first and whether the exception desk keeps up.
How we would measure itException volume per reason code, and time from detection to executed resolution, from exception desk logs.
04E-invoice rejection rate
Why it mattersRejected invoices delay payment and usually point to master data or mapping errors.
How we would measure itShare of sent and received e-invoices rejected, by reason, from access point responses.
05Interface failures and recovery time
Why it mattersShows whether the integration layer is reliable and whether failures are noticed and fixed quickly.
How we would measure itFailed messages per interface, and time from failure to successful replay, from integration monitoring.
06Master data duplicates and conflicts
Why it mattersMost exceptions trace back to data that differs between systems.
How we would measure itOpen duplicates and conflicting values per data object and system, from matching reports.
No targets are set before a baseline exists.
Rollout
How we would roll it out
Phase 01
Discovery and process map
One process, such as order to cash for one sales channel, and one exception type. We map the systems, interfaces, data owners and the way exceptions are handled today.
Exit criteria
Process, systems and data owners mapped
First exception type and approval thresholds agreed
Baseline taken from current logs
Phase 02
Integration and timeline
Documented APIs and events for the systems in scope, and the timeline running alongside the existing interfaces without changing them.
Exit criteria
Event contracts published and versioned
Timeline matches the systems of record on sampled orders
Replay and runbooks tested
Phase 03
Exception desk pilot
The agent proposes resolutions for the chosen exception type and people approve every proposal. We compare proposals with what staff would have done.
Exit criteria
Proposal quality meets the agreed criteria
Thresholds and approvers set per action type
Audit trail reviewed by finance and internal control
Phase 04
Extend and retire
More exception types, channels, entities and processes such as procure to pay, each on the same contracts. Old point-to-point interfaces are switched off one by one.
Exit criteria
Each new flow on the same contracts and monitoring
Make-to-order and spare-parts orders from the ERP to the warehouse and carriers, with supplier confirmations and e-invoices matched to purchase orders.
Procure to pay with structured e-invoices to and from public bodies, matched to orders and receipts before payment.
Illustrative example
A distributor selling in three countries
Situation
A distributor of technical supplies sells through a webshop, two marketplaces and field sales in three EU countries, from two warehouses. Orders are keyed again into the ERP, carriers report delivery problems by email, and each country invoices in its own way.
System
Orders, stock, shipments and invoices flow as events between the webshop, the ERP, the warehouse system and the carriers, and every order has one timeline. Invoices leave as structured e-invoices through one access point, in the network and format each country requires.
Human control
Stock shortages and failed deliveries land on one exception desk, where an agent proposes a substitute item or a new delivery date. Customer service approves each proposal; price changes and credit notes need finance approval.
What we would measure
Share of orders without manual touch per country and channel, exceptions by reason and time to resolve, and e-invoice rejection rate per country.
International
One process, several countries and mandates
Organisations operating in several EU Member States often run the same order-to-cash and procure-to-pay processes on different ERP instances, carriers and banks. National e-invoicing mandates arrive on different dates, and the EU VAT in the Digital Age package makes structured e-invoicing the default for intra-EU B2B supplies from 1 July 2030. We design one integration layer with the format and network of each country behind the same events, so a new mandate means a new connector, not a new process.
The Data Act, applicable since 12 September 2025, sets rules for switching between data processing services, so we keep event contracts and data exports portable. Agents on the exception desk are designed with the EU AI Act in mind, and integrations come with logged access and documented components for customers who must show NIS2 supply-chain security.
No. Your ERP, CRM, webshop and warehouse system each do their own job. We integrate around those systems of record, agree which system owns which data, and give the process one timeline across them. Where an old order or ERP system blocks change, legacy modernisation puts it behind APIs first.
02Do you replace our integration middleware?
Not if it does its job. We build on the integration platform or message broker you already run, and add contracts, monitoring and replay where they are missing. Where there is none, we build cloud native. More on our integration work.
03Can agents act on their own?
Only within thresholds you agree per action type, and only for low-impact actions that can be reversed, such as retrying a failed message. Financial postings, prices, credit limits and commitments to customers always need a person. Read where AI agents need human approval.
04How do e-invoicing mandates fit in?
National e-invoicing mandates arrive on different dates, and the EU VAT in the Digital Age package makes structured e-invoicing the default for intra-EU B2B supplies from 1 July 2030. We treat the e-invoice as one more event in the process: issued from the ERP, sent through an access point, and handled on the exception desk when it is rejected. See our guide to Peppol e-invoicing.
05How do you avoid another fragile web of point-to-point links?
Systems publish and consume documented events and APIs through one layer, not through direct links to each other. Contracts are versioned, consumers are idempotent, failed messages can be replayed and every flow has a named owner. A new channel subscribes to existing events rather than adding a link to every system.
06What does a first scope look like?
One process and one exception type, for example order to cash for one sales channel with stock shortages as the first exception. That proves the events, the timeline and the approval flow before more is added. Read about our delivery approach.
Discuss your order and invoice flows
Pick one process and the countries it runs in. We will map the systems, interfaces and exceptions with you and propose a first release that works across your entities.