Multi-Level Purchase Approval Workflows — Configuring Procurement Governance

Published: April 10, 2026

In most growing organisations, procurement starts informally. Someone sends a WhatsApp message to the manager: "Need to buy 50 chairs for the new office." The manager replies "ok." The admin team places the order, the invoice arrives, the accountant books it, and the chairs appear in the office. No one questions the process because it works — until it does not.

The problems emerge gradually. A department head approves a Rs 3 lakh purchase that should have required the CFO's sign-off. An employee raises the same purchase request twice and both get approved. A vendor is paid for goods that were never received because no one verified delivery against the order. The annual audit reveals that 40% of purchases have no documented approval trail.

This article explains how structured approval workflows address these problems — how an approval matrix routes requisitions to the right approvers, how multi-level chains enforce authority limits, and how the approval pattern cascades through the full procurement cycle from purchase requisition to purchase order to goods receipt.

1. The Problem — Informal Approvals Leave No Trail

Informal approval systems — email threads, WhatsApp messages, verbal confirmations — share common weaknesses:

• No authority limits: There is no systematic way to ensure that a Rs 5 lakh purchase is approved by someone with the authority to approve amounts of that magnitude. A department head may approve purchases that, per policy, require the CFO's approval.
• No audit trail: When the auditor asks "who approved this purchase?", the answer is a WhatsApp message that may or may not still exist on someone's phone. This does not satisfy the requirements of Section 143 of the Companies Act or CARO 2020 for documented internal financial controls.
• No segregation of duties: The same person who raises the purchase request can approve it. Without system-enforced segregation, the control exists only on paper.
• No visibility: Management has no dashboard showing how many purchases are pending approval, how long they have been waiting, or what the total committed value is. Procurement is a black box until the invoices arrive.
• No consistency: Similar purchases from different departments follow different approval paths because there is no documented routing logic. The engineering department's laptop purchases go through three levels of approval; the marketing department's identical laptop purchases get approved by a single manager.

2. The Approval Matrix — Rules That Route Requisitions

An approval matrix is a set of configured rules that map the characteristics of a purchase to a chain of approvers. The matrix answers the question: "Given this type of purchase, from this department, at this amount, who needs to approve it?"

2.1 Dimensions

Each approval rule is defined across several dimensions:

Dimension	What It Controls	Example
Department	Which department raised the request	"Engineering" or "Marketing" or "Any"
Classification	What type of asset or expense is being purchased	"IT_EQUIPMENT", "FURNITURE", "STATIONERY"
Location	Which site or campus the purchase is for	"Bangalore HQ", "Mumbai Office"
Amount Limit	Maximum value covered by this rule	Rs 50,000, Rs 5,00,000, Rs 50,00,000
Document Type	PR, PO, or GRN	Different approval chains for different document types
Requisition Type	Procurement, Expense, Write-Off, etc.	Asset removals may require different approvers than purchases

2.2 Approval Codes

Rules are grouped into named codes. Each code represents a complete approval chain — one or more levels of approvers that must act in sequence. For example:

• Code: "IT-LOW" — IT Equipment, up to Rs 50,000. One level: Department Manager.
• Code: "IT-HIGH" — IT Equipment, up to Rs 5,00,000. Two levels: Department Manager (Level 1), then CFO (Level 2).
• Code: "CAPEX-MAJOR" — Any classification, above Rs 5,00,000. Three levels: Department Manager (Level 1), CFO (Level 2), then MD (Level 3).

Within a code, all rows share the same governance version, document type, requisition type, and amount limit. Each approver within a code is unique — no person can appear twice in the same chain. Levels are contiguous, starting at 1.

3. How Routing Works

When a purchase requisition is submitted, the routing engine evaluates it against the approval matrix to determine the correct approval chain.

3.1 The Matching Process

1. Extract dimensions: The system reads the requisition's department, classification, location, amount, document type, and requisition type.
2. Filter candidates: All active approval codes that match the requisition's dimensions are identified. A code matches if its dimension values either match exactly or are set to "Any" (wildcard).
3. Score specificity: Among matching codes, the system ranks by specificity — a code that matches on department + classification + location is more specific than one that matches on department + "Any" + "Any".
4. Apply amount banding: Among codes with the same specificity score, the one with the lowest amount limit that still covers the requisition amount is selected. This ensures the tightest-fit authority band.
5. Select winner: The highest-specificity, tightest-amount code becomes the routing decision. All rows of that code — representing all levels of the approval chain — are seeded as the requisition's approval workflow.

3.2 Fallback Chain

If no exact match is found for the requisition type, the system falls back through a hierarchy:

1. Exact type (e.g., Write-Off)
2. Generic asset removal type (covers all removal requisitions)
3. Procurement (general catch-all)
4. Any (universal fallback)

This fallback chain ensures that every requisition gets routed, even if a specific rule for that exact combination of dimensions has not been configured. The trade-off is intentional: it is better to route a requisition to a general approval chain than to block it entirely because no rule matches.

Routing is computed once, at the moment of submission. Once the approval workflow is seeded, it is not recomputed — even if the approval matrix is updated later. This ensures that a requisition in progress is not retroactively rerouted, which would create confusion and audit issues.

4. Multi-Level Approvals — Sequential, Enforced

When an approval chain has multiple levels, the system enforces strict sequencing:

• Level 1 must complete before Level 2 can act. If Level 1 has multiple approvers (e.g., two department managers who share approval responsibility), all of them must complete their actions before Level 2 is activated.
• Rejection is allowed at any level. An approver at Level 1 can reject a requisition without waiting for other Level 1 approvers to act. Rejection is immediate and terminal — a rejected requisition cannot be approved by a higher level.
• Each action is recorded. When an approver approves or rejects a line, the system records the approver's identity, timestamp, and any remarks. This creates the audit trail that statutory auditors require.

The level enforcement prevents a common governance failure: a senior approver rubber-stamping a requisition before the operational-level approver has reviewed it. In a structured system, the CFO cannot approve a purchase before the department manager has reviewed and approved it.

5. Per-Line vs Collective Approval

A single purchase requisition may contain multiple line items — 10 laptops, 5 printers, and 20 headsets, for example. The approval topology determines how these lines are treated during the approval process:

5.1 LINE_LEVEL (Default)

Each line item is approved or rejected independently. An approver can approve the laptops, reject the printers, and approve the headsets — all within the same requisition. Each line carries its own status (PENDING, APPROVED, REJECTED) and progresses through the approval chain independently.

This is the more flexible option and is suitable when different items in a requisition may have different justifications, urgency levels, or budget implications.

5.2 COLLECTIVE

All line items are treated as a single unit. The approver either approves the entire requisition or rejects it. There is no option to approve some lines and reject others. Line-level approval endpoints return an error if attempted on a collective requisition.

This is appropriate when the items are interdependent — for example, a server and its associated networking equipment that are only useful together.

6. PO Progression Modes

Once a requisition is approved (fully or partially), the next step is creating a purchase order. The PO progression mode controls when this can happen:

6.1 COMBINED

All lines in the requisition must be approved before a PO can be created. This ensures the PO reflects the full approved scope. If some lines are still pending or have been rejected, PO creation is blocked.

6.2 INDIVIDUAL

A PO can be created with only the approved lines. If 8 out of 10 lines are approved and 2 are still pending, a PO can proceed with the 8 approved lines. The remaining 2 can be included in a subsequent PO once approved.

This mode is valuable for time-sensitive procurement where delaying the entire order for one or two pending lines is not practical.

7. Authority Projection — Telling Users What They Can Do

A common usability problem in approval systems is ambiguity: the user sees a requisition but does not know whether they can approve it, whether they need to wait for someone else to act first, or why the approve button is greyed out.

Authority projection solves this by computing, for each user and each document, exactly what actions they are allowed to take — and why.

When a user views a requisition, PO, or GRN, the system evaluates:

• Is this user in the approval chain for this document?
• If yes, at which level?
• Has the previous level completed?
• Has this user already acted on this document?

The result is a clear signal: "You can approve this", "You can reject this", "Waiting for Level 1 approval", or "You have already approved this at Level 1." The frontend renders the appropriate buttons based on this signal — it never makes its own access decisions.

8. Cascading to PO and GRN

The approval pattern does not end with the purchase requisition. It extends through the full procurement lifecycle:

8.1 Purchase Order Approval

When a PO is created from an approved PR and submitted for approval, the routing engine evaluates the PO against the approval matrix — using the same dimension-based matching but for the PO document type. The PO may route to different approvers than the PR, depending on how the matrix is configured. This provides a second layer of governance: the person who approved the purchase concept (PR) may not be the same person who approves the commercial commitment (PO).

8.2 GRN Approval

When goods are received and a GRN is submitted, it follows its own approval chain. GRN approval confirms that the goods were physically received, inspected, and accepted. This is typically handled by the stores or quality team, separate from the procurement and finance approvers who handled the PR and PO.

8.3 Service Acceptance

For service-type purchase orders (consulting, maintenance, professional services), the equivalent of a GRN is a service acceptance. Service acceptance follows its own approval routing — the person who confirms that a consulting engagement was satisfactorily completed may be the project manager, not the procurement officer.

Each document type — PR, PO, GRN, SA — has its own approval tables and snapshot history. They are never mixed. This ensures that the audit trail for each document type is self-contained and independently verifiable.

The cascading approval pattern serves a fundamental governance purpose: it ensures that no single person can unilaterally commit the organisation to a purchase. The requisitioner raises the need, the manager approves the concept, the procurement team selects the vendor and agrees terms (PO), and the stores team confirms receipt (GRN). Each step is independently approved and independently auditable.

9. Frequently Asked Questions

What is a purchase requisition multi-level approval workflow?

A multi-level approval workflow routes a purchase requisition through two or more approvers in sequence — typically department head, finance controller, and CFO — gated by authority limits and document type. Each level must act before the next can see the document. Routing is enforced by configured rules, not by email threads, with an audit trail at every step.

What is an approval matrix in procurement?

An approval matrix is a set of rules that determines who must approve a purchase requisition, purchase order, or goods receipt based on the characteristics of the request. The matrix maps combinations of dimensions — department, asset classification, location, amount, and document type — to a chain of approvers at specified levels. When a requisition is submitted, the system matches it against the matrix to find the best-fit rule and seeds the approval chain accordingly. This replaces informal email-based approvals with a structured, auditable process.

Can different items in one requisition route to different approvers?

It depends on the approval topology configured for the requisition. In LINE_LEVEL mode (the default), each line item is evaluated independently — different items can route to different approvers based on their individual dimensions (classification, amount, location). In COLLECTIVE mode, all line items in the requisition are treated as a unit and route to the same approval chain. The topology is set when the requisition is created and cannot be changed after submission.

How are approval limits configured?

Approval limits are configured as amount thresholds in the approval matrix. Each approval code can specify an amount limit. When a requisition line's value falls within a particular range, the system selects the approval code whose amount limit is the tightest fit — the lowest limit that still covers the line's value. For example, if there are codes for amounts up to Rs 50,000 (one-level approval) and up to Rs 5,00,000 (two-level approval), a requisition for Rs 75,000 would match the Rs 5,00,000 code and require two levels of approval.

What happens if the approver is unavailable?

The system does not currently support automatic delegation or re-routing when an approver is unavailable. A pending approval remains with the assigned approver until they act on it. The organisation can monitor pending approvals through the dashboard — items awaiting approval are visible to administrators and can be escalated manually. SLA tracking per approval level helps identify bottlenecks: if a level has a configured SLA of 2 days and the approval is still pending after 3 days, it is flagged for attention.

Is the approval history preserved for audit?

Yes. Every approval action — approve, reject — is recorded with the approver's identity, timestamp, and any remarks provided. The approval chain is versioned through snapshot groups: if routing changes (for example, during the transition from source to receiving department in a MOVEMENT requisition), the previous snapshot is superseded and a new one is created. Both snapshots are retained. Auditors can trace the complete approval history of any document from submission through each level of approval to final status.