> For the complete documentation index, see [llms.txt](https://docs.nalpeiron.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nalpeiron.com/education-and-training/licensing-education/usage-billing-basics/two-architectures-for-usage-based-billing.md).
# Two Architectures for Usage-Based Billing
**Usage-based billing**, **utility pricing**, **metered billing**, and **consumption-based pricing models** are now mainstream. Whether charging per API call, per GB processed, per active user, per transaction, or per AI credit, companies are increasingly aligning revenue to real product usage.
But as organizations adopt usage-based pricing, a critical architectural question emerges:
> Should usage billing be driven by the billing system — or by the product itself?
There are two fundamentally different approaches:
1. **Billing-Side Platforms** (metering → rating → invoicing)
2. **Product-Side Usage & Entitlement Platforms** (real-time enforcement → entitlement control → billing synchronization)
For simple SaaS businesses, billing-centric models may be sufficient.
For complex B2B organizations — especially those with ERP-driven workflows, offline deployments, enterprise contracts, and multi-channel GTM — a product-centric approach becomes strategically superior.
Let’s break down both models and where each fits.
***
## **Approach 1: Billing-Side Usage Platforms**
### **Metering and Invoices First**
In a billing-centric architecture, usage events are collected and sent into a billing system. That system calculates charges and produces invoices.
Typical capabilities include:
* Usage aggregation
* Tiered or volume pricing logic
* Invoice generation
* Revenue recognition
* Tax handling
* Payment collection
* ERP/CRM integration
This approach works well for:
* Simple B2C SaaS applications
* Single-metric usage models
* Self-serve businesses with standardized plans
* Companies where product enforcement is lightweight
In this model:
* The billing platform determines how much the customer owes.
* The product team must separately enforce usage limits.
* Entitlements and access control are often coded into the application.
#### **The Challenge for B2B**
As soon as complexity increases, friction appears:
* Enterprise customers require negotiated usage caps and exceptions.
* Multi-product bundles combine seats + APIs + storage.
* Hybrid models (subscription + usage + perpetual) coexist.
* Customers operate offline, in dark sites, or behind firewalls.
* Mid-cycle changes require real-time entitlement updates.
* ERP systems (NetSuite, SAP, Oracle) drive commercial terms.
Billing systems are excellent at financial accuracy.
They are not designed to control product behavior in real time.
***
## **Approach 2: Product-Side Usage & Entitlement Control**
### **Usage as a Runtime System of Record**
In a product-centric architecture, usage and entitlements are enforced directly within a monetization control plane — such as the **Nalpeiron Growth Platform**.
Instead of simply counting events for invoicing, the platform:
* Evaluates usage in real time
* Enforces limits at runtime
* Manages dynamic entitlements
* Applies contract terms instantly
* Supports hybrid pricing models
* Synchronizes usage data to billing systems
In this architecture:
> The product knows what the customer is allowed to do — before billing occurs.
Usage enforcement and entitlement logic are centralized in a secure, scalable system of record that integrates upstream (ERP, eCommerce, CRM) and downstream (billing, finance).
This is where B2B complexity becomes manageable.
***
## **Why Complex B2B Requires a Product-Side Platform**
Modern B2B software companies operate in environments that include:
* Cloud SaaS deployments
* On-prem enterprise software
* Dark site / air-gapped environments
* Network-based usage enforcement
* OEM redistribution models
* Channel/reseller sales
* Multi-entity corporate customers
* Negotiated contracts with custom usage rules
In these environments, usage is not just an invoice input.
Usage defines:
* Feature access
* Capacity limits
* SLA enforcement
* Contract compliance
* Upgrade triggers
* Expansion signals
A billing-only architecture cannot easily orchestrate these moving parts.
**A product-side monetization control plane can.**
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.nalpeiron.com/education-and-training/licensing-education/usage-billing-basics/two-architectures-for-usage-based-billing.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.