The 10 Most Important SAP Tables – An Overview for Consultants and Users
Where does the data actually live? Anyone working with SAP FI/CO will face this question sooner or later. This article explains the ten most important tables — what they contain, who needs them, and when they matter in day-to-day work. With practical notes on both ECC and S/4HANA.
Anyone working with SAP will reach a point sooner or later where a question comes up that no transaction can answer: Where does the data actually live?
The answer lies in the SAP tables. Every posting, every master record, every Customizing setting — it all ends up in a table. An SAP system can contain several hundred thousand of them, depending on the modules in use and any custom developments. Most of them never come up in day-to-day work. But a handful appear again and again, whether you are analyzing a document, debugging a problem, or writing a concept.
These are the tables listed here: the ten that everyone working in the FI/CO environment should really know. With a clear explanation of what each one contains — and who needs it most.
How to Look Inside an SAP Table
Table contents can be viewed using transaction SE16 or SE16N. The table structure — meaning which fields a table contains — is shown by SE11. Both transactions are available in ECC and S/4HANA.
1. BKPF — The Document Header
Who needs it: Consultants, key users, anyone who needs to analyze or trace postings.
BKPF is the header table for every financial document in the SAP system. Every posting — whether manual, automatic, or via interface — creates an entry in BKPF. It stores the top-level information about a document: company code, document number, fiscal year, document date, posting date, document type, posting period, and the user who created it.
BKPF alone does not say much about the content of a posting — for that, you always need its counterpart, BSEG. Together, they form the classic core of FI data storage in ECC.
Key Fields
- BUKRS — Company code
- BELNR — Document number
- GJAHR — Fiscal year
- BLART — Document type
- BUDAT — Posting date
- USNAM — Username of the person who created the entry
Typical Use
Checking document date, posting period, document type, and the creating user — for example during troubleshooting, as part of an audit, or to verify who triggered an automatic posting and when.
2. BSEG — The Document Line Items
Who needs it: Consultants, developers, experienced key users.
While BKPF describes the header of a document, BSEG contains all the individual line items — the actual posting lines with accounts, amounts, cost centers, tax codes, and payment terms. It is one of the largest and most frequently referenced tables in the SAP system.
In classic ECC systems, BSEG is a cluster table, meaning it cannot be queried directly via SQL — SAP provides specific read techniques for this purpose. In S/4HANA, the underlying data model has changed fundamentally: BSEG continues to be populated and remains relevant for certain FI document fields, but ACDOCA should be the primary source for reporting and custom developments.
Note for S/4HANA
In S/4HANA, ACDOCA (see Table 3) should be the primary source for reports and analysis. BSEG remains technically populated and is still relevant for certain FI-specific fields — but it is no longer the leading data storage layer.
Typical Use
Analyzing individual posting lines: Which account was debited? What amount? With which tax code? Which payment terms are stored? In ECC, the standard source for line-item-level document analysis.
3. ACDOCA — The Universal Journal ⭐
Who needs it: Consultants, developers, anyone working with S/4HANA.
ACDOCA is the central table of the Universal Journal in SAP S/4HANA — and one of the most significant changes in the entire FI/CO data model. It consolidates all accounting and controlling-relevant line item positions into a single table: general ledger, subledgers, cost accounting, asset accounting — all in one record per document line item.
With more than 360 fields, ACDOCA is considerably broader than any of its predecessors. This allows analyses that previously required multiple table joins to be run in a single query. Anyone developing reports or analyzing data in S/4HANA cannot avoid ACDOCA.
What ACDOCA Consolidates
- FI line item positions (held in ECC primarily in BSEG — BSEG remains relevant in S/4HANA)
- CO line items (in ECC: COEP)
- Asset accounting (in ECC: ANEK/ANEP)
- Profit center accounting (in ECC: GLPCA)
- Profitability analysis (CO-PA)
Typical Use
The foundation for all modern FI/CO reporting in S/4HANA: line item lists, period-close analysis, CO-PA reporting, asset depreciation — all from a single source, without table joins across multiple modules.
4. BUT000 — The Business Partner Master ⭐
Who needs it: FI consultants, master data owners, anyone involved in S/4HANA migrations.
BUT000 is the central master data table for the business partner in SAP — and in S/4HANA the leading structure for all customer and vendor master data. It stores the fundamental data of a business partner: BP number, BP category (person, organization, group), name, and core attributes. Address assignments are handled via BUT020 and ADRC.
The business partner is not optional in S/4HANA — it is mandatory. The classic customer (XD01) and vendor (XK01) transactions no longer exist as standalone entry points. All master data maintenance runs through transaction BP, with data stored in the BUT tables and synchronized with the classic structures KNA1/KNB1 and LFA1/LFB1 via the Customer-Vendor Integration (CVI).
Key BUT Tables at a Glance
- BUT000 — General master data of the business partner
- BUT020 / ADRC — Address assignments
- BUT100 — Business partner roles (e.g. customer, vendor, contact)
- CVIS_EI_MAPP — CVI mapping between BP number and customer/vendor number
Migration Note
Business partner migration is one of the most common stumbling blocks in S/4HANA projects. Not all customer and vendor master data can be transferred 1:1 — missing BP roles, duplicate records, or unsynchronized fields between BUT and KNA1/LFA1 structures regularly create extra effort. Checking the CVI mapping tables early saves time.
Typical Use
Checking BP master data, roles, and CVI mapping during migration projects, duplicate analysis, or when troubleshooting synchronization errors between business partner and classic customer/vendor structures.
5. KNA1 / KNB1 — Customer Master
Who needs it: FI-AR consultants, accounts receivable, key users.
The customer master is split across two tables — a principle that runs through the entire SAP master data area. KNA1 holds the client-independent data: name, address, country, language, tax number. KNB1 holds the company-code-specific data: payment terms, dunning procedure, reconciliation account, payment methods.
Both tables are essential for analysis, data migration, and business partner migration in S/4HANA projects. In S/4HANA, KNA1/KNB1 and LFA1/LFB1 are synchronized via the Customer-Vendor Integration (CVI) of the business partner.
Typical Use
Mass reporting on customer master data, data quality checks, migration preparation, or analysis of reconciliation accounts and payment terms across multiple company codes.
6. LFA1 / LFB1 — Vendor Master
Who needs it: FI-AP consultants, accounts payable, key users.
The exact counterpart to the customer master on the supplier side. LFA1 stores general vendor data (name, address, bank details at general level), while LFB1 holds company-code-specific data (reconciliation account, payment terms, payment methods, dunning procedure).
As part of the S/4HANA migration, vendor and customer master data is transferred into the business partner. LFA1 and LFB1 remain technically in place, but master data maintenance then runs through transaction BP. Synchronization between the business partner and the classic structures is handled by the Customer-Vendor Integration (CVI).
Typical Use
Analysis of vendor master data: bank details, payment terms, reconciliation accounts. Frequently used for data quality checks before go-live, payment run preparation, or vendor consolidation projects.
7. SKA1 / SKB1 — G/L Account Master
Who needs it: FI-GL consultants, Customizing, closing teams.
G/L accounts in SAP also follow a two-level master data structure. SKA1 holds the chart-of-accounts-level data: account number, description, account group, and the balance sheet or P&L indicator. SKB1 holds the company-code-specific settings: field status group, currency, open item management, and automatic posting indicators.
Anyone creating, maintaining, or migrating G/L accounts in bulk will almost inevitably work directly with these tables — for example during mass uploads via LSMW or when comparing chart of accounts structures between systems.
Typical Use
Checking and mass-reporting on G/L account master data: Which accounts are active in the company code? Which field status group is assigned? Which accounts are managed on an open item basis? Essential for chart of accounts analysis and migration preparation.
8. T001 — Company Codes
Who needs it: Consultants, Customizing, system-oriented key users.
T001 is one of the central Customizing tables in SAP FI. It contains all company codes defined in the system along with their key settings: company code name, local currency, chart of accounts, fiscal year variant, posting period variant, and country. Anyone running cross-company-code analyses or checking system configuration will find themselves in T001 sooner or later.
Typical Use
Overview of all active company codes in the system: Which local currency is set? Which chart of accounts applies? Which fiscal year variant is assigned? Relevant for system analysis, concept work, and cross-company-code projects.
9. REGUP / REGUH — Payment Run
Who needs it: FI-AP/AR consultants, accounts payable, treasury.
These two tables document the results of the automatic payment program (transaction F110). REGUH contains the payment header — information about the payment run itself: date, payment method, house bank, amount. REGUP contains the associated line items — which open items were cleared with which payment document.
These tables are indispensable for analyzing payment runs, troubleshooting payments that were not executed, or reconciling with the house bank.
Typical Use
Tracing payment runs: Which documents were paid in the last F110 run? Why was a specific document excluded? Which house bank was used? The first place to look when accounting teams have questions after a payment run.
10. ANLA / ANLZ — Asset Master
Who needs it: FI-AA consultants, asset accounting teams, closing teams.
ANLA is the header table of the asset master and contains the general, non-time-dependent data of an asset: asset number, asset class, company code, description, capitalization date, and inventory number. ANLZ contains the time-dependent master data — data that can change over the lifecycle of an asset, such as cost center or location, along with the relevant validity period.
Anyone working on asset migration, the FI-AA year-end close, or depreciation analysis will work directly with these tables — supplemented by transaction data in ANEK and ANEP (in ECC) or ACDOCA (in S/4HANA).
Typical Use
Mass reporting on asset master data: Which assets belong to a specific asset class? When were they capitalized? Which cost center is assigned at a given key date (ANLZ)? The basis for migration lists, inventory reports, and year-end analysis.
What About the Others?
There are many more tables that are equally relevant depending on your focus area. A few candidates that narrowly missed this list:
- T030 — Account determination (automatic account assignment)
- BSIK / BSAK — Open and cleared vendor line items
- BSID / BSAD — Open and cleared customer line items
- COEP — CO line items (in ECC; replaced by ACDOCA in S/4HANA)
- FEBEP — Electronic bank statement (line items from imported bank statements)
If you would like to go deeper — into specific modules, the differences between ECC and S/4HANA, or which tables work best for which reporting scenarios — that is exactly what I cover in my training and consulting work.
SAP Knowledge That Works in Practice
In my training sessions for end users, key users, and consultants, I do not just explain what tables contain — I show when and why you need them. Practical, without detours.
Get in Touch Now →