TM Forum and the ERP Boundary
Last updated 12 Oct 2026
At a glance
TM Forum’s Open Digital Architecture has no component for the ledger, payables or procurement. ERP sits outside ODA and connects through integration. A few Open APIs sit at its edge, but none carries billing postings into the ledger: that feed is a proprietary, usually batch, journal.
The picture
ERP sits outside the ODA components. Most of what crosses the line is batch, and the busiest feed has no standard.
- CPQ, COMTMF687 Stock ManagementSynchronous →Inventory and warehouse
- PaymentsTMF670 / TMF676Batch →Payments and refunds
- Resource inventoryTMF639Batch comparison →Fixed assets
- BillingNo Open API: proprietary journalBatch →General ledger
How it works
ERP outside ODA
ODA has components for the catalog, ordering, billing and inventory, but none for the general ledger, payables or procurement. In eTOM terms ERP’s work falls under Enterprise Management, where revenue assurance also sits.
The APIs at the boundary
| API | Role at the boundary |
|---|---|
| TMF687 Stock Management | The closest standard for CPQ and order capture to check and reserve device stock |
| TMF678 Customer Bill Management | Exposes issued bills to channels. Not a ledger feed |
| TMF670 Payment Method / TMF676 Payment Management | Payment means, and completed payments and refunds |
| TMF639 Resource Inventory Management | The network side of the asset reconciliation (7.5) |
| TMF699 Sales Management | Leads and opportunities: a CRM pipeline API, not finance |
Batch, synchronous or event
ERPs offer several integration styles, and the right one depends on volume. Dynamics 365 is a useful reference because Microsoft documents the limits plainly:
- Synchronous APIs (OData, custom services) for small, interactive calls such as a stock check. Microsoft points anything above a few hundred thousand records to its batch data API.
- Batch for billing journals, payments and bulk master data. The usual shape for billing-to-ledger posting.
- Business events as notifications only. Microsoft says they are not a data-export mechanism and their order is not guaranteed.
- Dual-write keeps customer, supplier and product masters in sync with Dataverse both ways. In a telco this can create a third competing customer record unless one system is declared the master.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Billing journal (summarised postings) | Billing | — | ERP general ledger | Proprietary interface; no Open API. |
| Device stock and reservation | ERP (inventory and warehouse) | — | CPQ, COM | TMF687 where used. |
| Payment | Whichever system owns receivables | Payment gateway, channels | — | TMF670 for payment means, TMF676 for payments and refunds. |
| Customer bill (as presented) | Billing | Channels via TMF678 | — | — |
| Network resource | Resource Inventory | — | ERP fixed assets | TMF639. |
| Customer, supplier, product masters | One declared master per entity | — | — | Dual-write sync does not decide which system is master. |
In practice
No public source describes a named operator’s billing-to-ERP interface. It is unannounced back-office plumbing, and often where reconciliation breaks. Expect a batch journal per period and legal entity, with control totals agreed between billing and finance.
The trade-off
What it solves
Treating ERP as outside ODA, with a small set of named interfaces, keeps finance integration explicit and stops ERP being used as an order or customer system.
What it does not solve
- A standard for the ledger feed; it stays proprietary.
- Reconciliation between billing totals and ledger totals.
- Which system is master when sync tools copy data both ways.
What it adds
- A proprietary journal interface to own and maintain through chart-of-accounts changes.
- A mix of synchronous, batch and event styles, each with its own failure modes.
- Licensing questions where third-party systems post into the ERP.
Architecture decision
How should billing post to the ERP ledger?
Batch summarised journal
Choose when billing owns receivables and finance needs balances by account, period and legal entity.
Event or synchronous posting
Choose when volumes are low, such as a small set of B2B invoices, and ERP needs each document as it is issued.
Breaks if business events are used as the ledger feed. They are notifications, not a data export, and their order is not guaranteed.
Takeaways
Key Takeaways
- ERP sits outside the ODA components and connects through integration
- TMF687, 678, 670/676, 639 and 699 sit at its edge; none carries the ledger feed
- Billing-to-ledger is usually a summarised batch journal, and the interface is proprietary
- Pick the integration style by volume, and declare one master before any two-way sync
Check yourself
An architect proposes TMF678 as the billing-to-ledger interface. What is wrong with that?Show answerHide
TMF678 exposes issued bills to channels. It is not a ledger feed. No Open API carries billing postings into the general ledger; that is a proprietary journal, usually batch.
Dual-write is switched on between ERP and Dataverse, and a third customer record appears. What was missed?Show answerHide
No system was declared the customer master. Dual-write keeps records in sync both ways; it does not decide ownership. The customer belongs to CRM or party management.