Analytics Catalog/SAP S/4HANA/Accounts Receivable/AR Aging
Explore the catalogReportsModulesEnterprise modelCDS viewsExtraction
SAP S/4HANA · Accounts Receivable (FI-AR)

AR Aging — Overdue Receivables

Every open customer invoice, sorted by how overdue it is — so you can see who owes you, who's late, and where to focus collections. Built on I_OperationalAcctgDocItem and tied to the customer sub-ledger.

Sample build of the AR Aging report — bucketed by net due date as of a key date, tied to the Manage Customer Line Items balance, and rendered tool-neutral so it runs in Power BI, SAC, or Tableau.

AR Aging — Overdue Receivables sample
reconciled · key date 22 Jun 2026
Filters
Company code
1010
Key date
22 Jun 2026
Account type
D · Customer
Currency
USD
14.80M
Open receivables
11.30M
Not yet due
3.50M
Overdue
24%
Overdue share
CustomerCurrent1–3031–6060+Total
100245 · Riverside Retail3,100,000220,0003,320,000
100318 · Summit Wholesale1,400,000680,000410,0001,350,0003,840,000
100402 · Cedar Foods2,250,000140,00060,0002,450,000
100455 · Harbor Supply1,180,00090,00040,0001,310,000
AI Analyst · active
reading

Open customer items are bucketed by net due date — invoice baseline date plus payment terms — as of the key date, by customer and company code, and tied to the Manage Customer Line Items balance.

flag

Customer 100318 (Summit Wholesale) has 1.35M past 60 days — 35% of its balance — and it's already at dunning level 2. That's a collections and credit-risk signal, not normal lateness.

root cause & next step

Route the 60-plus items to collections and escalate the dunning level before they age into bad debt. Clearing or disputing them lowers DSO and frees working capital.

Illustrative data · tied to the customer sub-ledger · runs on your warehouse. See it live →
ACDOCA+BSEG · terms+Business Partner────▶AR Aging

The report's query logic — it reads the released CDS view I_OperationalAcctgDocItem (customer lines), works out each item's due date, and sorts it into aging buckets. The same SQL becomes a dbt model in your warehouse.

How it interconnects: it reads the released CDS view — not the legacy BSID / BSAD compatibility views. The amount comes from ACDOCA; the payment terms and due date come from BSEG, surfaced by the view as PaymentTerms and NetPaymentDays.
SQL data set · genericized · parameterized · released CDS view, never compat views
Show / hide SQL
WITH ar_open AS (
  SELECT it.CompanyCode,
         it.Customer,
         it.GLAccount                                AS recon_account,
         je.AccountingDocument,
         je.FiscalYear,
         it.AmountInCompanyCodeCurrency              AS open_amount,
         it.PaymentTerms,
         it.NetPaymentDays,
         ADD_DAYS(it.DocumentItemDate,
                  TO_INTEGER(it.NetPaymentDays))      AS net_due_date,
         DAYS_BETWEEN(ADD_DAYS(it.DocumentItemDate,
                  TO_INTEGER(it.NetPaymentDays)),
                  :P_KEY_DATE)                        AS days_overdue
  FROM   I_JournalEntry            AS je
  JOIN   I_OperationalAcctgDocItem AS it
         ON  je.CompanyCode        = it.CompanyCode
         AND je.AccountingDocument = it.AccountingDocument
         AND je.FiscalYear         = it.FiscalYear
  WHERE  it.FinancialAccountType   = 'D'             -- D = customer (Debitor)
    AND  it.CompanyCode            = :P_COMPANY_CODE
    AND  it.ClearingDate           IS NULL           -- open as of the key date
)
SELECT Customer,
       SUM(CASE WHEN days_overdue <= 0                  THEN open_amount ELSE 0 END) AS current_not_due,
       SUM(CASE WHEN days_overdue BETWEEN  1 AND 30      THEN open_amount ELSE 0 END) AS d_1_30,
       SUM(CASE WHEN days_overdue BETWEEN 31 AND 60      THEN open_amount ELSE 0 END) AS d_31_60,
       SUM(CASE WHEN days_overdue > 60                   THEN open_amount ELSE 0 END) AS d_60_plus,
       SUM(open_amount)                                                              AS total_open
FROM   ar_open
GROUP  BY Customer
ORDER  BY d_60_plus DESC;
To tie out to the Manage Customer Line Items ledger, match its open-item conditions: account type D, special-G/L indicator, posting date, and clearing date as of the key date. Open = not cleared on or before that date.

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 open AR item.

dim_customerBusiness Partner · group dim_company_codecompany · ledger dim_gl_accountrecon account dim_datenet due date fct_ar_open_itemsfact · one row per open AR itemopen_amount · days_overdue · bucket
●— 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 on the net due date
open_amountmeasureOpen amount in company-code currency (HSL)
days_overduemeasureKey date minus net due date
aging_bucketmeasureCurrent / 1–30 / 31–60 / 60+ derived from days_overdue
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 with payment terms — the read objectreleasedReleased CDS view
ACDOCAUniversal Journal — the open amount & account assignment6 PK · 360+Transparent table
BSEGOpen-item management & payment terms (baseline date, net days)4 PKTransparent table
Business PartnerCustomer master (customer role) — the dimensionBUT000Transparent table
BSID / BSADLegacy customer open/cleared index — reference only, do not extractCompat view → ACDOCA
C_OverdueAcctRblsSAP's standard overdue receivables / aging grid (Overdue Receivables app) — referencereleasedReleased CDS view
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 AR aging layer on your cloud — your team owns the code. Ten-day proof of concept.
Download the AR pack → Talk to us →
Terms on this page
AR aging
Open customer invoices grouped by how overdue they are.
Net due date
When an invoice is actually due: its baseline date plus the payment-term days.
ACDOCA
SAP's single table holding every finance posting (the "Universal Journal").
BSEG
The table that still manages open items and payment terms in S/4HANA.
CDS view
Core Data Services — an SAP-supplied, upgrade-safe view onto the data.
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 customers and suppliers (table BUT000).
BSID / BSAD
The old customer open / cleared tables — now compatibility views; don't extract them.
DSO
Days Sales Outstanding — the average days it takes customers to pay you.
ODP-RFC
An older extraction route SAP now bans for non-SAP tools (Note 3255746).
star schema
A simple, report-friendly layout: one "facts" table with "lookup" tables around it.