VBLB table — Release Order Data for Quantity Contracts

A row in VBLB represents the accumulated release-order activity for one item of a quantity or value contract, broken down by the customer (and sometimes ship-to) authorized to release against it. When a contract of type quantity contract is created, the target quantity lives on VBAP; VBLB is the running ledger that tracks how much of that target has been consumed by release orders created with reference to the contract item. Every time a release order is created, changed, or rejected, the cumulative figure in VBLB is updated so the system can calculate the remaining open quantity and decide whether to warn or block further releases. Without VBLB the contract item itself would have no memory of what has already been drawn against it; VBAP only holds the target, not the consumption.

Always restrict by client (MANDT) implicitly through the transaction layer, and always start from a known contract number and item, not from KUNNR alone, since the same customer can appear against many contracts and VBLB has no date range or plant restriction to narrow a broad customer scan. The table is small relative to VBAK or VBAP because it only holds one row per contract item per releasing party, so a selection by VBELN plus POSNN is normally fast; a selection by KUNNR across the whole client is the slow, non-selective path and should be avoided in ad hoc queries.

Symptom: a release order against a quantity contract is being blocked or warned as exceeding the contract quantity, and the business insists the contract still has quantity left. Pull the contract item's target quantity from VBAP for the VBELN and POSNN in question, then pull the matching row in VBLB for the same VBELN, POSNN, and the releasing KUNNR. Compare the cumulative quantity in VBLB against the VBAP target quantity minus any tolerance configured on the contract. If the VBLB figure already equals or exceeds the target, the block is correct and the contract is genuinely exhausted for that customer.

VBLB continues to exist as a physical table in S/4HANA and is still populated by the same contract release-order logic. There is no widely known dedicated CDS compatibility view that replaces it the way VBAK and VBAP have been fronted by newer data models; consultants working release-order reporting in S/4HANA generally still read VBLB directly or through the same custom reports that existed in ECC. Confirm on the specific release whether a newer extraction or reporting layer has been introduced before assuming it, since this can vary.

The SD functional consultant owns configuration questions about how release quantities are calculated and tolerated; the business owner of contract management owns whether a given cumulative figure matches what was actually shipped or invoiced. Data corrections to VBLB itself are rarely a good first move and normally point back to the release orders and their status in VBFA rather than to the ledger table.

VBAK and VBAP hold the contract header and item that VBLB tracks consumption against. VBEP carries schedule line detail when the contract is schedule-line based. VBFA provides the document flow linking release orders back to the contract, which is the authoritative source for reconstructing VBLB's totals. Contracts and their release orders are created and changed through the standard sales order transactions, since contracts are a sales document type rather than a separate transaction family.