SAP Business Data Cloud: Start with Service Margin

Finance reports a profitable service contract. The service manager sees repeat visits and unbilled work. Both may be right, because they are counting different things.

TL;DR: A good first use case for SAP Business Data Cloud is one disputed metric with a decision behind it. Service margin fits: define the measure in writing, connect S/4HANA financials with contract and field-service data, reconcile a sample of contracts by hand, and only then add dashboards or AI. The output is a worklist of contracts to review, not a data lake.

That is a better starting point than “put all our data in one place”. Start with a decision: which contracts need attention, and why? The example below is an illustrative design exercise, not a claim about a delivered customer result.

Define the metric before connecting the sources

For this example, define a contribution measure as billed service revenue minus the agreed labour, material and external-service costs. Decide explicitly whether travel, warranty work, credits and overhead are included. Do not call two differently scoped measures “service margin”.

Agree the reporting period, currency conversion and treatment of late postings. A dashboard cannot settle an accounting definition that the business has not agreed.

A worked example (illustrative figures)

Take one maintenance contract over one quarter, with invented numbers:

Line	CHF
Billed service revenue	48,000
Labour at agreed internal rate (120 hours)	-18,000
Spare parts consumed	-9,500
External subcontractor	-4,000
Contribution (definition A)	16,500
Travel time, unbilled (30 hours)	-4,500
Warranty visit, not chargeable	-2,200
Contribution (definition B)	9,800

Finance, looking at definition A, sees a healthy 34 percent. The service manager, who lives with the travel and warranty work, sees roughly 20 percent. Neither is wrong. The disagreement is in the definition, and no platform resolves it for you. Write the chosen definition down, give it an owner in controlling, and name the other one differently if you still need it.

Where the data comes from

A service-margin measure usually needs four kinds of record:

• Financial value from S/4HANA: billing documents, service orders and the cost postings behind them. This is the accounting truth and the basis of the agreed measure. On SAP S/4HANA Public Cloud these objects are standard, which keeps the mapping manageable.
• Contract data: scope, price, service levels and what is chargeable. Without it you cannot tell unbilled work from included work.
• Field-service activity: visits, confirmed time and material from SAP Field Service Management (SAP Help). This explains the number; it does not replace the posted value.
• Master data: customer, equipment and material keys that let the three sources join.

How cleanly these records connect depends on the operational integration. Our FSM, Sales Cloud and S/4HANA Public Cloud integration checklist covers the handoffs that later decide whether an analytics join works.

What BDC contributes

SAP introduced Business Data Cloud in February 2025 (SAP News). It brings together SAP Datasphere, SAP Analytics Cloud, SAP BW and SAP Databricks (SAP Learning). SAP describes a data product as a refined data set, metadata describing it, and an access port or API; the data-product documentation explains how SAP-managed data products are activated and consumed.

Check the current catalogue and your entitlements for the specific sources required. The existence of BDC does not mean every FSM or contract field is already available as the exact data product your metric needs. Where none exists, replicate the source via Datasphere and govern it as your own data product, with the same owner and definition discipline as SAP’s. For the broader picture, see what SAP Business Data Cloud is.

Keep the first data contract small

Element	Agreement needed
Grain	One contract, service order or visit?
Keys	How do commercial, service and financial records join?
Freshness	How old may the data be for this decision?
Ownership	Who explains a missing or disputed value?
Access	Who may see costs, customer details and technician information?

Use ERP financial records for the agreed financial measure. Add field-service context where it explains the result. Keep operational status and accounting value distinct: a completed visit is not the same thing as posted revenue.

Access deserves its own decision. Internal cost rates, customer names and technician time are personal or commercially sensitive data under the Swiss nDSG and, for EU customers, the GDPR. Grant finance the costs, service managers their own contracts, and keep technician-level detail aggregated unless there is a documented reason.

Reconcile before adding AI

Choose a small sample of contracts. Reconcile the totals to the underlying records and ask finance and service to explain the differences together. We test at least these cases:

1. A credit note issued after the period closed.
2. A late time correction by a technician.
3. A job that spans two reporting periods.
4. A contract with a price change during the quarter.
5. A warranty visit that should carry cost but no revenue.

Only then consider an AI summary, such as “which contracts changed materially this month?” The summary should identify the records and definitions behind its answer. Plausible prose is not a substitute for reconciliation.

A first scope in four steps

1. Definition workshop (finance, service, controlling): agree definition A or B, the period logic and the owner.
2. Source check: confirm which data products exist for your release and which sources need replication.
3. Sample reconciliation: ten to twenty contracts, the five test cases above, differences explained in writing.
4. Worklist: publish the result to the people who make the decision, and review it monthly.

Make the output actionable

A useful result is a short worklist: contract, reason for review, accountable owner and next action. One contract may need billing cleanup; another may need a service-process change. The same low margin does not imply the same remedy.

BDC does not replace the operational integration that creates orders, dispatches technicians or posts confirmations. Analytics and transaction processing need different acceptance tests.

FAQ

Why start SAP Business Data Cloud with service margin?

Because it is a disputed number with a clear decision behind it: which service contracts need attention and why. It needs data from finance (S/4HANA), contracts and field service, so it tests the joins that every later use case depends on, while staying small enough to reconcile by hand.

Which data sources does a service-margin measure need?

Typically S/4HANA billing documents, service orders and cost postings for the financial value, contract data for scope and pricing, and SAP Field Service Management activities, time and material confirmations for operational context. Check the BDC data product catalogue for your release; where no SAP data product exists for a source, replicate it via Datasphere and govern it as your own data product.

Can AI explain the service margin before the numbers are reconciled?

It should not. An AI summary over an unreconciled measure produces plausible prose about a number nobody has agreed. Reconcile a sample of contracts first, then let an assistant summarise changes, always pointing to the records and definitions behind its answer.

Who should have access to service-margin data?

Fewer people than the dashboard audience suggests. Cost rates, customer details and technician time are sensitive under the Swiss nDSG and the GDPR. Define roles before go-live: finance sees costs, service managers see their contracts, and technician-level detail stays aggregated unless there is a documented need.

Discuss a first data product with Spadoom. Bring one disputed metric and the decision it should support. That gives the assessment a concrete boundary.