Pay-Per-Use in Mechanical Engineering: What Manufacturers Need Before Implementing Usage-Based Billing

If you can’t properly document usage, you can’t properly bill for it either. This is precisely why many pay-per-use initiatives in mechanical engineering fail.

The core concept is easy to outline: Before getting into pricing logic, contract models, or forecasts, three things must be in place— clear asset allocation, reliable usage data, and an honest assessment of the installed base. Only then does an idea become a model that supports the day-to-day operations of service, finance, and management.

The key questions first:

• Which machines are out in the field?
• Which of these are connected?
• What types of value can be assessed for each asset?
• Which contracts allow for which billing methods?
• Where is the data sufficient today—and where is it not?

In short: Pay-per-use follows the sequence of digitization → connectivity → decision-making → automation. Those who start with pricing plans are building on gaps. Those who start with data reduce billing disputes and lay the groundwork for forecasts, service, and financing.

From there, the platform question also becomes clear: Salesforce as the hub for contract and service context, Service Decision Intelligence (SDI) for traceable usage metrics with source attribution and EU-compliant processing within the customer’s infrastructure, supplemented by GRAX-powered CRM and contract context without API limits.

Why Usage-Based Billing Fails Without Reliable Usage Data

Without reliable usage data, pay-per-use becomes a matter of guesswork rather than actual billing. For the finance department, it’s not the concept that matters, but clear evidence of usage.

The Financial Risk Behind Weak Usage Metrics

For CFOs, this is no minor issue. If usage data cannot be clearly traced back to a single source, billing lacks a reliable basis. Recurring revenue can only be planned if the underlying usage metrics are reproducible. This requires an automated transfer into the billing process—one that is auditable and free of manual intermediate steps. Anything else leads to follow-up questions, delays, and additional effort to resolve issues.

In practice, we often see the same pattern: machines send individual values, but timestamps, device references, or plausibility checks are missing. Then the discussion doesn’t start with the price, but with the question of whether usage was even recorded correctly. That’s exactly where the model falls apart from the finance department’s perspective.

This becomes even more important at the fleet level. Only when a large number of machines provide data according to a uniform format can a model be created that can be used for control and billing purposes.

Why Connected Fleets Are More Important Than Individual Machines

Pay-per-use only becomes cost-effective with a larger, connected fleet of similar machines with measurably varying utilization rates. A single machine can demonstrate the potential. However, this does not yet result in a robust business model. Without IoT telemetry, there is no reliable way to measure usage and no billing system that can be operated at scale.

That is precisely why pay-per-use belongs at the end of a maturity sequence: Digitize → Connect → Decide → Automate. Anyone who starts with pricing logic or contract models is missing the heart of the matter. First, inventories, usage sources, and data quality must be in order. Only then can one assess which billing logic is actually viable for each machine, customer, or fleet.

For this step, it often makes sense to conduct a sober assessment of the current situation, such as through an installed base assessment. Once machine types, connectivity, data points, and utilization patterns have been accurately recorded, the sales process can later be integrated into Salesforce. The real hurdle, however, lies before that: the question of whether usage can be reliably demonstrated from both a technical and a business perspective.

What Manufacturers Need Before Usage-Based Billing

Before pay-per-use can work in everyday practice, three things must be clarified: a clear asset identity, reliable usage data, and a realistic picture of the installed base. Behind this lie three simple but business-critical questions: Which assets are actually in the field, which ones provide reliable data, and for which machines is the available data already sufficient for reliable billing?

A clean installed base and unique asset identity

Usage-based billing often fails not because of the rate plan, but because of how usage is assigned. If machines are recorded twice, serial numbers are not maintained consistently, or the contract reference is missing, usage cannot be billed accurately later on.

The digital machine file (IOTAM) lays the foundation here. A unique, structured data record is created for each asset, bringing together its configuration, service history, and contract details. Only then can the usage metrics of a specific machine be assigned to the appropriate contract. For service managers, this isn’t just an IT detail—it’s essential for ensuring that invoices remain traceable and that inquiries don’t drag on for days.

Telemetry, ERP data, and contract data in a single usage model

Usage data never comes from just one source. The machine provides data such as operating hours, cycles, or utilization via IoT telemetry. ERP data shows material consumption. Service events provide the necessary context: downtime, maintenance windows, or failures. In addition, contract data specifies which parameters may be billed to which customers.

Only when this data is automatically consolidated can billing become repeatable. This is precisely where Salesforce becomes attractive to many manufacturers: not as an end in itself, but as a place where service, contract, and asset context are brought together. If diagnostic or predictive cases also need to be evaluated, Service Decision Intelligence (SDI) can serve as a decision-making layer. What matters most here is that recommendations are provided with source references and that data can be processed within the customer’s infrastructure in compliance with EU regulations, if desired. This is a particularly crucial point, especially in disputes over usage values or billable downtime.

A Reality Check on the Fleet Before Designing the Rate Plan

Before rates are set, the fleet needs a sober reality check. Which types of vehicles are already connected? Where is telemetry missing? Which usage patterns can be accurately measured and, therefore, billed?

An Installed Base Assessment distinguishes precisely between billable and non-billable segments. It identifies data gaps, evaluates connectivity coverage, and highlights which parts of the fleet are immediately suitable for a usage-based model and which need to be retrofitted first. In practice, we often see that a pilot project with just a few well-connected machines runs smoothly. Things get more difficult as soon as older model series, different control systems, and incomplete master data come into play.

For a usage-based model to work, the data must be reliable enough that all parties involved—manufacturers, service partners, and customers—trust it. Without this trust, any billing will remain contentious. A pilot program involving a small number of well-connected machines demonstrates that the principle works. However, a reliable model can only be established if this level of data quality can be replicated across the entire fleet. That is precisely why the approach is not “technology first,” but rather: Digitize → Connect → Decide → Automate.

How SDI Makes Fragmented Data Useful for Billing and Forecasts

Once asset identities and data sources are in place, data collection alone is not enough. For billing and forecasting, you need a logic that seamlessly integrates telemetry, ERP consumption data, and contract context. Service Decision Intelligence (SDI) handles exactly this task. Only when a fleet of similar machines can transform a large volume of individual data points into a reliable trend can a scalable billing model be created.

Transparent usage calculations instead of opaque billing

As soon as a customer receives an invoice based on operating hours or cycles, the same question almost always comes up: “Where does this figure come from?” Without a source reference, this can quickly turn into a dispute.

This is exactly where SDI comes in. Every calculated usage value can be traced back to its source—that is, to the corresponding telemetry or ERP data point. For pay-per-use, this isn’t just a detail—it’s the foundation. Billing and forecasting thus draw on the same data source. This reduces the effort required for reconciliation and makes invoices verifiable rather than prone to disputes.

This is especially important in mechanical engineering. If usage values aren’t clearly documented, every discrepancy between the invoice, service report, and contract sparks a separate discussion. SDI provides a clear path here: value, source, calculation, and allocation remain traceable. For service managers, this means less follow-up clarification and greater certainty in day-to-day billing.

Data Sovereignty and Contractual Context as Prerequisites for Scaling

Whether pay-per-use in mechanical engineering can be scaled in an auditable manner or gets stuck on a case-by-case basis depends on two factors: data sovereignty and the contractual context.

For many companies, storing sensitive machine data in third-party cloud environments is not an option. SDI is therefore designed to run on the customer’s own infrastructure. This supports EU-compliant implementations and keeps control of the data where it belongs. What’s more, SDI is designed to be LLM-agnostic via MCP/BYOM. Those who want to switch models or integrate their own models remain flexible rather than having to commit early on.

The contractual context is just as important. A usage value alone does not determine which rate applies, what special terms have been agreed upon, or when billing takes effect. This is where GRAX comes in: GRAX stores CRM and contract history as a structured dataset—without the API limits that can otherwise become a bottleneck. This ensures that the context remains fully available for billing and reconciliation processes when usage data needs to be compared with the contractually agreed-upon rate plan.

In Salesforce, this does not result in a loose juxtaposition of metrics, contracts, and forecasts, but rather a shared working foundation. SDI thus serves as a bridge between the database, the rate plan, and the forecast.

The Business Model Behind Scalable Equipment-as-a-Service

When usage is measurable, the operating model determines how the system scales. Based on the data infrastructure and billing logic, Level 4 brings us to what often makes the difference in practice: automation. Pay-per-use isn’t just a different price list—it’s a different operating model. This is precisely where the difference between traditional sales and a viable EaaS offering becomes apparent.

In the “Digitize → Connect → Decide → Automate” process model, the bottleneck usually lies not in data collection, but in ensuring consistent execution across multiple machines, locations, and contracts. Anyone who bills for usage needs established processes for service, finance, IT, and sales. Otherwise, a pilot project can quickly turn into extra work instead of business.

Traditional Equipment Sales vs. Usage-Based Service Revenue

In traditional business, the sale is the final step. With Equipment-as-a-Service, it’s just the beginning. The manufacturer remains responsible for availability, maintenance, and a reliable data flow—which forms the basis for every invoice. This shifts responsibility across multiple areas. However, the model becomes scalable only through the fleet, not through individual machines. It is only by monetizing the installed base that a pilot project can be turned into a sustainable business.

With pay-per-use, the manufacturer only earns revenue when the machine is running. Downtime affects both parties. This changes maintenance planning, escalation procedures, and the way service contracts are drafted. In Salesforce, these processes usually only become manageable when contract rules, usage data, and service cases are integrated into a single, unified process. For diagnostic and AI-driven decisions, Service Decision Intelligence (SDI) often serves as the layer that validates recommendations with source attribution and can be operated within the customer’s infrastructure in compliance with EU regulations.

A real-life example and a clearly identified typical scenario

This example illustrates how significantly the focus is shifting from the product to ongoing use. KraussMaffei has implemented this approach with flexPay: Customers pay based on actual operating hours, billed through a financing partner. Pay-per-use thus shifts the focus from the sale to ongoing availability and verifiable usage.

Typical scenario (not a real-world example): A mass-production manufacturer with a large, networked fleet of similar processing machines implements a usage-based model. Usage varies greatly depending on the location and shift schedule. Only the fleet data allows for reliable rates and clear rules regarding downtime in the contract.

What successful models have in common is actually quite straightforward:

• The billing rules are established before the start.
• Exceptions are governed by the terms of the contract.
• The data is transparent to all parties involved.

Without this foundation, every invoice becomes a potential source of dispute. That is precisely why it is not enough to simply connect individual machines digitally. The key factor is whether manufacturers can manage their installed base as a controllable portfolio—for example, using a digital machine file (IOTAM) to capture the machine context and an Installed Base Assessment to classify the fleet within Salesforce.

Conclusion: Build the foundation in the correct order

Pay-per-use is not the starting point. In mechanical engineering, it is the result of an installed base that has been accurately recorded, networked, and made usable for billing. The sequence is clear: Digitize → Connect → Decide → Automate. Without this foundation, any pricing logic remains nothing more than a calculation model without reliable evidence.

Usage-based billing stands or falls on reliable, traceable usage data—across system boundaries and with source attribution. This is exactly where Service Decision Intelligence (SDI) comes in: SDI combines telemetry, ERP consumption data, and contract context into a verifiable basis for billing and forecasting. For service managers and executive management, it’s not just the pricing model that matters, but whether every billing item can be substantiated. Trust is built on verifiable data, not on pricing logic.

In this way, the installed base becomes a driver of growth throughout its entire lifecycle—right through to strategies for end-of-life and the late lifecycle. That’s why the starting point isn’t a pricing model, but a fleet assessment. Two pragmatic approaches:

• Installed Base Assessment – when it is unclear which machines are networked and which usage data is reliable. It distinguishes between billable and non-billable segments and identifies where retrofitting is needed.
• Initial Consultation – once the database is set up and you’d like to discuss the specific usage and billing model for your fleet.