Data contracts between billing, CRM, app, network and finance

A simple question

Take any customer from your base. Ask four systems — billing, CRM, mobile app, finance — what their current monthly revenue is. You will get four different numbers.

This is not rare and not a data error. It is a structural situation that arises in most regional telecoms because each system defines “monthly revenue” its own way. Billing counts on the billing cycle. CRM counts on the calendar month. The app shows rolling 30 days. Finance counts on recognition principles. All four are formally correct — each for its purpose.

The problem appears when a decision rests on “monthly revenue”. Which number is used? Often whichever is at hand of the decision-maker. This is data inconsistency, and it blocks any serious data-driven work.

What a data contract is

A data contract is a formal agreement between a data producer and a data consumer. The producer commits to providing data in a defined format, with defined semantics, and to defined SLAs. The consumer relies on that contract and builds its uses on top.

In telecom data contracts work at several levels.

Between core systems and downstream consumers. Billing publishes “customer ARPU” with an explicit definition — what period, which components are included, how often it refreshes. CRM, marketing, retention all consume the same definition.

Between operations and analytics. Network operations publishes “service availability” with explicit phenomenology of what counts as availability. Analytics consumes the same.

Between internal and external. If the operator provides a signal to a banking partner, the contract describes what the signal is, format, SLA, validity period.

Without data contracts each consumer interprets raw data its own way, and the discrepancies we observe follow.

What a real data contract contains

Minimum:

Schema. Data structure. Fields, types, constraints.

Semantic definition. What each field means in business terms. Not “monthly_arpu: decimal(10,2)” but “monthly_arpu — sum of payments received from the customer during the calendar month from the customer wallet, excluding partner-billed amounts and refunded amounts. Updated daily at 02:00 UTC”.

SLA. When it refreshes. Freshness. Availability.

Versioning. How the contract changes. How consumers are notified.

Owner. Who owns the contract on the producer side. Who to escalate to if something is wrong.

Without at least 4 of 5 it is not a contract but an emergency workaround.

Where data contracts usually do not exist

Between billing and CRM. Billing is the system of record for finance, CRM for customer relationships. When CRM shows “monthly spend” to the customer, it is usually calculated by CRM from CRM-internal data, not queried from billing. Discrepancies with billing are normal.

Between network and customer care. When the customer complains about quality, the contact centre asks network for current status in the customer’s zone. Often the answer is at a coarse level (“the area is fine”), without granular signals about a specific customer. Without a contract on granular signals the contact centre cannot deliver an informed answer.

Between retention and marketing. When retention is making an offer, marketing may be making a different offer at the same time. Without a shared customer view and a data contract on “the customer is in active retention” — collisions happen.

Between finance and everyone. Finance has its recognition rules. When finance reports revenue, those numbers usually differ from operational reports. Without a contract on “recognised revenue” vs “billed revenue” — operational decisions become arguments.

What introducing data contracts changes

Decisions are taken on consistent data. All consumers of one contract see one thing. Not “hypothetically accurate data” — a shared understanding of what the data is.

Faster downstream products. With a contract a new consumer can build a use case without months of discovery on “what does this data mean”.

Easier change management. When the producer wants to change the data, an explicit contract forces thinking about consumers. Versioning prevents breaking changes.

Easier troubleshooting. When something is wrong, the contract helps identify whether the issue is on the producer side (contract breach) or consumer side (misinterpretation).

Reduced political conflict. The “my data shows X, yours shows Y” dispute is common. Contracts make the spec explicit, and the dispute moves to a factual question.

What often becomes a barrier

Discipline effect. Introducing contracts requires discipline — each producer documents what it publishes, each consumer agrees to the contract. In an organisation without strong data discipline this is meaningful change.

Vendor systems. Some core systems (billers, vendor CRMs) do not provide clean data interfaces. They expose what they expose, and a contract cannot be imposed on their publishing.

Cost of formalism. Documenting contracts is work. Without a dedicated data architecture function nobody does it.

Versioning conflicts. Once a contract exists, changes become politically hard — consumers have to agree. This slows change.

Shadow data. Some data flows through ad-hoc queries (someone runs a query, exports a CSV). These flows have no contracts and exist outside the formal architecture.

A realistic roadmap

Months 1-3. Audit. Which data flows exist between major systems. Which of them produce known issues (discrepancies, disputes).

Months 4-9. Pilot contracts. On 5-7 most critical flows — explicit contracts. Producer commitments. Consumer agreement.

Months 10-15. Expansion. Adding contracts on mid-priority flows. A data contract registry is established.

Months 16-24. Sustainable operations. All significant flows have contracts. Versioning discipline. Change management process.

By two years the operator has a working foundation that strongly reduces the data inconsistency class of issues.

When not to launch a contracts project

If the data foundation is weak — master IDs do not work, sources do not reconcile even at raw level — contracts will be on flawed data.

If the organisation has no data architecture function (or equivalent), there is no owner for contracts.

If IT and business do not cooperate in principle, contracts do not get consumer engagement.

If the organisation is in an acute RFP phase on billing or CRM, contracts on shifting systems are unstable.

If the budget has no resource for ongoing contract maintenance (this is not one-time work).

Discussion points for the committee

Which 5-10 “data discrepancy” issues do teams keep encountering? That is the priority list for contracts.

Who owns data architecture today? If distributed — that is the problem.

What is regulatory exposure of current data quality? If there is risk — a motivator.

What 24-month sustained investment is needed and is it there?

Is the organisation ready for a master data function as a permanent role, not just a project?

How SamaraliSoft can help

Data Contracts Programme — audit of current data flows and known discrepancy issues, design of a data contracts methodology fitting the operator’s structure, organisational design of a data architecture function, pilot of 5-7 contracts on critical flows, and a phased rollout over 18-24 months with registry and change management establishment.

Related reading

• /en/architecture/telecom-around-core-architecture/ — layer around the core
• /en/insights/telecom-event-driven/ — event-driven foundation
• /en/insights/telecom-subscriber-360-v2/ — Subscriber 360 v2
• /en/insights/telecom-subscriber-intelligence-operating-model/ — operating model

Sources

• Ministry of Digital Technologies — telecom infrastructure UZ
• Digital Government Portal — digital infrastructure UZ
• UzDaily — telecom market
• MNP.UZ — number portability