Per-Line vs Collective Approval in Procurement — Choosing the Right Topology
Published: April 14, 2026
A department submits a purchase requisition with 10 line items. Nine are standard supplies that everyone agrees on. The tenth is a piece of equipment that the approver has questions about — the specification seems wrong, the quantity seems high, or the budget allocation is unclear. In most procurement systems, the approver has two choices: approve all 10 lines (including the questionable one) or reject the entire requisition (blocking the 9 items that are needed immediately).
This is a common source of procurement delays. The approver does not want to approve something they have concerns about. But they also do not want to delay the 9 items that are clearly needed. So they approve everything — and the governance purpose of the approval step is undermined. Or they reject everything — and the requester resubmits the same 9 items in a new requisition, wasting time for both parties.
This article explains two approval topologies that address this problem differently, and how they interact with PO creation modes to give organisations flexibility in how requisitions flow through the procurement cycle.
1. The Problem: One Bad Line Blocks the Entire Requisition
All-or-nothing approval is the default in most procurement workflows. The approver sees a requisition and can either approve it or reject it — as a whole. This creates predictable problems:
- Delayed procurement. Nine needed items wait while one item is debated. The debate may take days. The items that were needed last week are still waiting.
- Governance compromise. Approvers learn to approve everything to avoid being the bottleneck. The approval step becomes a formality — stamp it through, deal with problems later.
- Resubmission overhead. After rejection, the requester removes the problematic line and resubmits. The same 9 items go through the same approval chain again. The approver reviews items they already approved last time.
- Split-and-resubmit workarounds. Requesters learn to submit separate requisitions for each item to avoid the blocking problem. This defeats the purpose of multi-line requisitions and creates document sprawl.
2. LINE_LEVEL Topology — Independent Line Approval
In LINE_LEVEL topology, each line on a requisition has its own approval status. The approver can approve Line 1, approve Line 2, reject Line 3, and approve Line 4 — all in the same action. Each line progresses through the approval chain independently.
The practical effect:
- A 10-line requisition can have 9 lines approved and 1 rejected
- The approved lines proceed to PO creation without waiting for the rejected line
- The requester can address the rejected line separately — revise the specification, provide justification, or simply accept the rejection
- The approval chain tracks each line's status independently — who approved it, who rejected it, and when
LINE_LEVEL is the default topology. It provides the most granular control and prevents the one-bad-line-blocks-everything problem.
When an approver rejects a line in LINE_LEVEL topology, they must provide remarks explaining the rejection. These remarks are recorded against the specific line, not against the requisition as a whole. This means the requester knows exactly which item was objected to and why — not just that "the requisition was rejected."
3. COLLECTIVE Topology — All-or-Nothing Approval
In COLLECTIVE topology, all lines on a requisition are treated as a single unit. The approver approves or rejects the entire requisition — there is no option to approve some lines and reject others. Line-level approval endpoints return a 403 error in this mode.
This sounds like the problem described above — so why would anyone choose it? COLLECTIVE is appropriate when the lines are interdependent:
- Bundled requirements. A classroom setup requires desks, chairs, a projector, and a screen. Approving desks but rejecting the projector does not make sense — the items are needed as a set.
- Uniform batches. A requisition for 50 identical lab kits. There is no meaningful distinction between lines — either the batch is approved or it is not.
- Simplified workflow. For small, straightforward requisitions (2-3 lines of similar items), COLLECTIVE reduces the approver's decision to a single action rather than per-line evaluation.
4. PO Progression Modes — COMBINED vs INDIVIDUAL
Approval topology determines how lines are approved. PO progression mode determines when approved lines can become purchase orders. These are independent settings:
| Mode | Rule | When to Use |
|---|---|---|
| COMBINED | All lines must reach a final status (approved or rejected) before any PO can be created | When the PO should cover the complete requisition |
| INDIVIDUAL | Approved lines can be converted to POs independently, without waiting for remaining lines | When some items are urgent and others can wait |
The interaction between topology and progression creates four combinations:
| Topology | Progression | Behaviour |
|---|---|---|
| LINE_LEVEL | COMBINED | Each line approved independently, but PO waits until all lines are resolved |
| LINE_LEVEL | INDIVIDUAL | Each line approved independently, approved lines can create POs immediately |
| COLLECTIVE | COMBINED | All lines approved/rejected together, PO created after approval |
| COLLECTIVE | INDIVIDUAL | All lines approved/rejected together — INDIVIDUAL has no practical effect since lines move as a unit |
The most flexible combination is LINE_LEVEL + INDIVIDUAL: each line is evaluated on its own merit, and approved lines do not wait for pending or rejected lines before PO creation.
5. Choosing the Right Topology
The choice depends on the nature of the requisition, not on a global preference:
- Mixed requisitions (different categories, different urgencies, different vendors) — LINE_LEVEL with INDIVIDUAL progression. This gives maximum flexibility.
- Bundled requirements (interdependent items that must be procured together) — COLLECTIVE with COMBINED progression. This ensures the package is evaluated as a whole.
- Standard procurement (similar items, similar urgency, same vendor likely) — LINE_LEVEL with COMBINED progression. Line-level granularity at approval, but a single PO covering everything.
The topology is set at the requisition level, not at the organisation level. Different requisitions can use different topologies depending on what is being procured.
6. Bypass PO Mode
Some requisitions do not need a purchase order — internal transfers, expense claims, or items procured through petty cash. The bypass PO flag on a requisition allows it to skip the PO step entirely: once approved, the requisition moves directly to the posting stage without creating a purchase order.
This interacts with topology in a straightforward way: the approval topology (LINE_LEVEL or COLLECTIVE) controls how the requisition is approved. The bypass PO flag controls what happens after approval. Both settings are independent — a LINE_LEVEL requisition can bypass PO, and a COLLECTIVE requisition can bypass PO.
7. How This Works Across PR, PO, and GRN
The approval topology applies at the purchase requisition stage. The downstream effects flow through the document chain:
- PR Stage: Topology determines whether lines are approved independently (LINE_LEVEL) or as a unit (COLLECTIVE).
- PO Stage: Progression mode determines when approved lines can become POs. In INDIVIDUAL mode, a single PR might produce multiple POs. Each PO has its own approval chain.
- GRN Stage: Each PO has its own goods receipt sequence. If a PR produced three POs (via INDIVIDUAL mode), each PO is received independently — the GRN for PO-1 does not depend on PO-2 or PO-3.
The result is a document chain that adapts to the organisation's operational needs: tight coupling when items are interdependent, loose coupling when they are not.
8. Frequently Asked Questions
Can the approval topology be changed after a requisition is submitted?
No. The topology is set at creation and locked at submission. Once submitted, the approval chain has been seeded based on the selected mode — LINE_LEVEL seeds per-line statuses, COLLECTIVE seeds at the header level. Switching after submission would invalidate existing approval records. If a different topology is needed, the requisition must be rejected or cancelled and recreated with the correct setting. This is a deliberate governance constraint: the rules of approval are fixed before the first approver acts.
What happens if one line is rejected in LINE_LEVEL topology?
In LINE_LEVEL topology, each line is independent. If an approver rejects one line, only that line moves to REJECTED status. The remaining lines continue through the approval chain unaffected. A requisition with 10 lines might end up with 9 approved and 1 rejected. The approved lines can proceed to PO creation depending on the progression mode, while the rejected line is excluded. The approver can approve the items they agree with and reject only the specific item they object to, with remarks explaining the rejection.
How does INDIVIDUAL PO progression mode create multiple purchase orders?
In INDIVIDUAL mode, each approved line can be converted to a PO independently without waiting for all lines to be approved. If a 10-line requisition has 7 lines approved and 3 still pending, the 7 approved lines can be grouped into one or more POs immediately. The remaining 3 can be converted later when approved. This creates multiple POs from a single requisition, each traceable back to the original PR. INDIVIDUAL mode is useful when some items are urgent, or when different lines go to different vendors. COMBINED mode requires all lines to reach a final status first.
When should COLLECTIVE topology be used instead of LINE_LEVEL?
COLLECTIVE topology is appropriate when the lines on a requisition are interdependent — approving some but rejecting others would not make practical sense. A classroom setup requiring desks, chairs, a projector, and a screen is a package deal. COLLECTIVE ensures the approver evaluates the requisition as a whole. It is also simpler for requisitions where all items are of similar nature and value — a batch of identical items, for instance, where line-level granularity adds complexity without benefit. The approver makes one decision for the entire requisition.
Does the approval topology affect how GRN works?
The approval topology applies at the PR stage. By the time goods are received, the PR has been approved and a PO issued. The GRN workflow has its own approval chain at the GRN level. However, the topology's downstream effect is felt through PO creation. In LINE_LEVEL with INDIVIDUAL progression, a PR might produce multiple POs covering different approved lines, and each PO gets its own GRN. In COLLECTIVE with COMBINED progression, one PR produces one PO with one GRN sequence. The topology shapes the document chain, which in turn shapes goods receipt structure.