SAP Purchase Requisition Workflow Configuration: A Procurement Manager’s Practical Guide

TL;DR

SAP purchase requisition workflow configuration should begin with a documented approval policy, not with a list of approvers copied into the system. Decide whether approvals happen at header or item level, define thresholds and exception routes, identify which changes should restart approval, and establish a default workflow so no requisition is stranded. In SAP S/4HANA, flexible workflow supports condition-based, one-step, and multistep approvals through the Manage Workflows for Purchase Requisitions app. The strongest design also defines what happens before approval: when a competitive RFQ is required, how supplier quotes are collected, and what evidence reaches the approver. SAP can remain the system of record while AuraVMS manages the RFQ cycle, giving approvers a clearer quote comparison and a defensible sourcing record.

1. Define the operating model before configuring SAP

A purchase requisition workflow is a control system. Its job is not merely to move a document from one inbox to another. It must ensure that the right person reviews the right purchase, with enough evidence to make a decision, without adding avoidable delay.

That distinction matters because many teams begin SAP purchase requisition workflow configuration by recreating an existing email chain. They add the requester’s manager, a finance approver, and a procurement approver, then assume the process is complete. The result is a digital version of the same ambiguity: approvers do not know what they are validating, procurement receives incomplete requirements, and urgent requests bypass the workflow.

Start with five operating decisions.

1. What creates a purchase requisition? Define whether requisitions originate from employees, MRP, maintenance, projects, catalogs, or professional buyers. Different origins may require different checks.
2. What is approved? Decide whether approval applies to the whole requisition or to individual items. A mixed requisition containing office supplies, capital equipment, and a regulated service may not belong in one approval path.
3. Who owns each decision? Budget owners validate affordability, procurement validates sourcing policy, technical owners validate specifications, and risk or legal teams validate special exposure. Avoid asking every approver to approve everything.
4. What evidence is mandatory? Specify the business justification, account assignment, supplier recommendation, quote comparison, contract reference, and exception approval needed at each threshold.
5. What happens after approval? Define whether the requisition proceeds to source assignment, RFQ, contract call-off, purchase order creation, or rejection and rework.

A useful workflow charter can fit on one page.

The threshold values above are examples, not universal policy. Your thresholds should reflect delegation of authority, category risk, local regulation, and the cost of review. A $5,000 IT subscription can carry more data and renewal risk than a $20,000 catalog order from an approved supplier.

Procurement should own the design even if an SAP configuration expert implements it. The business team understands why a route exists; the configuration team understands how to express it safely. Both are required.

2. Build an approval matrix that SAP can execute

An approval matrix converts policy into deterministic routing. If two experienced buyers can read the policy and reach different conclusions, SAP will not rescue it. The rules must be mutually understandable, testable, and ordered.

Use dimensions that can be reliably populated on the requisition. Common dimensions include:

• Total net amount
• Company code
• Purchasing organization
• Purchasing group
• Plant
• Material group
• Account assignment category
• Cost center or project
• Document type
• Currency
• Requisition source
• Requested delivery date

Do not use every available field. Each condition increases the number of combinations to test and maintain. Choose the smallest set that reflects real approval authority.

Here is a practical approval matrix for a mid-sized company.

Three design rules prevent most failures.

First, separate approval authority from consultation. A cybersecurity specialist may need to review a software purchase, but that does not automatically make the specialist the budget approver. Use distinct steps or supporting reviews so accountability stays clear.

Second, avoid overlapping start conditions unless the workflow order is deliberate. SAP evaluates active workflows according to their defined order and uses the first matching start conditions. A specific capital-spend workflow should therefore appear before a broad workflow that matches all requests above a value threshold. Keep a documented priority table outside the system so administrators understand why the order exists.

Third, create a default workflow. SAP documentation notes that an active default automatic-approval workflow can handle requisitions when no other start condition matches. If you define a custom default, place it at the end of the workflow order. For strong control environments, the safer default is often manual procurement review rather than silent automatic approval.

Header-level approval works well when all items share one business purpose, budget, category, and sourcing decision. Item-level approval is better when a requisition mixes categories, plants, account assignments, or delivery requirements. The operational cost is that item-level routing can create split outcomes. Define whether approved items may continue while rejected items return to the requester.

Also decide how currencies are treated. A threshold expressed in one currency must behave predictably when requisitions are raised in another. Confirm which exchange-rate date and company-code currency SAP uses in your environment, then include boundary-value tests around each threshold.

3. Configure the flexible workflow step by step

The exact screens and available conditions depend on your SAP S/4HANA edition, release, activated scope, document types, and business roles. Validate the procedure against the documentation for your installed release. The sequence below is the business-safe pattern for flexible workflow configuration, not a substitute for change control in your SAP landscape.

Step 1: Confirm prerequisites and roles

Verify that flexible workflow is available and activated for the relevant purchase requisition document types. SAP’s current guidance identifies NB and NBS as common default document types in SAP S/4HANA Cloud Public Edition, with different default approval behavior. Your environment may be configured differently.

Confirm access to the configuration environment and the Manage Workflows for Purchase Requisitions app. The implementation team should also confirm approver master data, business users, responsibility definitions, teams, and substitutions. A technically correct workflow still fails if the recipient cannot be determined.

Step 2: Choose overall or item-level release

Select the workflow scenario that matches the approved operating model. Overall release approves the requisition at header level. Item-level release evaluates and approves individual requisition items.

Do not choose overall release merely because it looks simpler. If one requisition can contain items owned by different cost centers or categories, overall approval may give one manager authority over spend they do not own. Conversely, item-level approval for homogeneous requisitions can create needless work items.

Step 3: Name and describe the workflow

Use a naming convention that communicates scope and priority. For example:

PR | India Operations | Capex | Above INR 2,000,000 | v1

The description should state the policy reference, owner, effective date, and intended position in the workflow order. Avoid names such as “New PR Workflow” or “Test 2.” They become production archaeology within months.

Step 4: Define start preconditions

Translate the approval matrix into start conditions. Begin with the most specific workflows: regulatory exceptions, capital purchases, single-source cases, or restricted categories. Then add value-based standard routes. Finish with the default route.

Test each condition against three cases: one that must match, one that must not match, and one at the exact boundary. If the route is “above $25,000,” explicitly test $25,000 and $25,000.01. Ambiguous boundary language creates control gaps.

Step 5: Add approval steps

For each step, define:

• Step type and purpose
• Step preconditions
• Recipient determination
• Approval order
• Required action on rejection
• Deadline and escalation behavior, where supported
• Notifications

Use roles or responsibility-based determination where the business ownership changes frequently. Hard-coded individual users are acceptable only for stable, narrowly scoped exceptions and should have a named maintenance owner.

Keep the number of sequential steps under control. A five-step route where everyone performs the same superficial review is weaker than a three-step route with distinct responsibilities and complete evidence. Measure approval time per step after launch and remove checks that do not change decisions.

Step 6: Configure exceptions and outcomes

Define what happens if an approver rejects, requests rework, is unavailable, or cannot be determined. Include substitutions for leave and escalation for overdue tasks. Decide whether rejection ends the requisition or returns it to the requester for correction.

The workflow should produce a clear audit trail: who acted, when, on which version, and with what comment. Require meaningful rejection comments. “Rejected” is not enough for the requester or an auditor.

Step 7: Activate and order workflows

SAP’s workflow guidance warns that an activated workflow cannot simply be edited as though it were still a draft; the safe pattern is to deactivate it and create or activate a revised definition according to your release behavior. Treat activation as a controlled deployment.

After activation, define workflow order carefully. Put narrow exception routes before broad standard routes, and the default workflow last. Record the order in the change ticket and test that only the intended workflow starts.

For official product-specific details, consult SAP Help Portal documentation for “How to Configure the Flexible Workflow for Purchase Requisitions” and “Flexible Workflow.” Those sources should govern edition- and release-specific behavior.

4. Control restarts, exceptions, and urgent changes

Approval is valid only for the facts the approver reviewed. If a requester increases the quantity after approval, changes the account assignment, replaces the material group, or substitutes a supplier, the original decision may no longer be defensible.

Define a restart policy before go-live. SAP provides configuration options, and in some environments extensibility, for controlling which field changes restart flexible workflow. Procurement must decide the business rule; the SAP team must map it to supported fields and behavior.

Use a risk-based restart matrix.

Avoid two extremes. Restarting on every minor edit creates approval fatigue and encourages users to delay corrections. Restarting on almost nothing lets a requisition mutate after approval. Use materiality thresholds and controlled fields.

Emergency purchasing needs its own route, not a verbal promise to “approve later.” Require an emergency reason code, named operational owner, maximum value, restricted duration, and retrospective review. Track emergency use by requester and department. If the same category repeatedly appears as urgent, the root problem may be planning, inventory policy, or supplier performance.

Single-source exceptions also deserve a dedicated workflow. The approver should see why competition is impractical, how price reasonableness was assessed, how long the exception remains valid, and what action will restore competition. A single-source label without evidence is not a control.

Approver absence is another predictable exception. Maintain substitutions with start and end dates. Do not share credentials or route all leave coverage to one senior executive. Monitor recipient-determination failures and overdue work items daily during the first weeks after deployment.

5. Connect requisition approval to the RFQ and sourcing process

The purchase requisition workflow answers, “May we buy this?” Competitive sourcing answers, “From whom, at what commercial terms, and based on what comparison?” Treating those as the same decision creates a blind spot.

For some categories, a requisition can reference an existing contract or catalog and move directly toward purchase order creation. For competitive purchases, procurement needs an RFQ stage either before final approval or between initial demand approval and final supplier commitment.

A strong end-to-end pattern is:

1. The requester submits need, specification, delivery date, and account assignment.
2. The budget owner approves the business need.
3. Procurement determines the sourcing route.
4. Suppliers receive a consistent RFQ.
5. Quotes are collected and normalized.
6. Procurement documents the recommendation and exceptions.
7. The final approver reviews the requisition with the sourcing evidence.
8. The approved outcome proceeds to purchase order or contract execution.

Email and spreadsheets can support a small volume, but they break down when buyers chase multiple suppliers, compare nonstandard quote formats, or reconstruct a decision for audit. AuraVMS gives procurement teams a dedicated RFQ workspace while allowing suppliers to respond without creating an account. It supports anonymous bidding, which can reduce supplier anchoring and protect commercial fairness during the event.

The integration does not have to begin as a large SAP project. Use a controlled reference pattern first:

• Create a requisition or sourcing request identifier.
• Use that identifier in the RFQ workspace.
• Collect supplier responses and compare quotes in one place.
• Export or link the award summary and supporting evidence.
• Attach the summary to the SAP requisition or record its reference.
• Require the approver to confirm that the sourcing evidence matches the requested scope.

This keeps SAP as the financial and procurement system of record while AuraVMS handles the supplier-facing quote cycle. The approach is especially useful for SMB and mid-market procurement teams that need stronger RFQ discipline without implementing a broad source-to-pay suite.

Design the evidence pack around the approval decision. It should include the invited suppliers, response status, normalized prices, freight and tax treatment, lead times, payment terms, technical compliance, evaluation method, selected supplier, and any deviation from policy. A structured RFQ workspace can shorten the administrative collection cycle, but procurement still owns the commercial judgment.

Do not attach a spreadsheet with unexplained colored cells. Include a concise recommendation that states the decision, alternatives considered, quantified trade-offs, and residual risk. An approver should understand the choice in two minutes and be able to inspect the underlying quotes if needed.

Where the requisition changes after an RFQ, decide whether the event must be reopened. A material quantity or specification change can invalidate every supplier response. Link the RFQ version to the requisition version so approval never relies on stale evidence.

The product angle must also match the workflow stage. AuraVMS is not a replacement for SAP purchase requisition accounting, budget control, or purchase order processing. It solves the narrower problem of requesting, collecting, and comparing supplier quotes. That clarity makes adoption easier: buyers gain speed, approvers gain evidence, and finance keeps the existing system of record.

6. Test, deploy, govern, and measure the workflow

Workflow testing must prove routing and control, not merely confirm that a notification appeared. Build a scenario pack directly from the approval matrix.

At minimum, test:

• Every document type in scope
• Header-level and item-level behavior where applicable
• Each value threshold, including exact boundaries
• Each company code, purchasing organization, and currency in scope
• Each account assignment and restricted material group
• Automatic, one-step, and multistep routes
• Default workflow behavior
• Approver substitution and unavailable recipient handling
• Rejection, rework, withdrawal, and resubmission
• Material field changes that should restart approval
• Minor field changes that should not restart approval
• RFQ evidence attachment or reference
• Mobile and My Inbox approval behavior used by real approvers
• Audit-log completeness

Use production-like master data and representative roles in a non-production environment. Ask business users to execute the test, not just observe a consultant. Procurement should sign off on the routing outcome; internal controls or finance should sign off on authority and evidence requirements.

For deployment, use a short period of heightened monitoring. Publish the new policy, train requesters on required information, train approvers on their specific responsibility, and give procurement a triage route for stuck requisitions. Do not teach users to memorize workflow logic. Teach them what complete demand and defensible approval look like.

Track operational and control metrics together.

Governance should include a named process owner, technical owner, quarterly rule review, change log, test evidence, and versioned approval matrix. Review thresholds when the delegation-of-authority policy changes, the organization restructures, or currency movement makes old limits unreasonable.

Also review whether approvers are adding value. If an approval step almost never rejects, requests changes, or records a meaningful comment, it may be ceremonial. Remove or redesign it. More approvals do not automatically mean more control.

For the RFQ portion, compare supplier response rate, quote turnaround time, number of compliant bids, and award variance. A digital workflow is most valuable when those measures replace anecdotal claims that “email works fine.” A measured pilot on one category can establish the baseline before broader rollout.

Finally, protect the audit trail. Keep policy versions, workflow versions, test results, production changes, approval records, exception evidence, and sourcing comparisons according to retention requirements. The workflow is not complete when the button works; it is complete when the organization can explain a purchase months later.

7. Frequently asked questions

What is SAP purchase requisition workflow configuration?

It is the setup of rules that determine when a purchase requisition requires approval, which workflow applies, who receives each approval step, what sequence is followed, and how exceptions are handled. In SAP S/4HANA flexible workflow, configuration commonly combines activation for relevant document types with workflow definitions in the Manage Workflows for Purchase Requisitions app.

Should we use header-level or item-level approval?

Use header-level approval when all items share one coherent business purpose, ownership, risk profile, and sourcing route. Use item-level approval when requisition lines may belong to different categories, cost centers, plants, or approvers. The choice should follow accountability, not administrative convenience.

What happens if no workflow condition matches?

SAP can use an active default workflow when no other start condition matches, depending on your configuration. Define and test that default deliberately. Place a custom default at the end of the workflow order. For controlled procurement, an unmatched requisition should not become an invisible bypass.

Which changes should restart purchase requisition approval?

Changes that can alter authority, budget ownership, sourcing rationale, risk, or supplier selection should usually restart approval. Common examples include amount, quantity, account assignment, material group, supplier, and material scope. Minor text corrections may not require a restart. Document the rule and test every configured field.

How many approval levels should a purchase requisition have?

Use the fewest levels needed to assign distinct, meaningful decisions. A typical route may include a budget owner, procurement, and finance or executive approval for higher-risk spend. Avoid sequential steps where multiple people perform the same review. Measure whether each level changes outcomes.

Does SAP flexible workflow manage supplier RFQs?

Flexible workflow manages approval routing for procurement documents; it does not by itself solve every supplier quote collection and comparison task. AuraVMS can manage the supplier-facing RFQ process, then provide a comparison and award record for the SAP requisition approval. The systems serve complementary roles.

Can we implement the RFQ handoff without a full SAP integration?

Yes. Begin with a controlled reference number and evidence attachment pattern. Use the SAP requisition identifier in the RFQ workspace, run the event, export the comparison or award summary, and attach or reference it in the requisition. Automate the exchange later only when volume and measured savings justify the integration cost.

How should we test SAP purchase requisition workflow configuration?

Build tests from the approval matrix. Cover positive, negative, boundary, exception, rejection, substitution, restart, and default-route cases. Use realistic roles and master data. Business owners should validate the decision path while the SAP team validates technical behavior.

How can procurement reduce approval delays without weakening control?

Improve requisition completeness, use responsibility-based recipient determination, remove duplicate approvals, define substitutions, set risk-based thresholds, and supply approvers with a concise evidence pack. For competitive buys, AuraVMS can reduce the time spent chasing and normalizing supplier quotes before the approval reaches SAP.

What does AuraVMS cost?

AuraVMS starts at $5/month. Suppliers can respond without signing up, which removes a common source of friction in small and mid-market RFQ events.

SAP purchase requisition workflow configuration creates the strongest control when it connects policy, approval authority, sourcing evidence, and measurable cycle time. Configure SAP to govern the requisition and use a focused RFQ process to strengthen the commercial decision behind it.

Run your next competitive RFQ in hours, give approvers a cleaner quote comparison, and keep SAP as your system of record. Start with AuraVMS at $5/month: https://www.auravms.com