The Purchase Order Process: Requisition to Receipt Without the Email Chain

A purchase order is not paperwork. It is the moment a company decides to spend money, written down before the money is spent — which is the only point at which anyone can still say no. Organisations that raise purchase orders after the invoice arrives have a filing system, and they usually discover the difference during an audit.

The process, end to end

Five stages, and each one exists to make the next one possible.

1. Requisition. Somebody internally asks to buy something. No supplier is committed to at this point.

2. Approval. Somebody with the authority to spend that money agrees, before it is spent.

3. Purchase order. The approved request becomes an order placed with a supplier — an external commitment with a number, a quantity, a price and terms.

4. Receipt. The goods or the service arrive and somebody confirms what actually turned up.

5. Three-way match and payment. Order, receipt and invoice are compared, and the invoice is paid to the extent that all three agree.

Written like that it is obvious. In practice most organisations run stages 3 and 5 formally, treat stage 1 as an email, treat stage 2 as whoever happened to reply, and discover at stage 5 that they cannot match anything because nobody recorded stage 4.

Requisition versus purchase order, and why it matters

Almost every article on this subject uses the two words interchangeably. Every implementation that does the same puts approval in the wrong place.

A requisition is an internal request. It says a department wants something. It commits nobody, it can be refused freely, and it is where the business decision belongs — do we need this, is there budget, is it the right specification.

A purchase order is an external commitment. Once it is sent, a supplier has been instructed and a liability is forming. The decisions here are commercial: which supplier, what price, what terms.

Collapse the two and the approval attaches to the wrong document. The common symptom is a manager approving purchase orders full of supplier and pricing detail they have no basis to judge, while the question they could actually answer — does this department need this — was never formally asked.

The practical test, and the first thing to try in any demo of purchase order software: can somebody raise a request without naming a supplier? If the system demands a supplier before anyone can ask for anything, it has no requisition stage, and purchasing decisions are being made by whoever writes the request.

Approval that reflects authority, not hierarchy

Approval routing is where purchase order software either earns its cost or becomes the thing people work around. It is also the capability most often sold separately, as purchase order approval software or procurement workflow software, when it is really one feature of the same system.

Route by value band. Spend up to a level is approved by one role, above it by another. This is delegation of authority written down, and most organisations have it as a policy long before it exists in any system.

Route by category as well as value. A modest IT purchase may need a technical opinion that a far larger materials order does not. Value alone routes the wrong things to the wrong people, and it is why single-threshold designs get bypassed.

Name a delegate for every approver. The same rule that applies to leave approvals applies here and for the same reason: an approver who is away stops the process, and an urgent purchase that cannot be approved is the origin of most retrospective orders.

This article publishes no threshold figures. Delegation limits are set by the business, differ by entity and change; a number here would be wrong for almost every reader.

What matters is that the bands exist, are written down, and are the ones the system actually enforces — a policy that lives in a document while the system routes everything to one director is not a control, it is a bottleneck with a paper trail.

The three-way match, properly explained

This is the control the entire process exists to make possible, and it is worth stating precisely because most descriptions stop at the definition.

You ordered it, you received it, you were invoiced for it. Pay to the extent that all three agree, and investigate wherever they do not.

The definition is easy, and every piece of purchase order software claims it. The value is in what happens when the three disagree, which is most of the time in any real operation.

Partial delivery. Half the order arrives now and half in three weeks, and the supplier invoices for what they sent. The match has to work against a partial receipt rather than treating the order as an all-or-nothing quantity. Systems configured for the simple case fail here first.

Price variance. The invoice differs from the ordered price. Some tolerance is normal and should be defined; anything outside it is a question for purchasing, not a decision for accounts payable to make alone.

Over-receipt. More arrived than was ordered. Whether that is accepted, returned or treated as a new order is a policy decision, and if it is not made in advance it gets made at the receiving door by whoever signed for it.

Services rather than goods. There is nothing to count. The receipt stage becomes somebody confirming the work was done, which needs a named person and a date, or the match has only two legs.

Goods receipt is where purchasing hands over to stock

Receipt is the stage most likely to be treated as a formality and it is the one carrying the most information. It is also the point at which purchase order tracking stops being an administrative question and starts being an inventory one.

It is the moment quantity and condition are verified, and it is the point at which a purchase becomes stock the business owns and can count.

Skip it, or record it days later from a delivery note found in a folder, and two things break at once: the match has no middle leg, and inventory is wrong until somebody reconciles it.

Where receipt is captured at the door rather than re-entered later, most of that risk disappears — the record is created where and when the goods actually arrive, by the person looking at them.

From there the ordered items become stock that has to be located, counted and valued, which is the job of inventory planning software and is where the purchasing story ends and the inventory one begins.

If what arrived is held for later issue rather than immediate use, the method by which it is valued and counted matters more than the order did — see perpetual versus periodic inventory.

Assets enter the business here too

One consequence of the purchase order process is invisible until an audit, and it starts on the order line.

When something durable is bought — equipment, vehicles, furniture, machinery — the decision to treat it as a capital item rather than an expense is first visible at purchase.

If it is coded to an expense line, it will be paid, recorded and consumed as spend, and it will never reach the fixed asset register. Nobody is doing anything wrong; the item simply drops out of the asset record at the first step.

That is one of the standard reasons an asset register disagrees with reality, and unlike the others — disposals and transfers nobody recorded — this one is preventable at the point of purchase rather than discovered at verification.

The fix is a coding decision made when the requisition is raised, by somebody who knows the capitalisation policy, rather than by whoever processes the invoice.

Where purchasing and fixed asset management software read the same transaction, the asset is created from the receipt. Where they do not, somebody has to notice — and the failure is silent, which is what makes it persistent.

Purchase order or expense claim?

The boundary between something ordered and something bought-and-claimed-back is where purchasing control quietly leaks.

Expense claims are for genuinely unplanned, low-value, individual spend. A taxi, a meal with a client, a part bought urgently on site. They are reimbursements, and they are reviewed after the money has gone.

Everything else routed through claims is purchasing without a purchase order, which means without prior approval, without a commitment record, and without anything to match an invoice against. It is not fraud and it usually is not even deliberate — it is faster, and the process rewarded speed.

The diagnostic is simple and uncomfortable: look at what is actually being claimed. Recurring purchases from the same supplier, or claims consistently sitting just under an approval threshold, mean the purchasing route is too slow and people have found a faster one.

That is a process finding, not a compliance one, and the fix is usually to make requisitions easier rather than to police claims harder.

Emergency and retrospective orders

Every operation has purchases that cannot wait, and pretending otherwise is what makes a process dishonest — including a process enforced by purchase order software.

A plant stops. A part is needed today. Somebody buys it, and the purchase order is raised on Monday to cover a decision made on Saturday. That is a retrospective order, and treating every one as a policy breach means the process is permanently at odds with how the business actually runs.

The design question is whether the exception is defined or improvised. A defined path names who may authorise an emergency purchase, sets what evidence is captured at the time, and requires after-the-fact approval within a stated window — producing a record that is accurate about what happened and when.

An improvised path produces an order dated Monday that says it authorised a purchase already made, which is a record that states something untrue.

Watch the volume rather than the individual cases. A handful of genuine emergencies is an operation. A steady stream is a signal that ordinary approval is too slow, and the honest response is to fix the routing, not to add another rule.

When a spreadsheet stops being enough

Purchase order software is not the answer to every purchasing problem, and it is worth saying where the line actually is.

A note on names first, because the category is sold under a spread of them. Purchase order processing software, purchase order automation software, procurement tracking software and plain purchase order applications all describe the same territory, and where the tool also holds what was received you will see it sold as purchase order and inventory management software.

The label tells you very little; what to compare is routing, matching and the audit record.

A spreadsheet and a numbering convention genuinely work at low volume with one approver, one site and suppliers who deliver complete. Plenty of businesses run this way for years without difficulty, and buying software to formalise it would be spending money on a problem they do not have.

It stops working at three specific points, and usually more than one arrives at once. When there are multiple approvers, because routing by value and category cannot be done by hand reliably.

When partial deliveries become normal, because matching against a partly-received order in a spreadsheet is where errors live. And when a supplier disputes what was ordered, because the answer depends on having a version-controlled record rather than the current state of a file somebody has been editing.

At that point purchase order software is buying exactly three things: routing that reflects the delegation policy, a match that survives partial delivery and price variance, and a record nobody can quietly edit. The rest of the feature list is secondary.

Where purchasing sits alongside inventory, assets and the ledger rather than beside them, the order, the receipt and the invoice are one chain of events rather than three systems to reconcile — which is the argument for buying procurement software as part of an erp software platform rather than as a standalone tool, and the invoice leg reaches accounting software without being re-keyed.

A purchase order touches stock when it is received, the asset register when it is capitalised, and the ledger when it is paid. Keeping those on one chain of events rather than three systems to reconcile is what erp software is for.