Comparison
A parser extracts text. An order intake product produces a matched and priced Shopify draft order. Extraction is roughly half the job in wholesale, and it is the easier half.
An email parser extracts data. An order intake product produces an order. That sounds like a small distinction and it is the entire comparison.
Run a wholesale purchase order through Mailparser, Docparser, Rossum or AWS Textract and you get back fields and text, often with a confidence score. Line one reads "Lg Blue Widget, 24, CS". That is a correct extraction and it is not an order. Nothing yet knows which of your accounts sent it, which Shopify variant that description means, whether 24 is eaches or cases, what that account pays under their B2B price list, or how any of it reaches Shopify.
Most of these tools are also template based, so a rule built against one sender's sample holds until that sender adds a column or switches ERP, and then it keeps working silently on the wrong column. Several situations below should send you to a parser rather than to us. But if your purchase orders arrive in forty layouts, the question is not who extracts text best. It is who hands you a matched, priced draft order.
Described accurately, because these tools do their job well. The mechanics, from the moment an email lands to the moment data leaves.
A dedicated address you forward to, or a shared inbox that auto forwards. Scans go through OCR, digital PDFs already carry a text layer, and character accuracy is rarely the failure point.
You upload a sample and box the PO number, the ship to block and the line item table. The tool records the position or the anchor text, and later documents from that sender are read against that map.
The better tools detect column boundaries and repeat a row rule down the page, which is hard and genuinely well done. Merged cells and mid table subtotals are where they need help.
Some add a confidence score and a validation screen, but that review is on the document, not on the resulting order. Everything after the output is code your side writes and keeps running.
Named honestly, with the reader each one is right for. If your situation fits one of these better than it fits ours, buy that one.
Rule and template based. Highlight what you want on a sample and the tool builds a rule from position and surrounding text. Right for one or two stable layouts that carry your SKUs, wrong if every customer formats differently.
The point and click middle ground, with visual templates, good table handling and OCR on scans. Right for a handful of layouts and no engineering team, wrong if you expected a finished order.
A serious platform for transactional documents, strongest on invoices. It reads without a per layout template, and a reviewer's corrections on the validation screen train the model. Wrong if you want a Shopify draft order without an integration project.
Model based extraction you train on your own samples, with pre-trained models for common document types and a clean API. Right if you have engineers and a consistent, unusual document type.
The incumbent intelligent document processing suites, and the most configurable products here. Classification, validation stations, on premise or cloud. Right for many document classes at scale, heavy for a small team.
Raw cloud APIs, and excellent ones. Textract returns text, key value pairs and tables, and Document AI adds procurement processors for invoices and purchase orders. Right if you want a component, wrong if you wanted a product.
Send the document to a multimodal model with a JSON schema and get structured output back. Right if you have engineers who will still be here in two years, wrong if nobody owns it the week a sender changes format.
Order intake for wholesalers on Shopify. Reads any layout with no template, resolves the account, matches every line including loose descriptions and buyer part numbers, and writes a priced native draft order.
Zonal and template based extraction works by memorising where things are. You show it one document, draw the boxes, and it applies that map to everything from the same sender. On a stable layout that is fast, cheap and accurate, and it is why the category exists.
The problem in wholesale is that a purchase order layout is not a contract. It is whatever fell out of the buyer's system this month. Procurement adds a lot number column between description and quantity, so your quantity rule now reads lot numbers. They switch ERP and every field on the cover sheet moves. A second page of terms makes the anchor your rule keyed on appear twice. Someone merges two cells to fit a long description and the row rule reads a blank.
What makes this expensive is the silence. A template rarely throws an error when the layout moves, it returns a confident value from the wrong place. Twelve becomes one hundred and twenty because the rule picked up the pack size column, and nobody finds out at extraction time. They find out at the loading dock, and at roughly $250 to unwind one erroneous order, a template that drifts quietly costs more than one that fails loudly.
Every sender layout is also a template to build, test and own, and the count grows when you win a customer rather than when you win an order. Intelligent document processing answers exactly this. Rossum, Nanonets, ABBYY and Kofax read without a per layout template and let a reviewer correct the model rather than rebuild a rule. That fixes the document layer, and a purchase order is not finished when the document has been read correctly.
Three columns for the alternative, because the category is not one thing.
| Rule and template parsers | Intelligent document processing | Raw OCR APIs | LevelOps | |
|---|---|---|---|---|
| Setup time | Hours per sender layout | Weeks to months, often partner led | Developer days before document one | Under an hour, plus a 2 to 5 minute catalogue sync |
| Cost shape | Monthly tier by document volume | Platform fee plus an implementation | Per page, plus what you build on top | First 5 orders free, then $50 one time or $100 to $250 a month |
| Reads a layout it has never seen | No | Yes, that is the reason to buy one | Text and tables yes, meaning no | Yes |
| Customer has to change anything | Sometimes, if you impose a fixed layout | No | No | No |
| Human review before an order exists | Not included | Yes, on the document | Not included | Yes, a draft order awaiting approval |
| Matches lines to Shopify variants | No | Only against a lookup table you build | No | Exact SKU, then semantic, then learned codes |
| Handles a loose description with no SKU | No | Depends on your lookup data | No | Yes |
| Where the price comes from | Whatever is printed on the document | Whatever you map it to | No price concept at all | Your catalogue and B2B price lists |
| Creates a native Shopify draft order | No | Through an integration you build | No | Yes, with the source file attached |
| Ongoing maintenance | A template per layout, forever | Vendor managed, plus your integration | You own the entire pipeline | Vendor managed, updates ship to you |
| Who it fails for | Many senders with moving layouts | Small teams with no integration budget | Anyone who wanted a product, not an API | Orders that already arrive structured |
| Best fit | One stable layout, or non order documents | High volume across document classes | Engineers building their own system | Emailed purchase orders that become Shopify orders |
This is the important section and it is not a courtesy. Several readers should close this page and buy one of the tools above.
One stable layout across most senders. If most of your documents come out of one buying group's system, one distributor portal, or an order form you publish, a template based parser is the right answer. Cheaper than us, accurate, and the maintenance argument does not apply because there is one template.
Documents that are not purchase orders. Supplier invoices into accounts payable, shipping confirmations, advance ship notices, remittances, packing lists, certificates of analysis, customs paperwork. PDF to Order does none of that, and Rossum, ABBYY and Kofax cover document classes we have never looked at.
Very high page volume of a single form type. Thousands of identical inspection reports or lab results a month is what per page pricing was designed for, and a model trained on one consistent form gets very good. Pricing per order is the wrong unit for that workload.
Engineers who want a component, not a product. If you are building your own ordering system and want extraction as a library call inside it, Textract and Document AI are the right shape and we are the wrong shape.
Use cases outside order intake entirely. Routing lead notifications into a CRM, pulling tracking numbers out of carrier emails, triaging support mail. That is parser territory and always will be.
Shopify is not where your orders live. Everything valuable here ends in a Shopify draft order, so if your system of record is an ERP that output is worth nothing to you. Same answer if you already run Rossum or ABBYY with a competent team, because a second vendor for one document type rarely repays the coordination.
The output is fields and text, sometimes with a confidence score. Everything below sits between that and an order somebody can fulfil, and all of it is yours to build, run and fix.
Turning a letterhead and a sender domain into the right Shopify company, contact and ship to location, which gets harder with buying groups and shared procurement inboxes.
You get the string the buyer typed. Which of your variants it refers to is the actual work, and no extraction tool does it, because it needs your catalogue rather than the document.
Prices printed on a customer purchase order are often stale, sometimes absent and occasionally aspirational. Taking the number off the document is the most expensive habit in order entry.
The right variants, the company attached, the price list applied, the file attached, plus rate limits and idempotency so a replayed webhook does not create the order twice.
Confidence on a field says the text was read correctly, not that the match, the unit or the account was right. A reviewer's correction should become a per buyer alias.
Reading a purchase order is close to solved, and an engineer with a modern model can get usable extraction working in an afternoon. What nobody hands you is the decision about which of your thousands of variants a customer meant. Matching runs in three layers and the order matters.
Exact lookup first. If the line carries your SKU, a barcode or a variant identifier, look it up in the synced catalogue and that line is finished. It is the only layer a parser plus a spreadsheet can realistically cover, which is why parser based pipelines work fine until a customer stops using your codes.
Semantic matching on the description second, and this is where wholesale orders are won or lost. When the line says nothing more than "Lg Blue Widget", the match comes from your product titles, variant options, tags and descriptions, weighed against the pack size on the line, the unit beside the quantity, the other products on the same document and what that customer has bought before. A line reading "IPA 6-Pack Case of 24" has to resolve to the case variant rather than the single, and getting it wrong ships the wrong quantity at the wrong price.
Learned per buyer aliases third. Large buyers use their own item master, and their code for your product appears on every order they send. The first time a person confirms that code means your variant, the pairing is remembered against that sender, which is why review load falls over the first few weeks instead of staying flat.
A parser cannot do any of this, because it has never seen your catalogue. Intelligent document processing covers part of the first layer if you feed it a lookup dataset, and asking it for the second and third means maintaining a cross reference table per customer, which is the master data project the tool was meant to spare you.
A parser quoted in cents per page against an order product quoted per order looks like an easy decision until you price the same finished outcome on both sides. The parser price covers extraction. It does not cover inbox and attachment handling, retries when a document fails, customer resolution, catalogue matching, the price list lookup, Shopify Admin API work with its rate limits and idempotency, an exception queue, a review interface, or the alerting that tells you a sender's format has drifted. Price that at your loaded developer rate, then price it again for the second year, and then work out whose calendar the templates land in.
The other side of the ledger, using only numbers we can trace. Processing goes from about six minutes an order to about one, so a hundred document orders a month is roughly ten hours of typing reduced to under two. The measured error rate is 0.5% against 3% for manual entry, six times fewer, with a human still signing off. At about $250 to unwind one erroneous order, three percent of a hundred orders is around $750 a month spent unwinding them, and half a percent is closer to one wrong order every two months.
Set that against the price. Your first 5 successful orders are free with no expiry, then 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 annual billing saving 20 percent. Above 100 orders a month we quote. If the arithmetic favours the parser at your volume, the parser wins.
Four steps. The first is what a parser does. The other three are what make it an order.
Your customer emails the purchase order they always send. PDF, Word, Excel, CSV, HTML, email body text, scans and photographs all count. The layout is read rather than looked up against known coordinates, so there is nothing to configure first and nothing to rebuild when a sender changes.
The sending domain, the letterhead and the ship to address resolve the order to a Shopify company, contact and location. If the account does not exist yet, the draft order is still created and flagged as new.
Exact SKU lookup, then semantic matching from the description, the buyer's part number and the rest of the order, then any learned alias. Prices come from your catalogue and that company's B2B price list, never from the buyer's document.
A native Shopify draft order appears with the source file attached and anything uncertain flagged. The reviewer fixes what needs fixing and sends it, and that correction is remembered next time.
The common end state is not one tool. If you already run Mailparser, Parseur, Rossum or something built in house, keep it for the documents that are not purchase orders, because replacing a working invoice pipeline to solve an order problem is a bad trade.
To move the order documents across, run parallel first. Leave the parser running and add a forwarding rule that copies the same inbound orders to your LevelOps address for a week, so you compare on the customer who merges cells and the one who sends photographs rather than on tidy samples.
Then compare line by line rather than field by field. Did the right account come out. Did every line land on the right variant, including the ones with no SKU. Did the price come from your price list rather than the buyer's document. When you are satisfied, turn off the order templates last and leave the parser's other rules alone. Your customers never notice, because they were emailing the same document to the same address throughout.
We have used macros, but they are too rigid. Every change in invoice format requires costly internal maintenance in time and expertise. To grow without those technical constraints, LevelOps is the only viable option.
We considered multiple options before choosing LevelOps, including developing our own software and reviewing other existing tools. We chose LevelOps because their demo clearly showed they had already done the hard work of reading and transmitting data from disparate files into Shopify.
Draft orders get entered by magic. Even when the PO contains a vague description and no SKU, this app can still match it. The AI is that good.
Each page says where the alternative genuinely wins. If one of them describes your situation better than this one, that is the useful answer.
EDI covers mandated retailers. It never reads the emailed orders from everyone else.
Your biggest accounts will not log in. How to serve both without forcing anyone.
Keep SPS for mandated retailers, automate the emailed orders 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.
Read, resolve, match, price, approve.
What an order costs here, beside what it costs by hand.
Not tidy samples. The customer who merges cells, the one who sends photographs, the one whose ERP changed last quarter. Run them through your parser shortlist and through this, and judge what comes out of the far end.
Your first 5 successful orders are free with no expiry, a human approves every order before it goes anywhere, and if a parser fits your document mix better we will say so.
FAQ
A parser hands back fields and text. PDF to Order also resolves which account sent it, matches every line to a real Shopify variant, prices it from your B2B price lists, and writes a native draft order for a person to approve.
With rule based tools like Zapier Email Parser, Mailparser or Docparser, effectively yes, one per sender layout. PDF to Order reads the layout instead of memorising coordinates, so there is nothing to build and nothing to rebuild when a sender changes.
They can push extracted fields into Shopify through a Zap or a webhook, which works when every line carries an exact SKU and you accept the default price. They do not decide which variant a loose description means, or apply a B2B price list.
For high volume capture across many document classes, especially supplier invoices, they are strong platforms and we do not compete with them. What they do not give a Shopify wholesaler is catalogue matching, price list pricing and a native draft order.
The subscription usually is, the finished system usually is not. Per page pricing covers extraction only, so you still pay to build the matching, pricing, error handling and Shopify writing on top, then to maintain it.
Modern models extract purchase order fields well, and Textract and Document AI are excellent building blocks, so it is a real option with engineers. Extraction works on day one. The long tail of layouts, catalogue matching and Shopify API work is what runs for a year.
Not on its own, because it has never seen your catalogue. Intelligent document processing can match against a lookup table you build and maintain, which is the master data project most teams were trying to avoid.
A template based parser usually keeps running and returns a confident value from the wrong column, so you find out at the loading dock. PDF to Order reads the new layout the way it read the old one, and flags anything uncertain for review.
If your senders all use one stable layout, if your documents are not purchase orders, if you want extraction as a component inside your own system, or if Shopify is not where your orders live.
