Manufacturing / EDI alternative
An EDI alternative for customers too small to onboard
An EDI alternative for the long tail of your customers, the ones who will never send an 850. Mirage reads the orders they already send by email and PDF and writes them to your ERP the way an EDI order would arrive. Send us a batch and see the result within a week.
In production at Biodéal, on orders from 113 customers in their own formats.
The reality
EDI pays off with the customers who send orders every day. For the rest, each trading partner means a map, a round of testing, a VAN or AS2 connection and a partner who has to agree to it, so the small accounts keep sending PDFs and your team keeps typing them.
What Mirage does
Non-EDI order processing
The customer changes nothing. Mirage takes what they send today and produces what your ERP expects from an EDI order.
No onboarding on the customer side
No mapping project, no VAN or AS2 connection, no request to the customer's IT. A new customer is covered as soon as their first order reaches the inbox.
The same checks an EDI order gets
Item, unit, price and ship-to are validated against your master data before anything is written, the way a mapped EDI 850 purchase order is validated on the way in.
Into the same pipe
The order reaches the ERP through its API, or as an X12 850, an EDIFACT ORDERS message or a flat file your existing integration already reads, so nothing changes downstream.
EDI cost per trading partner, and why onboarding takes so long
EDI is the right tool for the partners it reaches. The question is how far down your customer list it is worth taking it.
What an EDI connection costs per partner
The bill has several lines: building and testing a map for each message type (the 850 order in, the 855 acknowledgment and 810 invoice out), the VAN's per-document charges or an AS2 setup, and maintaining the map whenever the partner changes its format.
Why EDI onboarding is slow
Because it is a project on both sides. The partner has to agree, assign someone, exchange test files and fix mapping errors in their own system. The slowest step is the one you do not control: the customer's IT calendar.
EDI or API for order intake
An API connection asks as much of the customer as EDI does. Both suit large accounts with IT resources. For everyone else, the realistic input is the email and PDF they already send, and that is the input Mirage reads.
The output
Each email order, read like an EDI 850
| On the email order | Equivalent 850 segment | Written to the ERP | Status |
|---|---|---|---|
| Order 4471, dated 3 March | BEG | Customer PO 4471 | Written |
| Deliver to our Lyon depot↳ The email gave an address, not a location code. It matched one of the customer's three delivery addresses on file. | N1 ship-to | Ship-to 2 of customer C1045 | Matched by address |
| Ref. 88-120-B, 40 pieces | PO1 line | Item 30412, 40 PC | Written |
| Same as last month's order↳ There is nothing to map: the customer referred to a previous order. The line goes to your team with that order attached, and the rest is written. | PO1 line | No quantity on the order | Sent to a person |
Proof
Orders from customers who will never use EDI, in production
Biodéal, an organic dairy distributor, receives orders by email from retail chains, bakeries and wholesalers. Mirage writes them to SAP Business One.
Biodéal
Orders from 113 distinct customers, each in its own format, written to SAP automatically
48 seconds median from email received to order ready
About 7% of orders flagged for a human check, none lost silently
An EDI alternative, tested on your own orders
Send us a batch of orders from customers you have never managed to put on EDI. Within a week you see each one as your ERP would receive it.
How a deployment runs: Observe, Map, Build, Run, Expand. See the method
Prefer to talk it through first? Book a call
FAQ