Before You Buy an ERP: A Small Retailer's Supplier and Purchase-Order Control Map

A small shop can outgrow a purchasing spreadsheet without needing an ERP.

That distinction matters.

Imagine a retailer ordering 40 units across 12 products from a supplier.

The supplier confirms 38 units, changes the price of two lines and moves one item to next week. The delivery arrives with 35 correct units, one damaged unit and two substitutions. The invoice still bills the original 40.

If the business keeps only one number called "quantity", someone has to decide which truth that number represents:

• what the retailer requested
• what the supplier confirmed
• what physically arrived
• what passed inspection
• what became available to sell
• what the supplier invoiced

Overwriting one number with the next does not simplify the process. It removes the evidence needed to understand the difference.

The first question is therefore not:

"Which ERP should we buy?"

It is:

"Which records and decisions must survive from supplier order to trusted stock?"

Once that control map is clear, the retailer can choose the lightest system capable of preserving it.

The real problem is not a missing ERP

A small retailer may begin with email, a spreadsheet and a bookkeeper.

That can work.

The owner may know every supplier. One person places orders. Deliveries arrive at one location. Discrepancies are rare. The same person checks the invoice and updates stock.

The problem begins when operational complexity grows faster than the control around it.

Common warning signs include:

• staff create purchase orders from different spreadsheet copies
• supplier changes stay buried in email threads
• nobody knows whether a line is ordered, confirmed, delayed or cancelled
• partial receipts are marked as complete
• damaged units become available stock
• a changed supplier price reaches the invoice but not the product cost record
• the bookkeeper sees an invoice but cannot find the original order or receipt
• stock is typed into the inventory system a second time
• one location receives goods intended for another
• the owner reconciles everything from memory at the end of the week

These are control problems before they are software problems.

A bigger platform can help only after the business defines what the platform is expected to control.

Build the purchase-to-stock control map

The map needs several connected records. They should refer to one another, but they should not be collapsed into one editable total.

1. Supplier record

The supplier record identifies who the business is buying from and the commercial context of that relationship.

Useful fields include:

• supplier name and contact
• account or supplier reference
• normal lead time
• payment terms
• delivery locations
• currency and tax treatment
• minimum order or case quantity
• returns and damaged-goods process
• agreed product references

The goal is not to collect every possible field. It is to stop important terms living only in one employee's inbox.

2. Purchase request and approval

Not every small shop needs a formal requisition workflow.

It still needs a clear answer to:

• who can decide to buy
• what spending limit applies
• which stock or sales information supports the decision
• whether an owner or manager must approve the order

Without clear authority, the business can create duplicate orders, buy outside agreed terms or discover commitments only when invoices arrive.

3. Purchase order

The purchase order records the retailer's commitment at the time the order is placed.

At minimum, preserve:

• unique PO number
• supplier
• order date
• product or SKU
• ordered quantity
• agreed unit cost
• tax, freight or other charges
• payment terms
• expected date
• destination location
• approval owner

Do not erase this baseline when the supplier changes the order or when the delivery differs.

The original agreement is what makes later differences measurable.

4. Supplier confirmation

A supplier may accept the order exactly as sent.

It may also change quantities, prices, dates, case sizes or substitutions.

Record those changes against the PO instead of treating the confirmation as an unrelated email. The confirmation should make it possible to see:

• what the supplier accepted
• what changed
• who approved the change
• which lines remain outstanding
• the revised delivery expectation

This prevents staff from discovering known changes while unpacking boxes.

5. Goods receipt

The receiving record answers a physical question: what arrived?

It should record:

• receipt date and location
• PO reference
• product or SKU
• quantity received
• condition
• batch, serial or expiry information where relevant
• receiver
• unresolved difference

A current Xero small-business guide (https://www.xero.com/us/guides/accounts-payable-process/) separates the purchase order, receiving record and supplier invoice. It recommends comparing what was ordered, what arrived and what was billed before payment.

That separation matters because ordered quantity is not received quantity.

If 20 units were ordered and 12 arrived, the purchase order should still show 20. The receipt should show 12. The remaining eight should have a clear state such as outstanding, cancelled or rescheduled.

6. Inspection and discrepancy record

Arrival does not automatically mean available to sell.

A delivery may include:

• damaged products
• wrong products
• incorrect quantities
• substitutions
• missing lines
• unexpected prices
• stock for the wrong branch
• products requiring quality, batch or expiry checks

Record the difference before adjusting it away.

For each exception, preserve:

• expected value
• actual value
• reason
• evidence or note
• owner
• next action
• resolution date

This creates a usable supplier history and prevents the same exception from being rediscovered during invoice approval.

7. Supplier invoice and payment check

The invoice should be linked to the order and the actual receipt.

The basic check asks:

• does the invoiced quantity match what was accepted or received?
• does the price match the approved terms?
• are freight, tax and discounts correct?
• are damaged, missing or returned goods handled correctly?
• is the invoice duplicated?
• is the payment due date clear?

Xero describes this purchase order, receipt and invoice comparison as three-way matching. A small retailer may perform it with simple tools, but the records still need to exist.

Payment should not be the first point at which the business discovers a delivery difference.

8. Trusted stock and cost update

Only confirmed stock should enter the appropriate available quantity.

The stock update needs to answer:

• which exact product or variant arrived
• how many units passed inspection
• which location owns them
• what cost should be recorded
• which units remain damaged, quarantined or unresolved
• who completed the update

This is the handoff between purchasing and inventory.

If staff retype the same receipt into another system, test how duplicates and errors are prevented. If the systems integrate, test what happens when one line fails or a supplier changes a product reference.

Choose the lightest system that preserves the map

The best tool depends on operational complexity, not ambition alone.

A controlled spreadsheet may still be enough

A spreadsheet can be reasonable when:

• one or two people own purchasing
• supplier and order volume is low
• deliveries go to one location
• exceptions are uncommon
• version control is clear
• the accounting and stock updates are consistently reconciled

Use one controlled file, unique PO numbers, protected definitions, named owners and clear status values. Avoid parallel personal copies.

Built-in accounting, POS or inventory purchasing may be the next step

This can work when the retailer needs purchase orders and receiving connected to products or accounts but does not need enterprise-wide planning.

Shopify's purchase-order documentation (https://help.shopify.com/en/manual/products/inventory/purchase-orders) describes supplier details, products, quantities, costs, terms, incoming shipments, receiving and cost adjustments.

Square's retail purchase-order documentation (https://squareup.com/help/us/en/article/8258-create-purchase-orders-with-square-for-retail) describes vendor tracking, product selection, partial receiving, damaged items and cost handling.

These examples show the workflow objects to test. They are not a recommendation that either product is automatically right for every retailer. Plans, regions, devices and integrations can change what is available.

A dedicated purchasing or inventory system may be justified

Move toward a dedicated tool when the business needs stronger supplier management, approvals, order planning, multi-location receiving, landed cost, batch tracking, forecasting or structured accounting handoffs.

The system should reduce duplicate entry and make exceptions easier to resolve, not simply add another place to type the same information.

An ERP becomes reasonable when the boundary is wider

An ERP may be appropriate when purchasing must coordinate with finance, warehouse operations, manufacturing, payroll, complex approvals, contracts, multiple legal entities or detailed planning.

The trigger is not that spreadsheets feel unfashionable.

It is that the business needs a governed operating model across functions that smaller tools can no longer preserve reliably.

Test the exception path before buying software

A clean demo usually shows a complete order arriving exactly as expected.

Real evaluation should test the difficult cases.

Create a trial PO and run these scenarios:

1. Full delivery at the agreed price.

2. Partial delivery with the remainder due next week.

3. One damaged unit that must not become sellable.

4. A supplier substitution that needs approval.

5. A price change after the PO was issued.

6. An invoice for more units than were received.

7. A duplicate invoice.

8. Stock delivered to the wrong location.

9. A line cancelled after supplier confirmation.

10. A receipt entered by one staff member and reviewed by another.

For each case, ask:

• Can we see the original order?
• Can we see what the supplier confirmed?
• Can we record what physically arrived without rewriting the PO?
• Can damaged or unresolved stock stay unavailable?
• Can the invoice difference be found before payment?
• Can the final stock and cost be explained?
• Can we see who approved and recorded each change?

If the answer depends on a private message, an unlabelled spreadsheet copy or someone's memory, the control map is incomplete.

Where EzyCarto fits

EzyCarto's currently documented supply-chain role begins with controlled stock movement across configured locations.

The EzyCarto Supply Chain and Transport Management page (https://ezycarto.com/supply-chain) describes:

• transfer orders between locations
• stock synchronization across affected locations
• sender and receiver validation
• SKU, batch and timestamp movement details
• delayed, incomplete or rejected transfer alerts
• transport notes and waybills
• role-based access and audit trails

Those controls matter after stock is received and when inventory moves between branches, stores or other configured locations.

They should not be confused with supplier purchase-order creation, accounts-payable approval or invoice matching. Keep those steps in a verified purchasing or accounting workflow unless a retailer's specific EzyCarto setup explicitly confirms otherwise.

This boundary is useful when designing the overall process:

• purchasing records what the business agreed to buy
• receiving records what arrived and passed inspection
• accounting verifies what should be paid
• inventory records what became available
• transfer control records where trusted stock moved next

The systems may be connected, but each control still needs a clear owner.

For a related stock-state map, see Stock Has More Than Two States (https://ezycarto.com/blog/stock-has-more-than-two-states). It explains why received, damaged, reserved, in-transit and available stock should not be treated as one quantity.

For broader workflow testing, see The POS Wish List Is Not the Same as a Store System You Can Trust (https://ezycarto.com/blog/the-pos-wish-list-is-not-the-same-as-a-store-system-you-can-trust).

The decision rule

Do not buy an ERP because purchasing feels untidy.

First map the records, owners, approvals and exception paths from supplier order to trusted stock.

Then identify exactly where the current process breaks:

• duplicate entry
• unclear ownership
• missing history
• weak approval
• uncontrolled exceptions
• disconnected stock
• invoice mismatches
• multi-location complexity

Choose the lightest system that fixes those failures without creating a new layer of work.

That may be a better spreadsheet.

It may be a feature already available in the retailer's accounting, POS or inventory platform.

It may be a dedicated purchasing tool.

Or it may genuinely be time for an ERP.

The control map should make the answer clearer before the sales demo begins.

Sources

• Xero, Accounts payable process for small businesses: https://www.xero.com/us/guides/accounts-payable-process/
• Shopify, Purchase orders: https://help.shopify.com/en/manual/products/inventory/purchase-orders
• Square, Create purchase orders with Square for Retail: https://squareup.com/help/us/en/article/8258-create-purchase-orders-with-square-for-retail
• Reddit research archive, Small-business supplier and purchase-order question: https://www.reddit.com/r/smallbusiness/comments/1tvgyp3/what_do_small_businesses_use_to_track_suppliers/
• Reddit research archive, Manual purchase-order and receiving workflow: https://www.reddit.com/r/InventoryManagement/comments/1nz4qun/question_for_store_owners_how_do_you_handle/
• EzyCarto, Supply Chain and Transport Management: https://ezycarto.com/supply-chain

CTA

Map one real supplier order from approval to receipt, discrepancy, invoice and trusted stock before adding more software. If inventory then needs controlled movement between locations, use EzyCarto's supply-chain page to test the transfer, validation and audit steps against your actual workflow.