Yes - treat the requisition as the internal stop point before any outside commitment. A Purchase Requisition should capture business purpose, expected cost, supplier identity, and approver decision, while the Purchase Order comes later as the supplier-facing step. Make requisitions mandatory for new suppliers and unclear requests, keep fast-path handling for repeat low-risk spend with complete prior records, and block PO creation or payout release when approval evidence is incomplete.
Requisition control matters when it answers one practical question: where must a Purchase Requisition exist before anyone commits company money, and where can you allow a faster path without losing control? The goal is not to make every purchase harder. It is to make sure higher-risk spend is authorized early, with enough detail for finance to review before a Purchase Order is issued.
A PR is an internal document used to request approval to buy goods or services. In plain terms, it captures the need, cost, and business justification so a manager, budget owner, or finance reviewer can decide whether the spend should move forward. That distinction matters. A PR authorizes spending, while a PO is the later step that commits to the purchase and is typically the external document. When a team blurs those two, it can lose the control boundary that matters inside Procure-to-Pay (P2P).
For platform teams, the hard part is not defining a PR on paper. It is making sure internal approval lines up with how requests move through the process. A request may look fine at intake, then stall later because key details are missing or unclear.
Start with one simple checkpoint before approval. Confirm the request includes the business purpose, expected cost, and enough identifying detail for reviewers to recognize the eventual purchase. If one of those fields is missing, do not treat it as a minor admin gap. It often leads to rework or approval delays later. Three operating truths shape the rest of this guide:
A PR exists for internal approval before a PO is issued. The key distinction is timing: you are deciding whether the spend should happen at all, not documenting a supplier commitment after the fact.
PR approvals can vary by amount or item type, which is how finance teams add control without forcing the same friction onto every request. If you use one approval lane for everything, you usually end up with either slow, low-risk purchases or weak review on sensitive ones.
Once submitted, a PR is routed to approvers and can be converted into a PO after approval. If the request record is thin or inconsistent, reviewers usually need extra back-and-forth before the process can move forward.
That is the lens for the rest of this guide. Keep it practical: decide where to put hard stops, where to keep a fast lane, and what evidence must exist before spend becomes real.
For a related breakdown, read How to Structure a Holdback in a Purchase Agreement.
Choose your model based on approval complexity and exception risk, not headcount. If requests already cross teams or generate disputes, formalize now. If spend is still centralized, keep controls lightweight but define clear triggers to tighten the process.
Use lightweight controls when one person or a very small group approves nearly all outbound spend. A simple Purchase Requisition record with business purpose, expected cost, vendor name, and one recorded approver is usually enough to prevent undocumented buying before it becomes a PO or payment.
Keep one visible approval gate, and make it usable for AP. If AP cannot recognize the eventual purchase from the request alone, you are already carrying avoidable rework.
Use an automated requisition flow once requests regularly pass through a manager, a Budget Owner, and finance. A purchase request is still an internal ask, and automation helps route submitted requisitions to the right approvers before external commitment.
Standardize the fields needed downstream, especially supplier identity, category, and budget context. If you enforce approved suppliers or category limits, enforce them at the request step.
If you already see duplicate requests, approval disputes, or frequent exceptions, implement a Requisition Management System before you scale payout volume. Weak request discipline is linked to maverick spending, budget overruns, and operational firefighting.
Test traceability end to end: each approved request should map to one business need and then to the final purchase or disbursement record. Reopened or recreated requests are a practical signal that controls are too loose.
Use a more formal Procure-to-Pay (P2P) model when approvals must enforce policy constraints, not only budget oversight. This is especially relevant when you must block nonapproved suppliers, enforce category limits, or support specialized requisition types in ERP workflows.
Validate fit by requisition type, not just approver count. In Oracle Self Service Procurement, internal material transfer requisitions require the Internal Material Transfers feature, and they are not supported for automated requests through FBDI Import or the Purchase Request Web Service.
For a deeper dive, read Internal Controls for Accounts Payable on Platforms: How to Prevent Fraud and Ensure Accurate Disbursements.
Treat these as two different control points: a Purchase Requisition (PR) is internal authorization, while a Purchase Order (PO) is the external supplier-facing step after approval.
| Checkpoint | Purchase Requisition | Purchase Order |
|---|---|---|
| Owner | Internal requester and approvers | Internal team issuing an order to the supplier |
| Legal effect | Internal authorization to spend | External order; may be a commitment point depending on terms |
| Required evidence | Clear request details plus approval outcome | Approved requisition, supplier details, and order terms |
| Policy compliance expectation | Show why spend should be approved | Show the approved spend was executed as ordered |
A PR requests approval before purchasing and stays internal as it routes through approval workflow. If AP or procurement still has to debate whether a request is approved, your PR record is not clear enough for downstream review.
A PO is issued after requisition approval and sent to the supplier to initiate or confirm the order. Once it leaves your organization, errors are no longer internal cleanup; they become external execution risk.
Do not issue a PO until requisition status is complete, approver identity is recorded, and the Audit Trail entry for approval exists. Keep this language consistent across AP and procurement so teams stop using "PR approved" and "PO approved" as if they mean the same thing.
Related: How Freelance Developers Use Linear to Control Scope and Billing.
Choose the operating pattern that matches your risk and policy load, not just your desired speed. There is no universal winner, but one rule is consistent: if policy complexity is high, use a risk-tiered model with Segregation of Duties (SoD) and Dual Approval rather than a single queue or fully ad hoc team approvals.
| Pattern | Best for | Key pros | Key cons | Common failure exposure | Concrete use case |
|---|---|---|---|---|---|
| Centralized AP gate | Lower-volume spend with one finance team owning review | Consistent documentation, one control point, easier verification before PO or payment | Slower cycle time, AP bottlenecks, business context can be diluted | Exception Handling backlog in AP; urgent work bypasses process | Early-stage platform where one AP lead reviews most vendor and contractor spend |
| Team-level approvals | Faster teams with simpler policy and clear budget ownership | Faster decisions, better local context, fewer handoffs | Inconsistent evidence, higher exception load, more downstream AP rework | Unauthorized purchasing risk, missing Audit Trail entries, cleanup late in AP | Product and marketing leads approve repeat purchases from pre-approved vendors |
| Risk-tiered hybrid | Mixed spend profiles and growing policy obligations | Balances speed and control by routing scrutiny where risk is higher | Requires clear routing rules, role design, and ongoing tuning | Misclassified risk tiers, incomplete escalation evidence, weak separation of roles | Platform with repeat low-risk spend plus higher-risk purchases requiring finance review |
| Fully integrated P2P orchestration | Higher scale and multi-step purchasing needing end-to-end visibility | Purchasing, approvals, invoicing, and payments in one system; less duplicate entry and fewer invoice errors | Heavier implementation effort and governance demands | Bad policy automated at scale; unresolved Exception Handling if workflow design is weak | Company connecting requisitions, PO creation, invoice matching, and payment status across finance and operations |
Stricter controls usually reduce leakage and improve consistency, but they can slow cycle time. Lighter controls move faster up front, but they often create more exceptions and rework later.
If disconnected procurement and AP steps are already causing delays, duplicate entry, errors, and weak visibility, integrated P2P workflows are often the next step. Automation can improve consistency in approvals and compliance tracking, and you can layer it onto existing systems instead of requiring full replacement. Claims like a 30-40% PR creation-time reduction should be treated as directional, not guaranteed outcomes.
Related: Internal Controls for Payment Platforms: Segregation of Duties Dual Approval and Audit Trails.
Make requisitions mandatory for new or unclear requests, and keep any fast path limited to repeat requests with complete prior records.
| Rule | When | Requirement |
|---|---|---|
| New supplier intake | Supplier is not already onboarded | Require a written requisition before PO creation or payout setup; confirm the supplier record, business purpose, expected amount, and owner |
| Minimum evidence | Any request is submitted | Keep the request in writing and complete with payee, purpose, amount, spend category, and approver |
| Fast path | Repeat spend with a pre-approved supplier and a complete prior approval record | Compare supplier identity, spend category, amount range, and approval evidence against the last approved request; if the purpose or risk profile changed, route it as a new decision |
| Escalation and stop conditions | Higher-risk requests or incomplete policy fields or supporting documentation | Route higher-risk requests to enhanced review; pause downstream processing until completed |
If a supplier is not already onboarded, require a written requisition before PO creation or payout setup. ServiceNow's supplier lifecycle docs separate an onboarding playbook from a risk assessment playbook, so treat setup and risk review as distinct checks. Verify the supplier record and required fields are complete, and confirm the request states the business purpose, expected amount, and owner.
DSCA's LOR guidance is a practical model: no single format is required, but the request must be in writing and complete. Apply the same rule internally by requiring the same core fields each time: payee, purpose, amount, spend category, and approver. If key fields are missing, keep the request in review.
Use a faster path only for repeat spend with a pre-approved supplier and a complete prior approval record. Before routing it as routine, compare against the last approved request for supplier identity, spend category, amount range, and approval evidence. If the purpose or risk profile changed, route it as a new decision.
Write if-then routing rules so AP and business teams classify requests the same way. Route higher-risk requests to an enhanced review path, and keep lower-risk requests in a lighter path only when required evidence is present. Make your local stop condition explicit: if required policy fields or supporting documentation are incomplete, pause downstream processing until completed.
Related: Best Merch Platforms for Creators Who Want Control and Compliance.
For a quick next step, try the free invoice generator.
Design approvals as a pre-spend control: route by risk signals and role responsibility so spending is authorized and tracked before a Purchase Order reaches a vendor and before money leaves the business.
Start simple with a standard lane, an enhanced-review lane, and a clear reject/escalate path.
Trigger approval based on spend threshold, category type, vendor status, and budget availability, not dollar amount alone. In practice, new vendor onboarding requests and purchases outside pre-approved vendor catalogs should move to enhanced review even when amounts are small.
Keep each Purchase Requisition complete and traceable with business justification, budget code, approver rationale, and linked Ledger Journal references when the request extends, renews, or corrects prior activity. The goal is not longer paperwork. It is enough written context that finance can verify intent and ownership without reconstructing decisions later.
Use automated approval routing to reduce manual handoffs and email chains while giving finance visibility into committed spend. Pair that with internal SLA targets, auto-escalation for aging items, and explicit Exception Handling states so requests are not all stuck as a generic "pending approval."
A practical starting model is standard review for pre-approved vendors with clear budget ownership, and enhanced review for new vendors, out-of-catalog requests, or unclear budget responsibility. Add layers only when exception data shows a recurring control gap, not because the org chart is complex.
To control spend at payout time, run one controlled path from approved requisition to payment records and reconciliation evidence.
In Procure-to-Pay, the cycle starts with a purchase requisition and ends when the supplier gets paid. Keep that sequence explicit: approved requisition, then Purchase Order when an external commitment is needed, then payment authorization and release, then reconciliation records. Check one thing at each handoff: the same internal request ID should be traceable across every step. If requests still enter through email, chat, or spreadsheets, fragmented intake can create duplicate orders and missed deadlines.
Treat retries as a control issue, not only a reliability issue. Define one business instruction per approved request and ensure technical retries replay that same instruction instead of creating a new payout action. If the underlying business instruction changes, route it back through approval before release.
Formal PO workflows are valuable because they create records finance can use for payment authorization and control. Carry that into payouts by keeping the approval record, payment record, and resulting Ledger Journal posting together in an export-ready package for AP close. A reviewer should be able to confirm who approved the spend, what was authorized, and where it landed in the ledger without reconstructing the trail manually.
As volume scales, document who owns approval, payout release, exception handling, and ledger review at each handoff. Ownership clarity is a control, not overhead: unclear boundaries are where reconciliation delays usually surface. If your ERP integrates P2P and O2C, use that shared visibility to improve exception follow-up and forecasting.
Related: How EOR Platforms Use FX Spreads to Make Money.
Tax-sensitive release checks should happen before disbursement, not after provider submission. If a payout is blocked, the requisition record should already show the decision state, reviewer, and rationale on the same internal ID used for execution and reconciliation.
Final approval alone should not auto-release funds when additional tax evidence is needed. The control only works if it sits between approval and payout release, with a clear pass/fail state recorded in the same workflow.
FEIE is conditional, not a blanket exemption. IRS guidance ties eligibility to foreign earned income, a foreign tax home, and a qualifying path such as bona fide residence or the physical presence test of 330 full days in 12 consecutive months (those qualifying days do not have to be consecutive). Even when income is excluded, it still must be reported on a U.S. tax return.
If FEIE is part of your tax handling flow, anchor decisions to the correct tax year instead of carrying forward old thresholds. IRS figures differ by year (for example, FEIE maximums and housing amount limits for 2025 vs. 2026), so your review record should capture which year's rules were applied.
For a step-by-step walkthrough, see Merchant of Record for Platforms and the Ownership Decisions That Matter.
Put the control where spend becomes real. For most platform teams, that means a Purchase Requisition must exist and be approved before anyone creates a Purchase Order or makes an outside commitment.
A requisition works because it is an internal control at the start of procurement, not a document you backfill after the fact. The point is timing: it captures what is needed and approval before external buying begins. If your team cannot say exactly which purchases require a requisition first, you can get uneven enforcement and policy drift.
Test one live spend category, such as recurring contractor tooling or a common vendor class. Verify that every request captures the need and requester before approval starts. A common failure mode is vendor contact or purchasing activity happening first, with the internal record created later just to paper over the decision.
Approval rules should reflect spend controls such as budget holder approvals or spend limits, and they can differ by amount spent or item type. The important principle is proportionality: you want enough review to stop unilateral buying and keep purchases aligned to guidelines, without sending every request through the same heavy queue.
If a request is routine and low risk, keep the path short. If it is unusual, expensive, or outside normal purchasing patterns, require a stronger approval path and complete justification. A clear red flag is when teams start bypassing the process because the approval path feels identical for a minor repeat buy and a nonstandard commitment.
The record that holds up is not just an approval stamp. It should include the approved requisition, the business justification, the final decision, and the link to the Purchase Order when one is issued. The advantage is traceability: finance and AP should be able to reconstruct why a purchase was allowed without relying on inbox searches or memory.
This is where standardized handling matters most. Standardized and automated requisition handling is associated with better transparency, fewer errors, and stronger budget oversight. Even a lighter process should still produce a clean audit trail for policy compliance. If you cannot pull one completed request and show the internal approval before the external commitment, your process is not ready to scale.
If you are refining internal purchase request controls, the next move is not a company-wide rollout. Define your mandatory triggers, document the approval differences by spend amount or item type, test them in one real category, and fix the evidence gaps before expanding.
Related reading: How to Use a Nominee Director in an Offshore Company Without Losing Control. Want to confirm what's supported for your specific country/program? Talk to Gruv.
A Purchase Requisition is an internal document used to request a purchase before anything is sent outside the company. A Purchase Order is the external document sent to a supplier to authorize or initiate the transaction. In plain terms, the requisition asks for permission to spend, while the PO carries that decision out with the vendor. For a deeper PO breakdown, see What Is a Purchase Order (PO)? And When Should Platforms Use POs for Contractor Engagements.
Require one when spend needs finance control before purchasing, especially where you need the request to capture the need, cost, and business justification in one record. That is the right default if multiple teams touch the decision or if the purchase may later become a PO. If a request cannot show who asked, why it is needed, and what it is expected to cost, it is not ready to move forward.
The minimum is clear routing to the person or team that controls your organization's finances, with approval paths that can differ by spend amount or purchase type. You do not need a large approval chain to get control, but you do need an identifiable approver and a recorded decision. A good checkpoint is simple: pick one approved PR and verify the file shows the requester, approver, business justification, and final status.
Yes, if spend is still centralized and the review path is obvious. The red flag is when lightweight handling stops giving you visibility into who approved what, or when requests start getting lost between inboxes, chat, and finance follow-up. Once that happens, a formal requisition process can reduce rework and improve visibility.
Manual requisition processes are associated with delays, unapproved spend, and poor visibility. The usual failure mode is not just slowness. It is weak visibility when finance needs to confirm why a purchase was approved. If two people are working from different spreadsheet versions, you also lose a clean handoff into the broader procure-to-pay process.
Those are system-integration details, not requisition policy requirements by themselves. For auditability, the key control is that downstream activity stays linked to the same approved Purchase Requisition, and to the related PO if one is issued.
Keep the approved Purchase Requisition itself plus the core fields it is supposed to capture: need, cost, business justification, approver identity, and final approval status. If a PO was issued after approval, retain the link between the two records because the sequence matters: PR first, PO second. The practical test is whether finance can reconstruct one purchase from request through approval without relying on memory or inbox searches.
Avery writes for operators who care about clean books: reconciliation habits, payout workflows, and the systems that prevent month-end chaos when money crosses borders.
Includes 2 external sources outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
Start here: your AP control design should reduce fraudulent disbursements and payment errors without turning every payout into a bureaucratic exercise. In practice, that means clear escalation points at the moments where money can move incorrectly, not extra approvals added just to look controlled.
A purchase order can tighten control in a contractor program. But it can also create pointless gates if it stops with procurement and never reaches billing and payout records. For platform teams, the real question is not whether a PO exists. It is whether the same record can authorize spend, support AP review, and still reconcile cleanly when money moves.
If you own payout risk, start with a short control set you can operate, verify, and defend when a payout is challenged by compliance, finance, legal, or audit. This ranked list of seven controls aims to reduce real release risk without adding approval theater. It is not a claim that seven controls are always enough.