Integration
NetSuite manages the order once it exists. LevelOps PDF to Order creates it. Emailed PDF, Excel and CSV purchase orders become validated Shopify draft orders, approved by a person, then carried into NetSuite by the Shopify to NetSuite sync you already run.
Oracle NetSuite is a full cloud ERP. Once a sales order exists, NetSuite owns it end to end: allocation, item fulfillment records, invoicing, revenue recognition, subsidiaries and currencies under OneWorld, and the saved searches your team lives in. Nobody who has run a NetSuite implementation doubts that part.
Shopify sits in front of it, usually for DTC and increasingly for B2B with company accounts and price lists, and a connector moves orders and inventory between the two. The order gets created in Shopify, the sync creates the NetSuite sales order, and NetSuite takes over. That flow is solid for anything a customer places themselves.
The gap is everything a customer does not place themselves. A wholesale buyer emails a PDF purchase order, or a spreadsheet export from their own system, and no part of that chain reads it. Somebody on your team opens the attachment and types it, line by line, into Shopify or straight into NetSuite. That work sits outside every NetSuite project plan, and it is what LevelOps PDF to Order removes.
These are the specific complaints we hear from order desks in NetSuite shops, not generic data entry pain.
Some reps key the PO into Shopify so the order follows the normal sync. Others key it straight into NetSuite because that is where they work. You end up with two intake habits, two error profiles and no single place to audit what arrived.
NetSuite holds tens of thousands of item records. Shopify holds the published subset. A buyer orders something that exists in NetSuite but was never published, and the rep discovers it halfway through typing the order.
Large accounts order using their own part numbers. Keeping those aliases current in NetSuite is a data project that never gets funded, so the rep translates them from memory or from a spreadsheet on the shared drive.
A mature NetSuite implementation is governed. Adding an intake workflow means SuiteScript, testing, a release window and a queue. Meanwhile the POs keep arriving as attachments.
A mistyped quantity passes validation, syncs cleanly, allocates stock and prints on a pick ticket. You find out when the customer calls, and by then you are issuing a credit and reworking a shipment.
End of month and promotional weeks triple the inbound POs. NetSuite scales fine. The two people who read attachments do not, so lead times stretch precisely when accounts are watching.
Nothing changes downstream. The order simply arrives in Shopify already correct, instead of arriving in an inbox as a document.
Your buyers keep emailing exactly what they email today. Forward it to your dedicated LevelOps address, or drop the file in from the Shopify admin.
Line items, quantities, units, requested dates and the customer PO number are extracted, then each line is matched to your Shopify catalogue on SKU, part number or description.
The result is a normal Shopify draft order with the source document attached. Your rep checks the flagged lines, fixes anything wrong, and approves. Nothing is created without that click.
Once approved, it is an ordinary Shopify order. Celigo, NetSuite Connector, Patchworks or your own RESTlet picks it up and creates the NetSuite sales order on the mapping you already trust.
This is the honest shape of the integration. LevelOps writes to Shopify natively. NetSuite receives the order the same way it receives every other Shopify order, which is why there is nothing to build on the ERP side.
Two systems, one clear division of labour. Here is the field level picture.
Everything LevelOps reads off the purchase order before anything is created.
The draft order your team reviews, built from your own Shopify data rather than from the document.
Whatever your connector already maps, unchanged. These orders are not a special case.
The boundary matters as much as the capability.
In almost every NetSuite shop, NetSuite is the item master and Shopify is a downstream publication of it. That is the right architecture, and PDF to Order is built to respect it. Matching runs against the Shopify catalogue, so it always resolves to something that can actually be ordered, priced and synced.
That has one practical consequence worth naming before you buy. If a buyer regularly orders items that live in NetSuite but were never published to Shopify, those lines will be flagged for a human instead of matched. That is the correct behaviour, and it usually surfaces a catalogue coverage gap your team already suspected. Publishing the missing items, or agreeing they are genuinely off catalogue, is a short piece of work we cover in the audit.
Customer specific part numbers are handled at the matching layer, which is where they belong. NetSuite item aliases help when they are maintained, but the AI does not depend on them. It matches loose descriptions, abbreviations and the buyer's own codes against your catalogue, and it improves as your team corrects it. Matrix subitems resolve to the matching Shopify variant, and a PO that names a parent item without enough detail to choose a variant is flagged rather than defaulted, because a defaulted size is a return waiting to happen.
You can start on the app alone. Most NetSuite merchants want the sync and the catalogue coverage looked at properly at the same time, which is what our implementation team does.
We look at a real sample of inbound purchase orders, the accounts they come from, the formats they arrive in, and how each one is handled today. That produces a coverage estimate rather than a promise.
We check SKU parity between the NetSuite item master and the Shopify catalogue, confirm your company accounts and price lists are set up for the accounts that matter, and list the gaps in priority order.
Start with your highest volume, messiest senders. Your team reviews every draft, corrections feed the matching, and you measure the time difference against your own baseline instead of ours.
If the Shopify to NetSuite sync needs mapping work, or if you want intake, catalogue and fulfilment reviewed as one system, that is an ERP implementation engagement. See the ERP and MRP implementation page for how those run.
Turnkey, fixed fee scope with defined milestones, delivered by a Montreal based bilingual team. Full detail on the ERP and MRP implementation page at /en/erp-implementation.
The question is never NetSuite versus something else. It is what handles the documents that arrive before NetSuite ever sees an order.
| Manual entry | Connector alone | EDI programme | LevelOps PDF to Order | |
|---|---|---|---|---|
| Reads a PDF or Excel purchase order | A person does | No | No | Yes |
| Works without the buyer changing anything | Yes | No order to sync | Buyer must onboard | Yes |
| Matches loose descriptions and buyer part numbers | From memory | No | Mapped per partner | Yes |
| Human approval before the order exists | Yes | Not applicable | Usually automatic | Yes |
| Time to first live order | Immediate, forever | Already running | Months per partner | Days |
| Cost of adding one more account | More headcount | Not applicable | New partner setup | None |
| Where the order is created | Shopify or NetSuite by hand | Shopify checkout only | Straight to the ERP | Shopify draft, then your sync |
| Needs NetSuite customisation | No | No | Usually | No |
Rated 5.0 on the Shopify App Store. These are operators running the same Shopify first pattern.
It is literally reading my PDF and uploading a 100+ item order in under 4 minutes. This just made us 10x more efficient.
About 60% of our orders come to us as PDFs and other file types attached to emails. After using LevelOps for three months, the percentage requiring manual entry has dropped to under 10%.
Companies are looking for the magic AI wand. For me, LevelOps is the first easy step into AI, relevant, and you see the impact the day you install it.
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.
Not with a native NetSuite connector, and we will not pretend otherwise. LevelOps PDF to Order writes validated draft orders into Shopify. Those orders reach NetSuite through your existing Shopify to NetSuite sync, such as Celigo integrator.io, NetSuite Connector, Patchworks or a SuiteScript RESTlet your team maintains. If you have no Shopify step at all, this is not the right fit yet.
Celigo integrator.io and NetSuite Connector cover most of the merchants we talk to, with Patchworks and custom RESTlet builds behind them. PDF to Order does not care which one you use. It creates a normal Shopify order, so whatever flow already turns Shopify orders into NetSuite sales orders handles these too, with no new mapping.
Matching runs against your Shopify catalogue, which in most NetSuite shops is the published subset of the NetSuite item master. Lines match on SKU, on manufacturer part number and on loose description, including when the buyer uses their own part numbers. Anything that exists in NetSuite but was never published to Shopify gets flagged for a person rather than guessed.
NetSuite matrix subitems normally map one to one to Shopify variants, so a matched line resolves to the exact variant and carries through the sync unchanged. When a PO names a parent item without enough detail to pick the size or colour, the line is flagged for review instead of resolved to a default.
Yes, as long as your sync maps it. The customer PO number is extracted from the document and written to the Shopify order, where connectors normally map it to the customer PO field on the NetSuite sales order. The source file stays attached to the draft, so anyone auditing an order later can open the original document.
No. Fulfilment, invoicing, revenue recognition and the whole document flow stay in NetSuite where they belong. LevelOps only removes the typing at the front of the process, and everything downstream keeps running exactly as your implementation configured it.
No, because nothing new appears in NetSuite. Orders arrive through the same channel your Shopify orders already use, so saved searches, dashboards and role based reporting keep working. If you want to isolate these orders in reporting, the sync can tag them from a Shopify order attribute.
It matters at the sync layer, not at the intake layer. If your connector already routes Shopify orders to the right subsidiary, currency and location, these orders follow the same rules. If routing depends on something written on the purchase order, tell us during the audit and we confirm the field is captured before you commit.
That is exactly why the Shopify first pattern is useful. PDF to Order sits in front of NetSuite and needs no SuiteScript, no workflow change and no new role. You test it on real purchase orders in days, not in the next release window.
Every store gets your first 5 orders free, with no expiry. Send us three real POs, ideally your messiest ones, and we run them live so you judge the extraction and the matching on your own catalogue before you commit.
How a LevelOps engagement runs, from intake audit to go live and hypercare.
Read, match, price, approve, in detail.
The app itself, its limits, and what setup looks like.
Where EDI still wins, and where emailed POs are cheaper to automate.
Why the Shopify draft order is the right object to create first.
The same pattern for merchants on the Microsoft stack.
Send three real POs from your hardest accounts. We run them live against a copy of your catalogue and show you the draft orders, the matched lines and the flagged ones, before you decide anything.
your first 5 orders free, free allowance of 5 orders, bilingual support in English and French.
