Online Purchase Requisition Approval Process Guide

Your controller is chasing approvals in Outlook. Department heads are forwarding PDFs. Purchasing can't tell whether a request is approved, merely acknowledged, or sitting in someone's inbox while month-end closes in. Then the auditor asks for support, and finance spends hours reconstructing who approved what, when, and under which budget.

That's the point where most companies say they need a better form. They don't. They need a better online purchase requisition approval process.

The issue isn't just speed. It's control before a purchase order exists. If you run multiple entities, manage restricted funds, or need clean audit evidence, the approval design matters more than the intake screen. A weak design turns your ERP into a faster version of the same mess. A disciplined design gives finance real visibility, enforces budget ownership, and leaves a usable trail when someone asks why a purchase was approved, held, split, or consolidated.

Table of Contents

• Why Your Current Requisition Process Is Costing You Control
  • Email approvals hide the decisions that matter
  • Digitizing the form is not enough
  • Control starts before the PO exists
• Mapping Your Requisition to Purchase Order Workflow
  • Map the flow from intake to PO release
  • Approve, hold, split, or consolidate
  • The map should expose failure points
• Defining Roles Thresholds and Segregation of Duties
  • Role design should follow control objectives
  • Thresholds should go beyond amount
  • Segregation of duties should be visible in the record
• Configuring Automation and Fund Controls in Your ERP
  • Configure rules around accounting outcomes, not just approval clicks
  • Treat fund restrictions as routing logic
  • Build exception handling into the workflow from day one
  • Audit evidence should be created by the process itself
• Testing Rollout and Measuring What Matters
  • Pilot the ugly cases first
  • Benchmarks are useful only if you apply them to control design
  • Measure control quality, not click activity
  • Tune after go-live
• Summary
• Frequently Asked Questions
  • When should we hold a requisition for consolidation instead of approving it straight to a PO
  • Should approval thresholds be based only on dollar amount
  • How should segregation of duties work in a requisition process
  • What audit evidence should the system capture
  • How do we know if the new process is actually working
• Additional External Resources

Why Your Current Requisition Process Is Costing You Control

Quarter-end is closing. A program director approves a purchase by email. Procurement treats it as ready. Finance finds out later that the cost belongs partly to another entity, partly to a restricted fund, and partly to an unrestricted department budget. Now someone has to reverse the coding, explain the exception, and rebuild the approval trail for the auditor.

That is not an approval problem. It is a control design failure.

Email approvals hide the decisions that matter

The weakness in a manual requisition process is not convenience. It is the lack of clear evidence around three separate decisions. Should the purchase happen at all. Who owns the budget. Should the request be held, split, or consolidated before a purchase order is created.

Email, chat, and spreadsheets blur those decisions together. The result is predictable:

• Budget ownership gets checked too late: The requester and vendor move ahead before finance confirms the right entity, department, project, or fund.
• Approvers sign off on different things: A manager approves need. Procurement assumes budget is covered. Finance assumes policy was reviewed. No one owns the full approval record.
• Audit evidence is weak: Forwarded messages and screenshots do not give you a clean sequence of submission, review, budget clearance, exception handling, and final approval.
• Multi-entity and nonprofit rules get bypassed: Requests that should be split by entity or funding source often move through as one request because the process does not force that decision early.

If you want a practical reference point for why purchasing discipline matters before payment, Lucentive's guide to the benefits of a purchase order system is a useful companion read. For a broader control lens, the Institute of Internal Auditors outlines why approval evidence and accountability matter in its guidance on internal controls.

Practical rule: If finance cannot show who approved the need, who cleared the budget, and why a request was held, split, or consolidated, control is already broken.

Digitizing the form is not enough

A web form alone will not fix this. It only gives you a cleaner front door.

Control improves when the online purchase requisition approval process forces the right accounting decision before anyone commits the business. That matters even more if you run multiple entities, use grants or donor-restricted funds, or need clear support for auditors. In those environments, the requisition is where finance decides whether one request should remain intact, be separated for funding control, or be grouped for operational efficiency.

CFOs should treat requisition approval as part of the close process, not an admin workflow. If the approval record is vague at the requisition stage, the mess shows up later in purchasing, AP, entity reporting, and audit prep. The National Council of Nonprofits also provides useful context on internal controls for nonprofits, especially for teams managing restricted funds and delegated authority.

Control starts before the PO exists

Companies outgrow informal approval habits long before they admit it. Growth adds entities, locations, fund restrictions, projects, and exception requests. The old habit of "manager approved it, so keep going" stops working.

Set the rules in advance. Move standard requests straight through. Hold requests that need budget review or funding clarification. Split requests when different entities, grants, or budget owners need separate approval. Consolidate only after those controls are satisfied.

That is the difference between faster paperwork and real governance. An online process should produce clean audit evidence and better consolidation decisions, not just replace PDFs with clicks.

Mapping Your Requisition to Purchase Order Workflow

Before you configure anything, map the path from request to purchase order. Not the policy document. The actual flow your people follow today.

Many teams discover that approval is treated as the finish line. It isn't. Approved requisition lines may still be held for manual processing and later consolidated into purchase orders, which is why workflow mapping needs to capture what happens after approval, not just before it, as documented in Microsoft's overview of purchase requisitions in Dynamics 365.

Map the flow from intake to PO release

Do this in one working session with finance, procurement, and two or three department owners. Keep it operational. Whiteboard the path using real recent requests.

Capture these points:

1. Where requests start
   Email, spreadsheet, form, procurement portal, or AP workaround. If intake is fragmented, approvals will be fragmented too.

2. Who reviews first
   This is often a manager, but in some companies it's a budget owner or project lead. Write down the role, not just the person.

3. What happens after approval
   Does the request convert directly to a PO, sit in a buyer queue, or wait to be grouped with similar lines?

4. Where splitting occurs
   Multi-entity and nonprofit organizations often need to break one request into separate budget owners, funds, or locations.

5. Where consolidation makes sense
   If several approved lines should roll into one PO for supplier efficiency or better oversight, define that point explicitly.

For finance leaders evaluating systems that support requisition-driven purchasing, Lucentive's overview of Sage Intacct Purchasing shows the business structure to aim for. The Chartered Institute of Procurement and Supply also offers a useful baseline for procurement process and workflow discipline.

Approve, hold, split, or consolidate

This is the decision point most companies miss. They configure “approve or reject” and stop there.

That's too simplistic for decentralized organizations. Some requests should be approved immediately because the budget owner, entity, and purpose are clear. Others should be held after approval so purchasing can consolidate lines into a single vendor order. Some should be split before PO creation because one request touches multiple departments or restricted funding sources.

Approval should confirm that a request is valid. It doesn't always mean the request should become a purchase order immediately.

The map should expose failure points

When you finish the map, look for these patterns:

• Duplicate approvals: Two people are checking the same thing.
• Missing ownership: No one clearly owns budget validation.
• Late exceptions: Restricted fund or entity issues appear only after approval.
• PO bottlenecks: Approved requests pile up because buyers still need to reinterpret what the approvers meant.

If your workflow map doesn't show who can hold a requisition, who can split it, and what triggers consolidation, it's incomplete. That's where control leaks out of the process.

Defining Roles Thresholds and Segregation of Duties

A requisition for software hits the system Friday afternoon. It charges one entity, draws from a restricted grant, and includes both annual licenses and implementation services. If one manager can approve that alone, you do not have a control framework. You have a fast path to rework, exceptions, and weak audit evidence.

Decision rights need to reflect how money is governed in your organization. Separate the approval of business need, budget ownership, purchasing authority, and receipt. If you combine those decisions, you lose visibility into who approved what, which entity owns the spend, and whether restricted funds were checked before commitment.

Role design should follow control objectives

Public-sector procurement policy gets this right because it separates requester, approver, buyer, receiver, and certifier in its guidance on iProcurement governance and segregation of duties. The labels vary by organization. The control principle does not.

Use a model that assigns one control question to one accountable role.

That structure matters most in multi-entity and nonprofit environments. One requisition can be valid operationally and still be wrong financially. If the spend touches more than one entity, grant, or donor restriction, route those checks to the people who own those boundaries. The Association of Certified Fraud Examiners also reinforces this in its practical overview of segregation of duties and fraud risk.

Thresholds should go beyond amount

Dollar thresholds are too blunt.

They catch approval authority. They do not catch cross-entity charging, restricted funding, capitalizable spend, technology risk, or vendor compliance issues. A good approval design uses amount as one trigger, not the only trigger.

Set thresholds and routing conditions around the risks that create audit findings or month-end cleanup:

• Amount-based triggers for delegated financial authority
• Entity-based triggers when a requisition allocates cost across legal entities
• Fund or grant triggers when restricted money, release conditions, or donor limits apply
• Category-based triggers for IT, capital purchases, regulated items, or contract-backed services
• Exception triggers when coding is incomplete, the budget line is overspent, or the vendor is not approved

This is also where you decide whether to hold, split, or consolidate a requisition after approval. Hold approved requests when purchasing should combine demand into one vendor order. Split them before PO creation when one request spans multiple funds or entities that need distinct approvals and audit support. Consolidate only when the accounting treatment and approval evidence remain clean.

Segregation of duties should be visible in the record

An approval chain is only useful if an auditor can follow it without interviews.

The requester should never be the final approver. The buyer should not approve a requisition they created. The person confirming receipt should not also certify the accounting outcome. One practical guide to purchase approval workflow makes the same point in operational terms: approval steps should be sequential, self-approval should be blocked, and each action should be recorded with user identity, timestamp, and comments.

That record needs to show more than who clicked approve. It should show why the requisition was routed, whether it was held for consolidation, whether lines were split by entity or fund, and who authorized each exception. That is the evidence CFOs need during audits, grant reviews, and intercompany scrutiny.

If your team needs help translating policy into role design and approval logic, an experienced Sage Intacct consultant for approval workflow design can usually identify weak segregation, bad threshold logic, and missing audit evidence quickly.

Configuring Automation and Fund Controls in Your ERP

A controller approves a requisition for office equipment. Two days later, AP learns one line belongs to a restricted grant, another belongs to a different entity, and the vendor should have received one consolidated PO. Now finance is cleaning up coding, reworking approvals, and explaining the trail to auditors. That is not a form problem. It is a configuration failure.

Your ERP should enforce the policy decisions your team already made about holding, splitting, and consolidating demand. If it does not, buyers and AP staff will make those decisions manually under pressure, and they will make them inconsistently.

Configure rules around accounting outcomes, not just approval clicks

Start with the conditions that change accounting treatment or audit evidence. Amount thresholds matter, but they are not the whole design. Entity, fund, natural account, spend category, location, grant restriction, and vendor type usually matter more because they determine who owns the spend, whether the request can be combined, and what support finance will need later.

Set your workflow to answer four questions before a buyer touches the request:

• Can this requisition proceed as submitted?
• Should it be held for later consolidation into one vendor order?
• Must it be split by entity, fund, or budget owner before PO creation?
• Does it require an exception path with finance review?

If those answers are not system-driven, your team does not have a controlled process. You have a polite request queue. APQC's process framework is also a helpful reference for thinking about standardized procure-to-pay controls.

Treat fund restrictions as routing logic

Restricted funding needs first-class treatment in the workflow. In nonprofits, healthcare, and multi-entity groups, the ERP should evaluate the funding source at submission, not at invoice entry and not after the PO is already out the door.

Configure the system to:

• Validate eligible funding sources early
• Route each line to the actual budget or fund owner
• Block or reroute lines that violate grant or donor restrictions
• Keep line-level coding and approval history intact
• Allow one line to move forward while another line waits, if policy allows it

Many teams get the design wrong. They approve the requisition as one document because it is convenient, then try to repair the accounting later. That creates weak audit support and avoidable rework. If one request spans multiple funds or entities, split it before PO creation unless the approval record remains clear and the accounting treatment stays clean. For grant-funded organizations, the National Council of Nonprofits provides a practical overview of restricted funds and financial stewardship.

Build exception handling into the workflow from day one

Stalled approvals are a design issue. So are budget failures, inactive approvers, and restricted-fund conflicts.

Set the workflow to respond predictably:

Do not leave these cases to email and judgment calls. The whole point of the ERP is to make the right path automatic and the exception path visible.

Audit evidence should be created by the process itself

CFOs do not need a prettier approval screen. They need a record an auditor can follow without interviews.

Your ERP should retain who approved, why the requisition was routed that way, whether any lines were held for consolidation, whether the request was split by entity or fund, what exception was raised, and who released it. Comments, timestamps, user identity, rule-trigger history, and status changes should all sit in the transaction record.

That matters downstream too. Requisition control only works if AP inherits a clean trail into invoice and payment processing. Teams aligning front-end approvals with disbursement controls should review how that handoff works in Sage Intacct accounts payable workflows. For a broader governance benchmark, COSO's overview of internal control is still the framework many finance teams use to judge whether approval evidence is complete and reliable.

Software does not solve this on its own. A capable ERP can still produce bad control if the configuration only mirrors org charts and ignores consolidation rules, fund restrictions, and audit evidence. In Sage Intacct projects, that design work usually determines whether the approval process reduces risk or just moves the same confusion into a new screen.

Testing Rollout and Measuring What Matters

On Monday, a program manager submits a valid request. By Friday, finance is still sorting out whether it should be split by entity, held for vendor consolidation, or stopped because the funding source does not allow the purchase. If your pilot does not catch that before go-live, the ERP will only speed up bad decisions.

Test with real spending patterns, not tidy demos. Pull actual requisitions from departments that buy differently. Include shared services, grant-funded requests, multi-entity charges, routine replenishment, and one-off purchases that create policy tension. The goal is not to prove the workflow works on clean requests. The goal is to prove it produces the right control outcome when the request creates consolidation, funding, or audit questions.

Pilot the ugly cases first

Start with scenarios that force the process to make a decision finance can defend later:

• One requisition with lines that belong to different entities
• One request that mixes unrestricted and restricted funding
• One purchase that should be approved but held until it can be consolidated into a larger PO
• One request that must be split because different budget owners or fund owners need separate accountability
• One request that stalls because an approver is unavailable
• One request that should be rejected for missing support or policy failure

This is the standard I use with CFOs. If buyers, AP, and auditors would answer “what should have happened here?” differently, the design is not ready.

Benchmarks are useful only if you apply them to control design

Use the benchmark table as context, not as a target sheet. Lower handling cost and higher touchless rates matter, but they are side effects of disciplined routing. They do not tell you whether your process preserves fund restrictions, prevents cross-entity confusion, or leaves enough evidence for audit review.

A fast requisition flow that consolidates the wrong lines, skips a restricted-fund check, or buries release decisions in email is a control failure. Treat efficiency metrics as secondary to rule accuracy. Get the hold, split, and consolidation logic right first. Speed follows.

Here's a practical scorecard finance leaders can use.

Measure control quality, not click activity

Do not send the steering committee a dashboard full of approvals completed, emails sent, or reminders triggered. Those numbers do not tell a CFO whether the process is protecting the organization.

Track the few measures that expose weak design:

1. Cycle time from submission to approved status
   Delays usually point to bad thresholds, the wrong approver role, or too many stops.

2. Manual touches after approval
   If purchasing keeps fixing approved requisitions, your workflow is approving incomplete decisions.

3. Exceptions by root cause
   Wrong entity, wrong fund, missing documentation, inactive approver, policy mismatch, duplicate request.

4. Hold and split outcomes
   How often did the system hold for consolidation, split for ownership, or release with an exception, and were those outcomes correct?

5. Audit retrieval time
   Pull a sample and see how long it takes to produce the full story, including approvals, comments, rule triggers, holds, releases, and changes.

One more point. Rollout failure usually comes from behavior, not configuration. Department leaders need to understand why a valid request may be delayed for consolidation or separated because of fund restrictions. That adoption work is part of control design. Lucentive outlines the practical side of that in its guidance on ERP change management. PMI also offers a broader view of organizational change management that can help frame rollout planning.

Tune after go-live

The first month will expose weak spots. Good. That is where the design work finishes.

Review exception logs every week at first. Remove approvals that add no control. Tighten rules where staff still bypass the system. Fix routing that confuses entity ownership, fund accountability, or PO grouping.

The standard is simple. Finance should be able to explain why a requisition was approved, held, split, consolidated, or stopped without interviewing three employees after the fact.

Summary

An effective online purchase requisition approval process does more than replace email with a form. It starts by mapping the full path from request to purchase order, including when approved lines should be held, split, or consolidated. It assigns clear roles, thresholds, and segregation of duties so budget ownership and purchasing authority don't blur together. It then translates those rules into ERP automation with budget checks, escalation paths, fund controls, and audit logging. The payoff comes when the rollout is tested with real exceptions, not just clean scenarios, and tuned after go-live.

Frequently Asked Questions

When should we hold a requisition for consolidation instead of approving it straight to a PO

Hold the requisition when approval is clear but PO timing is not. The trigger is usually purchasing efficiency or control, not uncertainty about the business need. If several approved requests will go to the same supplier, buyer review should happen before the ERP creates separate POs that fragment spend, receipts, and matching.

Example: three approved office supply lines from different departments can sit in a weekly hold queue, then roll into one PO to the same vendor. You cut duplicate orders, keep a cleaner audit trail, and make accruals easier at month-end.

For multi-entity or nonprofit teams, use holds even more deliberately. If one request includes lines funded by unrestricted operations and another includes grant-funded lines for the same supplier, do not consolidate by default. Hold them until purchasing confirms whether the lines should stay separate for reporting and compliance, or whether they can be grouped without breaking fund restrictions.

Should approval thresholds be based only on dollar amount

No. Dollar amount is the weakest approval rule when used alone because many purchasing problems start with coding, restrictions, or contract terms, not spend size.

Use amount with other routing conditions that reflect actual risk. A low-dollar software renewal may need legal or IT review. A mid-range purchase charged to a restricted grant may need program approval even if it sits below the CFO threshold. A routine replenishment order might bypass extra review at a higher amount if the supplier, item class, and budget are already controlled.

Example: a $2,500 laptop request should route differently from a $2,500 catering request. Same amount. Different policy, asset treatment, and downstream audit questions.

How should segregation of duties work in a requisition process

Build duties around decisions, not job titles. One person defines the need. Another confirms budget ownership. Purchasing converts approved demand into a PO or sourcing event. Receiving or the requesting department confirms delivery. Finance reviews invoice coding and payment support.

That split matters most in lean teams where people wear multiple hats. If your controller can request, approve, create the PO, receive it, and release the payment, the workflow looks efficient but the control is weak.

Example: in a small nonprofit, the development director can request event materials, the program or department budget owner can approve the spend, operations can issue the PO, and finance can process the invoice only after receipt is documented. You still move quickly, but one person never controls the full transaction.

What audit evidence should the system capture

Capture the decision and the context behind it. Auditor questions rarely stop at who clicked approve. They usually move to why this route was used, why lines were split, why a hold was applied, and whether restricted funds were checked before the PO was issued.

Store approver name, date, time, comments, and the exact coding at the time of approval. Keep the full history of edits, reroutes, hold reasons, budget check results, consolidation actions, and any override with the person who authorized it.

Example: if one requisition starts with five lines and purchasing splits two grant-funded lines into a separate PO, the system should show the original request, the split decision, the revised coding, and both approval paths. That record saves finance from assembling screenshots during an audit.

How do we know if the new process is actually working

Check whether approved requisitions arrive at purchasing ready to act. If buyers still fix coding, separate restricted lines, or chase missing approvals after the workflow says approved, your design is still pushing control work downstream.

Measure three things. Time from submission to final approval. Time from final approval to PO creation. The share of requisitions touched manually after approval because of coding errors, fund issues, or supplier consolidation decisions.

Run a monthly sample review too. Pull ten completed requisitions across departments, entities, and funds. If your team cannot explain each approval path and produce the full record in minutes, the process needs more work.

If your team has outgrown QuickBooks or you're evaluating Sage Intacct for stronger purchasing control, Lucentive can help you design the approval logic before you lock in the workflow. Schedule a practical working session through Lucentive to review your requisition-to-PO process, fund restrictions, and audit requirements so you can see what fits your company before you buy software alone.

Additional External Resources

If you want to compare your process design against broader procurement and internal control guidance, these references are worth reviewing:

• The Chartered Institute of Procurement and Supply explains core purchasing controls and governance in its guidance on procurement and supply policies.
• The Association of Certified Fraud Examiners offers practical context on why approval controls and separation of duties matter in its resource on internal controls.
• The Committee of Sponsoring Organizations of the Treadway Commission provides the control framework many finance teams use as a benchmark through its overview of internal control.
• For public company finance teams, the U.S. Securities and Exchange Commission outlines management responsibility for controls in its page on internal control over financial reporting.
• The Government Finance Officers Association shares policy-level recommendations that are useful for decentralized organizations in its best practice on purchasing card programs and expenditure controls.
• The U.S. Small Business Administration provides a straightforward reference on formalizing purchasing practices in its guide to buying and inventory management.
• APQC provides a broader process benchmark for procure-to-pay teams through its Process Classification Framework.
• The AICPA offers additional context on governance, evidence, and financial oversight in its resource center for internal control.
• NIST is useful when requisition approvals intersect with software, access, or vendor risk, especially its guidance on security and privacy controls.