VBRP table — VBRP Billing Document Item Data

Each VBRP row is one item on one billing document: a specific material or service line, its billed quantity, and the net value posted to that line. A billing document header in VBRK can have many VBRP items, exactly as a sales order has many VBAP lines. VBRP is populated when a billing document is created, whether via order-related billing, delivery-related billing, or manual credit and debit memo creation. Cancellation documents also produce VBRP rows, carrying the same item data with a reversing sign relationship to the original. The table is where quantity and value actually billed live; it does not itself carry pricing condition breakdowns, tax logic, or accounting postings, those sit in related pricing and FI tables. Read VBRP whenever the question is what was invoiced, not what was ordered or delivered.

Always restrict by MANDT and by VBELN when the billing document number is known; VBRP is large in any live system with years of billing history, and an unrestricted read on MATNR or WERKS alone will scan the whole table. When searching by material or customer, filter first by a date range on VBRK-FKDAT or by sales organisation, then join into VBRP, rather than filtering VBRP directly on fields it does not carry well for selectivity such as ARKTX. FKIMG is signed for credit memos and cancellations, so a raw sum across mixed document types produces a misleading total; always group by billing category or filter FKSTO before aggregating.

Customer claims an invoice line shows a different quantity than the delivery. Pull VBRP for the billing document and item, note VGBEL and VGPOS, then read LIPS with that document and item number to compare LIPS-LFIMG against VBRP-FKIMG. A mismatch confirms partial billing or a manual quantity override at billing; identical quantities push the investigation back to pricing or tax, not quantity.

VBRP remains a transparent table in S/4HANA and continues to be written by the same billing processes. Reporting and analytics increasingly go through CDS views built on top of VBRK and VBRP rather than direct table reads, but the underlying table structure and its core fields are unchanged for standard SD billing. Custom reports and interfaces that read VBRP directly continue to work; new Fiori-based billing reporting typically sits on the compatibility CDS layer instead.

Billing content and item category configuration sit with the SD/O2C functional consultant. Disputes about whether a specific quantity or value on an invoice is correct usually start with the billing or order desk, escalating to SD configuration only when the item category or copy control rules themselves are suspected of producing wrong values.

VBRK is the billing header this table always joins to. VBAP and LIPS are the order and delivery item tables VBRP traces back to depending on billing route. VBFA is the document flow table used to walk the chain in either direction. Transaction VF01 and its mass-processing counterparts create VBRP rows; VF02 displays and can adjust certain fields before release to accounting; VF03 is display-only.