Somebody asked, somebody said yes, and the order went to the vendor. Six weeks later a bill arrives for more than anyone remembers agreeing, and the record of the decision is in an inbox belonging to a person who has since changed roles. The order itself shows nothing: it was raised as approved, because by the time it was typed the approving had already been done somewhere else.
A purchase order with a real lifecycle on the record itself. An order opens as a request for quotation, can be emailed to the vendor from the system, and on confirmation either becomes a live order or parks in a "To Approve" state, which of the two depends on a company setting and a money threshold you set. Every transition is written to the order's own log. Confirmed orders can be locked against further editing, and an order carrying a posted bill cannot be cancelled until that bill is cancelled first.
Downstream, the order stays connected to what happens to it. For stocked lines, received quantity is totalled from completed stock moves rather than typed in. Each product carries a control policy deciding whether the amount available to bill is what was ordered or what actually arrived. Bill lines and order lines can be tied together on one screen. Expected arrival dates carry an optional automatic vendor reminder, and the vendor's answer is stored on the order. Purchase Analysis reports ordered, received and billed quantity by vendor, buyer, product category and country, alongside averaged days-to-confirm and days-to-receive.
It's already in Odoo, nothing to add, no upgrade tier to reach, no extra fee per user, and it runs on infrastructure you own. The whole purchase-order lifecycle is in the base system, not held back for a higher edition. NetSuite bills procurement as a module and a per-seat renewal; in Odoo it is already included, and that difference is the product. (Two things sit outside the base system, supplier-catalogue checkout, and the three-way-match gate that holds a bill from payment until receipt confirms it. The gate is what the agent closes, on the matching page; catalogue checkout is in the FAQ below.)
A purchase order is the document a buyer issues to a vendor stating what is being bought, in what quantity, at what price and by when. Once the vendor accepts it, it is a commitment on both sides: the buyer has agreed to pay the stated price for the stated goods, and the vendor has agreed to supply them on the stated terms. That is what makes it useful beyond record-keeping, it fixes the price before the invoice exists, so an invoice that disagrees with it can be challenged against something written rather than against somebody's memory. In accounting terms it is not yet a transaction, because nothing has been received and nothing is owed; it becomes one when the goods arrive and again when the bill is posted.
It is the choice of which document decides how much may be invoiced, and it decides whether you can be billed for goods that have not arrived. Under an ordered-quantity policy, the amount available to bill is what the purchase order says, less whatever has already been billed, so a vendor can invoice the full order the day it is confirmed, before anything ships. Under a received-quantity policy, the amount available to bill is what the goods receipt confirms actually arrived, less whatever has already been billed, so a partial delivery can only produce a partial bill. The second is the stronger control and is usually set per product rather than globally, because services often have no receipt to point at and default to the ordered policy for that reason.
A threshold approval holds an order above a stated amount in a pending state until someone with the authority releases it, and lets everything below it through. It is a genuinely useful control because it is unambiguous, it lives on the order record rather than in a mailbox, and the release is written to the order's history where an auditor can find it. It stops being enough when the organisation needs the route to vary rather than just the gate, when a capital purchase should go to a different approver than a marketing spend of the same size, when two signatures are required above some level, or when the department budget rather than the amount should decide. Those need a routed, multi-step workflow, which is a different capability from a threshold, and the distinction is worth establishing early in any ERP evaluation because both are described as "purchase approvals".
The argument for a separate tool is that dedicated procurement platforms offer richer routing, supplier catalogues and spend analytics than most ERPs ship with. The argument against is that the approval then lives in a different system from the order, the receipt and the bill, and the reconciliation between them becomes an integration that someone maintains. The question that usually settles it is what you want to be able to prove: if the useful artefact is "this order was approved by this person before it went to the vendor, and here is the same record the bill was matched against", then keeping the approval on the order itself is worth more than the extra routing. If the organisation's real problem is unmanaged indirect spend across hundreds of low-value purchases, that is a different problem and a threshold on the order will not solve it. NetSuite frames the gap the second way, Oracle's procurement page describes SuiteProcurement as bringing indirect procurement inside NetSuite, where "buyers shop directly from a supplier's online store and check out" and the system "automatically creates a purchase request, initiates the approval process and automatically transmits the purchase order once approved". That is a real capability and it is sold as an addition to the base product. It is worth knowing whether you are buying it because you need catalogue purchasing or because you need an approval that sticks, since only one of those requires it.