Who Owns Receivables?
Last updated 12 Oct 2026
At a glance
Both billing and ERP come with accounts receivable: what each customer owes, payments against it, and dunning when they do not pay. With millions of consumer accounts, only one should own it. Which one is a design decision, and it sets how billing posts to the ledger.
The picture
Two workable places for customer receivables. Each customer’s receivable lives in exactly one.
A · Billing owns receivables
Telco billing
Invoice, receivable, payments, dunning, collections
ERP general ledger
Balances only; drill-down goes back to billing
Usual where billing comes from a telco BSS vendor
B · ERP subledger owns receivables
Convergent charging and invoicing
Rates usage, creates the invoice
ERP receivables subledger
High-volume contract accounting (e.g. SAP FI-CA)
ERP general ledger
Receivables and ledger on one platform
Both keep live receivables
Two balances, two dunning runs, two credit decisions for the same customer
How it works
The two patterns
In the first, billing owns receivables: the telco billing platform handles payments, dunning and collections at subscriber scale, and the ledger receives summaries. In the second, an ERP subledger owns receivables: invoicing creates the receivable directly in a high-volume subledger, which posts to the ledger on the same platform.
SAP’s stack shows the second pattern end to end. Convergent charging rates usage, convergent invoicing creates the invoice and the receivable in FI-CA at the same time, and FI-CA posts to the receivable and revenue accounts of the S/4HANA ledger. SAP calls FI-CA “the first choice subledger” for high-volume service industries including telecommunications; that is SAP’s own positioning. Operators whose billing comes from a telco BSS vendor typically keep receivables in billing and post summaries.
B2B is often different
Large business customers with negotiated contracts, few invoices and finance-led collections are sometimes managed in ERP receivables even where consumer receivables stay in billing. That works only if each customer’s receivables are owned in exactly one place.
Summarised or detailed posting
| Summarised journals | Detailed posting | |
|---|---|---|
| What arrives in ERP | Totals by account, product line, period and legal entity | Every invoice, or close to it |
| ERP load | Light | Telco volumes inside the ERP; needs a high-volume subledger |
| Drill-down from ledger to invoice | Through billing, by control totals | Inside ERP |
| Where reconciliation happens | Billing totals against ledger totals | Within one platform |
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Customer receivable (open item) | Billing, or the ERP receivables subledger: one, never both | — | General ledger (control account) | The decision of this section. |
| Invoice | Billing (or ERP convergent invoicing in pattern B) | Channels via TMF678 | — | — |
| Payment | Whichever system owns the receivable | Payment gateway, channels | — | TMF676 carries completed payments and refunds. |
| Dunning and collections case | Whichever system owns the receivable | — | — | — |
| Receivable and revenue balances in the ledger | ERP general ledger | — | Billing control totals | In pattern A, drill-down to an invoice goes back to billing. |
In practice
The choice usually follows the billing platform. A telco BSS billing system already does payments, dunning and collections, so its receivables stay there and the ledger gets summarised journals. Where SAP’s convergent invoicing is in place, FI-CA tends to own receivables. Mixed estates, with consumer receivables in billing and some enterprise accounts in ERP, are workable when the split is by customer.
The trade-off
What it solves
A single owner for each customer’s receivable gives one balance, one dunning run and one credit decision, and a clear place where billing and ledger totals are reconciled.
What it does not solve
- Ledger drill-down to the invoice when posting is summarised; that still goes through billing.
- Revenue accounting under IFRS 15, which needs contract data as well as receivables.
- Dual balances inherited from a merger or migration.
What it adds
- A control-total reconciliation between billing and the ledger every period (pattern A).
- Telco volumes inside the ERP and a high-volume subledger to run (pattern B).
- A customer-by-customer split to maintain if B2B and B2C use different patterns.
Architecture decision
Where do customer receivables live?
Billing owns receivables; the ledger gets summaries
Choose when a telco billing platform already handles payments, dunning and collections at subscriber scale, and finance needs balances by account and period rather than per invoice.
An ERP subledger owns receivables
Choose when the operator runs an ERP-native high-volume receivables subledger, such as SAP FI-CA with SAP’s own convergent invoicing, and wants receivables and ledger on one platform.
Breaks if both systems keep live receivables for the same customer: two balances, two dunning runs and two credit decisions.
Takeaways
Key Takeaways
- Receivables belong in one system, billing or an ERP subledger, never both
- Telco billing platforms usually keep consumer receivables and post summaries to the ledger
- SAP FI-CA with convergent invoicing is the main ERP-side pattern, on SAP’s own positioning
- Summarised posting keeps ERP lean but puts drill-down and reconciliation on billing’s control totals
- B2B can differ from B2C, as long as each customer is owned in one place
Check yourself
Finance asks to see each consumer invoice in the ERP ledger. Billing posts summarised journals. What are the options?Show answerHide
Drill down through billing using control totals, or move to detailed posting, which brings telco volumes into the ERP and needs a high-volume subledger. Detailed posting is a platform decision, not a report change.
A customer receives two dunning letters for the same debt, one from billing and one from finance. What has gone wrong?Show answerHide
Both systems hold a live receivable for that customer. One must be made the owner and the other reduced to a reference or summary.