ERP Records the PO. Who Tracks Supplier Execution?

An ERP can record a purchase order and still leave the purchasing team doing the real work in email, supplier websites, spreadsheets, tracking pages, receiving notes, and accounting cleanup.

That is the gap this guide explains.

The short version: ERP should remain the system of record for finance, inventory value, COGS, vendor bills, purchase accruals, GL postings, and audit history. A procurement execution layer should run the supplier-side workflow that happens before those records are clean enough for finance.

Quick answer: ERP records the PO. Supplier execution changes the PO.

ERP is the financial and operational record. It stores purchase orders, vendor records, inventory value, bills, receipts, accounting codes, and reporting history.

But the supplier workflow keeps changing after the PO exists:

the supplier confirms fewer units
a website price differs from the expected cost
two SKUs are substituted
one shipment is split into three tracking numbers
the warehouse receives only part of the order
the invoice includes freight, fees, or credits
the buyer has to know what still needs follow-up

That is supplier execution. It is not just PO creation. It is the living workflow between demand, supplier reply, receiving, and the final bill.

The modern stack

A mature inventory business often has several systems that are each correct in their own lane:

Shopify / POS      = demand record
WMS / 3PL          = movement record
ERP / QBO / Xero   = financial record
Supplier channels  = operational reality
LineNow            = supplier execution layer

The job is not to make one system own every detail. The job is to make sure the operational reality reaches the right record before finance has to close the books.

That is why a company can use NetSuite and still have a procurement problem. NetSuite may record the PO and calculate COGS, while the team still has to chase confirmations, track website orders, watch price changes, receive partial shipments, and reconcile the invoice.

Why systems of record do not disappear

In May 2026, a16z published "From System of Record to System of Intelligence", arguing that systems of record remain sticky, but value moves upward into the orchestration layer that reads many systems, reasons across them, and takes action.

That is the right architecture for inventory purchasing too.

The ERP does not need to disappear. QuickBooks does not need to disappear. Shopify does not need to become procurement software. The valuable workflow is the layer that reads demand, inventory, supplier communication, receiving, and accounting context, then tells the team what to buy, what changed, and what needs action.

For supplier operations, that layer is not a dashboard. It is an execution system.

What escapes the ERP

The work that escapes the ERP is usually the work that happens in the world, not in the ledger.

Supplier-side reality	Why ERP often becomes stale
Supplier confirms different quantities	Original PO remains unchanged until someone edits it
Supplier portal price differs from planned cost	Buyer has to notice line-by-line
Supplier substitutes SKUs	Substitution may live in email, not the PO
Tracking numbers arrive in several emails	Status sits outside the order record
Shipment is partial	Receiving and invoice quantities diverge
Invoice includes freight or credits	Accounting sees a mismatch without the story
Buyer needs follow-up list	ERP status may still say sent or pending

The issue is not that ERP is bad. The issue is that ERP is optimized for structured records. Supplier execution is messy, frequent, and external-facing.

Why NetSuite alone is not the buying workflow

NetSuite can be the right system of record for a growing inventory business. It can hold the PO, inventory value, COGS, vendor bills, accounting workflows, and reporting logic.

But using NetSuite does not automatically answer:

Which supplier confirmations are missing?
Which supplier website orders have not sent a confirmation?
Which line prices changed since the PO was drafted?
Which shipments are partial?
Which tracking numbers belong to which PO lines?
Which receipts should update the payable?
Which supplier needs follow-up today?
Which operational changes should be reviewed before the bill posts?

Those are supplier execution questions. If they are handled in inboxes and spreadsheets, the ERP record is downstream of manual work.

The Isabella pattern

A common ecommerce version looks like this:

A planning model or spreadsheet creates recommended order quantities.
A CSV is uploaded to NetSuite so finance has a PO record.
Some suppliers receive emailed POs.
Other suppliers require website or portal ordering.
Confirmation emails arrive separately.
Prices, tracking numbers, and partial shipments have to be tracked manually.
Receiving and accounting reconcile what actually happened.

That workflow can be sophisticated and still fragile. The forecast may be fine. The ERP may be fine. The pain is the supplier-side execution layer between them.

Where LineNow fits

LineNow is the supplier execution layer for inventory purchasing. It is built around the living purchase order: a PO that keeps state as suppliers reply, prices change, shipments split, goods are received, and the final accounting handoff is prepared.

LineNow is strongest when the buyer needs to:

turn inventory or sales signals into supplier-grouped POs
send POs through email, WhatsApp, EDI, or portal workflows
keep supplier website orders connected to an internal planned PO
parse confirmations, tracking numbers, substitutions, ETAs, invoices, and price changes
review exceptions before they hit receiving or AP
receive against the supplier-confirmed state
stage cleaner bill context for accounting

That is different from replacing ERP. The cleaner claim is: LineNow makes the supplier-side purchase truth current before the ERP or accounting system has to rely on it.

What the handoff should look like

The right operating model is upstream reconciliation:

Buyer creates or reviews the planned PO.
Supplier confirms or changes the order.
LineNow updates the living PO with reviewable supplier-side changes.
Receiver records what actually arrived against the current PO state.
Supplier invoice is checked against the confirmed and received state.
Finance receives a cleaner payable, with the story attached.

AP should pay and govern. It should not have to reconstruct the order from email threads, tracking pages, receiving notes, and stale PO snapshots.

When ERP-native procurement is enough

ERP-native procurement may be enough when:

suppliers accept a standard PO process
order changes are rare
receiving is simple
line counts are low
finance and operations work in the same system every day
the business has internal ERP admins who keep workflows clean

In that case, adding another tool may create unnecessary complexity.

When a supplier execution layer becomes worth it

A dedicated supplier execution layer becomes worth evaluating when two or more of these are true:

you buy from 10, 20, 40, or more active suppliers
weekly PO runs involve hundreds of SKUs
some suppliers require website or portal orders
supplier confirmations arrive by email or PDF
tracking numbers arrive outside the ERP
partial shipments are common
cost changes are hard to spot
receiving teams and finance teams disagree about what happened
your ERP record is correct only after someone manually cleans it

That is the point where the company does not need a prettier PO. It needs supplier execution.

The identity shift

The old question was: "Can ERP do procurement?"

Of course it can.

The better question is: "Where does the actual purchasing work happen?"

If the answer is still spreadsheets, supplier portals, email, and manual follow-up, then the valuable workflow has escaped the system of record.

LineNow's role is to own that escaped workflow: what to buy, what changed, what arrived, what still needs follow-up, and what accounting should see next.

That is closed-loop procurement.

Sources Checked

a16z: From System of Record to System of Intelligence