Analytics Catalog/SAP S/4HANA/Accounts Receivable/Customer Balances
Explore the catalogCustomer Line ItemsAccounts ReceivableACDOCAExtraction
SAP S/4HANA · Accounts Receivable (FI-AR)

Customer Balances

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

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

Customer Balances sample
period 01–04 / 2026
Filters
Company code
1010
Customer
All
Fiscal year
2026
Periods
01 – 04
9.80M
Total balance
6.40M
Carryforward
+3.40M
Net movement
326
Customers
CustomerCarryforwardDebitsCreditsBalance
1400021 · Horizon Retail1,900,0001,600,0001,180,0002,320,000
1400033 · Cedar Foods1,500,000980,000650,0001,830,000
1400015 · Atlas Media900,000740,000420,0001,220,000
1400052 · Brightway Clinics120,00080,000360,000(160,000)
AI Analyst · active
reading

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

flag

Customer 1400052 (Brightway Clinics) shows a credit balance of 160K — they've paid more than they owe, or a credit memo is sitting unapplied. Apply or refund it before it ages.

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 customer sub-ledger · runs on your warehouse. See it live →
ACDOCA · incl. Period 0+Business Partner────▶Customer Balances

The report's query logic — it sums the released CDS view I_OperationalAcctgDocItem (customer lines) per customer, 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/R 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.Customer,
       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   = 'D'             -- D = customer (Debitor)
  AND  it.CompanyCode            = :P_COMPANY_CODE
  AND  it.FiscalYear             = :P_FISCAL_YEAR
GROUP  BY it.Customer
ORDER  BY balance DESC;
The classic check: the balance here should reconcile to the Customer 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 D, 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 customer · period.

dim_customerBusiness Partner · group dim_company_codecompany · ledger dim_gl_accountrecon account dim_datefiscal period fct_ar_balancefact · one row per customer · periodcarryforward · debit · credit · balance
●— fact → dimension join
ElementTypeDefinition
dim_customerdimensionCustomer — Business Partner (customer role), name, group
dim_company_codedimensionCompany code & ledger context
dim_gl_accountdimensionReconciliation (receivables) account — RACCT
dim_datedimensionConformed calendar — fiscal year & period
carryforwardmeasurePeriod 0 opening brought in from the prior year
period_debitsmeasureSum of debit movements in the period range
period_creditsmeasureSum of credit movements in the period range
balancemeasureCarryforward + credits − debits, cumulative to the period
Runs on your cloud warehouse — Snowflake, BigQuery, Redshift, or Synapse. Reconciled to the customer 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 Receivable 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.

ObjectRoleKey fieldsS/4HANA status
I_OperationalAcctgDocItemCustomer line item, summed per customer — the read objectreleasedReleased CDS view
ACDOCAUniversal Journal — movements plus the Period 0 carryforward6 PK · 360+Transparent table
BSEGOpen-item management & payment terms (baseline date, net days)4 PKTransparent table
Business PartnerCustomer master (customer role) — the dimensionBUT000Transparent table
KNC1 / LFC1Legacy vendor / customer balance tables — reference only, do not extractCompat view → ACDOCA
Display Customer BalancesThe S/4HANA app (FD10N's successor) this report reconciles to — referenceappReconcile 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 customer 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 customer account totals: carryforward plus the period’s debits minus credits.
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 customer balance is normally a debit.
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 customer sub-ledger rolls up into.
I_OperationalAcctgDocItem
The released view that gives the customer line with its terms (account type D = customer).
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).