One timeline for every order, from first request to paid invoice.
Order to cash, procure to pay and service request to invoice cross the ERP, CRM, webshop, warehouse, transport and finance systems. We link them with documented APIs and events, give each order a single status that all those systems share, and pass every exception to an agent that prepares a fix for a member of staff to approve.
For Irish companies and public bodies that buy, sell and invoice across many systems, with VAT modernisation on the way.
A sales order, purchase order or service request is captured a single time in the system that owns it, then shared with the other systems through documented APIs and events. Status events add up to one timeline for each order. If a step fails or goes outside tolerance, an agent collects the background and suggests a fix, and a member of staff approves it before the owning system carries it out. Invoices are sent, received and matched as structured EN 16931 e-invoices, and process owners keep an eye on flow and interface health.
Before and after
How day-to-day operations change
Today
With the system
Today
Today: Retyped at each handover
An order from the webshop or a sales rep is typed into the ERP again, and delivery and invoice details are copied by hand into the warehouse, transport and finance tools.
With the system
With the system: Captured once, used by all
Every order, delivery and invoice is created in its owning system and published as an event. The other systems subscribe to it and nobody types it in again.
Today
Today: Status a day old
Because interfaces run as overnight batches, customer service, planning and finance each see a different, stale picture of the same order. A customer asking about a delivery has to wait for someone to ring back.
With the system
With the system: A single, current status
Each order or request has one timeline assembled from the events of every system it touches. Customer service, planning and finance work from the same facts, and so can a service assistant that answers status queries.
Today
Today: Exceptions sorted out by email
Short stock, wrong prices, failed deliveries and bounced invoices are dealt with in email threads and spreadsheets, and afterwards nobody can tell who agreed to what.
With the system
With the system: Exceptions come with a suggested fix
An agent pulls together the data behind an exception and suggests how to resolve it. A member of staff approves, changes or turns down the suggestion on one exception desk, and the outcome is logged.
Today
Today: Master data that does not agree
A customer, supplier, product or price sits in several systems with different values, and nobody owns the question of which value is correct.
With the system
With the system: Every data object has an owner
Customers, suppliers, products and prices each have an agreed owning system and a named person in charge. Duplicates and conflicts are reported to that person rather than patched quietly further down the line.
Today
Today: One more interface for every change
Each new sales channel, marketplace or company in the group brings another point-to-point link. VAT modernisation will add a structured invoice format and reporting to Revenue to every invoicing process.
With the system
With the system: New links use the same contracts
A new channel, company or e-invoicing route connects once to the documented APIs and events, not separately to each system.
Workflow
The workflow, step by step
With clean data, the usual route needs no manual work at all. When an order, delivery or invoice goes off course, the exception loop puts it in front of a person with the evidence and a suggestion, and the approved fix travels 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 and exception loop
Read the diagram as text
The usual route starts by capturing a business event once in its owning system, then shares it with the other systems through APIs and events and assembles one timeline for each order, before invoicing, matching and closing. It finishes with process owners reviewing the flow and fixing the root causes of exceptions.
If a step fails, runs late or goes outside tolerance, the exception leaves the usual route after the timeline step. An agent collects the background and suggests a fix, which a member of staff approves, changes or rejects. The approved action runs in the owning system and returns to the sharing step as a fresh event.
Approval is the point where a person steps in: no financial posting, price or credit limit change, or promise to a customer happens unless a member of staff agrees.
01
Step 1: Capture the event onceSystem
A sales order from the webshop, a marketplace, EDI or a sales rep, a purchase order or a service request is created in its owning system. That system publishes a business event wrapped in CloudEvents and described in an AsyncAPI contract. Orders and supplier invoices on paper or PDF go through document intelligence first.
02
Step 2: Share through APIs and eventsSystem
The integration layer passes the event to the warehouse, transport, finance and CRM systems through their documented APIs (OpenAPI). Receivers are idempotent, so a duplicate message never triggers a second shipment or invoice, and messages that fail to arrive sit in an error queue until they are replayed.
03
Step 3: Assemble one timeline per orderSystem
Status events from each system (confirmed, picked, shipped, delivered, invoiced, paid) are linked on the business reference into a single timeline. Rules on milestones and tolerances flag an exception when a step fails, runs late or does not match: short stock, a price outside the agreed range, a failed delivery or an e-invoice that was rejected.
04
Step 4: Collect background and suggestAI agent
For each exception an agent reads what it needs from the systems concerned: the order, stock, the price agreement, the carrier’s status and the customer’s terms. It suggests a fix, showing its reasoning and the data behind it, for example a substitute product, a corrected price, a new delivery date or a corrected invoice.
Exception path: Step failed or outside tolerance
05
Step 5: Approve within limitsPerson
A member of staff in customer service, logistics or finance sees the exception, the evidence and the suggestion on the exception desk, then approves, changes or rejects it. The approved action runs through the API of the owning system, which publishes the change as a fresh event.
Exception path: Step failed or outside tolerance· Returns to step 2
Human checkpoint
An agent never posts a financial transaction, alters a price or credit limit, or makes a promise to a customer without approval. Limits set for each type of action decide who approves, and each suggestion and decision is logged.
06
Step 6: Invoice, match and closeSystem
Outgoing invoices leave the ERP as structured EN 16931 e-invoices, over Peppol to Irish public buyers (Peppol BIS Billing 3.0) and in the format Revenue’s planned model sets for business customers. Incoming supplier invoices are matched with purchase orders and goods receipts, and payment status from the bank or payment provider closes the timeline.
07
Step 7: Review the flow and fix root causesPerson
At a set rhythm, process owners and the integration team look at exceptions by reason, interface failures and master data conflicts. They fix the root cause where it lies, whether a master data record, a tolerance rule or a mapping, so the same exception does not have to be resolved again.
Components
What we would put in place
01
Integration layer built on events
APIs and events defined contract-first between ERP, CRM, webshop, warehouse, transport and finance, written in OpenAPI and AsyncAPI with CloudEvents envelopes, on the integration platform you already have or built cloud native.
An agreed owning system and owner for each data object, matching rules for customers, suppliers and products, and reports on duplicates and conflicts for the people in charge of them.
A service that links events into one timeline for each order or request, applies milestone and tolerance rules and shows process owners how work is flowing and where it is stuck.
A queue of exceptions with the collected background and the agent’s suggestion, offering approve, change and reject, and enforcing approval limits by action type at the point where the action runs.
EN 16931 invoices in UBL, sent and received through a Peppol access point for public buyers and through the route Revenue’s planned model requires for businesses, validated before sending, with rejections passed to the exception desk.
Health checks and alerts for each interface, runbooks for operations and controlled replay of failed messages, deployed as infrastructure as code in your own cloud tenancy in an EU region.
Sales, purchasing and finance in SAP S/4HANAPlatformSAP
Salesforce Sales Cloud, Service Cloud and Commerce CloudPlatformSalesforce
Sales, stock, purchasing and accounts in OdooPlatformOdoo
Webshop platforms, marketplaces and carrier APIs
Warehouse and transport management
Banks, payment providers and the Peppol access point
Product information management and your data platform
Controls
Safeguards built in
Access boundaries
Every integration and the agent run under a separate service identity in each system, restricted to the API operations they need. The agent can read across systems to collect background, but it can only write through a short list of approved actions, carried out by the owning system’s API and never by going straight to the database.
Human review
Approval limits are agreed with the process owner for each type of action: what the agent may only suggest, what a team member can approve, and what needs a second person. Financial postings, price and credit limit changes and promises to customers always wait for a member of staff. Small, reversible actions such as retrying a failed message can run unapproved if the owner agrees.
Auditability
Each event, suggestion, approval, rejection and completed action is logged against the order or request reference, together with the data the agent used, the model and prompt version and who approved it. A disputed invoice or a complaint can be followed step by step.
Data protection
Contact details of customers and suppliers go only to the systems that need them. The timeline holds business references and statuses, not complete records, and logs are kept as long as you decide. Processing stays in the EU region you agreed, under the GDPR and the Data Protection Act 2018.
AI transparency
On the exception desk, suggestions from the agent are labelled as such, with the evidence and reasoning beside them. The owning systems remain the authority: the timeline reflects what they report and never overrides them.
Measures
How we would judge it
These measures are settled with you in discovery, and the baseline comes from your current system and interface logs before anything changes.
How we would judge it
Metric
Why it matters
How we would measure it
01Time from order to cash
Why it mattersWhat customers notice first, and the figure that reveals where orders sit waiting.
How we would measure itTime from receiving an order to delivery and to payment, by channel and company, taken from timeline events.
02Orders nobody had to touch
Why it mattersTells you how much of the flow runs on clean data and agreed rules.
How we would measure itProportion of orders and requests that reach payment with no manual step or exception, from the timeline.
03Exceptions by cause and time to fix
Why it mattersShows which causes to tackle first and whether the exception desk is keeping pace.
How we would measure itNumber of exceptions for each reason code, and time from detection to the completed fix, from the exception desk logs.
04Rejected e-invoices
Why it mattersA rejected invoice holds up payment and usually points to a master data or mapping fault.
How we would measure itProportion of e-invoices sent and received that were rejected, by reason, from access point and validation responses.
05Interface failures and recovery
Why it mattersTells you if the integration layer can be relied on and if failures are spotted and fixed fast.
How we would measure itFailed messages for each interface, and time from failure to a successful replay, from integration monitoring.
06Duplicate and conflicting master data
Why it mattersMost exceptions come back to data that differs from one system to the next.
How we would measure itOpen duplicates and conflicting values for each data object and system, from the matching reports.
No targets are set before a baseline exists.
Rollout
How we would introduce it
Phase 01
Discovery and process map
A single process, for example order to cash for one sales channel, and a single exception type. We map the systems, interfaces and data owners, and how exceptions are handled now.
Exit criteria
Process, systems and data owners on the map
First exception type and approval limits signed off
Baseline drawn from today’s logs
Phase 02
Integration and timeline
Documented APIs and events for the systems in scope, with the timeline running next to the current interfaces and leaving them untouched.
Exit criteria
Event contracts published under version control
Timeline agrees with the owning systems on a sample of orders
Replay and runbooks rehearsed
Phase 03
Exception desk pilot
The agent suggests fixes for the chosen exception type, and staff approve every one. We compare the suggestions with what staff would have done themselves.
Exit criteria
Suggestions reach the agreed quality bar
Limits and approvers fixed for each action type
Audit trail checked by finance and internal audit
Phase 04
Widen and switch off
Further exception types, channels, companies and processes such as procure to pay, all on the same contracts. Old point-to-point interfaces are turned off one at a time.
Exit criteria
Every new flow uses the same contracts and monitoring
Orders for made-to-order products and spare parts at pharma, medtech and electronics sites, from the ERP to the warehouse and carriers, with supplier confirmations and e-invoices matched to purchase orders.
Customer service requests and installation jobs at energy suppliers and renewable developers, followed from work order through site visit to invoice, with materials bought under framework agreements.
Procure to pay at Government departments, State agencies and local authorities, with EN 16931 e-invoices received under S.I. No. 258 of 2019 and matched to orders and receipts before payment.
Illustrative example
An Irish wholesaler preparing for e-invoicing
Situation
A wholesaler of electrical and technical supplies sells through a webshop, a trade counter and field sales across Ireland from two warehouses. Orders are retyped into the ERP, carriers report delivery problems by email, and invoices go out as PDFs, which will no longer qualify once VAT modernisation applies to it.
System
Orders, stock, shipments and invoices travel as events between the webshop, the ERP, the warehouse system and the carriers, with one timeline per order. Supplier e-invoices are received and matched now, and outgoing invoices are prepared as EN 16931 e-invoices ahead of the planned timeline, with invoices to public buyers sent over Peppol.
Human control
Short stock and failed deliveries arrive on one exception desk, where an agent suggests a substitute product or a new delivery date. Customer service approves each suggestion; price changes and credit notes need finance approval.
What we would measure
Orders nobody had to touch by channel, exceptions by cause and time to fix, and the rate of rejected e-invoices, sent and received.
Ireland
Getting ready for e-invoicing in 2028?
Under Revenue’s published VAT modernisation timeline, VAT-registered large corporates are to issue EN 16931 e-invoices for domestic B2B sales and report the data to Revenue from 1 November 2028, and every business must be able to receive them from the same date. The legal basis sits in Finance Bill (No. 2) 2026, so the timeline is planned until it is enacted. Irish contracting authorities have had to receive and process e-invoices under S.I. No. 258 of 2019 for some years, and Ireland uses Peppol for that.
We design one integration layer where the invoice format and route sit behind the same events, so receiving first and issuing later is a new connector, not a new process. The Data Act’s switching rules, applicable since 12 September 2025, are a reason to keep contracts and exports portable. While the National Cyber Security Bill to transpose NIS2 is still being drafted, integrations come with logged access and documented components for customers who must show supply-chain security.
No. The ERP, CRM, webshop and warehouse system each keep doing their own job. We connect around those owning systems, agree which one is in charge of which data, and give the process a single timeline across all of them. If an old order or ERP system is blocking change, legacy modernisation first puts APIs in front of it.
02Will you replace our integration middleware?
Not if it works. We build on the integration platform or message broker you run today, adding contracts, monitoring and replay where they are absent. If you have none, we build cloud native. Read more about our integrations work.
03Are agents allowed to act without approval?
Only inside the limits you set for each type of action, and only for small actions that can be undone, such as retrying a failed message. Financial postings, prices, credit limits and promises to customers always need a member of staff. See where AI agents need sign-off by a person.
04How does VAT modernisation fit in?
On Revenue’s published timeline, which is still planned until the Finance Bill is enacted, VAT-registered large corporates must issue EN 16931 e-invoices for domestic B2B sales and report the data to Revenue from 1 November 2028, and every business must be able to receive them from that date; a PDF will not count. From 1 November 2029 the rules extend to businesses trading intra-EU, and the EU cross-border rules follow in July 2030. Public buyers already receive e-invoices under S.I. No. 258 of 2019. We treat each e-invoice as one more event in the process: issued from the ERP, sent through the right route and handled on the exception desk if it is rejected. Read our guide to e-invoicing and Peppol.
05How do you stop this turning into another tangle of point-to-point links?
Systems publish and consume documented events and APIs through a single layer, rather than linking to each other directly. Contracts carry versions, receivers are idempotent, failed messages can be replayed and each flow has a named owner. A new channel subscribes to events that already exist instead of adding a link to every system.
06What would a sensible first scope be?
A single process and a single exception type, say order to cash for one sales channel with short stock as the first exception. That tests the events, the timeline and the approval flow before anything else is added. Read about how we work.
Show us your order and invoice flows
Choose one process and the systems it runs through. We will map the interfaces and exceptions with you and propose a first release, with the VAT modernisation timeline built in.