A purchase order process without an ERP

The email that was almost a purchase order

Most small stores buy stock by email. Someone writes to the supplier asking for a quantity, the supplier replies, and stock arrives some weeks later. It works, right up until one of four things happens.

The delivery arrives and nobody can say what was supposed to be in it. The invoice does not match what turned up and there is no agreed record to check against. Two people order the same thing. Or somebody commits several thousand pounds that the person who watches the bank account did not know about.

None of these needs an ERP to fix. They need a purchase order, which is not a piece of software. It is an agreement written down before the money is spent.

What a purchase order actually has to contain

Six things. If your email has these, it is a purchase order, whatever it is called.

• A reference number. Anything unique and sequential. This is what makes the delivery, the invoice and the order findable as one thing.
• Exact items. Supplier's code and your SKU, together. Descriptions alone produce the wrong variant surprisingly often.
• Quantities and agreed unit price. The price you agreed, so the invoice can be checked against something.
• Agreed delivery date. A date, not "ASAP" and not "3 weeks". A date that can be missed is a date you can measure against.
• Where it goes. Obvious until you have two locations or a 3PL, then not obvious at all.
• Who raised it. So the person receiving it knows who to ask.

That is the whole thing. It fits in an email, a spreadsheet row, or a template document. The format matters far less than the fact that all six exist and are findable later.

Who is allowed to commit money

This is the part that gets skipped and the part that causes the expensive surprises.

In most stores under ten people the honest answer is "the owner, and sometimes whoever is dealing with it", which is not a rule. Write an actual one, with a number in it.

Something like: under a value floor, anyone in the buying role can raise and send a PO. Above it, one named person approves first. Above a second, much higher floor, the owner approves. Repeat orders of an existing line at an agreed price can go without approval regardless of value, because the decision was already made.

The floors should be high enough that most orders go through without approval. A rule that stops everything is a rule that gets bypassed, and a bypassed rule is worse than none because it creates a false sense of control.

Numbering, so things can be found

Sequential and boring. A year prefix and a counter is enough.

The number is what lets three separate events be recognised as one transaction: the order you sent, the delivery that arrived, and the invoice that followed. Without it, matching an invoice to a delivery means reading descriptions and guessing, which is how stores end up paying twice for the same pallet or paying for a short delivery at full quantity.

Put the number on the order, ask the supplier to put it on their paperwork, and write it on whatever the receiving person fills in. Three places, one number.

The three states a PO lives in

Every purchase order is in one of three states, and knowing which is most of the value of having them.

Raised. Sent, not confirmed. You are waiting for acknowledgement, and if that wait exceeds a few days it needs chasing, because unacknowledged orders are the most common source of a lead time that was longer than expected.

Confirmed. The supplier has agreed quantity, price and date. This is the state where a date exists that you can hold them to.

Received. Fully or partially. Partial receipts are the awkward case and the one an email-based process handles worst, because half a delivery leaves no obvious trace of what is still owed.

A list of open POs with their state, visible to the people who need it, answers most of the questions that otherwise get asked one at a time.

Connecting the order to the delivery

This is where the process earns its keep, and it is a communication problem more than an administrative one.

The person receiving a delivery needs to know what was supposed to arrive before they open the boxes. If they are counting into a void, discrepancies are invisible: 480 units of something feels like a lot, and only a document saying 500 makes it a problem.

So the open PO has to be reachable by whoever is on the loading bay, which in a small store might be a different person every week. If purchase orders live in the buyer's sent folder, the receiver cannot check anything, and the discrepancy surfaces weeks later when a count does not add up. The receiving half of this is covered in receiving stock.

Chasing, and when

Orders go quiet. The useful discipline is a chase rule tied to the confirmed date rather than to somebody remembering.

Something like: chase if not acknowledged within three working days; chase a week before the confirmed date to reconfirm; chase the day after it passes. Three touches, all predictable, none dependent on anyone's memory.

The pre-date reconfirmation is the one stores skip and the one that pays. A supplier who is going to be late usually knows a week beforehand, and will tell you if asked, which converts a stockout you discovered into a stockout you managed.

Matching the invoice

The last step, and the one that catches real money. Three documents should agree: what you ordered, what arrived, what you were billed for.

When they do not, the discrepancy is almost always one of four things: a price that differs from what was agreed, a quantity billed in full when a short delivery was received, a delivery charge that was not in the quote, or a duplicate invoice for a partial delivery already paid.

None of these is exotic and all of them are cheap to catch if the three documents share a reference number. Without one, checking is expensive enough that most small stores simply do not, which is a decision, just not usually a conscious one.

Doing this without buying anything

You do not need a purchasing system. A numbered template, a shared list of open orders with their state, and a written approval rule cover almost all of it.

What matters is that all three are reachable by more than one person. A process that lives in one person's email is not a process, it is a dependency, and it fails in exactly the week that person is away and a delivery arrives.

The general version of this argument is in writing an SOP your team will actually open: short, specific, and located where the work happens rather than in a folder somebody has to remember exists.

What this looks like in Store Huddle

A purchasing room, one task per purchase order, the reference number in the title, the due date set to the confirmed delivery date. The task moves through raised, confirmed and received as an owner updates it, so the open list is a by-product of doing the work rather than a document somebody maintains.

Because the task is visible to the room, the person receiving a delivery can see what is expected without asking the buyer, and the buyer can see at a glance which orders are unacknowledged. Products attached to the conversation identify the exact variant, which is the detail most often lost when an order is described in prose.

Approval above a value floor becomes a message in a room with the order attached rather than an email chain, and the decision stays with the order rather than in somebody's inbox.

Common questions