What Is Account Receivable Visibility, and How Do You Keep It Current in Real Time?
Josue Ramirez
Last updated: August 2026
What is account receivable visibility?
Account receivable visibility is a current view of what customers owe, assembled from the accounting documents that recorded the invoices, the clearing documents that recorded the payments, and the sales orders that represent business already committed but not yet invoiced.
The four key points:
- It is not one table. Receivables sit across Finance and Sales and Distribution, and a view built on one module understates the picture.
- It is not the receivables balance alone. Credit exposure is what the customer owes plus what they are about to owe.
- An invoice is not marked paid by a flag. It is cleared by a second document that points back at the first, which is where payment behavior actually lives.
- Freshness is a property of the design, not of the reporting cadence. If the view is rebuilt on an overnight schedule, every credit decision made during the day is made against yesterday's exposure.
The whole shape on one page: source, transport, engine and consumer.
Why can you not build it from one SAP table?
Because the question spans two SAP modules and four kinds of document.
BSID holds open customer items. BSAD holds cleared ones. A query that reads only open items has a balance with no payment history. The accounting record behind both is the Universal Journal, ACDOCA, joined to BSEG for the document segment. The customer's name, terms and grouping live in the customer master, KNA1 with KNB1, KNVV and KNVP. And the orders a customer has placed that have not yet been invoiced live in VBAK and VBAP, in Sales and Distribution.
Leave out the cleared items and you cannot compute days sales outstanding. Leave out the customer master and you cannot tell overdue from merely outstanding, because the payment terms are not in the accounting document. Leave out Sales and Distribution and you understate exposure by exactly the amount of business currently in flight.
How does SAP data reach the receivables view?
Three hops, and the first one starts with a definition rather than with code.
SAP to Kafka. In the OneConnect SAP Data Modeler you declare what a data product is: which SAP tables belong to it, how they join, and what every field is called on the way out. That declaration ships as a pair of spreadsheets. For the receivables product the first declares sixteen source entities with their join topology, and the second declares 1,203 fields, each with its source table, its published business name, whether it is a key and whether it is selectable.
Onibex OneConnect then captures changes in SAP ECC and SAP S/4HANA through application-layer business events (RAP, BOR, BTE, PPF), pushed outbound over an HTTP RFC destination of Type G to the Smart Gateway, and streamed to Apache Kafka, Confluent Cloud, Databricks, Snowflake, and other targets, with topics and schema registry entries created on the fly and schema evolution supported. Nothing is read from the database layer. Nothing is pulled.
Kafka to the engine. From those topics the data is transformed into layered entities. That transformation runs in Snowflake, Databricks, PostgreSQL or Flink SQL, and it is the same logic in all four.
The engine to the consumer. A dashboard, a warehouse, a CRM, a machine learning workload. They query the top layer and never touch SAP.
What sits in each medallion layer?
The middle hop follows the medallion architecture, and the clearest way to read it is as a count that shrinks.
| Layer | What it holds | Count |
|---|---|---|
| Bronze | Foundational data products: raw SAP tables grouped into the smallest units that mean something on their own | 16 |
| Silver | Business data products: one per business concept | 7 |
| Gold | Consolidations, unit of measure normalizations, summaries, and the two consumers query | 8 |
| Published surface | The two entities a dashboard, warehouse or model actually reads | 2 |
Sixteen becomes seven because the eight organizational structure entities are not concepts in their own right, they are descriptions attached later, and the two receivables entities, open items and cleared items, collapse into a single journal entries product.
Those sixteen come from four areas of SAP: Finance contributes three, order to cash four, human resources one, and organizational structure eight. Half the sources in a finance data product are not financial. They are the semantics that make a finance number readable by somebody who does not know SAP.
Sixteen foundational data products, seven business data products, eight gold entities, and five kinds of consumer on top.
Why does credit exposure span Finance and Sales?
Because the pipeline answers two questions, and they live in different modules. It runs two streams that never merge.
The finance stream answers what has been invoiced and not paid. It is anchored on ACDOCA, joined to BSEG on document, fiscal year and line item, and to BSID on company code, document, fiscal year, line item and customer. Cleared items join differently: BSAD on ACDOCA.BELNR = BSAD.AUGBL, the clearing document. An invoice becomes paid because a second document appears and points back at it.
The sales stream answers what has been committed and not yet invoiced. It is anchored on the sales order, VBAK with VBAP, VBFA, VBPA and VBKD, and it ends with a filter that is the definition of an open order written as three exclusions:
WHERE a.invoice <> 'X'
AND a.deposit <> 'X'
AND a.credit_note <> 'X'
Everything already billed, prepaid or credited comes out. What remains is business the company has committed to and has not yet turned into a receivable. That is the part a finance-only view misses.
What does the data product publish?
Two entities, at two different grains, sharing one dimensional spine.
| Journal entries contract | Open sales orders contract | |
|---|---|---|
| Grain | One journal entry line | One open sales order item |
| Key | Client, ledger, document, line item, fiscal year, company code | Sales order and item |
| Answers | What is invoiced and unpaid | What is committed and not invoiced |
| Measures | Quantity in base unit, amount in group currency | Net value and currency |
| Receivable state | Due date, payment terms, clearing document and date, on both the open and cleared sides | Invoice, deposit and credit note flags |
| Dimensions | Sales organization, distribution channel, division, plant, customer, customer groups, sales group, region, Nielsen indicator, each with its description | The same set |
| Ownership | Sales representative personnel number | The same |
The repetition in the last two rows is the design, not an accident. Because both contracts carry the same dimensional spine, one set of filters narrows both halves of the picture in the same way. If the two streams had been enriched independently, a regional exposure figure would stop reconciling with the sum of its parts.
What does the dashboard show, and where does each tile come from?
The data layer ships in four flavors. The dashboard ships in one: a Power BI report built directly on the two gold entities.
| Element | What it resolves to |
|---|---|
| Total and overdue receivables | Open item amount, compared against the due date |
| Percent overdue | The ratio of those two |
| Days sales outstanding | Posting date and clearing date, with the measure defined in the reporting layer |
| Cash collected | Clearing date and cleared amount from the cleared items side |
| Predicted cash | Both streams: receivables coming due plus open orders expected to bill |
| Aging analysis | Due date and payment term day count, with the bucket boundaries set in reporting |
| Top customers | Customer name and amount, ranked |
| Invoice ledger | The underlying grain made visible |
| Six filters | The shared dimensional spine of the two contracts |
Nothing on that page needs a join. The report reads two tables and does arithmetic, which is what a data product is supposed to leave for the consumer.
Which engines can maintain it in real time?
Four, each using that platform's own incremental primitive. The contract is identical across all of them.
| Engine | How the layers are maintained |
|---|---|
| Snowflake | Dynamic tables on incremental refresh, riding Snowflake's change tracking |
| Databricks | Streaming tables fed by the change data feed of the bronze Delta tables, folded by key with apply_changes |
| PostgreSQL | Layers maintained by stored procedures |
| Flink SQL | A continuously running job per layer, upsert changelog over compacted Kafka topics |
In the Snowflake implementation the freshness target is written down rather than inherited. Every silver and intermediate gold table is declared REFRESH_MODE = INCREMENTAL with TARGET_LAG = DOWNSTREAM, and the final entity the dashboard reads declares TARGET_LAG = '1 minutes'. Everything upstream inherits it.
That is the difference worth naming. Bronze, silver and gold are frequently built as scheduled batch jobs, one layer waiting on the one below, which is how a three-layer architecture turns into a three-window delay. Here every layer is maintained incrementally, so the freshness of the gold entity is not the sum of three schedules.
Frequently asked questions
What is account receivable visibility?
Account receivable visibility is a current view of what customers owe, built from open customer items, cleared items, the accounting documents behind them, and the sales orders already committed but not yet invoiced. It spans Finance and Sales and Distribution, because credit exposure includes business in flight as well as invoiced balances.
Which SAP tables does an account receivable visibility data product read?
The finance side is anchored on ACDOCA, the Universal Journal, joined to BSEG, to BSID for open customer items and to BSAD for cleared items through the clearing document. The sales side reads VBAK, VBAP, VBFA, VBPA and VBKD, plus billing in VBRK and VBRP. Customer master, material, exchange rate, personnel and organizational structure tables complete the sixteen source entities.
Can accounts receivable be updated in real time without changing SAP?
Yes. Capture happens at the application layer through business events pushed outbound over an RFC destination of Type G, so nothing reads the database layer and nothing modifies the SAP core. The layered entities downstream are maintained incrementally rather than rebuilt on a schedule.
Does this work on Snowflake and Databricks, or only one of them?
The same two output contracts ship in four implementations: Snowflake, Databricks, PostgreSQL and Flink SQL. They differ in where state lives and how the incremental update is expressed. A consumer querying the published entity cannot tell which one is running underneath.
What Account Receivable Visibility does not do
It does not set thresholds. Deciding that a customer at ninety percent of limit gets released and one at ninety-five does not is a business judgment, not a data problem.
It does not define your metrics for you. Aging bucket boundaries and the days sales outstanding formula live in the reporting layer, because two finance teams will define them differently and neither definition belongs baked into a pipeline.
It does not remove configuration. The material types included in the sales figures and the currency the conversion targets are parameters in the transformation scripts. Both change the number on the dashboard, and both need an owner.
It does not resolve a definition nobody wrote down. If two teams disagree about whether a disputed invoice counts toward exposure, a current view gets them to the disagreement sooner and no closer to resolving it.
About Onibex
Onibex is an SAP Silver Partner and Confluent Gold Partner building real-time SAP data hyperconnectivity for the enterprise. Its flagship platform, Onibex OneConnect, streams SAP ECC and SAP S/4HANA business events to Apache Kafka, Confluent Cloud, Databricks, Snowflake, and other destinations in real time. Onibex also maintains ASK (Agentic Semantic Knowledge), an open semantic-layer standard that grounds AI agents in governed, business-ready SAP data. Onibex is headquartered in The Woodlands, Texas.
Technical reference: the deployment artifacts, integration steps and cost and licensing analysis for this use case are documented in oneconnect-docs. The Account Receivable Visibility data product is listed in the Onibex Marketplace, alongside the Finance data products it consumes.
Related reading: What Is an SAP Data Product, and How Does It Fit a Data Mesh?