VBRK table — VBRK - Billing Document Header
VBRK stores one row per billing document header - invoice, credit memo, debit memo, or pro forma - created in the SD billing process. It carries the billing type, billing date, net value, currency, payer and sold-to, and the accounting transfer status. Line-level revenue and tax sit in VBRP; VBRK alone never gives a complete invoice.
VBRK is the header table behind every billing document created through VF01. This page covers which fields are safe to trust, how to join to items, partners, conditions and the sales order chain, and the pitfalls that cause people to double-count revenue or misdiagnose accounting posting failures.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,073 words
What it stores
One row in VBRK represents one billing document header - an invoice, credit memo, debit memo, cancellation document, or pro forma invoice created via the billing transactions in SD. The header carries document-level attributes common to the whole billing document: billing type, billing date, net value, document currency, payer, sold-to party, and whether the document has been transferred to accounting. It does not carry line item pricing, quantities, or material information - those live in VBRP. A single VBRK row can be built from multiple sales order or delivery items collected onto one invoice, and conversely a large order can be split across several VBRK documents depending on split criteria such as payer, currency, or billing date. VBRK is written by the standard billing transactions and by their background variants used in collective billing runs.
Key fields
- MANDT - client
- VBELN - billing document number, primary key
- FKART - billing type (F2 invoice, G2 credit memo, S1 cancellation, and similar)
- FKDAT - billing date, used for revenue period and pricing date defaults
- NETWR - net value of the billing document in document currency
- WAERK - document currency
- KUNAG - sold-to party
- KUNRG - payer
- VBTYP - SD document category, distinguishes invoice from credit memo from cancellation at document type level
- FKSTO - cancellation indicator, set when the document has been cancelled
- RFBSK - status of transfer to accounting, the field to check when a billing document has not generated a financial document
- KNUMV - condition record group number, the join key into the pricing condition tables
- BUKRS - company code derived for the billing document
How it joins the data model
- VBRK-VBELN = VBRP-VBELN (header to billing items)
- VBRP-AUBEL = VBAK-VBELN (billing item back to the originating sales order, not a direct VBRK to VBAK join)
- VBRK-VBELN = VBFA-VBELV or VBFA-VBELN (document flow, to trace order, delivery and billing chain and to find cancellation links)
- VBRK-VBELN = VBPA-VBELN with VBPA-POSNR = 000000 (header partners such as payer and bill-to)
- VBRK-KNUMV = KONV-KNUMV (pricing conditions applied to the billing document)
- VBRK-KUNAG = KNA1-KUNNR and VBRK-KUNRG = KNA1-KUNNR (customer master for sold-to and payer)
How to read it safely
VBRK is large in any live system with meaningful invoice volume, so date-range restriction on FKDAT and billing type restriction on FKART are the first two filters, before anything else. MANDT is implicit in most tools but matters in direct table access. Selection by VBELN range is cheap because it is the primary key; selection by KUNAG or KUNRG without a date restriction on FKDAT scans far more than intended. When looking for financially incomplete documents, filter on RFBSK rather than trying to infer posting status from the absence of a row elsewhere - RFBSK carries the explicit status code including blocked-for-posting states.
How to prove it in the data
Symptom: a customer disputes an invoice total. Select VBRK by VBELN to get FKART, FKDAT, NETWR, WAERK, KUNAG, KUNRG and confirm FKSTO is blank. If FKSTO is set, the document is cancelled and its reversal document is linked through VBFA - the dispute is likely about the original invoice's successor, not this one. Cross-check NETWR against the sum of VBRP-NETWR for the same VBELN; a mismatch points at header-level manual pricing or a rounding condition rather than a data error.
ECC vs S/4HANA
VBRK continues to exist as a persisted table in S/4HANA and is still written by the standard billing process; it has not been replaced by a compatibility view in the way several FI and MM tables have. Reporting layers increasingly sit CDS views on top of VBRK and VBRP for billing document analytics, but those views are additive rather than a substitute, and direct table reads for troubleshooting remain valid. The field layout is essentially unchanged from ECC, so joins and key fields used historically still apply.
Common pitfalls
- Summing NETWR across a date range to get total revenue without excluding FKSTO = X rows and their matching cancellation documents; a cancelled invoice and its cancellation both post NETWR values, and naive summation nets to a distorted figure if only one side is filtered.
- Assuming VBRK-VBELN equals the sales order number; billing documents have their own number range, and the only reliable path back to the order is through VBRP-AUBEL or the VBFA document flow.
- Reading NETWR as tax-inclusive; it is net of tax in the document currency, tax sits separately in the condition records and the accounting document.
- Concluding a billing document 'failed to post to FI' from its absence in an accounting report without checking RFBSK first; a non-zero or blocked RFBSK value usually explains exactly why, commonly an account determination or output tax condition issue, not a missing document.
- Ignoring WAERK when aggregating NETWR across documents in different currencies, producing a total that mixes currencies silently.
- Treating a pro forma billing type the same as an invoice for revenue reporting; pro forma documents sit in VBRK with their own FKART and never transfer to accounting, so including them inflates any accounting-linked report.
- Forgetting that collective billing runs can consolidate several sales orders or deliveries into one VBRK row, so a one-to-one assumption between order and invoice breaks down exactly where billing document splits occur.
Whose problem this is
Billing document content and creation logic belong to the SD order-to-cash consultant, particularly anything touching pricing, billing type configuration, or split criteria. Once RFBSK shows a posting problem or the accounting document itself is in question, ownership shifts to FI or CO for the accounting side, though the SD consultant usually diagnoses which billing document is stuck before handing it off.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/vbrkERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.