VBUK and VBUP replaced by compatibility views
In S/4HANA, VBUK and VBUP no longer exist as physical database tables. The header and item status fields they held are consolidated into the VBAK/VBAP data model, and VBUK/VBUP are exposed only as compatibility views so existing SELECT-based code keeps running. Direct writes, native SQL, or table-level tricks against them no longer work.
This page covers what changes when VBUK and VBUP stop being physical tables in S/4HANA and become compatibility views over the consolidated document status data. It focuses on which custom code, extraction jobs, and support habits break, and what a conversion project has to check before go-live rather than after.
Published 16 Sept 2026· 1,127 words
Classic ECC behaviour
In ECC, VBUK and VBUP are physical database tables holding aggregated status fields for sales documents: overall processing status, delivery status, picking status, goods movement status, billing status, rejection status, credit status, and incompleteness indicators, split by header (VBUK) and item (VBUP). These fields are maintained by standard document processing logic during order entry, delivery creation, goods issue, and billing, using update tasks and document-level enqueue locking. Standard reports such as the open order list, delivery due list, and billing due list rely on them heavily, and it is common practice for custom Z-reports and interfaces to SELECT directly from VBUK/VBUP, often joined to VBAK/VBAP, to build backlog reports, aging analyses, or feeds into downstream systems. Support consultants also routinely use direct table tools to inspect status flags during incident triage, and in some shops to manually correct a stuck status flag as an emergency fix outside standard transactions.
S/4HANA behaviour
The physical persistence of VBUK and VBUP as separate tables is removed as part of the SD data model simplification. The status information they used to carry is folded into the consolidated VBAK/VBAP structures, and VBUK/VBUP are retained only as compatibility views with the same field names and structure, so existing SELECT statements generally still compile and return correct data. What is different: there is no longer a real table underneath, so direct INSERT, UPDATE, or DELETE statements against VBUK/VBUP fail, native SQL and database triggers pointed at these names no longer see the expected object, and anything depending on database-level change tracking (change logs, replication triggers, CDC tooling) loses its source because the compatibility view does not generate the same change events a physical table would. Execution plans for joins involving VBUK/VBUP can also differ from ECC, since the database is now resolving a view rather than a stored table, which changes performance characteristics for large FOR ALL ENTRIES style reporting. Any change to status must now flow exclusively through standard document processing logic and its supported interfaces.
Project impact
- Custom reports and interfaces doing plain SELECT FROM VBUK or VBUP keep working through the compatibility view, but any code doing direct INSERT, UPDATE, DELETE, native SQL, or database trigger logic against these names fails outright after conversion.
- Replication, CDC, or third-party ETL jobs that pick up deltas from VBUK/VBUP based on database-level change tracking stop delivering new changes, because the compatibility view does not generate the change log entries a physical table would.
- Support staff lose the ability to use direct table browsing tools to patch a stuck rejection or delivery status flag on a handful of orders as an emergency fix; that reflex habit simply stops working and there is no equivalent shortcut.
- Authorization checks tied to the old table's authorization group can fail to map cleanly to the new view, so reporting tools and background users that worked in ECC hit access denied errors in S/4HANA even though nothing in the business role changed.
- Month-end backlog aging, open order, and billing due list extracts built as direct joins against VBUK can see different runtime behaviour at full production volume, since the join now resolves against a view over the consolidated tables rather than a dedicated status table.
- Any BW extractor, generic extraction program, or bespoke delta mechanism keyed on VBUK/VBUP as a source table needs to be re-pointed, because the source object it was built against no longer physically exists.
Migration actions
- Pre-conversion gate: run the custom code checks against the full SD custom inventory to find every program, CDS view, interface, or extraction job that references VBUK or VBUP directly. This step is mandatory before conversion, not a post-go-live cleanup item, because unresolved direct writes will fail hard in production.
- Triage the findings: pure SELECT statements will mostly keep working through the compatibility view and can be scheduled for later refactor; anything doing INSERT, UPDATE, DELETE, native SQL, or database triggers on VBUK/VBUP must be rewritten before go-live to use standard document status logic.
- Rebuild any extraction or replication mechanism that depended on database-level change detection against VBUK/VBUP, re-pointing it at the consolidated VBAK/VBAP data or a CDS-based delta source.
- Re-test authorization for every role and background user that reads VBUK/VBUP, using actual production-like roles rather than broad test authorizations, so access issues surface before go-live instead of after.
- Regression test backlog, incompleteness, delivery due list, and billing due list reports at full data volume, since view-based resolution changes join performance characteristics compared with the old physical table.
- Retrain support and functional teams away from direct table edits on VBUK for emergency status correction, and document which standard transaction or mass processing tool now covers that scenario.
Whose problem this is
Both functional and technical. The SD functional lead identifies which business processes rely on status reporting and which support habits need retraining; the ABAP/technical lead owns the custom code remediation and extraction rework. The direct-write findings from the custom code check should be treated by project management as a blocking gate, with the decision on remediation timeline owned jointly by the technical lead and the conversion project manager.
Common pitfalls
- Teams see hundreds of hits from the custom code check and assume they carry equal risk; almost all are harmless SELECTs, and the handful of direct UPDATE statements buried in an old batch job are the ones that actually take production down.
- CDC or replication jobs based on VBUK change tracking pass fine in sandbox testing with low volume and no timing pressure, then silently stop delivering deltas in production once real order volumes and job frequency kick in.
- Support consultants discover the direct table edit reflex no longer works only during a live incident weeks after go-live, often at month-end, which is exactly the moment a quick status correction was most needed.
- Performance testing on small data sets does not reveal the changed join behaviour between the VBUK/VBUP views and large VBAK tables; the slowdown only shows up at full production volume during peak order entry or month-end billing runs.
- Authorization gaps tied to the old table authorization group are missed in test because test users often run with broader authorizations than production roles, so the access denied error only appears once real business users hit the report.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-s4hana-changes/sd-status-tables-vbuk-and-vbup-removedERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.