# Blanket Purchase Order: How Releases Work

> A blanket purchase order commits to a total quantity over a period, drawn down by releases. See how call-offs work, with a worked drawdown example.

<QuickAnswer>
A blanket purchase order commits to a total quantity or value with a supplier over a set period, at agreed pricing. You do not receive it all at once. Instead you issue releases, also called call-offs, against the blanket as you need stock. Each release becomes a live order that consumes part of the committed total.
</QuickAnswer>

**A blanket purchase order is a single agreement covering a total quantity or dollar value over a period, and you draw against it with releases each time you actually need stock.** Instead of cutting a fresh PO every week for the same item at the same price, you negotiate one blanket, lock the pricing, and call off deliveries as demand comes. It cuts paperwork, holds your price steady across the term, and gives the supplier a demand signal to plan against.

The catch that trips people up is availability. A blanket commits you on paper, but the committed quantity usually does not touch inventory or promised-order availability until you release against it. Confuse the blanket total with real, orderable stock and your planning goes sideways.

This guide explains how releases work, how a blanket differs from a standing order and a scheduling agreement, how the major ERPs model each one, and where blankets fit in the wider [procure-to-pay process](/blog/procure-to-pay-process).

## How Blanket PO Releases Work

**A release, or call-off, is the transaction that converts part of a blanket's committed quantity into a live, deliverable order.** The blanket is the umbrella agreement. The release is the actual order for a specific quantity on a specific date.

The flow works like this:

1. **Negotiate the blanket.** You agree a total, say 12,000 units over 12 months at $8 each, and issue the blanket purchase order to the supplier.
2. **Release as needed.** Each month you issue a call-off for the quantity you need, say 1,000 units. That release references the blanket and draws down the remaining balance.
3. **Receive and match.** The released quantity ships, you record the goods receipt, and the supplier invoices against it. The [three-way match](/blog/three-way-match) runs on the release, not the blanket total.
4. **Track the balance.** Each release reduces the open quantity on the blanket until the total is consumed or the term ends.

The important mechanic is availability. Microsoft's own Business Central documentation states plainly that "quantities entered on a blanket order don't affect item availability," and the **Make Order** action is what converts a blanket line into a live order that does ([Microsoft Learn blanket purchase orders](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-how-to-create-blanket-sales-orders)). Until you make that release, the blanket quantity is a commitment, not stock you can promise to a customer.

## A Release Drawdown in Practice

**A drawdown ledger is the simplest way to see how releases consume a blanket.** Take a 12-month blanket for 12,000 units of packaging film at $8.00, issued January 2. Each release can travel to the supplier as its own [EDI 850 purchase order](/guides/edi/850-purchase-order) referencing the blanket number:

| Release | Date | Quantity released | Open balance remaining |
|---|---|---|---|
| (Blanket issued) | Jan 2 | 0 | 12,000 |
| REL-001 | Jan 20 | 2,000 | 10,000 |
| REL-002 | Mar 14 | 3,500 | 6,500 |
| REL-003 | Jun 9 | 2,500 | 4,000 |
| REL-004 | Sep 1 | 3,000 | 1,000 |
| REL-005 | Nov 17 | 1,000 | 0 |

Each release is a real order: it ships, gets received, and gets invoiced on its own. When the balance hits zero, or the term expires with balance left, you have a decision. If demand continues, renegotiate a new blanket while your consumption history strengthens your hand on price. If the need was temporary, cover any remainder with a spot PO at market price. Do not let releases keep going out against an expired agreement, because the supplier is then free to fill them at whatever price they choose.

## Blanket Order vs Standing Order vs Scheduling Agreement

These three arrangements all cover repeat buying, and they get used interchangeably even though they behave differently. Here is the distinction.

| Type | How it works | Delivery trigger |
|---|---|---|
| **Blanket order** | Draws against a negotiated total quantity or value | Manual releases (call-offs) as needed |
| **Standing order** | Fixed recurring quantity on a set template | Automatic on a fixed schedule |
| **Scheduling agreement** | A blanket with the delivery schedule built in | Schedule lines, often fed by EDI |

A **blanket order** commits to a total and lets you release against it flexibly, when and how much you decide within the agreed ceiling. A **standing order** is a fixed recurring order, the same 200 cases every week on a template, with no fresh decision each cycle. A **scheduling agreement** is a blanket with the delivery schedule embedded: the buyer publishes forecast and firm schedule lines, fed in automotive and high-volume manufacturing by the [EDI 830 planning schedule](/guides/edi/830-planning-schedule). If your releases and schedules travel over EDI, validate the 830 and 850 files with our [free EDI Inspector](/edi-inspector) before they reach the supplier.

For the full three-way comparison, see [scheduling agreement vs blanket order](/blog/scheduling-agreement-vs-blanket-order).

## How the Major ERPs Model Blanket Orders

The concept is standard, but each ERP names and structures it differently.

- **JD Edwards.** Blanket orders use order types SB (blanket sales order) and OB (blanket purchase order). You enter the blanket, then generate releases against it that flow into the standard order process ([Oracle JD Edwards procurement documentation](https://docs.oracle.com/en/applications/jd-edwards/)).
- **SAP.** SAP models the concept as a framework order, document type "FO," for value-limit purchasing, and as scheduling agreements when the delivery schedule is embedded and driven by releases ([SAP purchasing help](https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE)).
- **Microsoft Dynamics 365 Business Central.** Blanket purchase orders are a native document type, with the Make Order action converting a blanket line into a live purchase order ([Microsoft Learn blanket orders](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-how-to-create-blanket-sales-orders)).
- **Odoo.** Blanket orders live under Purchase Agreements, where you define the agreement, the products, and the negotiated pricing, then create purchase orders from it as needed ([Odoo purchase agreements documentation](https://www.odoo.com/documentation/17.0/applications/inventory_and_mrp/purchase.html)).

Four different labels, one shared mechanic: a negotiated agreement up front, releases drawn against it over time.

## Where Blanket Orders Fit in Procurement

Blanket orders solve a specific problem: repeat purchasing of the same items at a stable price without generating a mountain of individual POs. They belong wherever demand is predictable but not perfectly scheduled, MRO supplies, packaging, ingredients, components you consume steadily.

The benefits are concrete. You lock pricing for the term, so a mid-year cost increase does not hit you. You cut administrative overhead, because one blanket replaces dozens of standalone POs. And you give the supplier a forecast to plan against, which usually earns you better pricing and availability.

The risk is losing track of releases. Because the blanket total does not consume availability until released, it is easy to over-commit downstream if your systems do not tie releases back to the agreement. That is where [purchase order automation](/blog/purchase-order-automation) earns its keep, generating each release, tracking the remaining balance, and posting receipts against the right blanket line automatically.

Connect it through [ERP integration](/erp-integration) and every call-off, receipt, and invoice reconciles without manual tracking.

## Frequently Asked Questions

### What is a blanket purchase order?

It is one negotiated agreement that covers many future deliveries: a committed total quantity or value, a locked price, and a validity period, typically a year. The individual releases against it are the actual orders. Buyers use blankets for items with steady, predictable demand, like MRO supplies, packaging, and ingredients, where cutting a fresh PO for every delivery adds cost without adding control.

### What is a release or call-off against a blanket order?

A release, or call-off, is the transaction that converts part of a blanket's committed quantity into a live, deliverable order. The blanket is the overall agreement; the release is the specific order for a quantity on a date. Each release draws down the remaining balance on the blanket until the total is consumed.

### Does a blanket order affect inventory availability?

Usually not until you release against it. Microsoft's Business Central documentation states that quantities on a blanket order do not affect item availability. The committed total is an agreement, not orderable stock. Only when you issue a release does the quantity become a live order that affects availability.

### What is the difference between a blanket order and a standing order?

A blanket order commits to a total quantity and lets you issue releases flexibly as you need stock. A standing order is a fixed recurring order, the same quantity on the same schedule, delivered automatically without a fresh decision each cycle. Blanket orders are demand-driven; standing orders run on a set template.

### What is a scheduling agreement?

A scheduling agreement is a blanket order with the delivery schedule built into it. Instead of issuing ad-hoc releases, the buyer publishes forecast and firm schedule lines that the supplier ships against. In high-volume manufacturing these schedules are often fed electronically by the EDI 830 planning schedule and EDI 862 shipping schedule.
