Comparison
A buyer placing their own order in your catalogue at your prices beats any document being read by anything. The problem is not quality, it is adoption.
If your buyer will log into your portal, the portal wins and it is not close. A buyer choosing products from your catalogue, at the price list assigned to their company, with their payment terms applied at checkout, produces an order that needed no extraction, no matching and no review. Nothing was read, so nothing could be misread. Shopify B2B does this natively and most wholesalers on Shopify should turn it on.
The problem with portals has never been quality. It is adoption. Your largest and oldest accounts are usually the least willing to change how they order, because their side of the process has a procurement system that emits a PDF and a buyer who is measured on something other than your convenience. When a purchase order is generated, numbered and approved inside the buyer's own system, keying it into your portal is doing the work twice.
So the two are not competitors. The correct shape for most wholesalers is both: a portal for the accounts that self serve, and document intake behind it for the accounts that will not. PDF to Order reads the emailed purchase order whatever its layout, matches every line to your Shopify catalogue, prices it from the same B2B price lists your portal uses, and writes a native draft order for a person to approve.
The honest test is your account list rather than a feature table. Ask your ten largest customers whether they will place their own orders in a portal, and note that the ones who say no are the reason this page exists.
Described generously, because it deserves it. This is a real wholesale platform, and if you are not using it you are probably rebuilding parts of it by hand.
A company is a first class record, not a customer with a tag. Each location carries its own address, catalogue, payment terms and tax settings, and history rolls up to the company rather than one email address.
Buyers are attached to a company with ordering permission per location, so a junior buyer can order for one branch without seeing the pricing or history of the whole group.
A catalogue controls what a company sees and what it pays. Publish a subset of products, hide the lines they cannot buy, show a distributor a different assortment from a retailer.
A catalogue carries a price list, either a percentage off retail or a fixed price per variant. Quantity rules sit on top, so minimums and increments are enforced at the cart and volume breaks apply automatically.
Terms are assigned to a company location and applied at checkout. A buyer on net 30 completes the order without paying, and the order carries its due date and the buyer's own PO number.
Your team can build an order for a company in the admin and send it to the buyer, which covers the quote and the account that confirms before committing. That draft order is the same object PDF to Order writes, which is why the two converge rather than collide.
The first group adopts immediately: newer accounts, smaller accounts, accounts run by one or two people who order for themselves, and accounts with no procurement system at all. For them the portal is a straight upgrade. They see stock, they see their price, they reorder last month's order in a few clicks.
The second group adopts under pressure and then drifts. They use the portal for the first order because you asked, then a rush order goes out by email because that was faster on the day, and within a quarter half their volume is back in your inbox.
The third group never adopts, and this is where the money is. Accounts whose purchase orders are produced by an ERP or a procurement suite, institutional buyers whose process is set by policy rather than preference, and buyers who order from three hundred suppliers and will not learn three hundred portals. This group is usually a minority of your accounts and a majority of your revenue. The mistake is not building the portal, it is assuming group three eventually becomes group one.
If you recognise more than two of these in your top ten customers, a portal alone will not empty your inbox.
The order is assembled, numbered and approved inside their system, and the PDF is the output. Their finance team will not accept an order with no matching PO number on their side.
Procurement policy decides the process, not the buyer. The PO is a controlled document with a reference, an approver and a budget line behind it, and nobody in that chain can switch to your portal.
A purchasing manager deals with more vendors than they can hold in their head, and every one of them wants a login. Learning your portal is a cost they pay for your benefit.
Someone has ordered from you the same way for eleven years. It works, it is documented internally, and this is the account you are least willing to push. Ordering there is often three roles rather than one person, a store manager who sends a list, a desk that turns it into a purchase order and accounts who approve it, so no single person can adopt your portal.
From your side a portal is obviously better: cleaner data, no retyping, no extraction risk, live stock, fewer support calls. From the buyer's side it is one more login, one more password reset, and one more workflow outside the system where the rest of their purchasing lives. Email costs them nothing. It is already open, it needs no training, it leaves a thread they can forward to their manager, and it works identically for every supplier they buy from.
That asymmetry is the whole story. The benefits accrue mostly to you and the effort accrues mostly to them. Plenty of buyers absorb it happily, because the stock visibility and self serve reordering are worth it to them too. The ones who will not are not being difficult, they are doing the arithmetic on their own time.
It gets sharper the larger the account. A buyer at a large organisation is measured on cost, on availability and on compliance with their procurement process, and nothing on that list rewards them for making your intake easier. So adoption should be offered rather than demanded.
The rows that change a decision. Notice how many the portal wins outright, and that the ones it loses are about which accounts it reaches rather than how well it works.
| Shopify B2B portal | Third party portal app | LevelOps PDF to Order | |
|---|---|---|---|
| Setup time | Days to weeks of configuration | Days to weeks, plus a data load | Under an hour, plus a 2 to 5 minute catalogue sync |
| Cost shape | Included in your plan, no per order fee | Monthly subscription, varies widely | Free for your first 5 orders, then $50 one time or $100 to $250 a month |
| Who has to change their behaviour | The buyer, on every order | The buyer, on every order | Nobody, the buyer keeps emailing what they send today |
| Handles the PO the buyer's ERP produced | Only if someone retypes it | Most expect a defined structure | Yes, any layout, no template and no field mapping |
| Human review before an order exists | Not needed, the buyer is the author, so nothing is read | Varies by app | Yes, always, because extraction risk is real |
| Catalogue matching | The buyer does it by choosing the product | Often exact SKU only on import | Exact SKU, then semantic matching, plus learned buyer codes |
| Pricing source | Your catalogue and price list | Varies, often a separate price file | Your catalogue and B2B price lists, never the document |
| Native Shopify draft order | A real order at checkout, plus self serve reordering | Varies | Yes, with the source file attached |
| Ongoing maintenance | Catalogue upkeep plus buyer onboarding | Vendor managed, plus your data load | Vendor managed, catalogue stays in sync |
| Who it fails for | Anyone who will not log in | Anyone who will not log in | Nobody sending documents, useless if none arrive |
| Best fit | Accounts that will self serve | Self serve accounts without native B2B | Accounts that keep emailing purchase orders |
It produces the cleanest possible order. A buyer selecting products from your catalogue at your price list means no extraction step, no matching step and no review step, and nothing to get wrong because nothing was interpreted. Every other approach on this page, ours included, tries to recover that quality after the fact, and a recovered order is never better than one that was right at source.
It has no per order cost. Once companies, catalogues and price lists are configured, an account can place a thousand orders and the marginal cost is zero. Document intake, ours or anyone's, is priced per order because reading a document is work. Volume you move onto a portal becomes free to process, which beats automating it.
It is a better experience for the buyer who wants it: live stock, their own pricing, order history, reorder in a few clicks. It removes a class of dispute, because a buyer who picks the product and sees the price cannot argue later about which SKU was meant. And an order that starts in Shopify with the right company, location and price list reaches your ERP and your reporting with fewer corrections.
So if you can move most of your volume into a portal, do that and buy nothing else until you have tried. If your buyers are enthusiastic about self service, we are the wrong purchase.
Not flaws in the portal. Just the orders it never receives, and what happens to them in a business that has decided the portal is the plan.
The PDF from the account that will not log in still arrives, still has to become a Shopify order, and is still typed by a person. A portal project does not reduce that work, it shrinks the account list it applies to.
Portal orders absorb a peak without help. Emailed ones do not, and peak days are when the order desk is least able to absorb an extra hour of typing and most likely to make an expensive mistake. Spreadsheets with merged cells, scanned forms and photographed order lists all land in the same queue.
Your largest customer is the one you are least willing to give an ultimatum to. The exception you granted becomes permanent, and permanent exceptions are how manual order entry survives a successful portal launch.
Once the portal is live, emailed orders are an exception rather than a process, so nobody counts them. The typing continues and stops appearing in any plan.
Same order, same account, same prices. The buyer changed nothing.
You get a unique forwarding address at install, and a forwarding rule sends a copy of the purchase order through. Nothing changes on the customer's side, which is the only reason this reaches the accounts a portal cannot.
Exact SKU lookup first. Where there is no SKU, or the SKU is theirs rather than yours, matching works from the description, the pack configuration and the unit, and a reviewer's correction is remembered for that account.
The draft is created against the Shopify B2B company where one exists, so the catalogue, price list, quantity rules and payment terms assigned to that account apply automatically. If the buyer's PDF carries an optimistic price, your price list still decides.
The result is an ordinary Shopify draft order with the source file attached. Your team sees the original beside the matched lines, fixes anything flagged, and approves. Once approved it joins the portal orders, and nothing downstream needs to know which door it came through.
Sequence it portal first. Turn on Shopify B2B, configure companies, locations, catalogues and price lists properly, and invite the accounts most likely to adopt. Then count the purchase orders still arriving by email after the push rather than before it, because that residue is what you are solving for and it is usually larger than the plan assumed.
Put intake behind the portal for that residue. Both read the same catalogue and the same price lists, so an account that adopts the portal later simply stops sending documents and nothing has to be unwound.
The arithmetic is straightforward once you have the residue count. At 100 emailed orders a month, Growth is $250, so roughly $2.50 an order against about 6 minutes of someone's time each, which is about 10 hours a month back. At a 3% manual error rate those 100 orders carry about three bad ones, and at about $250 to unwind each that is a real number sitting in your month.
Forcing the portal is where this goes wrong, and the failure is commercial rather than technical. A buyer who cannot order the way they want does not usually complain. They order less often, or they consolidate onto a supplier who accepts an email. You will see it as softening volume on a long standing account, not as a portal problem. So make the portal the best option and never the only option.
A large share of wholesale volume never comes from a buyer at all. It comes from your own reps, at a trade show, on a store visit or on a call, and both options on this page serve it. If your reps will use the portal, give them a login and let them order on the account's behalf: they see live stock, the account's pricing applies, and the order exists the moment they submit.
In practice many reps do not order that way. They write on a paper form because the venue has no signal, they collect a booth sheet, or the customer hands them a list. That document has the same fate as an emailed purchase order, typed in later from handwriting by somebody at the office. Forwarding it produces the same matched, priced draft order.
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.
After using LevelOps for three months, the percentage of email PDF orders requiring manual entry has dropped to under 10%, down from 60% prior to adopting the tool.
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.
Each comparison page says where the alternative genuinely wins. If one fits your account mix better than we do, that is the useful answer.
EDI covers the retailers who mandate it, not the accounts in between.
Parsers need a template per sender. One real purchase order through both.
Keep SPS for mandated retailers, automate what it never touches.
OrderEase is a portal and an EDI bridge. Where each one wins.
An OMS manages orders after they exist. Intake gets them in.
Minutes per order and the salary hiding in your inbox, costed out.
Companies, catalogues, price lists and terms, plus the orders that skip your portal.
The product itself, from extraction to the draft order.
What the residue costs to automate, worked through by volume.
The accounts whose ERP already emitted the PO. Why they will not log in.
Wholesale on a plan that is not Plus, and what you still need a person for.
Count the purchase orders still arriving by email after your portal push. That number is what document intake is for, and your own worst formatted orders will settle it faster than a comparison table.
Your first 5 successful orders are free with no expiry. If your buyers will use your portal, we will tell you to build the portal instead.
FAQ
If you sell wholesale on Shopify and have access to the native B2B features, yes. Companies, locations, catalogues, price lists and payment terms replace a pile of spreadsheets and manual discounting, and nothing on this page argues against running a portal.
Some will, some will not, and the split is predictable. Newer, smaller and digitally comfortable accounts adopt quickly, especially those with no procurement system of their own. Accounts whose purchase orders are generated by an ERP almost never adopt.
We will not give you a number, because we cannot trace one, and any vendor quoting a universal adoption rate is guessing. Measure your own: count the accounts emailing a purchase order today, then ask your ten largest whether they would key that order into a portal themselves.
You can, and it is a real commercial risk. A buyer who cannot order the way they want orders less often, orders smaller, or orders from a competitor who accepts an email. Mandating works when the account needs you more than you need them, which is rarely true of your largest customers.
Those are the accounts a portal will not reach. The PO is assembled, numbered and approved inside their system, then emailed to you because that is the output it produces, so PDF to Order reads it rather than asking the buyer to key it twice.
Yes. Where the account exists as a Shopify B2B company, the draft order is created against that company and priced from the catalogue and price list assigned to it. The buyer's document never sets the price.
The native B2B features, companies, catalogues and price lists, are available on Shopify Plus. PDF to Order works on any Shopify plan that supports draft orders, and uses B2B companies and price lists automatically when present.
The portal costs whatever your Shopify plan costs, with no per order fee. PDF to Order is free for your first 5 successful orders 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.
