Purchase Order Approval Process: Workflow & Thresholds

The purchase order approval process is the set of checks a company runs before a PO is issued to a supplier. A requisition is raised, it is routed to one or more approvers based on the amount and category of spend, each approver confirms the purchase is needed and within budget, and only then does the PO become a binding commitment. The point is to make sure someone with authority to spend the money has agreed to spend it before the order goes out, not after the invoice arrives.

Last updated July 2026.

If you already have approved POs and just need the data out of them, the tool above does that: upload a purchase order PDF or scan and the PO number, supplier, dates, and line items come back as spreadsheet rows in about ten seconds. Approval routing itself lives in your ERP, which we are honest about below.

How approval fits the wider purchase order flow

Approval is one stage in a longer chain: someone raises a purchase requisition, it is approved, a PO is created and approved, the supplier fills the order, goods arrive, and accounts payable pays against a matched invoice. The full sequence is in the purchase order process, end to end, and the two documents that bookend approval are compared in purchase requisition vs purchase order. The requisition approval asks whether to buy at all; the PO approval asks whether this specific order is authorized to send.

How approvals get routed: amount, category, and risk

A purchase order approval workflow decides who signs off before a PO is released. Three routing logics do the work, and most companies blend all three.

Amount-based routing is the common one: the dollar value sets how far up the chain the PO travels. A small order stops at a team lead; a large one climbs to a director, a VP, or the CFO. Those cutoffs are the PO approval limits, also called purchase approval thresholds, and they come from the company's delegation of authority policy, not any external standard.

Category-based routing sends certain spend to specialists regardless of amount: IT purchases through security, anything touching personal data through legal, capital equipment through finance for treatment under GAAP. A $300 software subscription can need more approvals than a $30,000 order of raw material bought weekly.

Risk-based routing adds approvers when something looks unusual: a brand new supplier, a sole-source justification, an auto-renewing contract, or spend that pushes a department over budget. This layer catches what the flat thresholds miss.

What is the purchase order approval process?

It is the sequence of authorizations a purchase order passes through before it is sent to a supplier. A requisition is raised, routed to approvers based on spend amount and category, checked against budget and policy, and approved or rejected. Once approved, the PO is issued and becomes a commitment the company is obligated to honor.

The process exists to put a decision on record before money is committed, which is what auditors, budget owners, and accounts payable all rely on later.

Who approves a purchase order?

The approver is whoever holds spending authority for that amount and category under the company's delegation of authority policy. For small amounts that is usually the requester's manager or a budget owner. As the value rises, approval moves to directors, vice presidents, and eventually the CFO or CEO for the largest commitments.

The requester is never the approver of their own PO, because that would let one person both create and authorize a purchase. Category approvers in IT, legal, or finance may be added on top.

What are purchase order approval limits?

Purchase order approval limits are the dollar thresholds that decide which level of management must sign off on a PO. Below a limit, a lower-level approver can authorize the order; above it, the PO escalates to higher spending authority. The limits are set by each company in its delegation of authority policy.

There is no universal number. A small business might let a manager approve a few thousand dollars, while an enterprise sets the same tier at fifty thousand. The limits reflect the company's risk tolerance and size.

An illustrative approval matrix

A purchase order approval matrix maps spend bands to the approver required at each level. The table below is an illustrative example only. It is not a standard or a recommendation. Every organization sets its own bands and titles in its delegation of authority policy, and yours will look different.

The higher bands add approvers rather than replacing them: a $60,000 PO collects the director's approval, the VP's, and procurement's. That accumulation is deliberate.

Segregation of duties and delegation of authority

Segregation of duties is the principle that no single person should control every step of a transaction. In purchasing, the person who requests a purchase, the one who approves it, and the one who receives goods and pays the invoice should not be the same individual. Split those roles and it takes collusion, not one bad actor, to push through a fraudulent purchase. This is why every workflow blocks self-approval: if a director raises a requisition within their own limit, the system routes it to a peer or their manager. An approval you can grant yourself is not a control.

The delegation of authority (DoA) policy assigns those limits to roles, and finance owns it. A delegation of authority purchase order limit says, in effect, this title may commit the company up to this amount for this kind of spend. The DoA also defines who approvals delegate to when someone is out, so an absent VP does not stall the queue.

Blanket POs get approved differently. A blanket purchase order is a standing agreement to buy up to a set amount from a supplier over a period, and the total commitment gets approved up front. Individual releases then draw down that ceiling without a fresh full approval each time. That is efficient, but the up-front approval has to be scrutinized harder, because it authorizes a year of spend in one signature.

The workflow stages, and where each one breaks

Here is the approval workflow as a sequence of stages, with the check each performs and the failure mode that most often shows up in an audit.

After-the-fact POs, and why they defeat the control

A retroactive or after-the-fact PO is one raised to cover a purchase that already happened. Someone called the supplier, the goods arrived, the invoice showed up, and only then did anyone create the PO so accounts payable had something to match against. The approval on that PO is theater: nobody was deciding whether to spend the money, they were papering over a decision already made.

The value of pre-approval is that it happens while you can still say no. Approve after the invoice and you cannot reject the purchase, negotiate the price, or catch that it was never budgeted. A high rate of after-the-fact POs is one of the first things an auditor looks for, because it means the workflow is being routed around. The fix is procedural: make it faster to do it right than to do it wrong.

How approval evidence supports the three-way match and audit

Once the PO is approved and issued, its approval record becomes evidence later stages depend on. When the invoice arrives, accounts payable runs a three-way match against the PO and the receipt, and the fact that the PO was properly approved is part of what makes the payment authorized. The mechanics in AP are covered in three-way matching in accounts payable.

For US public companies, this is where the Sarbanes-Oxley Act (SOX) enters. Section 404 requires management to maintain and attest to internal controls over financial reporting, and purchase approval is one of them. An auditor testing it pulls a sample of POs and confirms each was approved by someone within their delegated limit, before the commitment, with no self-approval. That is only possible if the approval leaves a clean, timestamped trail. Missing or backdated approvals are control deficiencies, and enough of them become a material weakness the company must disclose.

Where PurchaseOrders fits (and where it does not)

Plainly: PurchaseOrders does not route approvals, hold budgets, or run three-way matching. It reads purchase order documents and turns them into structured data (PO number, supplier, dates, line items) as Excel, CSV, JSON, or an API response. Approval routing belongs in your ERP or procurement suite, such as NetSuite, SAP, Coupa, Procurify, Precoro, or Ramp, where the DoA limits and workflow rules live. What extraction removes is the retyping at the edges of those systems, getting a PO PDF into structured form for the AP clerk or into the spend rollups procurement leaders report on. The approval decision stays with people and their ERP.

How many approvers should a purchase order have?

Enough to enforce authority and segregation of duties, and no more. For routine low-value spend, one approver who is not the requester is usually sufficient. As the amount rises, add levels; as the category gets sensitive, add a specialist. Most well-run PO workflows land between one and three approvers for typical spend.

More approvers is not more control past a point, because long chains create diffusion of responsibility and everyone rubber-stamps.

What is a purchase order approval matrix?

A purchase order approval matrix is a table that maps spend bands and categories to the approvers required for each. It turns the delegation of authority policy into a lookup: find the amount and type of purchase, read across, and you know who must sign off. It is the reference the workflow engine and the auditor both use.

A good matrix names roles, not individuals, so it stays valid when people change jobs, and it defines what happens at the band boundaries, because those edges are where control gaps appear.

How do you speed up purchase order approvals?

Cut approvers to the policy minimum, auto-approve genuinely low-risk low-value spend, configure delegation so an absent approver does not stall the queue, and give approvers the context to decide in one pass. Most delay is waiting on people, not the work itself.

The other lever is clean requisitions, since approvals bounce when a request is missing a cost, spec, or budget line. Automating the downstream matching, so that once the supplier invoice lands the tools that handle the accounts payable side of the workflow remove another queue, keeps the whole cycle from backing up at month end.

What happens if a PO is approved after the invoice arrives?

The approval no longer functions as a control. Approving a PO after the invoice means the spending decision was already made and the money already committed, so the approver cannot reject or renegotiate anything. It creates a valid-looking record of a control that did not really operate.

Operationally the invoice can still be matched and paid, so nothing visibly breaks. The damage is in governance: retroactive approvals are a red flag for auditors and undermine budget discipline. Track and reduce them rather than accept them as normal.

Does PurchaseOrders approve or route purchase orders?

No. PurchaseOrders extracts data from purchase order documents; it does not route approvals, enforce thresholds, hold budgets, or perform three-way matching. Those functions live in your ERP or procurement platform, where the delegation of authority rules are configured. What it gives the approval process is clean, structured PO data feeding in and out of those systems, so the people doing the routing are not slowed by manual re-keying.

Putting it together

A working approval process is easy to hollow out. Keep the thresholds in a delegation of authority policy that finance owns, express them as a matrix of roles, enforce segregation of duties, and guard the timing so approval happens before the commitment rather than after the invoice. Do those four things and the trail holds up to a SOX audit and feeds a clean three-way match downstream. If manual routing is the bottleneck, look at how purchase order automation software handles it. On cost, published industry estimates put the fully loaded cost of processing a single purchase order in the range of tens of dollars to over a hundred, depending on how manual the process is. Treat that as a rough benchmark, not a precise fact.