Recognise
A routing model classifies each email, file or EDI signal and selects the correct workflow.
Case study · Order operations
From emailed PDFs to an ERP-ready order.
Orders are read, reconciled and written back to the existing ERP. People handle exceptions instead of retyping every line.
Operating proof
7Operational inboxesClassified by one routing layer
38Signal typesOrders, notices, returns and exceptions
11Retailer formatsEach read by a dedicated extractor
02 / Problem
Fast growth turned rekeying into an operational bottleneck.
Retailer orders arrived by email as PDFs, while the same information was copied between mail, spreadsheets, logistics and the ERP. One missing message could mean one missing order; every manual rewrite added time and another opportunity for error.
03 / System
One operational layer over the ERP already in place.
The system handles the complete route from incoming communication to an approved ERP record. It does not replace the ERP or ask departments to adopt another general-purpose tool.
Read
Dedicated extractors recover products, quantities, dates and logistics units from every retailer format.
Reconcile
The order is matched against ERP master data. Ambiguity is isolated and sent to a person.
Write
An approved order enters the ERP buffer through its native API, with the source document attached.
04 / Outcome
The team approves exceptions instead of transcribing orders.
The full flow runs on client data: message intake, ERP reconciliation, human approval and native API write-back. Existing systems remain; the manual coordination between them is what disappears.