An industrial customer signs a blanket order for 500 units of a component at a fixed price and calls the quantity off in parts over twelve months. For their purchasing department this is one transaction. For the shop it is up to twenty orders that all point to the same contract line, carry the same price and have to reduce the remaining quantity step by step. This article describes how blanket order and call-off are mapped between shop, middleware and ERP system: which data model holds up, how the remaining quantity is tracked and reserved, how a call-off is matched to the right contract, and how contract and call-off numbers find their way back into delivery note and invoice. Anyone connecting ERP and shop in wholesale decides at this point whether the online channel serves the contract or bypasses it.
Key takeaways
- In the data model a blanket order is not an order but a header with lines from which orders arise: contract quantity, contract price and term sit on the contract, the called-off quantity sits on the call-off.
- Code list UNTDID 1001 keeps the two apart: code 221 stands for the blanket order, code 226 for the call-off that provides split quantities and delivery dates referring to a previous blanket order (OpenPeppol).
- The remaining quantity per contract line is the key value. It belongs in the middleware, is derived from order and delivery events, and makes it visible when more is called off than was agreed.
- The contract price applies before the list price as long as the term covers the requested delivery date - price determination therefore needs the date, not just item and customer.
- Where no time for performance has been specified or where it is not evident from the circumstances, the obligee may demand performance immediately (Section 271 German Civil Code, Federal Ministry of Justice). A contract without a date rule shifts the risk to the supplier.
- Contract reference and purchase order reference are fields of their own in the electronic invoice (OpenPeppol) - the return path of the call-off into the document is provided for and only has to be filled.
What a blanket order means in the shop
A blanket order records which quantity a customer takes over a period and at which price. It is not an order itself: no goods move and no invoice arises as long as nothing is called off. Only the call-off - depending on the house also called release order, delivery schedule or partial call - creates an order with quantity, date and delivery address. This split is the core of the task. The shop has to know two objects that behave differently: a long-lived contract that rarely changes, and many short-lived call-offs that change daily. Pressing both into a single order form means losing either the price or the remaining quantity.
How strongly this process runs over electronic channels can be read from two figures. Almost half of manufacturing companies with e-commerce in the EU receive orders via EDI: 46.04 percent (Eurostat, EU figure for the 2024 reporting year) - blanket orders and call-offs have been arriving there by machine for years, with their own message types and their own codes. Through online shops and marketplaces, wholesalers and manufacturers in Germany turned over 509 billion euros (ECC KÖLN) in 2024. The shop is therefore not a side channel but a second door to the same contracts. If that door stands open without the contract being known behind it, orders at list price arise that order processing corrects by hand afterwards - and the customer learns to avoid the channel.
Price and quantity are negotiated
The customer has been promised a price for a total quantity and expects it with every call-off. A list price in the cart is not a cosmetic flaw at this point but the reason purchasing reaches for the phone instead of the shop.
Demand spreads over time
Production sites and construction projects call off when they need the goods. The contract covers the period, the individual call-off names the date. Every contract line therefore needs a term and every call-off a requested date.
The quantity is limited
Anything beyond the contract quantity is no longer a call-off but an order on different terms. Without a tracked remaining quantity this only surfaces when the invoice is checked in the customer's purchasing department - or when inventory sync across several warehouses hands out reserved quantities twice.
The data model: contract, line, call-off
Three levels are enough. The contract header carries contract number, customer, valid-from and valid-to dates, currency, payment terms and a status. The contract line carries item, unit of measure, contract quantity, contract price, price unit and a term of its own where it differs from the header. The call-off is an ordinary order with two additional fields per line: the contract number and the number of the contract line the quantity comes from. Everything else - delivery address, shipping method, date - belongs to the call-off, not to the contract. Anyone nailing the delivery address to the contract cannot later send a call-off to a construction site.
The question of where this data is held determines the effort. The contract arises in the ERP system, because that is where it is negotiated and released. The shop needs a read copy of it: contract quantity, price, term and remaining quantity per line, filtered to the logged-in customer. The called-off quantity, by contrast, arises in the shop and is written into the ERP system. The value therefore travels in both directions, and that is exactly what a middleware is for: it holds the remaining quantity as a tracked stock of its own and answers the question "how much may this customer still call off now?" without a synchronous call into the ERP.
The contract number belongs on the order line, not on the order header
contract_no, contract_line_no and price_source with the values contract, list and manual. The same pattern carries the search across customer part numbers in the B2B shop: the line knows where its value came from, and the document can state it later.Tracking and reserving the remaining quantity
The remaining quantity is not a stored figure you overwrite but the result of a calculation: contract quantity minus called-off quantity minus reserved quantity. The difference matters. Overwriting the value loses the history with every failed attempt and makes it impossible to reconstruct after an incident which call-off consumed which share. Deriving it from events lets you recount at any time and find deviations instead of inheriting them. Every event carries a timestamp, a quantity, a sign and the document that triggered it.
Between call-off and delivery lies a state many models overlook: the reservation. Once the customer puts a call-off in the cart and runs it through their purchasing release, the quantity is neither free nor consumed. Without a reservation a second buyer from the same customer can call off the same remaining quantity at the same time, and both orders go through. A reservation with an expiry - minutes to a few hours is common - closes that gap without blocking the contract. The same thinking sits behind the document chain of partial deliveries and part invoices: what is stored is not the end state but the path to it.
- Contract quantity - the agreed total quantity per line in the unit of measure of the contract. It changes only through a contract amendment, which is recorded as an event of its own.
- Called-off quantity - the sum of all confirmed call-offs. A cancelled call-off is reversed by a counter-event, not by overwriting the sum.
- Reserved quantity - quantities from carts and from call-offs awaiting a release. They carry an expiry and disappear by themselves if the call-off does not follow.
- Delivered quantity - the sum of the delivery events from the ERP system. It may lag behind the called-off quantity without anything being wrong.
- Invoiced quantity - the sum from the invoices. Where it deviates from the delivered quantity for good, either an invoice or a delivery note is missing.
- Open quantity - contract quantity minus called-off minus reserved quantity. This is the value the customer sees in the account and the value price determination checks.
Matching the call-off to the right contract
As soon as a customer has more than one open contract for an item, the matching becomes the actual task. Two contracts for the same item arise regularly: one from an annual agreement, one from a project with its own calculation and its own cost centre. Automatic selection by the lowest price is the wrong rule here, because it distorts the customer's project budget. The rule that holds is: the call-off names the contract. The shop offers the eligible contracts for selection, with remaining quantity, price and term as decision support, and writes the choice into the order line.
For the machine route the matching is already provided for. Code list UNTDID 1001 knows code 221 for the blanket order and code 226 for the call-off that provides split quantities and delivery dates referring to a previous blanket order (OpenPeppol). Both codes sit in the same list the order types of the EDI route come from; anyone running an EDI integration via EDIFACT finds the same separation there. The shop should set the same code value as the EDI route, so the ERP system does not have to maintain two paths for the same transaction.
<Order>
<cbc:ID>ABR-2026-0188-4</cbc:ID>
<cbc:IssueDate>2027-08-28</cbc:IssueDate>
<cbc:OrderTypeCode>226</cbc:OrderTypeCode>
<cac:ContractDocumentReference>
<cbc:ID>RV-2026-0188</cbc:ID>
</cac:ContractDocumentReference>
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>10</cbc:ID>
<cbc:Quantity unitCode="H87">60</cbc:Quantity>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">8.40</cbc:PriceAmount>
</cac:Price>
<cac:Delivery>
<cac:RequestedDeliveryPeriod>
<cbc:EndDate>2027-09-15</cbc:EndDate>
</cac:RequestedDeliveryPeriod>
</cac:Delivery>
</cac:LineItem>
</cac:OrderLine>
</Order>Three things stand out in this example. First, the contract number sits as a reference of its own in the header, not as free text in a comment field - only then can the receiving side evaluate it by machine. Second, the line carries the number of the contract line, not just the item; with contracts that hold scales across several lines of the same item this is the only unambiguous link. Third, the unit of measure sits as a code on the quantity. Anyone selling pack sizes keeps the contract quantity in the same unit as the call-off or converts it cleanly; the pitfalls are described in the piece on units of measure and pack sizes.
Sequence is not matching
Checking price and term with every call-off
The contract price applies before the list price and before the customer-specific price list, as long as quantity and term are covered. In practice that means price determination receives four inputs instead of two: customer, item, quantity and date. The date is the input most often missing. Check against the order date instead of the requested date, and a call-off at the contract price passes on the last day of the term while its delivery falls three weeks after the contract ends. The order of price sources belongs in the documentation and in the tests; how the sources interact is described in the article on price synchronisation from the ERP.
The term check deserves a look at the time zone. A contract ending on 30 September typically ends at the close of that day in the seller's time zone. If the boundary is held as a UTC timestamp and the call-off is placed on the evening of 30 September from another zone, the same transaction can fall inside or outside the term depending on the machine. Contract boundaries therefore belong in the data as a date and are converted into a point in time by a fixed rule - the same care that daylight saving in ERP interfaces requires.
{
"contract_no": "RV-2026-0188",
"customer_no": "100482",
"valid_from": "2026-10-01",
"valid_to": "2027-09-30",
"lines": [
{
"line_no": 10,
"sku": "40-2517-KH25",
"uom": "H87",
"qty_contracted": 500,
"qty_called_off": 260,
"qty_reserved": 40,
"qty_open": 200,
"price_net": 8.40,
"price_unit": 1,
"currency": "EUR",
"call_offs": [
{ "order_no": "ABR-2026-0188-1", "qty": 120, "date": "2026-11-04" },
{ "order_no": "ABR-2026-0188-2", "qty": 80, "date": "2027-03-16" },
{ "order_no": "ABR-2026-0188-3", "qty": 60, "date": "2027-08-11" }
]
}
]
}The call-off in the customer account
A digital customer portal is operated by 78 percent (ECC KÖLN) of manufacturers and wholesalers with an online shop, and 84 percent (ECC KÖLN) of the buyers surveyed at industrial companies believe that the entire day-to-day business in purchasing could be digitalised. The blanket order is precisely the transaction where this is decided: too rare to become routine, too important for a phone call. In the account the buyer therefore does not need the contract document but six values per line - and a button that turns them into a call-off. The same claim is made by live order status from the ERP: make visible what is in the system anyway.
- Contract quantity, called-off quantity and remaining quantity per line, in the unit of the contract and with the time of the last update.
- The contract price per line with price unit and currency, visible next to the list price so the advantage stays recognisable.
- The term with its end date and a note once fewer than 60 days remain - that is the point at which purchasing can act.
- The list of call-offs so far with date, quantity, order number and status, linked to delivery note and invoice.
- A call-off form that asks only for quantity, requested date and delivery point, because item and price come from the contract.
- A warning as soon as the requested quantity exceeds the remaining quantity, stating which quantity still goes at the contract price.
Two limits that are checked together
The return path into delivery note and invoice
A call-off is only mapped cleanly once its number reappears in the document. The customer's goods receipt posts against the call-off, not against the contract; invoice verification reconciles price and quantity against the call-off. Where the number is missing, the document is matched by hand and the advantage of the electronic channel is spent again at the recipient. In practice that means: contract number and call-off number go out with the order confirmation, appear on the delivery note and appear in the invoice - in the header, and on mixed documents additionally on the line.
The fields for this are provided in the electronic invoice. The contract reference names the identification of a contract, the purchase order reference an identifier of a referenced purchase order issued by the buyer, and alongside it sits the seller's sales order reference (OpenPeppol). Contract and call-off can therefore be stated separately without a number having to fall back into a free-text field. Anyone touching the document route anyway can take this step along at the lowest cost: the matching is part of the same field mapping, and whoever builds the interface themselves sets the reference fields in one go.
| Case | What the customer sees | What the interface has to deliver |
|---|---|---|
| Call-off within quantity and term | Contract price, remaining quantity drops | Contract number, line number, quantity, requested date |
| Call-off beyond the remaining quantity | Note stating the quantity left | Split into covered call-off and free order, or rejection with a reason |
| Call-off after the term has ended | List price with a note about the contract | Check of the requested date against the term, not of the order date |
| Several open contracts for the item | Contract selection in the cart | Contract list per customer and item with remaining quantity, price and term |
| Call-off to a different delivery point | Address selectable per call-off | Check against the delivery points recorded in the contract |
| Cancellation of a call-off | Remaining quantity rises again | Counter-event referring to the cancelled call-off instead of overwriting |
Tax, deadlines and retention
The contract triggers no tax, the call-off does. For VAT purposes the tax arises per part performance as soon as the consideration for a specific part of an economically divisible supply has been agreed separately (Section 13 German VAT Act, Federal Ministry of Justice). Without a differing agreement the obligor is not entitled to render part performance at all (Section 266 German Civil Code, Federal Ministry of Justice) - the blanket order is exactly that agreement and therefore belongs in the documentation. Every call-off invoice states the date of the supply or other service (Section 14 (4) German VAT Act, Federal Ministry of Justice), and for supplies to other traders the issuing period of six months (Federal Ministry of Justice) runs per call-off, not per contract.
Two further deadlines touch the interface directly. Where goods are moved into call-off stock at the customer and only called off there, the call-off stock arrangement applies: if the supply to the acquirer is not effected within twelve months (Section 6b German VAT Act, Federal Ministry of Justice) after the end of the transport, a deemed intra-Community transfer applies from the day after. The clock per stocking therefore belongs in the same data store as the remaining quantity. And under commercial law the duty to examine and give notice runs per delivery (Section 377 German Commercial Code, Federal Ministry of Justice) - another reason why documents are kept per call-off and not per contract. With hazardous substances there is the added point that every call-off needs current data; how it comes out of the ERP is covered in the piece on hazardous goods and substance data.
What goes wrong in operation
The most frequent failures are not programming errors but modelling errors. The remaining quantity is maintained as a field in the shop and drifts against the ERP because a posting fails to arrive. A call-off is cancelled, the counter-event is missing, and the remaining quantity stays too low until someone reviews the contract. The contract price sits in a cache and survives a contract amendment by hours. A contract expires without a deadline being recorded anywhere, and the first call-off at list price turns into a complaint. What these cases share is that they stay silent until a customer recalculates - around 80 percent (ECC KÖLN) of the manufacturers surveyed expect industry to buy more through online channels in future, and with that share grows the number of those who recalculate.
A narrow, regular check helps against this. A reconciliation that once a night sets the remaining quantity derived from the middleware events against the remaining quantity in the ERP finds drift on the day it arises. Two separately kept stocks that check each other expose errors a single stock hides. What matters is that the check produces output and not just a return value: a run that stays silent at zero deviations cannot be told apart from a run that was not started at all. The same logic runs through interface observation in general - what is measured is the state, not the message about the state.
Where no time for performance has been specified or where it is not evident from the circumstances, the obligee may demand performance immediately, and the obligor may effect it immediately.
Rolling it out in stages
A blanket order model can be introduced in stages, and the first stage already delivers most of the benefit. The entry point is visibility: show contracts and remaining quantities in the customer account without the call-off being possible online yet. That costs one read interface and answers the most frequent call to inside sales. Only after that comes the call-off with price determination, then the reservation, then the return path into the document. Each stage can be accepted on its own, and each can be rolled back without damaging the previous one.
- Take stock. How many active contracts are there, how many lines do they carry, how many customers have more than one open contract for the same item? These three figures set the scope.
- Build the read copy. Pull contract header, lines, price, term and remaining quantity from the ERP into the middleware, first as a scheduled reconciliation, later event-driven.
- Show it in the account. Make remaining quantity and contract price visible per line, with the time of the last update. From here the number of queries drops measurably.
- Enable the call-off. Call-off form with quantity, requested date and delivery point, check against remaining quantity and term, contract price in the order line with a source flag.
- Add the reservation. Cart and release bind quantity for a time; an expiry releases it automatically. Simultaneous call-offs from the same customer become manageable.
- Close the return path. Write contract and call-off number into order confirmation, delivery note and invoice, and test the reference fields against a validation file.
The effort depends less on the number of contracts than on the number of special rules: price scales within a contract, minimum call-off quantities, fixed call-off grids, differing payment terms per contract. Each of these rules is straightforward on its own and together they are the reason a blanket order model takes longer than an ordinary price list. Anyone connecting ERP and shop in industry should collect the special rules early and decide which of them are mapped in the first stage. What has to be clarified technically belongs in a short preliminary talk - the services around shop integration start exactly there.
Sources and regulations
Related Articles
Partial Deliveries and Part Invoices in the B2B Shop
Partial deliveries and part invoices between shop, middleware and ERP: data model, open quantity, document references and the fields of the electronic invoice.
Daylight Saving Time: Timestamps in ERP Interfaces
On changeover night one hour occurs twice. How timestamps, delta queries and job schedules between shop and ERP stay unambiguous, plus a test plan for October.
Customer Part Numbers Searchable in the B2B Shop
Making customer part numbers from the ERP searchable in a B2B shop: data model, BMEcat elements, tenant permissions and the return path into the e-invoice.