SAP FI Important TABLES: Must Know!
Mason Garcia
⚡ Smart Summary
SAP FI tables store the master data, accounting documents, and configuration that drive Financial Accounting, organized into master, transaction, and customizing groups that S/4HANA now consolidates into the Universal Journal table ACDOCA.
Financial Accounting in SAP stores every balance, document, and configuration setting inside database tables, so knowing the important tables in the SAP FI module helps you read data with SE16, build reports, and trace postings from end to end. This reference groups the key SAP FI tables by purpose — master data, transaction data, payment runs, and customizing — and explains how they fit together in both SAP ERP and SAP S/4HANA.
SAP FI Master Data Tables
Master data tables hold the relatively static records that postings refer to, such as the chart of accounts, customers, and vendors. These tables are shared across many transactions, so their contents change far less often than the daily accounting documents that point to them.
General Ledger (G/L) Account Tables
General ledger master data is split between chart-of-accounts level and company-code level, which lets one chart of accounts serve several company codes.
| Code | Description |
|---|---|
| SKA1 | G/L accounts (chart of accounts) |
| SKAT | G/L accounts (chart of accounts: description) |
| SKB1 | G/L accounts (company code) |
Customer Master Tables
Customer master data supports accounts receivable. The general data in KNA1 is shared across the client, while KNB1 stores the company-code-specific view such as the reconciliation account and dunning procedure.
| Code | Description |
|---|---|
| KNA1 | Customer master (general data) |
| KNB1 | Customer master (company code) |
| KNVV | Customer sales data |
| KNBK | Bank details |
| KNVH | Customer hierarchy |
| KNVP | Customer partner functions |
| KNVS | Shipment data for customer |
| KNVK | Contact persons |
| KNVI | Customer master tax indicator |
Vendor Master Tables
Vendor master data supports accounts payable and mirrors the customer structure. LFA1 carries the general data, LFB1 the company-code data, and LFB5 the dunning data used by the dunning program. The account group that controls these fields is set when you create a vendor account group.
| Code | Description |
|---|---|
| LFA1 | Vendor master (general data) |
| LFB1 | Vendor master (company code) |
| LFB5 | Vendor dunning data |
| LFM1 | Purchasing organization data |
| LFM2 | Purchasing data |
| LFBK | Bank details |
Customer–Material Info and Bank Data Tables
Two smaller master data tables round out this group: KNMT links a customer to a material, and BNKA holds the central bank directory used by customer, vendor, and house bank records.
| Code | Description |
|---|---|
| KNMT | Customer–material info record |
| BNKA | Master bank data |
SAP FI Transaction Data Tables (Accounting Documents)
Every posting in Financial Accounting creates an accounting document that is stored across a header table and a line item table, supported by a set of secondary index tables that speed up open and cleared item reporting.
BKPF holds one row per document with header details such as document type, posting date, and fiscal year. BSEG holds the line items, so a single BKPF header is linked to several BSEG rows. The secondary index tables then copy selected line items by account type: the BSI* tables hold open items and the BSA* tables hold cleared items, split into customer (D), vendor (K), and general ledger (S) versions.
| Code | Description |
|---|---|
| BKPF | Accounting document header |
| BSEG | Accounting document segment (line items) |
| BSID | Secondary index for customers (open items) |
| BSIK | Secondary index for vendors (open items) |
| BSIM | Secondary index, documents for material |
| BSIP | Index for vendor validation of double documents |
| BSIS | Secondary index for G/L accounts (open items) |
| BSAD | Index for customers (cleared items) |
| BSAK | Index for vendors (cleared items) |
| BSAS | Index for G/L accounts (cleared items) |
SAP FI Payment Run Tables
The automatic payment program (transaction F110) writes its results into two tables. REGUH stores the payment (settlement) data per payee, and REGUP stores the individual open items that each payment cleared, which is useful when you reconcile an outgoing payment or investigate a proposal.
| Code | Description |
|---|---|
| REGUH | Settlement data from the payment program |
| REGUP | Processed items from the payment program |
SAP FI Customizing (Configuration) Tables
Customizing tables store the configuration set in the Implementation Guide (SPRO). They control how documents post and how the company code, fiscal year, and posting periods behave, so consultants often check them to confirm a setting quickly.
Company Code Configuration Tables
These tables define the organizational and chart-of-accounts settings that anchor every posting to a company code.
| Code | Description |
|---|---|
| T004 | Chart of accounts |
| T077S | Account group (G/L accounts) |
| T009 | Fiscal year variants |
| T880 | Global company data |
| T014 | Credit control area |
FI Document Configuration Tables
Document control tables decide which document types are allowed and which posting periods are open, working together with the posting period variant.
| Code | Description |
|---|---|
| T010O | Posting period variant |
| T010P | Posting period variant names |
| T001B | Permitted posting periods |
| T003 | Document types |
| T012 | House banks |
How to View SAP FI Table Data (SE16, SE16N, SE16H)
Knowing a table name is only useful if you can read its contents. SAP ships a data browser for exactly this, and it needs no ABAP programming.
- SE16 / SE16N — the general data browser. Enter the table name, for example BSEG, apply filters on key fields, and run the selection to list matching rows. SE16N is the more flexible successor and lets you filter on any field.
- SE16H — an enhanced browser available in SAP S/4HANA that supports joins, grouping, and aggregation directly in the interface, which helps when analyzing large datasets.
- SE11 — the ABAP Dictionary. Use it to view a table definition (its fields, data types, and keys) rather than its data.
To discover a table name while working, place the cursor on any field, press F1, and choose the Technical Information button. SAP then shows the table and field that store the value, which you can open in SE16N straight away. Access to these transactions is governed by the standard authorization objects in the SAP GUI, so display access is usually restricted in production systems.
SAP FI Tables in S/4HANA and the Universal Journal (ACDOCA)
SAP S/4HANA simplifies the FI data model around a single line item table called the Universal Journal, ACDOCA. It merges Financial Accounting and Controlling line items into one table, which removes the need to reconcile FI and CO separately.
Because of this, the classic secondary index and totals tables — BSID, BSIK, BSIS, BSAD, BSAK, BSAS, and totals such as GLT0 — are no longer written as separate physical tables. SAP replaces them with CDS compatibility views of the same name that read from ACDOCA and BSEG, so older reports keep working. BKPF still stores the document header and BSEG still exists as an open item registry, but ACDOCA is the source of truth for reporting.
How SAP FI Tables Are Linked Together
The FI tables connect through a small set of shared key fields, which is what lets you follow a figure from a report back to its source document.
- An accounting document is identified by company code (BUKRS), document number (BELNR), and fiscal year (GJAHR); BKPF and BSEG share this key, so one header joins to its line items.
- Line items in BSEG carry the account number, which links back to master data in SKA1/SKB1 (G/L), KNA1/KNB1 (customer), or LFA1/LFB1 (vendor).
- The secondary index tables (BSID, BSIK, BSIS and the cleared-item BSA* tables) are derived from the document line items, so they always trace back to the same BKPF and BSEG rows.
Understanding these links makes month-end tasks such as dunning and open item clearing much easier to audit, because every balance can be traced to the documents behind it.
