Raising a purchase order is the easy half. PO management is what happens over the following six weeks, when the order is out with a supplier, part of it has arrived, an invoice has come in for the part that has not, and somebody has to say whether that is a problem. Most small businesses have a generator of some kind and no management at all, which is why the question who is this invoice for cannot be answered. This page is about the statuses worth keeping, what a PO log has to hold, and where tracking software earns its price.
Four statuses and no more
Raised, approved, received, invoiced. Four is enough for a small business and each one earns its place because a different question depends on it. Raised answers what has been asked for. Approved answers what we are committed to, which is the number a bookkeeper needs at month end and almost never has. Received answers what has actually arrived. Invoiced answers what has been billed. Adding statuses beyond these, partially received, closed, cancelled with reasons, is possible and rarely worth the friction until the volume justifies it.
The po log is the record, not a report
A PO log is one row per order with its number, date, supplier, requester, approver, amount and status. It sounds trivial and it is the single artefact that makes every other question answerable: what is outstanding with this supplier, what did we commit to in March, does this invoice match anything. Keep it as the source rather than as something generated at month end from memory, and keep the number sequential so a gap is visible. A gap in a PO number sequence is either a cancelled order or an order somebody raised outside the system, and both are worth knowing.
What po tracking software adds over the log
Three things. It updates the status as a consequence of an action rather than as a separate act of data entry, which is the only way a log stays current. It tells the requester when their order is received rather than making them ask. And it holds the line detail, so a partial delivery can be recorded against the lines that arrived rather than as a note. If a product does not do the first of those, it is a spreadsheet with a login and the log you already have is cheaper.
Matching the invoice, without pretending to be accounts payable
When the invoice arrives, the question is whether it matches an approved order and what was actually received. A small business does not need automated three-way matching at volume; it needs the PO number on the invoice and a record it can be checked against, which is why the number belongs on the order the supplier receives. This hub stops there deliberately. Paying the invoice, coding it and posting it is accounts payable and a different product; the purchase order ends at the match.
Questions people ask about po management
What statuses should a purchase order have?
Raised, approved, received, invoiced. Each answers a different question, and the approved total is the committed-spend figure most small businesses cannot produce.
What is a PO log?
One row per order carrying its number, date, supplier, requester, approver, amount and status. Kept as the source rather than assembled at month end, it answers what is outstanding, what was committed and whether an invoice matches anything.
Why should PO numbers be sequential?
So a gap is visible. A missing number is either a cancelled order or one somebody raised outside the system, and both are things worth noticing.
Does PO management replace accounts payable?
No. It gives AP something to match against. Paying, coding and posting the invoice is a different product; the purchase order ends at the match.