BSIS BSAS BSID BSAD BSIK BSAK become compatibility views
In S/4HANA the FI open and cleared item index tables BSIS, BSAS, BSID, BSAD, BSIK and BSAK are no longer physical tables. They exist as compatibility views computed on the fly from the Universal Journal, kept for backward compatibility with SELECT statements. Direct writes to them are no longer possible, and custom reports that filtered or updated them directly need remediation before conversion, not after.
This page covers what happens to the classic FI secondary index tables for open and cleared items once a system moves to S/4HANA, where they are replaced by compatibility views over the Universal Journal. It focuses on where custom ABAP code and interfaces built against these tables break, and what has to be fixed before go-live rather than discovered afterwards.
Published 16 Sept 2026· 1,164 words
Classic ECC behaviour
In ECC, BSEG carries the full line item detail but is not efficiently selectable by account across large document ranges, so FI maintained a set of redundant secondary index tables updated at posting time: BSIS and BSAS for G/L open and cleared items, BSID and BSAD for customer open and cleared items, BSIK and BSAK for vendor open and cleared items. Every posting, clearing, and reversal wrote to both BSEG and the relevant index table. These tables were the backbone of open item reports, dunning, payment proposals, and most custom aging and reconciliation reports, because selecting directly against BSEG by account and status was too slow. They grew continuously, needed regular archiving or reorganisation, and their volume was a recognised database sizing concern in any long-running FI system. Custom Z-programs routinely selected from them directly, joined them to other tables, and in some cases updated them from batch interfaces or correction programs when standard clearing logic did not fit the business case.
S/4HANA behaviour
With the Universal Journal, ACDOCA becomes the single source of financial truth, and the six index tables are converted into compatibility views carrying the same names and largely the same field structure. Reads against them still work in most cases because the view computes the open or cleared item set from ACDOCA and BSEG at query time, rather than reading a physically maintained table. There is no independent storage to keep in sync, no separate update at posting time, and no archiving requirement for these objects specifically, since there is nothing physically growing. The critical change is that these are now views, not tables: INSERT, UPDATE, DELETE and MODIFY statements against them are not supported, and any ABAP construct that assumes table semantics, such as a SELECT ... FOR UPDATE, a database lock, or a dictionary-level secondary index, does not carry over. Selection performance depends on how well the query maps onto ACDOCA's structure and partitioning rather than on an index that used to exist physically on the old table.
Project impact
The break is almost entirely on the custom code and interface side, and it surfaces at very different points depending on how the code was written.
- Any Z-report or LSMW/BDC routine that directly inserted, updated or deleted rows in BSIS, BSAS, BSID, BSAD, BSIK or BSAK fails outright at conversion, because the target is now a view.
- Reports using SELECT ... FOR UPDATE or explicit database locks on these tables fail, since views do not support row locking the same way.
- Custom secondary indexes built on these tables in the ABAP Dictionary are lost, and any report tuned around them silently loses its performance advantage rather than failing loudly.
- Open item aging and dunning-adjacent custom reports that ran fine on small test data can become materially slower in production once the view has to filter the much larger ACDOCA table without the old dedicated index.
- Interfaces feeding downstream systems (collections, treasury, credit exposure) that read these tables directly for open item snapshots need revalidation, since row order, buffering behaviour and even some field population can differ subtly from the old physical table.
- Authorisation objects and table logging configured against the old table names still resolve, but do not reflect the actual data source, which can confuse audit trails during investigation.
Migration actions
Remediation of direct writes to these tables is a pre-conversion gate, not optional cleanup, because the target system will reject them regardless of how the project prioritises the backlog.
- Run a custom code scan against the six table names to find every SELECT, INSERT, UPDATE, DELETE, MODIFY and lock statement referencing them, across reports, function modules, and interface code, not just Z-transactions.
- Classify every write access separately from read access; writes must be redesigned to go through standard posting and clearing logic before the technical conversion, since the views will not accept them afterward.
- For read-only custom reports, decide case by case whether to leave the select against the compatibility view or rewrite it against ACDOCA or a released CDS view for better performance; leaving it as-is is acceptable for low-volume, low-frequency reports.
- Remove custom secondary indexes defined on the old physical tables from the technical inventory and, if the corresponding report is performance-critical, redesign selection logic with ACDOCA's actual key fields and partitioning in mind.
- Test the heaviest open item and aging reports against production-volume data, not sandbox data, since the performance delta between the old indexed table and the new computed view only shows up at scale.
- Reconcile historical data: rows posted before the technical conversion date still need to trace correctly through the view, so validate a sample of aged open items spanning the cutover boundary.
Whose problem this is
Joint ownership. The technical or ABAP team owns finding and fixing every direct read and write against the six tables, since this is a code-level break with a hard gate at conversion. FI functional consultants own the decision on which custom open item reports get rebuilt against ACDOCA versus left on the compatibility view, based on report criticality and volume.
Common pitfalls
The most common failure mode is treating the compatibility view as functionally identical to the old table and only testing reads, missing that a batch job somewhere still writes to one of these tables directly, often a correction program built years earlier for a one-off data fix that nobody remembers exists.
- Custom code scans run too late, after the technical conversion is already scheduled, leaving no time to redesign a write-heavy interface properly and forcing a rushed workaround.
- Sandbox testing with a small data set shows no performance regression, then the same open item report times out or runs for hours in production once ACDOCA volume is realistic.
- Teams assume archiving strategy for these tables carries over unchanged and continue running reorg or archiving jobs against objects that no longer physically exist in the old sense, wasting effort and causing confusing job failures.
- A custom lock or FOR UPDATE statement passes code review because the reviewer checks for syntax errors only, not for view compatibility, and the failure only appears at runtime during conversion testing.
- Reconciliation between old and new open item balances at the cutover boundary is skipped because it looks like a formality, then a discrepancy in aged items surfaces during the first post-conversion month-end close.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-s4hana-changes/index-tables-bsis-bsas-bsid-bsad-bsik-bsak-replaced-by-compatibility-viewsERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.