Equipment-as-a-Service: Which Customer Data Objects Subscription Models Require

Equipment-as-a-Service doesn’t just mean “we rent instead of sell.” It means: We must continuously capture, invoice, and integrate consumption, condition, and status per asset and customer into the lifecycle.

Deloitte identifies four core areas for scalable EaaS models: service offering, leasing model, operations and IT, billing and invoicing. The last point is regularly underestimated. Most machinery manufacturers have invoiced once per sale for decades. Now they need monthly, usage-based billing logic distributed across dozens of assets per customer. The problem: Classic ERP systems are built for product sales, not for continuous service streams. IoT platforms deliver raw data but not billable events. And CRM manages accounts and opportunities but not subscription hierarchies with asset-specific conditions. Those who take servitization seriously need a data model that connects these three worlds.

A scalable equipment-as-a-service model requires at least three additional data objects that cannot be derived from the classic product sales world.

Subscription: The central contract framework. One subscription per asset, defining duration, cancellation rules, conditions, pricing model, and billing cycle. A subscription is not identical to a service contract. It’s the legal and commercial framework for a usage-based business model. The subscription object must know: Which asset is involved? Which customer account pays? Which pricing logic applies (flat fee, pay-per-part, pay-per-hour)? When does the term start, when does it expire, when does it renew?

Usage: The consumption object. This is where actual usage data converges. Operating hours, units produced, cycle counts, energy consumption. Per asset and billing period. Usage data comes from the IoT platform but is not adopted 1:1. It must be deduplicated, aggregated, validated, and mapped to the subscription. A single asset can produce multiple usage metrics. A milling machine captures operating hours, spindle speed, tool changes, and energy consumption. Not all are billing-relevant. The usage object filters and structures what flows into the invoice.

Billing Event: The billable event. It emerges from the combination of subscription conditions and usage data. A billing event is not an invoice but a structured data record passed to the billing system. It contains: Which subscription? Which period? What quantity? What price? Which taxes? The billing event is the interface between data model and billing system. Without clean billing events, manual post-processing loops, reconciliation errors, and customer disputes over invoice amounts emerge.

One subscription per asset, one customer account per subscription, possibly multiple subscriptions per account. The data model must cleanly represent these N:M relationships, or every invoice will fail. The classic case: A customer operates five machines at three sites. Two machines run under pay-per-part, three under flat-fee subscription with included maintenance. The customer wants one consolidated invoice per month, broken down by site and asset. The ERP knows the customer as one account. The installed base knows five assets with different serial numbers and locations. The CRM knows three contacts and two billing addresses. How do you bring this together? The answer: Through a consistent data architecture that treats account, asset, subscription, and billing event as relational objects. Each subscription references exactly one asset and exactly one account. Each billing event references exactly one subscription. Each invoice aggregates multiple billing events of one account for one period. This sounds trivial but fails in practice due to missing master data standards. When the ERP manages the account under the customer number, the CRM under the HubSpot Company ID, and the IoT platform under the machine serial number, a mapping problem emerges. MARINI, the platform for Customer Intelligence with Data Integration, Data Cloud, and Agentic, solves this through Golden Records and bidirectional synchronization. An account is uniquely referenced across systems. An asset is linked to its subscription, regardless of which system it was originally created in.

Pay-per-use without real-time consumption transparency creates distrust. The portal shows the customer their usage in real time, enables forecasting and self-service adjustments. The customer wants to know: How much have I consumed this month? When will I exceed my budget? Can I adjust the subscription before the invoice arrives? A customer portal that can’t answer these questions is worthless. The technical challenge: The portal must access the same data sources as the billing logic. It doesn’t show IoT raw data but the aggregated, validated usage data that later flows into the invoice. If the portal shows “27 operating hours this week” but the invoice states “31 operating hours,” the business model is damaged. MARINI Data Cloud consolidates usage data, subscription conditions, and billing events in a unified data foundation. The portal accesses this foundation, not the individual systems. The customer sees the same numbers that will later be invoiced. They can define thresholds, set alerts, and control their usage themselves. This reduces support inquiries and increases acceptance of the business model.

MARINI addresses precisely the gap between IoT platform, ERP, and CRM that regularly stalls servitization initiatives. The MARINI platform offers DataEngine Data Objects for usage-based billing models. Subscription, usage, billing event: These objects are available out-of-the-box and can be adapted to customer-specific business models. A machinery manufacturer can set up a functional data model within days instead of months of custom development. The HubEngine connects master data from SAP, Salesforce, or Dynamics 365 with customer and contract master data from the CRM. Asset information flows from the installed base. Usage data comes from Siemens Insights Hub or other IoT platforms. MARINI deduplicates, validates, and creates billable billing events. Automated transfer of consumption data to billing systems eliminates manual reconciliation loops. No more Excel sheets. No monthly database exports. No discussions between sales, controlling, and IT because the numbers don’t match. MARINI Professional Services accompanies machinery manufacturers in building customer-specific data models. Not as generic consulting but as an operational partner who sets up data integration, configures billing logic, and implements interfaces to the billing system.