Does order intake replace our EDI?
No. EDI keeps serving the retailers who mandate it. Order intake picks up the emailed orders EDI never covered, so the two run side by side.
Comparison
EDI vs API vs Order Intake: Which One?
EDI covers mandated retailers. API covers systems. Neither reads the emailed purchase orders from everyone else.
The short answer
EDI is not a competitor and we will not pretend otherwise. If a trading partner mandates EDI, EDI is the correct answer, an EDI provider is the correct supplier, and there is no argument to have. Structured, acknowledged, auditable document exchange at volume is what EDI was built for, and it does that job better than anything else. Nothing on this page suggests dropping it.
The useful question is narrower: what does your EDI not cover? EDI works because both sides implement it. The retailer runs a compliance programme, you run a translator and a map, and a purchase order becomes an EDI 850 that lands in your system without a human touching it. That symmetry is the strength and also the limit. Every account has to build the same thing, which is why onboarding a partner takes weeks to months, and why nobody onboards a customer who orders twice a quarter.
So the long tail stays on email. A PDF arrives as an attachment, or a spreadsheet with merged cells, or a scan with a handwritten line at the bottom, and somebody retypes it into Shopify. There is a second gap that surprises people more. Many EDI setups end with a human readable document rather than a posted order: the platform receives the 850, renders it as a purchase order PDF, emails it to your orders inbox, and nothing imports it. The order arrived through EDI and is still typed in by hand.
Order intake is the layer for both cases. LevelOps reads whatever purchase order document arrives, matches every line to your Shopify catalogue including the buyer's own part numbers, prices from your catalogue and B2B price lists rather than from the document, and writes a native Shopify draft order for a person to approve. Keep EDI for the partners who mandate it, add order intake for everyone else. Most wholesalers on Shopify should run both.
What EDI actually is, mechanically
Described accurately, because most pages on this subject describe a caricature. If you already run EDI, skip to the table.
A set of standard documents
EDI is a family of standardised transaction sets, X12 in North America and EDIFACT internationally. The ones that matter in wholesale are the 850 purchase order, the 855 acknowledgement, the 856 advance ship notice and the 810 invoice, with a 997 functional acknowledgement confirming the file was received and parsed.
- 850 in, 855 back, 856 before the truck, 810 after
- Every field is defined and positional, nothing is inferred
A network that moves them
Documents travel over a value added network, a mailbox service between trading partners, or over a direct AS2 connection between two servers with signed, encrypted payloads and a machine receipt. Either way there is a delivery guarantee and an audit trail, which is exactly what a compliance team wants.
- VAN mailboxes, or AS2 point to point
- Network costs are usually per document or per kilocharacter
A map per trading partner
The standard leaves room, so every retailer publishes an implementation guide saying which segments it sends, which qualifiers it uses, which identifiers apply and what it expects back. Your provider builds a map against that guide. The map, not the standard, is the actual work.
- One implementation guide per partner, sometimes hundreds of pages
- A guide revision means rebuilding the map
An onboarding project on both sides
Bringing a partner live means connectivity setup, mapping, a test cycle in their certification environment, sample documents signed off, then a parallel run. The hub page puts this at weeks to months per trading partner and that matches what wholesalers tell us. The effort is not waste, it is what buys the reliability.
- Setup fees per partner, then recurring transaction fees
- Both sides commit engineering time, not just you
Vendor compliance and chargebacks
Large retailers run compliance programmes. The vendor manual sets out what must be sent, in what format, within what window: an acknowledgement inside a stated time, an ASN before the shipment arrives, correct labels and identifiers. Miss one and the deduction comes off your invoice. That is a real cost of the channel, and a reason to run EDI properly rather than to avoid it.
- Deductions are governed by the retailer's compliance manual
- Late or malformed documents are the common trigger
The document that nothing imports
The end of the chain is where the gap shows. Plenty of setups deliver the 850 into a portal or an inbox as a rendered purchase order rather than posting it to your store, because Shopify has no native X12 and something has to bridge the last step. The order arrived through EDI and a person still retypes it.
- A rendered PO in an inbox is a document, not an order
- This is the most common EDI gap we are asked to fill
What each path does with one purchase order
Three ways the same order reaches Shopify. EDI wins outright on the rows it was designed for and loses only on reach.
| EDI through a provider | Re-keying the EDI document | LevelOps order intake | |
|---|---|---|---|
| Setup time | Weeks to months per trading partner | None | Under an hour, plus a 2 to 5 minute catalogue sync |
| Cost shape | Setup fee per partner, then transaction fees | Labour only, rises with every order | Free for your first 5 orders, then $50 one time or $100 to $250 a month by volume |
| Handles non standard formats | No | Yes, a person reads anything | Yes, no template and no field mapping |
| Does the customer have to change anything | Yes, they must run EDI too | No | No |
| Documents covered | 850, 855, 856, 810 and more, both directions | Whatever a person will read | Inbound purchase orders only, PDF, spreadsheet, scan or email body |
| Human review before an order exists | Usually straight through processing | The person is the review | Yes, always, a draft order awaiting approval |
| Catalogue matching | By identifiers agreed in the implementation guide | By hand, from memory or a lookup sheet | Exact SKU, then semantic matching, plus learned buyer part numbers |
| Pricing source | The agreed price file between partners | Whatever the person checks, or does not | Your Shopify catalogue and B2B price lists, never the document |
| Native Shopify draft order | Through a connector, varies by provider | Yes, typed by hand | Yes |
| Acknowledgements and ASN | Yes, 855 and 856 as the partner requires | No | No |
| Chargeback exposure on mandated accounts | Managed, that is the point of the programme | High, deadlines rely on somebody remembering | Not applicable, these are not those accounts |
| Ongoing maintenance | Partner onboarding and map revisions, forever | None technically, but the work never stops | Vendor managed, updates ship to you |
| Who it fails for | Accounts too small to justify onboarding, which is most of them | Anyone above about 15 document orders a month | Partners who mandate certified X12 |
| Best fit | Retailers who mandate it and have the volume | Under about 15 document orders a month | The long tail of emailed, non standard purchase orders |
Where EDI genuinely wins
On mandated accounts, EDI wins and nothing else is close. If a compliance team specifies an 850 over AS2, an 855 inside a stated window and an 856 before the truck arrives, that is the specification. No document reader satisfies it. Buy EDI from a provider certified for that partner and treat the cost as the price of being in the channel.
EDI wins on unambiguity. A parsed 850 has no layout, no font, no scanned coffee stain and no argument about which column is quantity. Every field is defined by the implementation guide, so the retailer item number sits where it belongs and means one thing. Any system reading a rendered document, ours included, is recovering structure that EDI never lost. Where the volume justifies the map, that is the better foundation.
EDI wins on the round trip, and this is a gap in our product rather than a detail. Order intake is one directional by design: a document comes in, a draft order goes into Shopify. EDI carries the whole conversation, the acknowledgement that tells the buyer what you accepted, the ASN that lets their dock plan receiving, the invoice their accounts payable posts without a human. If you need those flowing back, you need EDI, and the same channel then covers routing and settlement for those partners.
EDI wins on high volume with a stable partner. A retailer sending hundreds of orders a month through a map you built two years ago costs almost nothing per order and never surprises you. Amortised across that volume the onboarding project was cheap. The arithmetic that makes EDI look expensive is the arithmetic of onboarding a partner who orders occasionally, which is a reach problem rather than a quality problem.
EDI wins on commercial standing rather than on technology. Being EDI capable is a condition of doing business with large retail: it is how you get on the vendor list, survive an audit and avoid deductions that eat the margin on the account. If you are growing into big box retail, invest in EDI and do it properly. Anyone selling you a document reader as a substitute is selling you a chargeback.
What EDI leaves behind
Six gaps, none of them a defect in EDI. They all follow from the fact that both sides have to implement it.
The long tail that will never onboard
The independent retailer, the regional distributor, the school board, the contractor buying for one job. They order a few times a year with no EDI capability, and nobody will fund a mapping project on either side to serve them. For most Shopify wholesalers these accounts are the majority of the customer list, and they all send email.
The large account that still emails
Size predicts EDI capability less reliably than people assume. Plenty of substantial buyers run a procurement system that emits a PDF purchase order and emails it, because that is what their process does. They are too important to refuse and too settled to change, so somebody retypes a hundred lines.
The rendered document at the end of the chain
Check this before you buy anything. Your EDI platform receives the 850 and produces a readable purchase order that lands in an inbox or waits in a portal, because Shopify has no native X12. Everything upstream worked. The last step is a person with a keyboard, and that step is the one order intake removes.
New accounts before the project finishes
A trading partner takes weeks to months to bring live and orders do not wait for certification. During onboarding, and during the parallel run afterwards, orders arrive as documents and get typed in. The same happens whenever a partner revises its implementation guide and the map has to be rebuilt.
Anything that is not a purchase order
Order changes in an email reply, a revised quantity sent as a photo of a marked up sheet, a standing order attached as a spreadsheet. EDI has transaction sets for some of this, but only with partners who implement them. On the long tail this traffic is unstructured by nature and still has to become an order.
The catalogue and pricing work at your end
EDI delivers a clean document. It does not decide that the buyer's part number is your SKU, and it does not apply the price list attached to that company in Shopify. On mandated accounts the identifiers and the price file are agreed in advance. On everyone else that matching is the actual work, and it is what order intake does.
Questions to ask before you push another account onto EDI
Worth running through with your provider and with the account itself. Two or three honest answers usually settle it faster than a quote does.
- Does this partner mandate EDI, or would we be asking them to adopt it voluntarily?
- What is their annual order volume, and does it cover the setup fee plus transaction fees?
- Do they have EDI capability today, or would they need a project of their own?
- Which documents does the partner require back, an 855, an 856, an 810, or none?
- Is there a compliance manual with deduction terms attached to this relationship?
- What happens to their orders during the weeks the onboarding runs?
- When the 850 lands, does it post to Shopify, or become a PDF somebody opens?
- How many other accounts are in the same position, and will we onboard all of them?
How LevelOps handles the same order
The account that will never onboard sends a PDF to your orders inbox. Here is the whole path, and a person still signs off at the end.
- 01
The document arrives as it always did
Forward it, or point an inbox at us. PDF, spreadsheet, scan, an email body with the order typed into it, or the purchase order your EDI platform rendered and never posted. No template, no per sender mapping, nothing asked of the customer.
- 02
Every line is read
Header details, ship to, requested dates, line items, quantities, units of measure and the buyer's own part numbers, including the note in the margin that changes what was ordered. Nothing is fitted to a fixed field map, which is why a new sender needs no setup.
- 03
Lines are matched to your catalogue
Exact SKU lookup first, then semantic matching, then the buyer part numbers learned from previous orders on that account. Anything ambiguous is flagged for the reviewer rather than guessed, so a doubtful match becomes a question instead of a shipment.
- 04
Pricing comes from Shopify, not the document
The resolved company decides the price list. Contract pricing, volume breaks and payment terms come from your Shopify B2B setup, so a stale price on the buyer's purchase order never becomes a stale price on your order.
- 05
A native Shopify draft order waits for approval
A standard draft order with the source file attached, ready to check and convert. Whatever runs downstream, Flow, your ERP sync, your fulfilment routing, sees it like any other order. The human sign off is the feature, not a limitation.
About one minute of review per order in practice, against about six minutes to retype the same document. Nothing here touches your EDI partners, which keep flowing exactly as they do today.
The measured difference on the emailed side
~1 min
Processing per order, down from about six minutes
6x
Fewer errors, 0.5% against 3% for manual entry, with a human signing off
$250
Typical cost to unwind a single erroneous order
2 min
Self-serve time to value, with catalogue sync in 2 to 5 minutes
Running EDI and order intake together
There is nothing to migrate, because the two touch different accounts. This is what adding intake looks like for a wholesaler already running EDI.
List your accounts against how their orders actually arrive. One column for the partners on EDI, one for the accounts using a portal, one for everyone who emails a document. Count order lines rather than orders, because the long tail tends to send the long documents and the line count is what your team retypes.
Then check the EDI column for the rendered document case. For each mandated partner, follow one recent order from the 850 to the record in Shopify and note whether anybody typed anything. If they did, the fix is not more EDI, it is reading the document your platform already produces. That is usually the fastest saving on this page, because the volume is high and the format is consistent.
Take the email column and run your five worst documents through, not tidy samples. Judge on what comes out: a matched, priced Shopify draft order, or extracted text somebody still has to finish. Your first 5 successful orders are free with no expiry, so the test costs time and nothing else. Nothing changes on the EDI side while you do it. No map is touched, no partner is notified, no certification is repeated. If a long tail account later grows into a mandated relationship, onboard it to EDI then and it simply stops arriving as a document.
Wholesalers running both
Reviews from merchants who kept EDI and added document intake for the accounts it never reached.
EDI, PDF, Excel, email
Every channel, one flow
Such a timesaver and super easy to implement. We process purchase orders via EDI, PDF, Excel or email format, and the team always listens to customer feedback.
Three Ships Wholesale
B2B and distribution
Day 1
Time to visible impact
Exactly what we needed to save manual processing time entering emailed purchase orders into our B2B store. Awesome app and awesome team.
Concrete Countertop Solutions
Building materials
Keeps the account
Formats handled, customer unchanged
Manually processing B2B orders is something you simply have to deal with if you want to keep specific customers. LevelOps provides a great time-saving solution for reading orders in various formats and converting them to draft orders for final review.
Earth Fed Muscle
Supplements
Keep comparing
Every comparison page says where the alternative genuinely wins. If one fits you better than we do, that is the useful answer.
vs SPS Commerce
The same argument applied to one named EDI platform, including the documents it emits.
vs a Shopify B2B portal
Your biggest accounts will not log in. How to serve both without forcing anyone.
vs email parsers
Parsers need a template per sender. One real purchase order run through both.
vs OrderEase
OrderEase is a portal and an EDI bridge. Where each one wins.
vs an OMS
An OMS manages orders after they exist. Intake gets them in.
vs manual order entry
Minutes per order and the salary hiding in your inbox, costed out.
EDI integration for Shopify
Accepting EDI orders on Shopify without the X12 project, and when to build the real one.
Purchase order automation
The full intake picture across every channel, not just EDI.
Keep your EDI. Cover what it does not reach.
Bring one mandated retailer order and one emailed purchase order from the long tail. We will show you where each lands, and tell you if your EDI provider is the better answer for both.
Your first 5 successful orders are free with no expiry. If a partner mandates certified X12, we will say so and point you at an EDI provider rather than sell you around it.
FAQ
Questions teams ask first
Do customers have to change how they send orders?
No. They keep emailing the way they already do. Order intake reads whatever layout arrives.
Can it read the documents our EDI platform emits?
Yes, including the order documents that get produced but never imported, so nothing falls between systems.
Is this cheaper than a traditional EDI integration?
Yes. That is exactly why merchants like Three Ships adopted it, EDI-style automation without the EDI project.
What about accounts that use a portal?
Those keep working. Order intake covers the accounts that will not adopt a portal and keep emailing instead.
What is an EDI 850, and does LevelOps handle it?
The 850 is the X12 transaction set for a purchase order, the structured file a retailer sends when it mandates EDI. LevelOps is not a certified X12 network and does not receive an 850 off a VAN. It reads the human readable purchase order your EDI platform or partner produces from that transaction, as a PDF, a printable or a CSV, and writes a Shopify draft order.
Can LevelOps send an 855 acknowledgement or an 856 ASN?
No, and you should not expect it to. Acknowledgements, advance ship notices and EDI invoices are your provider's job, and a mandated partner needs a provider certified for that relationship. LevelOps handles the inbound order document and stops there.
Will this protect us from chargebacks?
Not on your EDI partners. Vendor compliance deductions are governed by the retailer's manual and by the documents you return on time, which stays with your EDI provider. Where order intake cuts cost is the emailed side, where the measured error rate is 0.5% against 3% for manual entry and an erroneous order costs about $250 to unwind.
How long does it take to add a new account?
There is no per partner onboarding, because nothing changes on the customer's side. You connect the store, the catalogue syncs in 2 to 5 minutes, and the first order can be processed in about two minutes. A single EDI trading partner takes weeks to months to bring live.
What does it cost next to an EDI project?
Your first 5 successful orders are free with no expiry. After that it is $50 one time for 15 orders on Pay as You Go, $100 a month for 33 orders on Starter, or $250 a month for up to 100 orders on Growth, with 20 percent off on annual billing. Above 100 orders a month we quote. EDI is priced differently, usually a setup fee per trading partner plus transaction fees, so the two do not compare line for line.