How Purchase Order Workflows Actually Work Inside an ERP
A construction supply company's purchasing manager needed a $340 replacement part urgently enough to drive to the supplier himself rather than wait for the PO to clear their ERP's approval chain — which, for that dollar amount, required sign-off from a department head who was out of the office for three days. Meanwhile, a $28,000 equipment purchase from a different department sailed through in under an hour because it happened to fall under a manager's individually high approval limit, set years earlier and never revisited. The PO system wasn't broken exactly — every step functioned as configured. It was configured badly, with approval thresholds that no longer matched actual risk or urgency.
This is a common pattern: companies implement PO workflows once, during initial ERP setup, and rarely revisit whether the thresholds and routing still make sense as the business changes. Understanding what's actually happening at each stage makes it much easier to spot where a given company's setup has drifted out of alignment with reality.
The stages a purchase order actually moves through
1. Requisition
Before a PO exists, most ERP workflows start with a purchase requisition — an internal request from an employee for something to be bought, which hasn't yet committed the company to a vendor or price. This step exists specifically to separate "someone wants to buy something" from "the company has committed to buying it," giving purchasing or finance a review point before a vendor is even involved. Smaller companies sometimes skip this and let any authorized user create a PO directly; that's a reasonable simplification below a certain size, but it removes a checkpoint that becomes more valuable as spend volume and headcount grow.
2. PO creation and vendor/price assignment
The requisition (or a direct request) becomes an actual purchase order once a vendor, quantity, unit price, and delivery terms are attached. This is where a company's negotiated vendor pricing should be enforced automatically — a well-configured ERP pulls in a pre-negotiated contract price rather than letting whoever's creating the PO enter whatever number a vendor quoted them that day, which is a common, quiet source of margin leakage when it's not enforced.
3. Approval routing
This is the stage that broke down for the construction supply company. Approval routing should be based on a combination of dollar amount and category/risk, not dollar amount alone. A well-designed matrix has multiple tiers — for example, under $500 auto-approved or single-manager approval, $500-$5,000 requiring department head sign-off, $5,000-$25,000 requiring both department head and finance, above $25,000 requiring executive approval — reviewed at least annually against actual spend patterns, not set once at implementation and left untouched for years while the business's scale and risk profile change around it.
4. PO issued to vendor
Once approved, the PO is formally issued — sent to the vendor, and the system typically records the encumbrance, meaning the budget is reserved against that spend even though the invoice hasn't arrived yet. This matters for cash flow visibility: a company that only tracks committed spend once the invoice lands is always looking at a partial, lagging picture of its actual financial obligations.
5. Receiving
When goods or services arrive, someone logs the receipt in the system — ideally checking actual quantity and condition against what the PO specified, not just rubber-stamping it as received. This step is where partial shipments, damaged goods, or short deliveries get caught and flagged before they become a payment dispute weeks later.
6. Three-way matching and invoice approval
Before an invoice gets paid, most ERP AP workflows perform a three-way match: comparing the purchase order, the receiving record, and the vendor invoice to confirm they agree on quantity and price. A mismatch — the invoice says $4,200 but the PO said $3,950 — flags for manual review rather than auto-paying. This is one of the highest-value fraud and error controls in the whole PO workflow, and it only works if receiving records are actually entered accurately and promptly, which ties directly back to step 5 being taken seriously rather than treated as a formality.
Blanket and contract POs: a different pattern for recurring purchases
The stage-by-stage workflow above describes a standard, one-time PO, but a meaningful share of real purchasing volume — recurring orders from a regular supplier, like weekly shop consumables or a service contract billed monthly — doesn't fit that pattern well if every single order has to go through full requisition-to-approval each time. Most ERPs support a blanket PO (sometimes called a contract PO): a single approved purchase order covering a total dollar amount or quantity over a defined period, against which individual "releases" get issued without triggering a fresh approval cycle each time, as long as the release stays within the blanket's pre-approved terms and remaining balance.
Setting this up correctly requires the same rigor as the main workflow: a defined review point (usually quarterly) checking that actual usage against the blanket is tracking to what was approved, and a hard stop or alert when the remaining balance gets low, so a blanket PO doesn't quietly become an unmonitored, indefinitely renewing commitment that nobody's actively reviewing. Done well, this removes a large share of low-risk, repetitive requisition overhead from the approval queue — exactly the kind of purchase that shouldn't need a full approval chain every single time — while keeping the periodic review that catches a blanket PO's usage drifting from its original intent.
Tying PO performance back to vendor evaluation
An underused byproduct of a well-run PO workflow is vendor performance data that accumulates automatically if the workflow's stages are actually used as designed: on-time delivery rate (comparing PO promised date against actual receiving date), price accuracy (how often three-way matching flags a mismatch for that specific vendor), and fulfillment accuracy (how often what's received doesn't match what was ordered in quantity or condition). Very few companies actually pull this data into a regular vendor review, even though it's sitting in the system already, generated as a side effect of receiving and matching transactions that were happening anyway. A quarterly report ranking primary suppliers by these three measures turns the PO system from a pure transaction-processing tool into a source of real negotiating leverage — a vendor with a documented 15% late-delivery rate over two quarters is a very different renewal conversation than one going in with only a general impression that "deliveries have felt slow lately."
Where PO workflows commonly go wrong
| Problem | Usual cause |
|---|---|
| Urgent small purchases get stuck in approval | Thresholds set too low, never revisited as the business grew |
| Large purchases sail through easily | Individual manager limits set years ago, inconsistent across departments |
| Invoices routinely get paid at the wrong price | Negotiated contract pricing not enforced at PO creation |
| Three-way match constantly flags false mismatches | Receiving records entered late or inaccurately |
| Purchasing gets bypassed entirely for "urgent" buys | No fast-track approval path exists for genuinely time-sensitive, low-risk purchases |
The fix that actually matters most: a fast-track path, not lower thresholds everywhere
The instinct after a story like the construction supply company's $340 part is to just lower every approval threshold across the board so nothing gets stuck. That overcorrects: it removes a real control on larger spend to fix a problem that only existed for small, urgent purchases. A better fix is a genuine fast-track path: a defined category of low-dollar, pre-approved-vendor purchases (say, under $500, from an already-vetted supplier) that route to a single, always-available approver or auto-approve outright, while normal multi-tier approval stays intact for everything else. This solves the actual problem — urgency mismatched to risk — without weakening the controls that exist for a reason on larger spend.
Approval thresholds and routing logic are one of the few parts of an ERP configuration that should be actively revisited on a schedule — annually at minimum, or whenever the company crosses a meaningful growth milestone — rather than set once during implementation and forgotten. The construction supply company's mismatched thresholds weren't a software failure; they were a maintenance failure, a configuration decision made years earlier that nobody had revisited as the business, and the dollar amounts that counted as "significant," had both changed.