One history for every order, from the first request to the payment received.
Order to cash, procure to pay and service request to invoice pass through the ERP, the CRM, the webshop, the warehouse, the carriers and accounts. We link these with documented APIs and events, keep a single status for each order across all of them, and hand every deviation to an agent that drafts a fix for a member of staff to sign off.
For Maltese family businesses, distributors and international companies with operations in Malta that sell, buy and invoice across systems, carriers and borders.
A sales order, purchase order or service request is entered a single time in the system that owns it, and documented APIs and events pass it to every other system. Status events form one history per order. If a step breaks down or drifts beyond tolerance, an agent collects the background and drafts a fix, which a member of staff signs off before the owning system carries it out. Invoices travel and are matched as structured e-invoices, and process owners keep an eye on the flow and on the health of each interface.
Before and after
What shifts in day-to-day operations
Today
With the system
Today
Today: Typed again at each handover
An order received online or by a sales rep is keyed into the ERP once more, and the delivery and billing details are copied manually into the warehouse, carrier and accounts systems.
With the system
With the system: Keyed in once, reused by all
Orders, deliveries and invoices are created in the system responsible for them and announced as events. The other systems listen for those events rather than retyping the data.
Today
Today: Status from the night before
Because interfaces run as night batches, client service, planning and accounts each see a different and stale picture of one order. When a hotel or shop asks where its delivery is, someone promises to ring back.
With the system
With the system: A single, up-to-date status
Each order or request has one history assembled from the events of every system it touches. Client service, planning and accounts work from the same facts, as does a service assistant that answers clients asking about their order.
Today
Today: Problems settled by email
Items out of stock, prices that do not match, deliveries that failed and e-invoices sent back are sorted out in mail threads and spreadsheets, leaving no trace of who agreed to what.
With the system
With the system: Deviations come with a draft fix
For every deviation an agent gathers the underlying data and drafts a fix. A member of staff signs it off, amends it or turns it down at a single exceptions desk, and that choice is recorded.
Today
Today: Master data at odds
One client, supplier, item or price is stored in several systems with different values, and nobody is accountable for the correct one.
With the system
With the system: A named owner for each data object
Clients, suppliers, items and prices each have an agreed source system and a person responsible. Duplicates and clashes are reported to that person instead of being patched quietly further down the line.
Today
Today: A new interface for every change
Adding a sales channel, a marketplace or a company in the group means yet another direct link between two systems. E-invoicing requirements then add a structured format and a network on top of each process.
With the system
With the system: New links reuse existing contracts
A new channel, group company or e-invoicing network plugs into the documented APIs and events a single time, not into each system one after another.
Workflow
The workflow, step by step
With clean data, the main route runs without anyone touching it. When an order, delivery or invoice strays, the deviation loop puts it in front of a member of staff with the evidence and a draft fix, and the signed-off 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 with its deviation loop (illustrative)
Read the diagram as text
The main route begins when a business event is entered a single time in the system that owns it, passes it to the other systems by APIs and events, assembles one history per order and moves on to invoicing, matching and closing. It finishes with process owners looking at the flow and removing the causes of deviations.
If a step breaks down, is overdue or drifts beyond tolerance, the deviation leaves the main route after the history step. An agent collects the background and drafts a fix, which a member of staff signs off, amends or turns down. The signed-off action is carried out in the owning system and comes back to the pass-on step as a fresh event.
Sign-off is where a person decides: nothing is posted to the ledger, no price or credit limit is altered and no promise is made to a client without a member of staff.
01
Step 1: Enter the event a single timeSystem
A sales order from the webshop, a marketplace, EDI or a sales rep, a purchase order or a service request is created in the system responsible for it. That system announces a business event wrapped in a CloudEvents envelope and described by an AsyncAPI contract. Orders and supplier invoices on paper or in PDF go through document intelligence beforehand.
02
Step 2: Pass it on through APIs and eventsSystem
The integration layer hands the event to the warehouse, carrier, accounts and CRM systems over their documented OpenAPI interfaces. Receivers are idempotent, so a message arriving twice never produces a second shipment or a second invoice, and messages that cannot be delivered are parked in an error queue for replay.
03
Step 3: Assemble one history per orderSystem
Status events from all systems (confirmed, picked, dispatched, delivered, invoiced, paid) are linked through the business reference into a single history. Milestone and tolerance rules flag a deviation when a step breaks down, is overdue or does not match: an item out of stock, a price beyond the agreed margin, a delivery that failed, an e-invoice sent back.
04
Step 4: Collect the background and draft a fixAI agent
For every deviation, an agent reads what it needs from the systems concerned: the order, stock levels, the price agreement, the carrier status and the client’s terms. It drafts a fix together with its reasoning and the data it relied on, for example an alternative item, a corrected price, a new delivery slot or an amended invoice.
Exception path: Step broke down or beyond tolerance
05
Step 5: Sign off within set limitsPerson
A colleague in client service, logistics or accounts sees the deviation, the supporting data and the draft fix at the exceptions desk, and signs it off, amends it or turns it down. Once signed off, the action runs through the API of the owning system, which announces the change as a fresh event.
Exception path: Step broke down or beyond tolerance· Returns to step 2
Human checkpoint
An agent never posts to the ledger, alters prices or credit limits, or makes a promise to a client without sign-off. Limits for each type of action determine who signs off, and every draft and every choice is logged.
06
Step 6: Invoice, match and closeSystem
Sales invoices leave the ERP as structured e-invoices in EN 16931 with Peppol BIS Billing 3.0, sent through your Peppol service provider. Supplier invoices coming in are matched with purchase orders and goods received, and the payment status reported by the bank or payment provider closes the history.
07
Step 7: Look at the flow and remove causesPerson
At a fixed rhythm, process owners and the integration team go over deviations by reason, failed interfaces and master data clashes. They correct the cause at its source, be it a master data record, a tolerance rule or a field mapping, so the same deviation does not have to be settled twice.
Components
The building blocks
01
Event-driven integration layer
APIs and events defined contract first between ERP, CRM, webshop, warehouse, carriers and accounts, specified in OpenAPI and AsyncAPI with CloudEvents envelopes, on the integration platform you already run or built cloud native.
An agreed source system and owner for each data object, matching rules for clients, suppliers and items, and reports on duplicates and clashes addressed to the people responsible.
A service that links events into one history per order or request, applies milestone and tolerance rules and shows process owners the flow and its deviations.
A queue of deviations with the background collected and the agent’s draft fix, offering sign-off, amend and turn-down, with limits for each type of action enforced where the action is carried out.
UBL invoices in EN 16931 and Peppol BIS Billing 3.0, exchanged through a Peppol service provider, validated before dispatch, with returned invoices sent to the exceptions desk.
Health checks and alerts for each interface, runbooks for the operations team and controlled replay of failed messages, deployed as infrastructure as code in your cloud tenancy.
Service requests and reports from field technicians
Tracking and delivery events from carriers
Peppol e-invoices and their status messages
Bank statements and payment advices
Solution core
Connected operations
Systems it works with
SAP S/4HANA for sales, purchasing and financePlatformSAP
Salesforce Sales, Service and Commerce cloudsPlatformSalesforce
Odoo for sales, stock, purchasing and accountingPlatformOdoo
Webshop platforms, marketplaces and carrier APIs
Warehouse and transport management software
Peppol service provider, banks and payment providers
Product information management and the data platform
Controls
Controls built in from the start
Access boundaries
Every integration and the agent use a separate service identity in each system, restricted to the API operations they actually need. The agent may read across systems to collect background, but it can write only through a short list of approved actions, carried out by the owning system’s API and never by reaching into a database.
Human review
Together with the process owner we fix limits for each type of action: what the agent may only draft, what a team member signs off, and what calls for a second signature. Ledger postings, price and credit-limit changes and promises to clients always wait for a person. Minor actions that can be undone, such as resending a failed message, may run without sign-off where the owner agrees.
Auditability
Each event, draft, sign-off, refusal and completed action is logged against the order or request reference, together with the data the agent consulted, the model and prompt version and the person who signed off. A disputed invoice or a client complaint can be followed back one step at a time.
Data protection
Contact details of clients and suppliers reach only the systems that require them. The order history keeps business references and statuses, not complete records, and logs are retained for the period you choose. Processing stays in the region agreed with you, within the EU.
AI transparency
The exceptions desk labels agent drafts clearly, with the evidence and reasoning beside them. The owning systems remain the authority: the order history reflects what they report and never overrules them.
Measures
Indicators we would track
We settle these indicators with you in discovery and draw the baseline from your current system and interface logs before anything is changed.
Indicators we would track
Metric
Why it matters
How we would measure it
01Order cycle time
Why it mattersWhat clients notice first, and the figure that shows where orders are held up.
How we would measure itTime from receiving the order to delivery and to payment, by channel and group company, from history events.
02Orders nobody had to touch
Why it mattersReveals how much of the flow already runs on clean data and agreed rules.
How we would measure itThe share of orders and requests that reach payment without a manual step or a deviation, from the order history.
03Deviations by reason and time to settle
Why it mattersShows which causes to tackle first and whether the exceptions desk is keeping pace.
How we would measure itNumber of deviations per reason code, and time from detection to the fix being carried out, from exceptions desk logs.
04Share of e-invoices sent back
Why it mattersReturned invoices hold up payment and usually reveal a master data or mapping fault.
How we would measure itThe share of outgoing and incoming e-invoices returned, by reason, from Peppol status messages.
05Interface failures and recovery
Why it mattersShows whether the integration layer can be relied on and whether failures are spotted and fixed fast.
How we would measure itFailed messages per interface, and time from failure to a successful replay, from integration monitoring.
06Duplicate and clashing master data
Why it mattersMost deviations go back to data that differs from one system to another.
How we would measure itOpen duplicates and clashing values per data object and system, from the matching reports.
No targets are set before a baseline exists.
Rollout
A phased rollout
Phase 01
Discovery and process map
A single process, for example order to cash for one sales channel, and a single type of deviation. We chart the systems, interfaces and data owners, and how deviations are dealt with now.
Exit criteria
Process, systems and data owners charted
First deviation type and sign-off limits settled
Baseline drawn from current logs
Phase 02
Integration and order history
Documented APIs and events for the systems in scope, with the order history running next to the current interfaces and leaving them untouched.
Exit criteria
Event contracts published under version control
Order history agrees with the owning systems on a sample of orders
Replay and runbooks tested
Phase 03
Exceptions desk pilot
The agent drafts fixes for the chosen type of deviation, and staff sign off every draft. We compare the drafts with what staff would have done themselves.
Exit criteria
Drafts reach the agreed quality
Limits and signatories set per action type
Audit trail checked by finance and internal control
Phase 04
Widen and switch off
Further deviation types, channels, group companies and processes such as procure to pay, all on the same contracts. Old direct links between systems are turned off one at a time.
Exit criteria
Every new flow on the same contracts and monitoring
Build-to-order and spare-parts orders at a Maltese plant, from the ERP through the warehouse to the carrier and the port, with supplier confirmations and e-invoices matched to purchase orders.
Solar and installation jobs at energy service firms, followed from job order through the site visit to the invoice, with materials bought under framework agreements.
Procure to pay with Government departments, entities and local councils, using EN 16931 e-invoices over Peppol matched to orders and receipts before payment.
Illustrative example
A Maltese distributor supplying hotels and Government
Situation
A family-owned distributor imports supplies and sells them to hotels, shops and Government entities through a webshop and its sales reps, from two warehouses in Malta and Gozo. Orders are typed into the ERP again, carriers report problems by email, and invoices to Government buyers are prepared by hand.
System
Orders, stock, deliveries and invoices pass as events between the webshop, the ERP, the warehouse software and the carriers, and every order has a single history. Invoices to Government entities leave as EN 16931 e-invoices through a Peppol service provider.
Human control
Items out of stock and failed deliveries arrive at one exceptions desk, where an agent drafts an alternative item or a new delivery slot. Client service signs off each draft; price changes and credit notes need sign-off from accounts.
What we would measure
Share of orders nobody had to touch per channel, deviations by reason and time to settle, and the share of e-invoices sent back.
Malta
Selling from Malta, invoicing Government and the EU
Companies in Malta often sell to local clients, to Government buyers and to customers elsewhere in the EU, while importing much of what they sell, all through one ERP and a handful of carriers and banks. The Government of Malta has opted for Peppol and accepts EN 16931 e-invoices, with no legal obligation yet on suppliers unless a call for tenders requires it, and the EU VAT in the Digital Age package makes structured e-invoicing the norm for intra-EU business-to-business supplies from 1 July 2030. We build one integration layer that keeps each format and network behind the same events, so a new requirement means a new connector rather than a new process.
The Data Act, applicable since 12 September 2025, lays down rules for switching between data processing services, so we keep event contracts and data exports portable. Agents at the exceptions desk are designed with the EU AI Act in view, and integrations come with logged access and documented components for clients that must show supply-chain security under the NIS2 Order (Legal Notice 71 of 2025).
No. The ERP, CRM, webshop and warehouse software each keep doing what they are good at. We integrate around those owning systems, agree which one is responsible for which data, and give the process one history across them all. If an ageing order or ERP system stands in the way, legacy modernisation first puts APIs in front of it.
02Will our integration middleware be replaced?
Not if it works. We build on the integration platform or message broker you already operate and add contracts, monitoring and replay where these are lacking. If you have none, we build cloud native. Read more about our integration services.
03May the agents act without anyone signing off?
Only inside limits you set for each type of action, and only for minor steps that can be undone, such as resending a failed message. Ledger postings, prices, credit limits and promises to clients always need a person. Our article on when AI agents need a person to approve explains the reasoning.
04Where does e-invoicing come in for a Maltese business?
The Government of Malta has chosen Peppol and accepts EN 16931 e-invoices from its suppliers, although suppliers are not legally required to send them unless a call for tenders asks for it. At EU level, the VAT in the Digital Age package makes structured e-invoicing the norm for intra-EU business-to-business supplies from 1 July 2030. We treat the e-invoice as one more event in the process: produced by the ERP, sent through your Peppol service provider, and dealt with at the exceptions desk if it is returned. Our guide to Peppol e-invoicing covers the detail.
05How do you stop this becoming another tangle of direct links?
Systems announce and read documented events and APIs through a single layer, not through direct connections with one another. Contracts carry versions, receivers are idempotent, failed messages can be replayed and each flow has a named owner. A new channel listens to events that already exist instead of being wired to every system.
06What would a sensible first scope be?
A single process and a single type of deviation, for instance order to cash for one sales channel, starting with items out of stock. That proves the events, the order history and the sign-off flow before anything else is added. See how we take projects into production.
Tell us about your order and invoice flows
Choose one process and the systems it runs through. Together we will chart interfaces and deviations and propose a first release that works for your business in Malta and beyond.