# Build the API layer before replacing the billing system.

**Author:** Ivan Misic  
**Published:** 2026-02-15  
**URL:** https://ivanmisic.net/blog/digital-transformation/dont-replace-billing-system

**TL;DR**

A large core-system transformation should not be the entry ticket for every new digital capability. Put a stable API contract between digital products and the existing billing, CRM, catalog, ordering, and provisioning systems. The contract gives digital teams a clean interface while adapters handle the legacy reality behind it. This adds work around consistency, transactions, latency, monitoring, and ownership, but it lets digital delivery and backend modernization move on separate timelines.

Digital delivery should not wait for a full core-system transformation.

In telecom, that usually means the OSS/BSS estate. In other industries, the names differ, but the problem is the same: a [new app or customer journey](/blog/digital-transformation/app-isnt-service-channel) needs data and actions from billing, CRM, catalog, ordering, provisioning, or another system that was not designed for modern digital products.

The tempting response is to start a large replacement program. I would start with a smaller question: what stable contract does the digital product need?

Build that API layer first. Let it translate between new digital demand and the systems already running the business. Then modernize those systems behind the contract at the pace the backend can handle.

## The Transformation Trap

A core-system replacement can be necessary. It is also a poor dependency for a digital roadmap.

The replacement has to deal with old business rules, integrations, reporting, finance, operations, and customer-service processes. The digital product needs a clear way to read a balance, show an offer, submit an order, or check its status. Those are related problems, but they do not need the same delivery plan.

When they are tied together, every new digital capability inherits the scope and risk of the backend program. The customer waits for the whole estate to become modern instead of [getting a smaller useful scope live](/blog/digital-transformation/stop-trying-to-digitalize-everything).

That is the assumption I would challenge.

## Put a Stable Contract in the Middle

The digital product should talk to a stable API contract, not directly to every core system.

The API layer exposes the capabilities the product needs in a consistent shape. Adapters behind it translate those requests into the data models, protocols, and business rules used by the existing systems. Microsoft describes a similar boundary as an [Anti-Corruption Layer](https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer): the new product keeps its own model instead of copying the legacy system's structure.

The old systems can stay ugly. They just stop setting the shape of every new product.

The first benefit is calendar time. The digital team can build against the contract while the backend teams improve or replace the systems behind it. If a billing platform changes later, the adapter changes. Every app should not have to learn the new billing interface.

<figure>

![Architecture showing a mobile app using one standardized API contract that translates profile, product, billing, usage, and order requests across legacy billing, catalog, and usage systems](/images/blog/digital-transformation/billing-abstraction-layer.png)

<figcaption>The stable contract separates digital demand from backend change. It does not remove the hard work around consistency, latency, error translation, and ownership.</figcaption>

</figure>

## Billing Is One Example

Billing makes the problem easy to see because it sits behind balances, invoices, payments, contracts, and product changes. The same approach applies to CRM, product catalog, order management, provisioning, usage, and other core capabilities.

Keep the scope narrow. Start with the capabilities required by a real digital journey. Add another contract when there is another useful demand.

![The Iceberg Model of enterprise backends: a cheerful surface hiding underwater complexity](/images/blog/billing-iceberg-model.png)

Customers do not need to know how many systems are involved in showing a bill or changing a product. They need a clear result. The abstraction layer is the boundary that keeps the complexity below the surface without pretending it has disappeared.

## What the API Layer Should Expose

The contract should describe what the digital product needs, not reproduce every table and code from the systems behind it.

| Capability | Digital Contract | Where the Complexity Usually Lives |
|------------|------------------|------------------------------------|
| Customer profile | Name, contact details, account status | CRM or customer master |
| Products and entitlements | Active products, prices, allowances | Catalog, billing, and entitlement systems |
| Billing and payment | Balance, invoices, payment options | Billing, finance, and payment services, depending on the current architecture |
| Usage | Current usage, history, remaining allowance | Network and operational systems |
| Orders and changes | Create, track, change, or cancel an order | Ordering and provisioning systems |

This table is only an example. The source of truth and ownership will differ between companies. Design the contract around a real digital need. Let each adapter handle the backend that exists today.

## What This Layer Does Not Solve

An abstraction layer moves the boundary. It does not remove the complexity.

**Data ownership.** The layer needs to know which system owns each field. If it keeps a cache or read model, the team must define how fresh the data needs to be and what happens when synchronization fails.

**Transactions.** A read is usually easier than an order, payment, or plan change. Multi-step operations need clear consistency rules, monitoring, retries, and a way to recover when only part of the work succeeds.

**Error translation.** A legacy error code may be correct for the backend and useless to the app. The API layer has to translate it without hiding the real failure from support and operations.

**Performance and resilience.** The extra layer adds latency and another component that can fail. Caching, timeouts, capacity, observability, and fallback behavior need deliberate design.

**Contract governance.** A stable contract still changes. Versioning and compatibility need one owner, or every digital team will create its own unofficial version.

## Treat It as Infrastructure

I would fund and own the API layer as infrastructure. Give it one accountable team, a budget, and a roadmap tied to real product demand.

Digital and backend teams should shape its priorities, but shared input is not shared accountability. Someone has to own the contract, the production incidents, and the decision about what belongs in the layer.

If every change needs a temporary project and another funding discussion, the operating model has turned the layer into a queue.

## When Replacement Is Still the Right Call

Building around a system is not an argument for keeping it forever.

Replacement still makes sense when the system blocks the business model, vendor support is ending, or the business process must change. It also makes sense when adapters and workarounds cost more than replacing it properly.

Even then, the contract still helps. Replace capabilities behind it in phases while the digital products keep using the same interface. The [Strangler Fig approach](https://martinfowler.com/bliki/StranglerFigApplication.html) uses this kind of gradual replacement to deliver value earlier and reduce the risk of one large cutover. Each phase still needs monitoring, rollback, and a clear exit condition.

## Ask a Better Question

When someone proposes a major OSS/BSS or core-system transformation, ask:

- What digital capability is waiting for it?
- What stable contract would let that capability move now?
- Can the backend change behind that contract without forcing every digital product to change?
- What operational cost and failure modes will the new layer add?

If full replacement is still necessary, do it. If one API contract can separate the timelines, build that first.

The backend does not need to be modern before the digital roadmap can move.