Comparison
Keep SPS Commerce for the retailers who mandate EDI. LevelOps picks up the emailed purchase orders the network was never pointed at.
SPS Commerce is a retail EDI network, and for the problem it was built to solve it is one of the best answers available. If a large retailer says their purchase orders arrive as an EDI 850, that you owe acknowledgements and advance ship notices back, and that their compliance team will charge you back for a mislabelled carton, you need a managed EDI provider. SPS Commerce is a credible choice for exactly that, and we do not sell a replacement for it.
The comparison is about a different set of orders. A network covers the trading partners you deliberately enabled on it, because enabling one costs money and effort on both sides, so the budget goes to partners whose volume justifies it. That is a rational allocation, not a failure. What is left is the long tail: the independent retailer, the four store distributor, the buying group that emails a purchase order as a PDF every Tuesday. Those accounts were never on the network, so somebody on your team retypes them into Shopify.
LevelOps PDF to Order reads that document. Any layout, no template, no field mapping, nothing asked of the customer. Every line is matched against your Shopify catalogue including the buyer's own part numbers, priced from your catalogue and that account's Shopify B2B price list, and written as a native Shopify draft order for a person to approve. It never sees your EDI traffic.
So the verdict is both, not either. Keep SPS Commerce for the retailers who mandate EDI, add order intake for everyone else, and watch the gap between them: a purchase order that arrives through an EDI or supplier portal channel but lands as a PDF that nothing imports into Shopify, so someone retypes it anyway.
This work is hard and worth paying for. If you have never run an EDI programme, here is what you are buying.
The network already holds the relationship with the retailer, which is the part you cannot build yourself. Enablement connects your business to one named partner, with the right identifiers, transport and document types switched on, coordinated with the retailer's vendor onboarding team. Their side has to participate, not just yours.
EDI is a standard, and then every retailer publishes an implementation guide on top of it: which segments are mandatory, which qualifiers they use, how they identify a store, how they express a case pack. The 850 from one retailer is not the 850 from another, so mapping is written per retailer rather than once.
Retailers dictate carton and pallet labelling, usually a GS1 style shipping label, and require an advance ship notice matching what is physically on the truck. If label, notice and carton disagree, the receiving dock finds out. Operational compliance, not data entry.
The retailer certifies the connection against their guide before it goes live, which is why enabling a partner is a project rather than a setting. Then specifications change, and somebody has to update the map before documents start being rejected. On a managed network that somebody is the vendor.
The usual explanation is that EDI is old or expensive, and both miss the point. Your independent accounts are not on the network because onboarding a trading partner has a cost, in fees and in effort, paid per partner rather than once. Retailer mandated EDI programmes typically involve per partner onboarding work and recurring charges, so the budget goes where the order volume returns it. Nobody made a mistake.
A few accounts produce a large share of your volume, and those are usually the ones mandating EDI anyway. Then comes the tail: the four store distributor, the specialty retailer who reorders when the shelf empties, the buying group consolidating six independents onto one purchase order. Individually none justifies an enablement project, collectively they are often the majority of your accounts. EDI is also bilateral, so even if you paid to enable a small account, they have to implement their side, and most independents have no EDI capability and no intention of acquiring one.
So the tail stays on email and the cost moves from software into labour, where it hides in somebody's day rather than on an invoice. Manual entry runs about 6 minutes an order once you count opening the document, finding the customer, matching lines and checking price. One customer measured an operator spending 8 hours a day on a single customer's orders, which came down to 40 minutes. The error rate hurts more: 3% for manual entry against 0.5% with a matched, reviewed draft order, which is 6x fewer, and an erroneous order costs about $250 to unwind.
This is the sharpest point on the page, so it is worth being precise rather than scoring off anybody. Across EDI and supplier portal channels generally, a purchase order can travel through the channel correctly and still arrive as a human readable document: a printable purchase order, a portal export, an emailed order copy with a tidy table on it. The document is right, the channel worked, nothing imports it into Shopify, and an operator retypes it on an account that is nominally automated. The causes are ordinary configuration. A partner served through a web portal rather than a direct connection. A document type outside the set enabled for that partner. A mapped endpoint that is an ERP rather than the Shopify store where the order needs to exist. Or a retailer's own vendor portal that emails the purchase order as a PDF.
Check it before you buy anything. Sort last month's orders into three piles: arrived structured and landed in Shopify untouched, documents from accounts never on the network, and orders that came through an automated channel and were still typed by hand. The third pile is usually bigger than anyone expects, and it is where a document reader pays for itself fastest, since you are already paying for the channel.
Two different jobs on the same rows. The third column is what most wholesalers do today with the orders the network does not cover.
| SPS Commerce and retail EDI networks | Retyping the leftovers | LevelOps PDF to Order | |
|---|---|---|---|
| Setup shape | Per partner enablement, mapping, testing, certification | None, a person and a keyboard | Install, catalogue sync in 2 to 5 minutes, forward an order |
| Cost shape | Not published, so we do not quote it. Programmes of this kind generally combine platform, per partner and per document fees | Labour, rising with volume and with peak | Free for your first 5 orders, then $50 one time or $100 to $250 a month |
| Handles non standard formats | No, and that is the point: the format is the contract | Yes, a person reads anything | Yes, no template and no field mapping |
| Customer has to change something | Yes, they implement their side | No | No |
| Human review before an order exists | Usually straight through, which is right at volume | The person is the review | Yes, a draft order awaiting approval |
| Catalogue matching | By identifiers agreed between partners | By hand, from memory or a lookup sheet | Exact SKU, then semantic matching, plus learned buyer part numbers |
| Pricing source | The agreed price file for that partner | If the person remembers to check | Your catalogue and that account's B2B price list, never the document |
| Native Shopify draft order | Through a connector, varies by mapped endpoint | Yes, typed by hand | Yes, with the source file attached |
| Retailer compliance sign off | Yes, certified against the retailer's guide | No | No, and not for mandated relationships |
| Ongoing maintenance | Vendor managed maps as retailer specs change | Never ends, invisible until somebody leaves | Vendor managed, nothing to remap on a layout change |
| Best fit | Retailers who mandate EDI, with chargeback exposure | A handful of document orders a month | The long tail of emailed, non standard purchase orders |
A mandate is not a negotiation. If a large retailer's vendor requirements say EDI, with their document set, their labelling and their certification, a managed retail EDI network is what you buy and there is no argument to have. Do not let anybody sell you a document reader as a way around it, ours included. It would not be accepted by that retailer's compliance team, and it should not be.
Chargeback avoidance is the win people underrate until they have paid one. Big box relationships carry penalties for late or missing documents, for labelling that does not match the specification, for advance ship notices that disagree with the pallet, and those penalties are administered by a team whose job is to administer them. A certified connection, maintained by a provider watching for specification changes, is how you stay out of that.
The full document set is a category advantage rather than a feature. Order intake reads inbound purchase orders. A network runs the whole conversation: order in, acknowledgement back, advance ship notice with the shipment, invoice after, plus whatever else the programme requires. If your problem is the round trip, nothing in our category is even the right shape.
Scale is the other clear win, because one provider holding and maintaining a map per retailer is the only sane way to sell into several large chains at once. And acceptance matters more than capability: the retailer's compliance team already knows the major networks, so a connection through one removes an objection you would otherwise answer with engineering. Two things follow. If an account is large enough that a certified connection pays for itself, enable it even where EDI is not mandated. And if a retailer mandate is the whole of your problem, buy EDI and skip us.
None of this is a criticism. It sits outside the design of a retailer facing EDI programme, and it is where the retyping lives. First, the accounts you will never enable: the independent retailer, the four store distributor, the specialty shop, the buying group. No EDI capability, and not enough volume individually to justify enablement even if they had it. Second, the order that came through an automated channel and still arrived as a readable document, so a person reads and retypes it anyway.
Third, Shopify as the destination. A connection is mapped to an endpoint, often an ERP or an accounting system. If the order needs to exist in Shopify, with the account's B2B price list applied and the draft order workflow your team already uses, that is a different problem from document translation. Fourth, the messy real document: merged cells in a spreadsheet, a scan with a handwritten quantity in the margin, two purchase orders on one page, a buyer ordering by their own part numbers, a layout that changes when the account switches accounting system.
The order arrives as a document from an account that is not on your network. Here is the whole path, and a person still has the last word.
Forward the email, or point your forwarding address at the mailbox where purchase orders land. PDF attachment, spreadsheet, plain text in the body, a scan. No template, no specification and no portal login on their side, and it works the same on documents an automated channel delivered as a PDF. Your EDI setup is not touched.
Exact SKU lookup first, then semantic matching against your product descriptions when the buyer did not use your SKU, then the buyer part numbers the system has learned from previous orders with that account. Nothing to train per sender, so a buyer ordering by their own codes or by description alone still lands correctly.
Each line is priced from your Shopify catalogue and that account's Shopify B2B price list. If the purchase order carries a stale price, the draft order shows yours and the difference is visible to whoever approves it. The buyer's document never sets the price, which is the part that protects margin.
The output is a standard Shopify draft order with the source document attached, not extracted text and not a separate system to learn. Your team checks it in the admin they already use and approves, and from there it is an ordinary Shopify order flowing to fulfilment, accounting and your ERP as before. About 6 minutes of work becomes about 1, and nothing becomes an order without a human sign off.
In practice the split is boring, which is the point. Orders arriving through your EDI connections continue exactly as they do now, straight through, acknowledged, with documents going back the way the retailer requires, and nobody at LevelOps sees them. Orders arriving as documents get forwarded to your LevelOps address and come back as Shopify draft orders for review. Two paths, no overlap, no routing rules to write.
The only deliberate decision is the pile in the middle, the orders that arrived through an automated channel as a readable document. Those go to order intake, because the alternative is retyping them. If a partner in that pile is large enough that a certified straight through connection is worth the enablement, that is an EDI conversation and the right one to have.
For the operator there is one queue rather than a new system. Draft orders appear in the Shopify admin your team already uses with the source document attached, and when an order needs judgement, a credit hold, a discontinued line, an unmet minimum, the person makes the call before the order exists rather than unwinding it afterwards. Nothing has to be migrated, because there is no data to move and no partner to re enable. Count the purchase orders a person retyped last month at about 6 minutes each, weigh that against $100 a month for 33 orders or $250 a month for up to 100, and use the 5 free orders to check your worst formatted document first.
Real Shopify merchants using PDF to Order alongside the channels they already had.
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.
We wanted EDI for Shopify without the cost of a traditional EDI integration. Retail purchase orders now convert automatically into Shopify draft orders.
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.
Each of these says where the alternative genuinely wins. If one fits you better than we do, that is the useful answer.
The category level version of this page.
Your biggest accounts will not log in.
Parsers need a template per sender.
A portal and an EDI bridge. Where each wins.
An OMS manages orders after they exist.
The salary hiding in your inbox, costed out.
Six ways an order gets into Shopify.
How LevelOps reads what an EDI platform outputs.
The full grid, and the arithmetic against manual entry.
Check last month's orders for the ones a person typed in by hand, including the ones that arrived through an automated channel as a PDF. Then forward one and see what comes back.
Your first 5 successful orders are free with no expiry. If your problem turns out to be a retailer mandate, we will tell you to buy EDI.
FAQ
No, and we would talk you out of trying. SPS Commerce is a retail EDI network and it is the right supplier for retailers who mandate EDI. LevelOps reads the orders that arrive as documents from accounts never enabled on the network, so the two never touch the same order.
Because they cover different accounts. Your connections cover the partners you deliberately onboarded, the ones whose volume justified the work. Everything else arrives as a PDF, a spreadsheet or an email, and somebody retypes it.
Very common, and it is the sharpest reason merchants find us with EDI already in place. A purchase order can travel through an EDI or supplier portal channel and still land as a human readable document, because that is what the channel was configured to deliver for that partner or document type. LevelOps reads it and writes a Shopify draft order.
Any order from a retailer who mandates EDI as a condition of doing business, and any relationship where you owe acknowledgements, advance ship notices and invoices back through the same channel. Compliance and chargeback exposure make that call for you.
For a few it may be worth it. Enabling a trading partner is work on both sides: mapping to a specification, testing, then ongoing maintenance. Retailer mandated EDI programmes typically carry per partner onboarding and recurring fees, which is why the budget goes to partners with real volume. Most independents also have no EDI capability.
Nothing. They keep emailing the purchase order they already send, in whatever layout their system produces. No portal login, no template, no specification. The long tail is the set of accounts that will not change how they order.
A native Shopify draft order, every line matched to your catalogue and priced from your catalogue and that account's Shopify B2B price list, with the source document attached. Nothing becomes an order without a human signing off.
Your first 5 successful orders are free with no expiry. Then $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 annually. Above 100 orders a month we quote. SPS Commerce does not publish prices, so we will not guess at theirs.
