One timeline for each order, from the first entry to the paid invoice.
Selling, buying and servicing run through ERP, CRM, e-commerce, warehouse, transport and finance systems. We link them with documented APIs and events, give each order a single status across all of them, and route every exception to an agent that prepares a fix for an employee to accept or reject.
For organisations in Malaysia that sell, buy and invoice through many systems, under the e-Invoice rules at home and Peppol for business in the EU.
A sales order, purchase order or service request is entered once in the system that owns it and shared with the other systems through documented APIs and events. Status events form one timeline per order. When a step fails or goes outside tolerance, an agent collects the context and suggests a fix, which an employee accepts before the system of record carries it out. Invoices are issued as e-Invoices, validated and matched, and process owners review the flow and the health of each interface.
Before and after
How daily operations change
Today
With the system
Today
Today: Retyped at every hand-off
An order from the webshop or the sales team is typed into the ERP a second time, and staff copy delivery and billing details into the systems for stock, shipping and accounts.
With the system
With the system: Entered once, reused everywhere
Every order, delivery and invoice is created in the system that owns it and published as an event. Other systems subscribe to that event rather than typing the data again.
Today
Today: Status from last night
Overnight batch interfaces leave customer service, planning and finance looking at different, outdated versions of one order. A customer asking about a delivery has to wait for a call-back.
With the system
With the system: A single current status
Each order or request has one timeline built from the events of every system it passes through. Customer service, planning and finance work from the same facts, and so can Service assistance when it answers status questions.
Today
Today: Exceptions handled by email
Stock shortages, price differences, failed deliveries and e-Invoices that fail validation are resolved through email and spreadsheets, and afterwards nobody can say who decided what.
With the system
With the system: Exceptions come with a proposal
An agent gathers the data behind each exception and suggests a fix. An employee accepts, changes or rejects it at one exception desk, and the decision is recorded.
Today
Today: Master data in conflict
One customer, supplier, product or price exists in several systems with different values, and nobody is responsible for the correct one.
With the system
With the system: One owner for each 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 instead of being patched quietly further down.
Today
Today: Each change adds a link
A new sales channel, marketplace or group company brings another point-to-point interface. The e-Invoice obligation in Malaysia, and Peppol for buyers in the EU, add formats and networks on top.
With the system
With the system: New links reuse existing contracts
A new channel, group company or e-invoicing network connects once to documented APIs and events, rather than to each system in turn.
Workflow
How the flow runs
With clean data, the main path needs no manual work. When an order, delivery or invoice goes off plan, the loop puts it in front of an employee together with the evidence and a suggestion, and whatever is approved 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 flow with an exception loop
Read the diagram as text
The main path starts when a business event is entered once in its system of record, shares it with the other systems through APIs and events, and builds one timeline per order before invoicing, validation and matching. It closes with process owners reviewing the flow and removing the causes of exceptions.
When a step fails, runs late or goes outside tolerance, the exception leaves the main path after the timeline step. An agent collects the context and suggests a fix, and an employee accepts, edits or rejects it. The approved action runs in the system of record and returns to the sharing step as a new event.
Approval is the human checkpoint: no ledger posting, price or credit-limit change, or promise to a customer happens without a person.
01
Step 1: Enter the event onceSystem
Orders arrive from the webshop, marketplaces, EDI or the sales team, along with purchase orders and service requests, and each is created in its owning system. That system then emits a business event, wrapped in CloudEvents and specified in AsyncAPI. Orders and supplier invoices on paper or as PDFs are first handled by Document intelligence.
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). Every consumer is idempotent: if a message arrives twice, no duplicate shipment or invoice results. Messages that cannot be delivered are held in an error queue until they are replayed.
03
Step 3: One timeline per orderSystem
Status events from all systems (order confirmed, goods picked and shipped, delivery made, invoice issued, payment received) are linked through the business reference into a single timeline. Milestone and tolerance rules raise an exception when a step fails, is late or does not match: too little stock, a price beyond tolerance, a delivery that did not arrive, or an e-Invoice that fails validation in MyInvois.
04
Step 4: Propose a fixAI agent
For each exception the agent looks up the relevant data in the systems concerned, such as the order, available stock, the agreed price, the carrier’s tracking status and the customer’s terms. It then suggests a fix, for example an alternative item, an amended price, a later delivery date or a corrected invoice, with its reasoning and the data behind it.
Exception path: Failed step or beyond tolerance
05
Step 5: Approval within limitsPerson
A member of the customer service, logistics or finance team sees the exception, the evidence and the suggestion on the exception desk, and accepts, edits or rejects it. The approved action runs through the API of the system of record, which publishes the change as a new event.
Exception path: Failed step or beyond tolerance· Returns to step 2
Human checkpoint
Without approval, an agent cannot post to the ledger, alter a price or credit limit, or promise anything to a customer. Limits set for each type of action determine who signs off, and each suggestion and decision is logged.
06
Step 6: Invoice, validate and matchSystem
Outgoing invoices are submitted from the ERP to MyInvois for validation through the API, or through a Peppol service provider; invoices to EU buyers go out as Peppol BIS Billing 3.0 (EN 16931) through an access point. Supplier e-Invoices coming in are compared with the purchase order and the goods received note, and the timeline closes once the bank or payment provider confirms payment.
07
Step 7: Fix causes, not symptomsPerson
On a fixed schedule, process owners and the integration team go through exceptions by reason, interface failures and master data conflicts. They correct the 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
Components we would deliver
01
Event-based integration layer
APIs and events designed contract first between ERP, CRM, e-commerce, warehouse, transport and finance, specified in OpenAPI and AsyncAPI with CloudEvents envelopes, on the integration platform you run or built cloud native.
Each data object gets an agreed source system and an owner; matching rules find duplicate customers, suppliers and products, and the owners receive the conflicts to resolve.
A service that joins events into a timeline for each order or request, checks milestones and tolerances, and gives process owners a view of flow and exceptions.
A queue of exceptions showing the collected context and the agent’s suggestion, with accept, edit and reject actions, and approval limits enforced for each action type where the action is executed.
e-Invoices submitted to MyInvois through the API, or as Malaysia PINT documents through a Peppol service provider, checked before sending; Peppol BIS Billing 3.0 invoices in UBL for EU buyers; failed validations routed to the exception desk.
Health checks and alerts for every interface, runbooks for the operations team and controlled replay of failed messages, deployed as infrastructure as code in your cloud tenancy.
Sales, purchasing and finance in SAP S/4HANAPlatformSAP
Salesforce clouds for sales, service and commercePlatformSalesforce
Odoo apps for sales, inventory, purchasing and accountingPlatformOdoo
Carrier APIs, marketplaces and e-commerce platforms
Transport and warehouse management systems
MyInvois API, Peppol service provider and banks
Data platform and product information management
Controls
Controls built in
Access boundaries
Each integration and the agent hold a separate service identity per system, restricted to the API operations they require. The agent can read widely to collect context; it writes only through a short list of approved actions, executed by the owning system’s API, never straight into a database.
Human review
With the process owner we decide, for each action type, which actions the agent can only suggest, which one team member can approve and which require two approvers. Ledger postings, price and credit-limit changes and promises to customers always wait for a person. Minor actions that can be undone, such as retrying a failed message, may run without approval where the owner agrees.
Auditability
The log for each order or request reference holds every event, suggestion, approval, rejection and executed action, together with the approver, the agent’s input data and the model and prompt version. That lets you trace a disputed invoice or a complaint from start to finish.
Data protection
Contact details of customers and suppliers go only to the systems that need them. The timeline holds business references and statuses rather than full records, logs follow the retention you set, and processing stays at the hosting location recorded in the contract. Personal data in orders and invoices is handled under the Personal Data Protection Act 2010 (PDPA).
AI transparency
Suggestions from the agent are labelled as such on the exception desk, with the evidence and reasoning beside them. The systems of record keep the final word; the timeline reflects their data and cannot overrule it.
Measures
Measures we would agree
Measures are agreed in discovery, and the starting baseline comes from the logs your systems and interfaces already keep.
Measures we would agree
Metric
Why it matters
How we would measure it
01Order cycle time
Why it mattersWhat customers notice first, and the measure that shows where orders stand still.
How we would measure itDays between receiving an order, delivering it and being paid, by channel and group company, from the timeline.
02Orders with no manual step
Why it mattersIndicates how far clean data and agreed rules carry the flow without help.
How we would measure itShare of orders and requests that reach payment with no manual step or exception, from the timeline.
03Exception causes and resolution time
Why it mattersTells you which causes to remove first and whether the exception desk keeps pace.
How we would measure itExceptions per reason code, and time from detection to executed fix, from the exception desk logs.
04Failed e-Invoice validations
Why it mattersFailed e-Invoices delay payment and usually point to master data or mapping errors.
How we would measure itShare of submitted e-Invoices that fail MyInvois validation, and of Peppol invoices rejected, by reason, from the API and access point responses.
05Interface failures and recovery
Why it mattersTells you how dependable the integration layer is, and how fast failures are spotted and repaired.
How we would measure itFailed messages per interface, and the time until a successful replay, from integration monitoring.
06Duplicate and conflicting master data
Why it mattersMost exceptions go back to data that differs between systems.
How we would measure itDuplicates and conflicting values still open, per data object and system, taken from matching reports.
No targets are set before a baseline exists.
Rollout
Rollout in stages
Phase 01
Discovery and process mapping
One process, for example order to cash for a single sales channel, and one exception type. We map the systems, interfaces and data owners, and how exceptions are handled today.
Exit criteria
Map of process, systems and data owners
First exception type and approval limits agreed
Baseline drawn from existing logs
Phase 02
Integration and timeline
Documented APIs and events for the systems in scope, with the timeline running next to the existing interfaces without altering them.
Exit criteria
Event contracts versioned and published
Timeline agrees with systems of record 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 suggestion. We compare the suggestions with what staff would have done themselves.
Exit criteria
Suggestions meet the agreed quality
Limits and approvers set per action type
Audit trail reviewed by finance and internal audit
Phase 04
Extend and retire
Further exception types, channels, group companies and processes such as procure to pay, all on the same contracts. Old point-to-point interfaces are switched off one at a time.
Build-to-order and spare-parts orders from the ERP to the warehouse and carriers at electrical and electronics manufacturers, with supplier confirmations and e-Invoices matched to purchase orders.
Installation requests at solar and renewable energy firms followed from work order and site visit to e-Invoice, with materials bought under framework agreements.
Purchase orders, deliveries and supplier invoices at statutory bodies and government-linked companies, matched against receipts before payment.
Illustrative example
Procure to pay at a construction firm
Situation
A construction firm could buy materials and subcontract work for several projects at once, with purchase orders in the ERP, deliveries confirmed on site and supplier invoices arriving as e-Invoices and PDFs. Site, procurement and finance staff would match them by hand.
System
Purchase orders, delivery confirmations and supplier invoices would flow as events between the ERP, a site app and finance, giving every order one timeline. Supplier e-Invoices, once validated through MyInvois, would be matched to the order and the goods received.
Human control
Quantity or price differences and missing site confirmations land on one exception desk, where an agent suggests a resolution. The procurement officer approves each suggestion; price changes and payments need finance approval.
What we would measure
Share of orders with no manual step per project, exception causes and resolution time, and failed e-Invoice validations by reason.
Malaysia
MyInvois at home, Peppol for Europe
Since 1 January 2026, the last of four phases that began on 1 August 2024, businesses in scope issue e-Invoices that the Inland Revenue Board of Malaysia (IRBM) validates through the MyInvois Portal or API. The Malaysia Digital Economy Corporation (MDEC) is the Peppol Authority for Malaysia, with Malaysia PINT as the national specification, and IRBM recognises submission through a Peppol service provider as one option. We design one integration layer in which the ERP feeds MyInvois, a Peppol service provider or both, behind the same events.
Malaysian groups that sell to EU buyers or run EU subsidiaries meet a second set of rules. The EU VAT in the Digital Age package brings structured e-invoicing for B2B supplies between Member States from 1 July 2030, and the EU Data Act, applicable since 12 September 2025, sets switching rules that make portable event contracts and data exports worthwhile. Agents on the exception desk are designed with the EU AI Act in mind, and documented, logged integrations help EU customers who must show NIS2 supply-chain security.
No. Each of your systems, from ERP and CRM to webshop and warehouse, keeps doing its own job. We connect them, decide with you which system owns which data, and run one timeline for the process across all of them. If an old order or ERP system blocks change, Legacy modernisation first places it behind APIs.
02Will you replace our integration middleware?
Not if it does what you need. Your existing broker or integration platform stays, and we add contracts, monitoring and replay where they are lacking. Without one, we build cloud native. See Integrations & APIs.
03Can agents act by themselves?
Only inside limits you agree for each action type, and only where the action is minor and reversible, for example a retry of a failed message. Ledger postings, prices, credit limits and promises to customers always need a person. See AI agents and human approval.
04How do e-Invoice and Peppol fit in?
In Malaysia, e-Invoice became mandatory in four phases from 1 August 2024 to 1 January 2026, with each invoice validated through MyInvois. The Malaysia Digital Economy Corporation (MDEC) is the Peppol Authority for Malaysia, and the Inland Revenue Board of Malaysia (IRBM) recognises submission through a Peppol service provider as one option. For EU subsidiaries and EU buyers, the EU’s VAT in the Digital Age package will make structured e-invoicing the norm for B2B supplies between Member States from 1 July 2030. We treat each e-Invoice as one more event: issued from the ERP, validated or sent, and handled on the exception desk if it fails. See the MyInvois and Peppol guide.
05How do you prevent a new tangle of point-to-point links?
All traffic passes through one layer of documented events and APIs instead of direct connections between systems. Contracts carry versions, consumers tolerate repeated messages, failed messages can be replayed, and every flow has a named owner. A new channel subscribes to events that already exist instead of being wired to each system.
06Where would a first release start?
With one process and one exception type: for example, procure to pay for one business unit, with e-Invoices that fail validation as the first exception type. Events, timeline and approvals prove themselves there before the scope grows. See Our delivery approach.
Map one order or invoice flow with us
Choose one process and the companies it runs through. We will map the systems, interfaces and exceptions with you and propose a first release that serves MyInvois and your buyers abroad alike.