A blanket PO is not the procurement act. It is the framework that authorizes future procurement acts. The actual spending happens through releases, also called call offs, against the blanket.
Release workflow is often where blanket PO governance fails. The blanket gets approved with substantial diligence, then releases against it route through lightweight or informal processes because the heavy approval happened upstream. The cumulative effect is significant spend moving through controls that would not be acceptable for the same amounts as standalone POs.
Designing release workflows that match the risk and value of each release, while still capturing the efficiency benefit of the blanket structure, is the practical challenge.
What a Release Is
A release is a specific order placed against an active blanket PO. It identifies which blanket it is calling off against, what items or services are being ordered, the quantity, the delivery requirement, and the value of the order.
The release consumes some portion of the blanket's available limit. Multiple releases over time progressively exhaust the limit until the blanket reaches its validity end or its limit is fully committed.
In ERP terms, releases are typically created as PO lines or as child POs linked to the parent blanket. The exact mechanics vary by system, but the concept is the same: a transactional order that draws from a standing authorization.
Who Can Request a Release
Release authority should be explicit and limited. The default failure mode is allowing anyone in a requesting department to call off against the blanket, which effectively distributes spending authority broadly without any approval trail.
Named release requestors
For each blanket, a small set of named individuals should be authorized to initiate releases. Typically these are department managers, project leads, or designated procurement coordinators within the business unit.
The roster is documented as part of the blanket setup and reviewed annually. People who leave the role lose release authority; new people in the role gain it through a defined update process.
Release size limits per requestor
Individual requestors may have their own release size limits within the broader blanket. A junior coordinator might be authorized for releases up to $5K; a department head for up to $25K; releases above $25K require additional authorization regardless of blanket headroom.
These tiered limits prevent the blanket structure from creating implicit unlimited spend authority for any single individual.
Approval Routing on Releases
The approval workflow on a release should be lighter than a standalone PO of the same value, but not absent. The blanket has been pre approved at the structural level. The release approval focuses on whether this specific call off is consistent with the intent of the blanket.
Low value releases (below department threshold)
Below a defined threshold (often $5K to $10K), releases can be system approved automatically, provided they meet basic criteria: within the blanket scope, against an active blanket with sufficient headroom, from an authorized requestor. No manual approval needed.
Medium value releases
Mid range releases route to the requestor's manager or to a designated approver in the business unit. The approval is confirming that this release is intended and appropriate, not redoing the upstream procurement analysis.
High value releases
Releases above a defined threshold should route to a procurement reviewer or to finance, depending on the value and the company's segregation of duties policy. The threshold should be calibrated so that high value releases get meaningful review even though they fall under an approved blanket.
Out of scope or exception releases
Releases that fall outside the blanket scope but use the blanket structure (because the requesting team thinks they are similar enough) should trigger an exception review. These are the cases where blankets quietly expand beyond their original purpose.
Documentation Per Release
Each release should generate documentation sufficient to support an audit trail. The documentation level should be lighter than a standalone PO but should still cover:
- The blanket being called off against, with reference number
- The specific items or services ordered, with quantities and unit pricing where applicable
- The delivery or service period
- The requestor and the approval chain
- The cost center or project code for accounting
- Any deviation from standard blanket pricing or terms that requires special handling
ERPs typically capture this automatically when releases are processed through the procurement module. The documentation gap shows up when releases happen outside the system (verbal orders to the supplier, emails with no PO reference) and only the invoice arrives later.
Recurring Releases and Templates
For blankets that support highly repetitive ordering (office supplies, recurring services), release templates simplify the workflow significantly.
Standing release schedules
A monthly cleaning service blanket might have a standing release of $X per month, automatically generated and approved. The approval happens once at the schedule setup; subsequent monthly releases process through the schedule without re approval.
Quick release templates
For known recurring orders that are not on a fixed schedule (a maintenance team's typical part replenishment), a template captures the common attributes. The requestor fills in only the variable elements (quantity, delivery date) and submits, dramatically reducing the time per release.
Boundaries for templates
Templates are appropriate only for releases that genuinely fit a repeating pattern. Using a template to fast track an unusual order defeats the control purpose. Templates should be reviewed annually to confirm they still reflect the actual ordering patterns.
Post Release Tracking
Once a release is approved, it consumes blanket headroom. The tracking should be updated in real time so that:
- The remaining blanket limit is current and visible to requestors before they submit the next release
- Releases that have not yet been invoiced are visible as outstanding commitments
- Releases that have been invoiced and paid show as fully closed against the blanket
- Three way matching at the invoice stage references the release, not just the blanket
The tracking is what closes the loop between authorization and actual spending. Without it, the blanket limit can be exceeded by the cumulative effect of small releases that individually looked fine, because no one was watching the running total.
Start Here
Walk through one of your active blankets and document the release workflow as it actually operates today, not as the procedure document says it should. Who initiates releases? What approval do they go through? How is the running limit tracked? Where does the documentation live?
The gap between the as designed workflow and the as operated workflow is usually the source of the control issues. Fixing the actual workflow, with named requestors and tiered approval, is the substantive change.
