Vendor Balances

Each supplier’s balance — the carryforward brought in from last year, this period’s debits and credits, and the closing balance. The old FK10N, built on I_OperationalAcctgDocItem.

Sample build of the Vendor Balances report — carryforward, period movement, and closing balance per supplier, reconciled to the payables control account, and rendered tool-neutral so it runs in Power BI, SAC, or Tableau.

Vendor Balances sample

period 01–04 / 2026

Filters

Company code

1010

Supplier

All

Fiscal year

2026

Periods

01 – 04

12.40M

Total balance

8.10M

Carryforward

+4.30M

Net movement

248

Suppliers

Supplier	Carryforward	Debits	Credits	Balance
4800021 · Northwind Steel	2,100,000	1,200,000	1,720,000	2,620,000
4800033 · Globex Logistics	1,800,000	400,000	730,000	2,130,000
4800015 · Acme Components	1,300,000	600,000	760,000	1,460,000
4800052 · Pinnacle Freight	240,000	520,000	100,000	(180,000)

AI Analyst · active

reading

Each supplier's balance is its carryforward — the Period 0 opening brought in from last year — plus the period's credits minus debits. The total reconciles to the payables control account on the trial balance.

flag

Supplier 4800052 (Pinnacle Freight) shows a debit balance of 180K — you've paid more than you owe. Usually a duplicate payment or an unapplied credit; worth recovering before year-end.

root cause & next step

If a balance doesn't match the line-item report, special-G/L items (down payments) are the usual cause — the balance includes them, the standard line-item view may not. Reconcile on account type, reconciliation account, and special G/L.

Illustrative data · tied to the supplier sub-ledger · runs on your warehouse. See it live →

ACDOCA · incl. Period 0+Business Partner────▶Vendor Balances

The report's query logic — it sums the released CDS view I_OperationalAcctgDocItem (vendor lines) per supplier, taking Period 0 as the carryforward and the period movements as debits and credits. The same SQL becomes a dbt model in your warehouse.

How it interconnects: the carryforward comes from ACDOCA's Period 0 documents (created by the A/P balance-carryforward run). It never reads the legacy KNC1 / LFC1 balance views — those are compatibility views over the same ACDOCA data.

SQL data set · genericized · parameterized · carryforward from Period 0, never KNC1 / LFC1

Show / hide SQL

SELECT it.Supplier,
       SUM(CASE WHEN it.FiscalPeriod = 0
                THEN it.AmountInCompanyCodeCurrency ELSE 0 END)            AS carryforward,
       SUM(CASE WHEN it.FiscalPeriod BETWEEN 1 AND :P_TO_PERIOD
                 AND it.DebitCreditCode = 'S'                              -- S = debit
                THEN it.AmountInCompanyCodeCurrency ELSE 0 END)            AS period_debits,
       SUM(CASE WHEN it.FiscalPeriod BETWEEN 1 AND :P_TO_PERIOD
                 AND it.DebitCreditCode = 'H'                              -- H = credit
                THEN it.AmountInCompanyCodeCurrency ELSE 0 END)            AS period_credits,
       SUM(CASE WHEN it.FiscalPeriod <= :P_TO_PERIOD
                THEN it.AmountInCompanyCodeCurrency ELSE 0 END)            AS balance
FROM   I_OperationalAcctgDocItem AS it
WHERE  it.FinancialAccountType   = 'K'             -- K = vendor (Kreditor)
  AND  it.CompanyCode            = :P_COMPANY_CODE
  AND  it.FiscalYear             = :P_FISCAL_YEAR
GROUP  BY it.Supplier
ORDER  BY balance DESC;

The classic check: the balance here should reconcile to the Vendor Line Items total. When they differ, special-G/L items (down payments) are almost always the reason — the balance includes them; the standard open-item view may not. Match on account type K, reconciliation account, and special G/L.

The data-warehouse model — one fact surrounded by conformed dimensions (what you slice by) and measures (what you aggregate), expressed as dbt so it migrates with you. Grain: one row per supplier · period.

●— fact → dimension join

Element	Type	Definition
dim_supplier	dimension	Supplier — Business Partner (supplier role), name, group
dim_company_code	dimension	Company code & ledger context
dim_gl_account	dimension	Reconciliation (payables) account — RACCT
dim_date	dimension	Conformed calendar — fiscal year & period
carryforward	measure	Period 0 opening brought in from the prior year
period_debits	measure	Sum of debit movements in the period range
period_credits	measure	Sum of credit movements in the period range
balance	measure	Carryforward + credits − debits, cumulative to the period

Runs on your cloud warehouse — Snowflake, BigQuery, Redshift, or Synapse. Reconciled to the supplier sub-ledger — 0% variance by design. You own the code, the model, and the data.

How the data gets here: a SAP-compliant extract — released CDS view via SLT, or Table / Table-CDC — never ODP-RFC (prohibited under SAP Note 3255746, blocked June 2026). See the extraction pattern & data flow →

See the complete model

How this report's fact and dimensions fit the full ACDOCA-centered picture, via conformed keys.

Accounts Payable data model → Enterprise model →

Every source object behind this report. Each linked object has its own page — with its fields and its real S/4HANA status, so you build on the right thing.

Object	Role	Key fields	S/4HANA status
I_OperationalAcctgDocItem	Vendor line item, summed per supplier — the read object	released	Released CDS view
ACDOCA	Universal Journal — movements plus the Period 0 carryforward	6 PK · 360+	Transparent table
BSEG	Open-item management & payment terms (baseline date, net days)	4 PK	Transparent table
Business Partner	Supplier master (supplier role) — the dimension	BUT000	Transparent table
KNC1 / LFC1	Legacy vendor / customer balance tables — reference only, do not extract	—	Compat view → ACDOCA
Display Supplier Balances	The S/4HANA app (FK10N's successor) this report reconciles to — reference	app	Reconcile target

Key fields = the primary key plus the columns this report selects; S/4HANA status = whether the object is a live transparent table, a released CDS view, or a compatibility view over ACDOCA. The compat views are referenced by legacy joins but are never the extraction source — that's the point, not a gap.

Want this built & owned?

A reconciled, customer-owned vendor balance layer on your cloud — your team owns the code. Ten-day proof of concept.

Download the AP pack → Talk to us →

Terms on this page

Balance: What a supplier account totals: carryforward plus the period’s credits minus debits.
Carryforward: The opening balance brought in from the prior fiscal year.
Period 0: How ACDOCA stores the carryforward — a special “period zero” document.
Special G/L: Items like down payments shown separately — the usual reconciliation gap.
Debit / credit: The two sides of a posting; a vendor balance is normally a credit.
KNC1 / LFC1: The old customer / vendor balance tables — now compatibility views.
ACDOCA: SAP's single table holding every finance posting (the "Universal Journal").
Reconciliation account: The single G/L account the supplier sub-ledger rolls up into.
I_OperationalAcctgDocItem: The released view that gives the vendor line with its terms (account type K = vendor).
Business Partner: The single S/4HANA master for suppliers and customers (table BUT000).
ODP-RFC: An older extraction route SAP now bans for non-SAP tools (Note 3255746).