Common SAP Table Joins for Financial Reporting

Understanding SAP's Financial Data Architecture

SAP FI stores financial data across multiple layers, each serving a distinct purpose in the accounting ecosystem. The architecture separates document structure (headers and items) from master data (chart of accounts) and aggregated ledger data (New GL tables). This separation enables high-performance reporting while maintaining detailed audit trails and supporting parallel accounting scenarios required by multinational corporations.

The fundamental principle behind SAP's financial table design is normalization balanced with reporting performance. Document-level data lives in header and item tables, master data provides descriptive attributes and control parameters, and the New General Ledger maintains pre-aggregated totals for fast period-end reporting. Understanding when to query transactional tables versus ledger tables is the first critical decision in financial report development.

Layer 1: Document Tables (Transaction Detail)
├── BKPF (Accounting Document Header)
│   └── BUKRS + BELNR + GJAHR [Primary Key]
└── BSEG (Accounting Document Segment)
    └── BUKRS + BELNR + GJAHR + BUZEI [Primary Key]

Layer 2: Master Data (Chart of Accounts)
├── SKA1 (G/L Account Master - Chart of Accounts)
│   └── KTOPL + SAKNR [Primary Key]
└── SKAS (G/L Account Master - Chart of Accounts Segment)
    └── KTOPL + SAKNR [Primary Key]

Layer 3: New General Ledger (Aggregated Balances)
├── FAGLFLEXA (Actual Line Items)
│   └── Multi-dimensional key with RLDNR, RBUKRS, GJAHR
└── FAGLFLEXT (Totals Table)
    └── RLDNR + RBUKRS + RACCT + GJAHR [Key Components]

Join Pattern 1: BKPF-BSEG (Document Header to Line Items)

The BKPF-BSEG relationship is the foundation of all document-level financial reporting. BKPF contains document header data—posting date, document type, reference numbers, and document status—while BSEG stores individual line items with account assignments, amounts, and posting keys. This is a classic 1:N relationship where one document header can contain multiple line items.

Understanding the Table Structures

BKPF (Accounting Document Header) contains approximately 200 fields, but these are the most critical for financial reporting:

BSEG (Accounting Document Segment) contains the detailed posting information:

Basic BKPF-BSEG Join Pattern

The standard join pattern uses the composite key of company code, document number, and fiscal year. Always include fiscal year in your WHERE clause for optimal performance, as BKPF and BSEG are typically partitioned by fiscal year in production systems.

SELECT
    h.bukrs AS company_code,
    h.belnr AS document_number,
    h.gjahr AS fiscal_year,
    h.blart AS document_type,
    h.bldat AS document_date,
    h.budat AS posting_date,
    h.usnam AS posted_by,
    h.xblnr AS reference,
    i.buzei AS line_item,
    i.hkont AS gl_account,
    i.dmbtr AS local_amount,
    i.shkzg AS debit_credit,
    i.kostl AS cost_center,
    i.prctr AS profit_center,
    i.sgtxt AS line_item_text
FROM bkpf AS h
INNER JOIN bseg AS i
    ON h.bukrs = i.bukrs
    AND h.belnr = i.belnr
    AND h.gjahr = i.gjahr
WHERE h.bukrs = '1000'
    AND h.gjahr = 2024
    AND h.budat BETWEEN '20240101' AND '20241231'
    AND i.koart = 'S'  -- G/L account line items only
ORDER BY h.budat, h.belnr, i.buzei;

This query retrieves all general ledger postings for company code 1000 in fiscal year 2024. The KOART filter on BSEG ensures we only get G/L account line items, excluding customer, vendor, and material line items which have their own specialized tables (BSID, BSIK, BSIM).

Advanced Pattern: Journal Entry Analysis with Amount Aggregation

Financial controllers often need to analyze journal entries by document type with debit and credit totals calculated separately. This pattern demonstrates proper amount handling with the SHKZG indicator:

SELECT
    h.bukrs,
    h.gjahr,
    h.blart AS document_type,
    t.ltext AS document_type_desc,
    COUNT(DISTINCT h.belnr) AS document_count,
    COUNT(i.buzei) AS line_item_count,
    SUM(CASE WHEN i.shkzg = 'S' THEN i.dmbtr ELSE 0 END) AS total_debits,
    SUM(CASE WHEN i.shkzg = 'H' THEN i.dmbtr ELSE 0 END) AS total_credits,
    SUM(CASE WHEN i.shkzg = 'S' THEN i.dmbtr ELSE -i.dmbtr END) AS net_amount
FROM bkpf AS h
INNER JOIN bseg AS i
    ON h.bukrs = i.bukrs
    AND h.belnr = i.belnr
    AND h.gjahr = i.gjahr
LEFT JOIN t003t AS t
    ON h.blart = t.blart
    AND t.spras = 'E'  -- English language
WHERE h.bukrs = '1000'
    AND h.gjahr = 2024
    AND h.budat BETWEEN '20240401' AND '20240630'  -- Q2 2024
    AND i.koart = 'S'
GROUP BY h.bukrs, h.gjahr, h.blart, t.ltext
ORDER BY total_debits DESC;

This query provides quarterly document type analysis, joining to T003T for document type descriptions. The CASE statements handle debit/credit amounts correctly—credits are stored as positive amounts with SHKZG='H', so we negate them for net amount calculations.

Performance Optimization: Fiscal Year Filtering

-- Fast: Uses partition elimination
WHERE bukrs = '1000' AND gjahr = 2024

-- Slow: Scans all fiscal year partitions
WHERE bukrs = '1000' AND budat >= '20240101'

Practical Example: Month-End Close Validation

A common reporting requirement during month-end close is validating that all documents balance (debits equal credits). This query identifies unbalanced documents, which indicate data integrity issues:

WITH document_balances AS (
    SELECT
        i.bukrs,
        i.belnr,
        i.gjahr,
        SUM(CASE WHEN i.shkzg = 'S' THEN i.dmbtr ELSE 0 END) AS debit_total,
        SUM(CASE WHEN i.shkzg = 'H' THEN i.dmbtr ELSE 0 END) AS credit_total,
        ABS(SUM(CASE WHEN i.shkzg = 'S' THEN i.dmbtr ELSE -i.dmbtr END)) AS imbalance
    FROM bseg AS i
    WHERE i.bukrs = '1000'
        AND i.gjahr = 2024
    GROUP BY i.bukrs, i.belnr, i.gjahr
    HAVING ABS(SUM(CASE WHEN i.shkzg = 'S' THEN i.dmbtr ELSE -i.dmbtr END)) > 0.01
)
SELECT
    h.bukrs,
    h.belnr,
    h.gjahr,
    h.blart,
    h.budat,
    h.usnam,
    h.bktxt,
    b.debit_total,
    b.credit_total,
    b.imbalance
FROM document_balances AS b
INNER JOIN bkpf AS h
    ON b.bukrs = h.bukrs
    AND b.belnr = h.belnr
    AND b.gjahr = h.gjahr
ORDER BY b.imbalance DESC;

This CTE-based query first calculates debit/credit totals per document, filters to only unbalanced documents (allowing for 0.01 rounding tolerance), then joins back to BKPF for header details. The 0.01 tolerance handles minor rounding differences from currency conversions.

Join Pattern 2: SKA1-SKAS (Chart of Accounts Master Data)

The chart of accounts master data is split between SKA1 (general attributes) and SKAS (language-dependent descriptions and control indicators). While less commonly joined in transactional queries, these tables are essential for building financial reports that require account descriptions, financial statement assignments, and account control parameters.

Understanding SKA1 and SKAS

SKA1 (G/L Account Master - Chart of Accounts) contains language-independent account attributes:

SKAS (G/L Account Master - Chart of Accounts Segment) contains language-dependent text:

Basic SKA1-SKAS Join Pattern

The typical use case joins SKA1 to SKAS to retrieve account descriptions in a specific language for financial report displays:

SELECT
    a.ktopl AS chart_of_accounts,
    a.saknr AS account_number,
    s.txt50 AS account_description,
    a.bilkt AS balance_sheet_indicator,
    a.gvtyp AS pnl_account_type,
    a.ktoks AS account_group,
    a.func_area AS functional_area
FROM ska1 AS a
INNER JOIN skas AS s
    ON a.ktopl = s.ktopl
    AND a.saknr = s.saknr
    AND s.spras = 'E'  -- English language
WHERE a.ktopl = 'YCOA'  -- Your chart of accounts
    AND a.bilkt = 'X'   -- Balance sheet accounts only
ORDER BY a.saknr;

This query retrieves all balance sheet accounts from a specific chart of accounts with English descriptions. The language filter (SPRAS = 'E') is critical—omitting it can result in duplicate rows if your system maintains multiple languages.

Practical Example: Combining Account Master with Transactional Data

The real power of SKA1/SKAS joins emerges when you combine chart of accounts master data with transactional postings from BKPF/BSEG. This pattern creates a comprehensive general ledger report with account descriptions:

SELECT
    t001.butxt AS company_name,
    h.bukrs AS company_code,
    i.hkont AS account_number,
    s.txt50 AS account_description,
    a.bilkt AS account_type,
    COUNT(DISTINCT h.belnr) AS document_count,
    SUM(CASE WHEN i.shkzg = 'S' THEN i.dmbtr ELSE 0 END) AS debits,
    SUM(CASE WHEN i.shkzg = 'H' THEN i.dmbtr ELSE 0 END) AS credits,
    SUM(CASE WHEN i.shkzg = 'S' THEN i.dmbtr ELSE -i.dmbtr END) AS net_change
FROM bkpf AS h
INNER JOIN bseg AS i
    ON h.bukrs = i.bukrs
    AND h.belnr = i.belnr
    AND h.gjahr = i.gjahr
INNER JOIN t001 AS t001
    ON h.bukrs = t001.bukrs
INNER JOIN ska1 AS a
    ON t001.ktopl = a.ktopl
    AND i.hkont = a.saknr
LEFT JOIN skas AS s
    ON a.ktopl = s.ktopl
    AND a.saknr = s.saknr
    AND s.spras = 'E'
WHERE h.bukrs = '1000'
    AND h.gjahr = 2024
    AND h.budat BETWEEN '20240101' AND '20240331'  -- Q1 2024
    AND i.koart = 'S'
GROUP BY t001.butxt, h.bukrs, i.hkont, s.txt50, a.bilkt
ORDER BY i.hkont;

This query demonstrates the complete chain: BKPF → BSEG → T001 (company code) → SKA1 → SKAS. We join through T001 to get the chart of accounts (KTOPL) that links accounts to the company code. The result is a quarterly account activity summary with full account descriptions, essential for financial review packages.

Join Pattern 3: FAGLFLEXA-FAGLFLEXT (New General Ledger Tables)

With the introduction of SAP's New General Ledger (introduced in ECC 6.0 and standard in S/4HANA), financial reporting shifted from document-level queries to pre-aggregated ledger tables. FAGLFLEXA stores actual line items with full dimensional detail, while FAGLFLEXT maintains aggregated totals by period. Understanding when to use each table—and how to join them—is critical for high-performance financial reporting.

FAGLFLEXA: Actual Line Items

FAGLFLEXA contains individual posting line items in the New GL, similar to BSEG but with additional dimensions and multi-ledger support:

FAGLFLEXT: Totals Table

FAGLFLEXT stores pre-aggregated period totals, dramatically improving performance for balance sheet and P&L reporting:

When to Use FAGLFLEXA vs FAGLFLEXT

FAGLFLEXA Query Pattern: Line Item Analysis

SELECT
    f.rbukrs AS company_code,
    f.racct AS account,
    s.txt50 AS account_description,
    f.prctr AS profit_center,
    f.belnr AS document_number,
    f.budat AS posting_date,
    f.hsl AS local_amount,
    f.tsl AS transaction_amount,
    f.rtcur AS transaction_currency,
    f.segment
FROM faglflexa AS f
INNER JOIN t001 AS t
    ON f.rbukrs = t.bukrs
INNER JOIN ska1 AS a
    ON t.ktopl = a.ktopl
    AND f.racct = a.saknr
LEFT JOIN skas AS s
    ON a.ktopl = s.ktopl
    AND a.saknr = s.saknr
    AND s.spras = 'E'
WHERE f.rldnr = '0L'          -- Leading ledger
    AND f.rbukrs = '1000'
    AND f.gjahr = 2024
    AND f.budat BETWEEN '20240101' AND '20240131'  -- January 2024
    AND f.racct BETWEEN '400000' AND '499999'      -- Revenue accounts
ORDER BY f.budat, f.belnr, f.docln;

This query retrieves revenue line items for January 2024 with account descriptions. Note the HSL field contains signed amounts (positive for debits, negative for credits), unlike BSEG where amounts are always positive with a separate SHKZG indicator.

FAGLFLEXT Query Pattern: Multi-Period Comparison

SELECT
    t.rbukrs AS company_code,
    t.racct AS account,
    s.txt50 AS account_description,
    t.prctr AS profit_center,
    t.hslvt AS opening_balance,
    t.hsl01 AS january,
    t.hsl02 AS february,
    t.hsl03 AS march,
    (t.hsl01 + t.hsl02 + t.hsl03) AS q1_total,
    t.hsl04 AS april,
    t.hsl05 AS may,
    t.hsl06 AS june,
    (t.hsl04 + t.hsl05 + t.hsl06) AS q2_total,
    (t.hsl01 + t.hsl02 + t.hsl03 + t.hsl04 + t.hsl05 + t.hsl06) AS ytd_total
FROM faglflext AS t
INNER JOIN t001 AS c
    ON t.rbukrs = c.bukrs
INNER JOIN ska1 AS a
    ON c.ktopl = a.ktopl
    AND t.racct = a.saknr
LEFT JOIN skas AS s
    ON a.ktopl = s.ktopl
    AND a.saknr = s.saknr
    AND s.spras = 'E'
WHERE t.rldnr = '0L'
    AND t.rbukrs = '1000'
    AND t.gjahr = 2024
    AND t.racct BETWEEN '100000' AND '299999'  -- Balance sheet accounts
    AND a.bilkt = 'X'
ORDER BY t.racct, t.prctr;

This query demonstrates FAGLFLEXT's power for period comparison. Instead of aggregating individual postings, we directly access pre-calculated monthly totals (HSL01 through HSL06) and combine them for quarterly and YTD calculations. For a balance sheet report with thousands of accounts, this approach is 50-100 times faster than aggregating FAGLFLEXA or BSEG.

Advanced Pattern: Combining FAGLFLEXA and FAGLFLEXT

A powerful reporting pattern uses FAGLFLEXT for high-level summaries with drill-down capability to FAGLFLEXA for detailed analysis. This example creates a variance report comparing budget to actuals:

-- Summary level from FAGLFLEXT
WITH account_totals AS (
    SELECT
        t.rbukrs,
        t.racct,
        t.prctr,
        (t.hsl01 + t.hsl02 + t.hsl03) AS q1_actual
    FROM faglflext AS t
    WHERE t.rldnr = '0L'
        AND t.rbukrs = '1000'
        AND t.gjahr = 2024
        AND t.racct BETWEEN '600000' AND '799999'  -- Expense accounts
),
budget_data AS (
    SELECT
        b.rbukrs,
        b.racct,
        b.prctr,
        (b.hsl01 + b.hsl02 + b.hsl03) AS q1_budget
    FROM faglflext AS b
    WHERE b.rldnr = 'B1'  -- Budget ledger
        AND b.rbukrs = '1000'
        AND b.gjahr = 2024
        AND b.racct BETWEEN '600000' AND '799999'
)
SELECT
    a.rbukrs AS company_code,
    a.racct AS account,
    s.txt50 AS account_description,
    a.prctr AS profit_center,
    b.q1_budget AS budget,
    a.q1_actual AS actual,
    (a.q1_actual - b.q1_budget) AS variance,
    CASE
        WHEN b.q1_budget <> 0
        THEN ROUND(((a.q1_actual - b.q1_budget) / ABS(b.q1_budget)) * 100, 2)
        ELSE NULL
    END AS variance_percent
FROM account_totals AS a
INNER JOIN budget_data AS b
    ON a.rbukrs = b.rbukrs
    AND a.racct = b.racct
    AND a.prctr = b.prctr
INNER JOIN t001 AS c
    ON a.rbukrs = c.bukrs
INNER JOIN ska1 AS k
    ON c.ktopl = k.ktopl
    AND a.racct = k.saknr
LEFT JOIN skas AS s
    ON k.ktopl = s.ktopl
    AND k.saknr = s.saknr
    AND s.spras = 'E'
WHERE ABS(a.q1_actual - b.q1_budget) > 1000  -- Material variances only
ORDER BY ABS(a.q1_actual - b.q1_budget) DESC;

This CTE-based query compares actuals (ledger 0L) to budget (ledger B1) using FAGLFLEXT's period totals, then filters to material variances. For drill-down reporting, you would then query FAGLFLEXA filtering on the specific account and profit center showing variances.

Performance Optimization for Financial Reporting

Financial tables in SAP are among the largest in any system. A global company might have hundreds of millions of rows in BSEG and FAGLFLEXA. Query performance isn't just about speed—poorly optimized queries can bring production systems to a halt during month-end close when hundreds of users run reports simultaneously.

Index Usage and WHERE Clause Optimization

SAP delivers standard indexes on financial tables, but leveraging them requires discipline in query construction:

Optimized Example: General Ledger by Profit Center

-- Optimized approach: Filter first, then join
WITH filtered_items AS (
    SELECT
        i.bukrs,
        i.belnr,
        i.gjahr,
        i.buzei,
        i.hkont,
        i.prctr,
        i.dmbtr,
        i.shkzg
    FROM bseg AS i
    WHERE i.bukrs = '1000'
        AND i.gjahr = 2024
        AND i.hkont BETWEEN '400000' AND '899999'  -- P&L accounts only
        AND i.prctr IN ('PC01', 'PC02', 'PC03')    -- Specific profit centers
        AND i.koart = 'S'
)
SELECT
    h.bukrs,
    h.blart,
    i.prctr AS profit_center,
    i.hkont AS account,
    s.txt50 AS account_description,
    COUNT(DISTINCT i.belnr) AS documents,
    SUM(CASE WHEN i.shkzg = 'S' THEN i.dmbtr ELSE -i.dmbtr END) AS net_amount
FROM filtered_items AS i
INNER JOIN bkpf AS h
    ON i.bukrs = h.bukrs
    AND i.belnr = h.belnr
    AND i.gjahr = h.gjahr
INNER JOIN t001 AS c
    ON i.bukrs = c.bukrs
INNER JOIN ska1 AS a
    ON c.ktopl = a.ktopl
    AND i.hkont = a.saknr
LEFT JOIN skas AS s
    ON a.ktopl = s.ktopl
    AND a.saknr = s.saknr
    AND s.spras = 'E'
WHERE h.budat BETWEEN '20240101' AND '20241231'
GROUP BY h.bukrs, h.blart, i.prctr, i.hkont, s.txt50
ORDER BY i.prctr, i.hkont;

This CTE approach filters BSEG first using indexed fields (BUKRS, GJAHR, HKONT range, PRCTR), dramatically reducing the result set before joining to BKPF and master data tables. For a system with 50 million BSEG rows in fiscal year 2024, filtering to specific profit centers might reduce the working set to 50,000 rows—a 1,000x reduction that enables sub-second query execution.

Common Pitfalls and Troubleshooting

Pitfall 1: Incorrect Debit/Credit Handling

Different table structures store amounts differently. BSEG stores absolute amounts with SHKZG indicator, while FAGLFLEXA uses signed amounts. Mixing these approaches causes incorrect totals:

-- INCORRECT for BSEG (ignores debit/credit indicator)
SELECT SUM(dmbtr) FROM bseg WHERE hkont = '200000';

-- CORRECT for BSEG
SELECT SUM(CASE WHEN shkzg = 'S' THEN dmbtr ELSE -dmbtr END)
FROM bseg WHERE hkont = '200000';

-- CORRECT for FAGLFLEXA (already signed)
SELECT SUM(hsl) FROM faglflexa WHERE racct = '200000';

Pitfall 2: Missing Ledger Filter in New GL Queries

Systems with parallel accounting have multiple ledgers. Omitting the ledger filter (RLDNR) returns duplicate data from all ledgers:

-- INCORRECT: Returns actuals + budget + other ledgers
SELECT racct, SUM(hsl) FROM faglflexa
WHERE rbukrs = '1000' GROUP BY racct;

-- CORRECT: Leading ledger actuals only
SELECT racct, SUM(hsl) FROM faglflexa
WHERE rldnr = '0L' AND rbukrs = '1000' GROUP BY racct;

Pitfall 3: Language-Dependent Text Without SPRAS Filter

SKAS and other text tables store descriptions in multiple languages. Joining without a language filter creates duplicate rows:

-- INCORRECT: Duplicates for each language maintained
SELECT a.saknr, s.txt50 FROM ska1 a
JOIN skas s ON a.ktopl = s.ktopl AND a.saknr = s.saknr;

-- CORRECT: Single language specification
SELECT a.saknr, s.txt50 FROM ska1 a
JOIN skas s ON a.ktopl = s.ktopl AND a.saknr = s.saknr
AND s.spras = 'E';

Pitfall 4: Querying BSEG Instead of Specialized Tables

Customer and vendor line items should be queried from BSID/BSAD (customer) and BSIK/BSAK (vendor) tables, not BSEG. These specialized tables contain additional fields and better indexes for AR/AP reporting:

-- SUBOPTIMAL: Using BSEG for customer open items
SELECT * FROM bseg
WHERE koart = 'D' AND augbl = '';

-- OPTIMAL: Using specialized table with better indexes
SELECT * FROM bsid
WHERE bukrs = '1000' AND gjahr = 2024;

Real-World Reporting Scenarios

Scenario 1: Trial Balance Report

A trial balance shows all accounts with their debit and credit totals for a specific period. Using FAGLFLEXT provides optimal performance:

SELECT
    t.rbukrs AS company_code,
    co.butxt AS company_name,
    t.racct AS account,
    s.txt50 AS account_description,
    a.bilkt AS account_type,
    t.hslvt AS opening_balance,
    (t.hsl01 + t.hsl02 + t.hsl03 + t.hsl04 + t.hsl05 + t.hsl06 +
     t.hsl07 + t.hsl08 + t.hsl09 + t.hsl10 + t.hsl11 + t.hsl12) AS period_activity,
    (t.hslvt + t.hsl01 + t.hsl02 + t.hsl03 + t.hsl04 + t.hsl05 + t.hsl06 +
     t.hsl07 + t.hsl08 + t.hsl09 + t.hsl10 + t.hsl11 + t.hsl12) AS ending_balance
FROM faglflext AS t
INNER JOIN t001 AS co
    ON t.rbukrs = co.bukrs
INNER JOIN ska1 AS a
    ON co.ktopl = a.ktopl
    AND t.racct = a.saknr
LEFT JOIN skas AS s
    ON a.ktopl = s.ktopl
    AND a.saknr = s.saknr
    AND s.spras = 'E'
WHERE t.rldnr = '0L'
    AND t.rbukrs = '1000'
    AND t.gjahr = 2024
ORDER BY t.racct;

Scenario 2: Document Aging Analysis

Analyzing document posting patterns by age requires BKPF-BSEG joins with date calculations:

SELECT
    h.bukrs,
    h.blart AS doc_type,
    DATEDIFF(day, h.cpudt, h.budat) AS days_to_post,
    CASE
        WHEN DATEDIFF(day, h.cpudt, h.budat) <= 1 THEN 'Same Day'
        WHEN DATEDIFF(day, h.cpudt, h.budat) <= 7 THEN 'Within Week'
        WHEN DATEDIFF(day, h.cpudt, h.budat) <= 30 THEN 'Within Month'
        ELSE 'Over 30 Days'
    END AS aging_bucket,
    COUNT(*) AS document_count,
    AVG(DATEDIFF(day, h.cpudt, h.budat)) AS avg_days_to_post
FROM bkpf AS h
WHERE h.bukrs = '1000'
    AND h.gjahr = 2024
    AND h.cpudt IS NOT NULL
    AND h.budat IS NOT NULL
GROUP BY h.bukrs, h.blart,
    CASE
        WHEN DATEDIFF(day, h.cpudt, h.budat) <= 1 THEN 'Same Day'
        WHEN DATEDIFF(day, h.cpudt, h.budat) <= 7 THEN 'Within Week'
        WHEN DATEDIFF(day, h.cpudt, h.budat) <= 30 THEN 'Within Month'
        ELSE 'Over 30 Days'
    END
ORDER BY h.blart, avg_days_to_post;

Conclusion: Mastering Financial Table Joins

SAP financial reporting demands expertise in multiple table join patterns, each optimized for specific use cases. The BKPF-BSEG relationship provides granular document-level detail essential for audit trails and transaction analysis. SKA1-SKAS joins enrich reports with descriptive account information and control parameters. The New General Ledger tables—FAGLFLEXA for line items and FAGLFLEXT for aggregated totals—enable high-performance financial statements and period comparisons.

Success in SAP FI reporting comes from understanding when to use each table structure:

• Use BKPF-BSEG for detailed document analysis, audit reports, and transaction-level drill-down
• Use SKA1-SKAS to add account descriptions and master data attributes to any financial report
• Use FAGLFLEXA when you need New GL line item detail with dimensional analysis
• Use FAGLFLEXT for balance sheets, P&L statements, and any multi-period comparison reporting
• Always filter on fiscal year (GJAHR) to leverage table partitioning
• Include ledger filters (RLDNR) for all New GL queries in parallel accounting environments
• Handle debit/credit amounts correctly based on table structure (SHKZG vs signed amounts)

The SQL patterns presented in this guide form the foundation for virtually all SAP financial reporting scenarios. Whether you're building month-end close packages, developing custom financial statements, or creating management dashboards, mastering these table relationships and join patterns will dramatically accelerate your development work and ensure your queries perform optimally even with millions of financial documents.