Picture a 500-employee mid-market company that has been selling industrial forklifts for thirty years. Customers always asked the same question: “How much does it cost?” And the answer was always simple: a unit price, a purchase order, a delivery, an invoice. SAP Business One handled all of that perfectly well.
Now imagine that same company switching to a “pay-per-lift-cycle” model. Customers no longer buy the forklift — they pay each time they use it, based on the number of lift cycles measured by an onboard sensor. Strong commercial case: better retention, more predictable revenue. But SAP Business One has no idea what a “lift cycle” is. Its data model stops at the sales order.
That is the core challenge of usage-based billing for mid-market companies: the business model evolves faster than the information systems that support it.
The Rise of XaaS in Industry: From Product Sales to Usage Sales
The Shift Is Already Here, Across Every Sector
Usage-based selling is nothing new. It goes back to photocopiers billed per copy, vehicle fleets billed per kilometre, and industrial chillers billed per kilowatt consumed.
What has changed is the widespread adoption of the model, driven by IoT sensors, low-cost cellular connectivity, and ubiquitous APIs. Today, virtually any industrial equipment can be fitted with a consumption counter, and virtually any B2B service can be metered in real time. Industrial machinery suppliers, logistics providers, IT service firms, and maintenance equipment vendors all face the same opportunity: transforming a one-off sale into a recurring revenue stream tied to actual usage.
The Critical Distinction: Subscription Billing vs. Usage-Based Billing
Before going further, a terminology clarification that many teams get wrong — at the cost of choosing the wrong tool.
Subscription billing means a fixed amount charged at regular intervals, regardless of actual consumption. The customer pays £2,000 per month whether the machine runs for ten hours or a hundred. Traditional ERP handles this reasonably well: it is a recurring order with a constant amount.
Usage-based billing means a variable amount calculated from measured real-world consumption. The customer pays exactly what they use — no more, no less. The ERP must ingest metering data, aggregate it, apply a pricing grid (often tiered), and produce an invoice whose final amount is unknown in advance. These are fundamentally different problems, and the solutions are not the same.
Hybrid structures — a fixed base fee plus a variable component for consumption above a threshold — combine both challenges. This is the most common pattern in practice, and the hardest to manage without a dedicated tool.
Why Usage-Based Models Improve Retention and Predictability
From a commercial standpoint, the argument is compelling: a customer paying for usage has no reason to churn during a slow period since they only pay for what they consume. The barrier to entry is lower, the alignment between perceived value and billed amount is direct, and commercial conversations shift toward usage optimisation rather than contract renewals.
From a financial standpoint, revenue becomes more predictable once the installed base is large enough: fluctuations from one customer are offset by the stability of the overall portfolio. It is the same principle as insurance — variance decreases as the portfolio grows.
Why Traditional ERPs Aren’t Built for Usage-Based Billing
The Classic ERP Data Model: Order, Delivery, Invoice
A general-purpose ERP was designed around a well-defined logical sequence: a sales order fixes quantities and prices, a delivery confirms execution, an invoice translates the delivery into a customer receivable. This model is remarkably effective for everything that follows this sequence. It is structurally ill-suited to anything that interrupts or short-circuits it.
In usage-based billing, the “quantity” is not known at order creation. It builds up in real time, measurement by measurement, on remote equipment. The invoice does not close out a delivery — it summarises a consumption period. The ERP has no field for that.
Problem 1: Multi-Tier Pricing
Most usage-based pricing grids are non-linear. The first 1,000 lift cycles in a month cost £0.15 each. The next 1,000 cost £0.12. Beyond 5,000, the rate drops to £0.08. This is what is called tiered or volume pricing.
A standard ERP can apply volume discounts on an order line, but only if the total quantity is known when the order is created. When quantities accumulate progressively over a month, the ERP cannot tell which pricing tier a customer sits in at any given moment. The final calculation at month-end requires either a custom development or an export to an external tool.
Problem 2: Consumption Data Collection
Consumption data does not originate in the ERP. It comes from IoT sensors embedded in equipment (MQTT or OPC-UA protocols), from third-party APIs exposing usage metrics for a cloud service, or from partner portals that report processed transaction volumes.
The ERP has no native connector to ingest these data streams. You will need to build or buy an integration layer that collects events, normalises them, deduplicates them, and transforms them into data the billing engine can use. This integration project is consistently underestimated in XaaS transformation initiatives.
Problem 3: Reconciliation with Contract Terms
A usage-based contract typically contains complex clauses: a minimum billable floor (minimum commit), a ceiling beyond which surplus usage is free (cap), credits issued for missed SLA commitments (SLA credits), and grace periods for new customers.
The ERP must not only calculate the consumption amount — it must also reconcile it against these contract clauses to arrive at the final billed amount. A £800 minimum commit when actual consumption is £620? The ERP must invoice £800 and expose the gap in the customer report. This level of contractual logic exceeds the native capabilities of standard billing modules.
Problem 4: Revenue Recognition Under IFRS 15
IFRS 15 requires that revenue be recognised when — and only when — a performance obligation is satisfied. For usage-based billing, this means revenue must be recognised in line with actual consumption, not at the invoice date or the payment date.
If a customer consumes 400 cycles in October and receives their invoice on 5 November, the revenue from those 400 cycles belongs to October. If the ERP has no “as-consumed” recognition mechanism, it will either defer recognition to the invoice date (incorrect under IFRS 15) or require manual adjustments at every month-end close.
Three Warning Signs Your ERP Is No Longer Keeping Up
If you observe three patterns in your billing cycle, your ERP is hitting its limits on usage-based billing.
First signal: credit notes exceed 5% of invoices issued. Recurring calculation errors, cascading credits, and re-invoicing point to billing logic being managed manually — with all the error risk that entails.
Second signal: the gap between the end of the consumption period and invoice issuance exceeds 30 days. This delay reveals a manual consolidation phase: exporting consumption data, calculating in a spreadsheet, then re-entering figures into the ERP.
Third signal: customer disputes concern the consumption measurement itself, not the rates. When a customer contests the number of cycles recorded and you have no timestamped audit trail of events, you have a data governance problem — not just a billing problem.
Four Architectures for Mid-Market XaaS Companies
Architecture 1: Everything in the ERP with Custom Extensions
The first instinct of most IT directors is to try to fit usage-based billing into the existing ERP through custom development: a new “consumption statement” document type, a tiered pricing calculation engine, custom fields for contract clauses.
This approach has a genuine advantage: the single source of truth is preserved, and billing data coexists with general ledger and procurement without any synchronisation to manage. For simple models — a single consumption metric, a linear pricing grid, no complex contract clauses — it can work.
The downsides are structural. Initial development costs are high, routinely underestimated by in-house teams. Maintenance falls on the internal IT team. The custom module is at risk with every major ERP upgrade. And when the pricing model evolves — adding a new metric, introducing a cap, creating a hybrid plan — each change requires new development.
This architecture suits mid-market companies where usage-based billing remains marginal in volume and stable in complexity, and where the IT team has the capacity to maintain ERP-specific development over the long term.
Architecture 2: Dedicated Billing Engine + ERP Connector
The second architecture separates billing calculation from accounting. A dedicated usage-based billing engine ingests consumption events, applies pricing and contract rules, and generates invoices. The ERP receives the final accounting documents (validated invoice, credit note, payment) and manages the general ledger, bank reconciliations, and period closes.
This is the recommended approach for the majority of mid-market companies and SaaS vendors starting or scaling usage-based billing.
Specialist solutions in this space include:
- m3ter: a platform purpose-built for usage-based billing for SaaS vendors and industrial companies. Designed to ingest high volumes of events, apply complex pricing grids (flat, tiered, volume, matrix), and synchronise invoices to ERPs and CRMs via native connectors.
- Maxio (formerly SaaSOptics and Chargify, merged): suited to B2B mid-market SaaS vendors with IFRS 15 revenue recognition requirements on top of billing. Native connectors to NetSuite, QuickBooks, and Salesforce.
- Chargebee: well-established for recurring billing, with expanded usage-based capabilities. A strong fit for companies with a subscription + usage mix, and attractively priced for growth-stage mid-market companies.
- Orb: a newer platform focused on high-frequency event ingestion and pricing grid flexibility. Popular with API-first SaaS vendors billing for API calls or compute units.
- Metronome: a platform with a no-code pricing grid configuration interface and embedded customer dashboards, so customers can monitor their own consumption in real time.
Common thread: all of these solutions produce a validated invoice that the ERP receives as an ordinary accounting document. Calculation complexity stays in the dedicated engine; the ERP retains its role as the accounting and financial system of record.
Architecture 3: Revenue Management Platform + ERP for Finance
The third architecture steps up in functional scope. Platforms such as Zuora Revenue Cloud, Salesforce Revenue Cloud, or Conga Billing cover the entire order-to-cash cycle: customer contract management, usage metrics, billing, IFRS 15 revenue recognition, and financial reporting.
The ERP retains its role for general ledger, payments, and group consolidation. The Revenue Management platform becomes the system of record for everything related to customer contracts and revenue streams.
This architecture suits large industrial groups or enterprise SaaS vendors with multiple product lines, multiple coexisting pricing models (usage-based, subscription, transactional), and strict IFRS 15 requirements driven by stock exchange listing or Big Four audits. The ROI is justified when contractual complexity is high enough that the Revenue Management platform saves tens of hours of manual close work every month.
Architecture 4: Advanced CPQ for Pricing Configuration
The fourth architecture addresses a more specific use case: companies whose sales cycle includes a complex quoting phase before usage goes live. A services integrator offering consumption-based service packages with individually negotiated contract commitments will need a CPQ (Configure Price Quote) tool that supports usage-based pricing rules from the commercial stage onwards.
Solutions such as SAP CPQ, Tacton (industrial specialist), or Salesforce CPQ allow you to model offers with usage-based components during the quoting process, and pass validated contract parameters to the ERP or billing engine for execution. This architecture fits cases where contract customisation is high and the ERP receives fully configured contracts rather than parameters to be defined internally.
Profile-Based Recommendations
Three profiles cover the majority of cases encountered in European mid-market companies.
Mid-market industrial company with less than £10M in usage-based revenue, simple model (one or two metrics). Start with native ERP extensions if the IT team has the capacity to maintain them, or Chargebee at the entry-level tier if usage-based billing needs to scale quickly. Prioritise the accounting connector to the existing ERP over billing engine feature richness.
B2B SaaS vendor or services company with £10M–£50M in usage-based revenue, multiple consumption metrics, enterprise accounts with contract clauses. m3ter or Maxio with a native ERP connector are the best fits. The selection criterion between the two comes down to the weight of IFRS 15 recognition in the decision (Maxio is stronger here) and the volume of consumption events to process (m3ter is built for high volumes).
Industrial group or vendor with more than £50M in usage-based revenue, multiple business units with different pricing models, IFRS 15 requirements from a listed entity. Zuora Revenue Cloud or Salesforce Revenue Cloud, with SAP S/4HANA or Oracle Fusion Cloud as the general ledger ERP. At this level of complexity, a dedicated Revenue Management platform is justified — provided you have an IT and finance project team capable of driving the implementation.
The Data Challenge: Capturing and Aggregating Consumption Signals
The billing tool is worthless without reliable consumption data. This is often the longest and most complex workstream in a XaaS transformation project.
Collecting Usage Events
Consumption data sources are heterogeneous. For connected industrial equipment, MQTT and OPC-UA protocols stream metrics in near-real time from PLCs or embedded sensors to a message broker or IoT platform. For software services, metering APIs expose consumption counters (API calls, gigabytes stored, transactions processed) via webhooks or periodic exports. For distribution partners, dedicated portals allow them to declare volumes manually or via integration for third-party-processed transactions.
Each source has its own latency, format, and granularity. The data architecture must include a normalisation layer that transforms all these heterogeneous events into a unified format before they enter the billing engine.
Aggregation and Deduplication
Distributed systems inevitably produce duplicates: a sensor that sends the same event twice after a network hiccup, a webhook that replays after a timeout. The billing engine must detect and reject these duplicates; otherwise customers will be overbilled and disputes will accumulate.
Aggregation means consolidating raw events into billable metrics by period. 45,000 API calls in October for a given customer, across three regions: aggregation produces a total of 45,000 billable units and traces the source events to substantiate that total in case of dispute.
Governance: Who Validates Consumption Before Invoicing?
In a traditional transactional billing model, the customer order implicitly validates the amount. In usage-based billing, customers often have no visibility into the quantities consumed until they receive their invoice. A post-invoice dispute is harder and more expensive to resolve than a pre-invoice validation.
The most mature companies on this model give their customers access to a real-time consumption tracking portal, with the ability to set overage alerts. They send the customer a notification at the start of the billing period with a summary of the prior month’s consumption before issuing the final invoice. This “pre-bill notification” process significantly reduces the dispute rate and improves the customer experience.
IFRS 15 and Usage-Based Billing: What the CFO Needs to Know
Contract Classification and Identifying Performance Obligations
The first step of the IFRS 15 analysis is identifying whether a usage-based contract contains one or more performance obligations. A contract combining an obligation to provide equipment (a lease) with an obligation to provide consumption-based services (maintenance, support) may contain two distinct obligations with different recognition methods.
Variable Consideration Under IFRS 15
The amount billed in a usage-based contract is not known at contract inception — this is what IFRS 15 calls “variable consideration.” The standard requires estimating this variable amount and constraining it to the amount for which it is “highly probable” that no significant reversal will occur.
In practice, for a contract with a minimum commit, the constrained variable consideration is at minimum equal to that commit. Above the commit, recognition is progressive in line with actual consumption. This mechanism is described in IFRS 15.B20–B21 and its accounting implications must be configured in the ERP or billing engine when the contract is set up.
”As-Consumed” Recognition and Balance Sheet Impact
Unlike subscription billing — where recognition is linear over the period — usage-based billing requires “as-consumed” recognition: each unit consumed is recognised at the moment of consumption, not at the invoice date.
This creates a permanent gap between recognised revenue (tied to consumption) and billed revenue (tied to the billing cycle, typically monthly or quarterly). The ERP must manage “contract assets” (revenue recognised but not yet billed if consumption precedes invoicing) and “contract liabilities” (revenue billed but not yet recognised if invoicing precedes consumption). These balance sheet items are scrutinised by auditors and must be reconcilable event by event.
Finance teams approaching this topic for the first time consistently underestimate the initial configuration effort and the ongoing monthly control burden this recognition mode imposes. Plan for specialist IFRS 15 advisory support during billing engine deployment, particularly if the company is subject to a statutory audit requirement.
Going Further
Moving to a usage-based billing model is rarely a standalone project — it sits within a broader transformation of your finance architecture and order-to-cash cycle. Three articles on this blog will help you explore adjacent topics:
- Our full analysis of ERP subscription management and recurring billing covers native subscription management modules in the major ERPs and dedicated tools like Chargebee and Zuora in detail.
- The Zuora vs. Salesforce Revenue Cloud vs. native ERP module comparison helps you choose between the major Revenue Management platforms based on your ARR and pricing complexity.
- If your usage-based billing project is part of a broader IT architecture overhaul, our guide on composable ERP architecture explains how to decouple business modules from the ERP core for a best-of-breed approach without sacrificing referential coherence.
