Purchase Orders

Purchase Order Process 101: How to Create, Approve, and Track POs Without the Email Back-and-Forth

Timothy Farcwell·July 6, 2026·4 min read

A purchase order sounds like paperwork, but it exists for a genuinely good reason: it's the formal record of exactly what was ordered, from whom, at what price, and whether it's actually been paid for yet or just committed to. Without one, "did we already order this?" and "how much did we agree to pay?" become questions someone has to dig through an email inbox to answer. Assuming the answer is in an email at all.

Here's how the process should actually work, end to end.

The Five Stages Every PO Goes Through

Draft. The PO exists but hasn't gone anywhere yet. Vendor, quantity, price, and what it's for are all recorded, but nothing's been sent or committed.

Sent. The order has actually gone to the vendor. This is the point where "we've ordered it" becomes true. And where a lot of informal processes lose the thread, because "I emailed them" doesn't automatically update any record anyone else can see.

Approved. Someone with the authority to commit the spend has signed off. Depending on your organisation, this might happen before sending (approve, then send) or as a separate confirmation once the vendor's accepted the order. Either way, it's a distinct, visible step, not an assumption.

Received. The goods have actually arrived. This is the step that should trigger a real update elsewhere. If the PO was for restocking a consumable, the stock count should increase automatically the moment this happens, not as a second manual entry someone has to remember to make.

Cancelled. Plans changed. A clean process needs an explicit cancelled state, distinct from simply deleting the record. You want a history of what was ordered and then not fulfilled, not a gap in the record as if it never existed.

Two Numbers That Genuinely Matter: Committed vs. Spent

A draft or sent PO represents a commitment. Money you intend to spend but haven't yet. A received PO represents actual spend. Conflating these two into one "total spend" figure is a common and genuinely misleading mistake: it either overstates what's actually been paid, or understates what's already been committed and is coming due. Keep them separate, always.

The Part Most Manual Processes Get Wrong: New Products vs. Existing Assets

Not every PO is for restocking something you already track. Sometimes it's for something entirely new. The first laptop of a model you've never owned before, a piece of equipment that doesn't exist as an asset yet. A good process should handle both without forcing the first one into an awkward workaround: link the PO to an existing asset when you're restocking it, or let it reference a not-yet-created product by name when you're not, and only create the actual asset record once it's confirmed received.

Who Should Be Able to Create One, and Who Should Approve It

This should mirror your actual organisational authority, not an arbitrary system default. A manager creating a PO for their own department's equipment is normal. Whether they can also approve it, or whether it needs a signer above them, should be a deliberate choice your system reflects. Not something bypassed because the form didn't require it.

What to Look For in a System That Actually Handles This Well

Dozz.ai's purchase order module runs exactly this workflow. Draft through received, with committed and actual spend tracked and reported separately, a real signer field for who's authorizing the order, and the new-product path for anything that isn't in your asset register yet. Mark a PO for a consumable as received, and the stock count updates itself in the same action. No second step to remember.

Try the full PO workflow. Start your free 30-day trial, no credit card needed.

Ready to see it in action?

Start free trial