Purchase requisition

The purchase requisition captures demand before any supplier commitment. Requesters specify items or services, quantities, needed-by dates, ship-to locations, and accounting codes. Procurement uses the PR to verify policy, source from contract or catalog, and convert approved demand into a purchase order.

Unlike a PO, a requisition is not legally binding on a vendor. It is an internal control that ensures spend is authorized, budgeted, and routed to the right buyer. ERP systems assign PR numbers (for example PR-7003) and track status from draft through approval, sourcing, and PO creation.

Strong requisitions include a clear description (not just a part nickname), preferred supplier if known, estimated unit price, capital vs expense indicator, and project or cost center. Attachments might be quotes, statements of work, or safety data sheets.

For catalog items, the PR should reference the contracted SKU so the buyer does not renegotiate price on every request. For one-off services, the PR should state acceptance criteria so receiving and AP know when the obligation is fulfilled.

Approval chains depend on amount, category, and department. A laptop under a delegated limit might need only a manager; capital equipment might need finance and IT security. Policy checks include preferred supplier rules, blocked vendors, sole-source justification, and export control flags.

When approvals stall, root causes are usually missing budget codes, vague descriptions, or wrong commodity codes. Intake automation can pre-fill catalog lines, flag policy violations early, and route to the correct approver based on org rules.

Once approved, the buyer converts the PR to a PO, carrying over lines and prices. Any change in supplier or price after approval should be visible on the audit trail. Partial fulfillment splits one PR across multiple POs when deliveries are staggered.

Metrics teams watch PR-to-PO cycle time and rejection rates to tune catalogs and training. Shorter, cleaner requisitions generally mean faster sourcing and fewer invoice exceptions later.

Standardize free-text fields with minimum description length and required commodity codes before routing. Embed catalog search in the requisition screen so requesters see contracted price while typing.

Track rejection reasons to fix training gaps versus policy gaps. Connect approved requisitions to sourcing queues when no contract exists instead of letting buyers work from email threads.

Review metrics quarterly with procurement, finance, and business owners who feel process pain—adjust rules when data shows a control is cosmetic or a bottleneck is upstream.

Internal audit samples purchase requisitions by tracing transactions from requisition or contract through payment, looking for missing evidence and override patterns. Findings are usually systemic—stale catalogs, receivers not trained, or tolerances set too wide—rather than one rogue approver. Remediation plans should name a process owner outside AP when the root cause is upstream.

Leading indicators for purchase requisitions include open exceptions, unposted receipts, contracts past notice windows, and classification backlog; lagging indicators include paid-after-due volume, duplicate hits, and price variance dollars. Review the same dashboard weekly with procurement during a transformation, not only at quarter close, so fixes land before suppliers escalate.

Pilot changes to purchase requisitions on one company code or region with documented before-and-after samples on the same supplier mix. Parallel-run old and new rules until match or classification variances fall below an agreed threshold, then cut over with a rollback plan. Executive sponsors should see cycle time and touch-per-document, not only license go-live dates.

Technology helps purchase requisitions only when master data, contracts, and receiving discipline keep pace. Budget for content stewardship—catalog updates, clause playbooks, screening lists—alongside software. Tie savings claims to redirected spend, captured discounts, and avoided overbill with line-level examples auditors can reproduce.

Stakeholder alignment matters: publish a one-page RACI for purchase requisitions that names who sets policy, who operates the process, and who approves exceptions. Exception approvals should expire automatically after 90 days unless renewed with business justification, preventing "temporary" tolerances from becoming permanent holes in control.

Training should use live examples from your ERP, not generic slides—walk receivers and buyers through one held document and show which fields they can change to clear purchase requisitions issues. Reinforce that fixing upstream data beats overriding match or approval rules downstream, because overrides rarely scale across thousands of transactions per month.