VBFA table — Sales Document Flow Table VBFA

One row in VBFA represents a single link between a preceding document (or preceding item) and a subsequent document (or subsequent item) somewhere in the sales process. A sales order line that results in two partial deliveries produces two rows. A delivery split into two invoices produces two rows on the delivery side. Header-level links, such as an order header referencing a contract header, also appear as rows with item fields set to zero. The table does not store the business documents themselves, only the fact that document A produced document B, plus the quantity and value that moved across that particular link. Reading VBFA in isolation tells nothing about the current status of either document; it only tells what was created from what, and how much.

MANDT restriction is mandatory and usually handled by the environment. Beyond that, never select from VBFA without restricting on VBELV or VBELN, ideally both plus VBTYP_V or VBTYP_N to narrow the document category. The table has no natural date range field worth filtering on for performance since ERDAT reflects flow creation, not business relevance, so filtering by date alone on a large table is a full scan. In a mature production system this table can hold many years of history across every sales document ever created, so an unrestricted select against it is one of the more common ways to time out a report. Always drive the query from a known document number or a small set of them.

Symptom: a customer disputes that an order was ever delivered. Select VBFA where VBELV equals the order number and POSNV equals the item, restricted to rows where VBTYP_N indicates a delivery. If no row exists, the order item was never copied into a delivery, which points to a blocked schedule line or missing delivery run rather than a delivery that was created and lost. If a row exists, take the VBELN from that row and check LIKP and the delivery's own status, since VBFA will still show the link even if the delivery was later cancelled.

VBFA remains a standard transparent table in S/4HANA with the same structure used in ECC; it has not been replaced by a compatibility view in the way VBUK and VBUP status handling was reworked around the simplified document status model. Existing ABAP reading VBFA directly continues to work. The practical change on S/4HANA projects is more often about volume and archiving strategy than about structure, since the table keeps growing with every document created and is a frequent candidate for data volume management discussions during system conversion.

Document flow questions belong to the SD functional consultant responsible for order-to-cash configuration, specifically copy control between document types, since that configuration determines which links get written and with what quantity and value. Basis or data management gets involved only when the discussion turns to table growth, archiving, or performance, not when the question is why a particular link is missing.

VBAK and VBAP supply the preceding order side of most flows; LIKP and LIPS the delivery side; VBRK and VBRP the billing side. VBUK and VBUP carry the current header and item status that VBFA itself does not track. Documents that generate VBFA rows are created through the standard order, delivery, and billing transactions such as VA01, VL01N, and VF01, with the actual link controlled by copy control configuration behind those transactions rather than by VBFA itself.