Launching usage-based pricing can align customer cost with the value they receive. But it requires more than deciding to charge per API call, transaction, user or document.
A working usage-based billing process must connect three things:
- the commercial agreement — what the customer agreed to pay;
- operational data — what the customer actually used;
- billing infrastructure — where the approved charge is invoiced and collected.
For a standard self-service plan, this may be relatively simple. For negotiated enterprise contracts, each customer may have different rates, thresholds, commitments and exclusions. Here are the main components required.
1. Choose the right value metric
The billable metric should reflect the value delivered to the customer.
Common examples include:
- API calls;
- AI tokens;
- completed transactions;
- active users;
- documents processed;
- compute hours;
- completed workflows;
- successful outcomes.
A metric should be understandable to the customer, measurable in the product and reliable enough to support an invoice. A technically available metric is not always a commercially useful one. Charging for every system event may be easy to measure but difficult for the customer to understand or predict.
2. Define exactly what counts as billable
A contract may state:
€0.04 per successfully completed transaction above 100,000 transactions per month.
That still leaves several operational questions:
- What status means “successfully completed”?
- Are refunds and reversals excluded?
- Do internal test transactions count?
- Which timestamp determines the billing month?
- How is usage attributed to the correct customer?
- What happens when records are corrected later?
These definitions must be documented before the first invoice is generated. The output should be a clear connection between the contract clause and the operational data used to calculate the charge.
3. Identify the source of usage data
The required activity may already exist in the product database, a data warehouse, an internal API, a transaction platform, an analytics system or a third-party operational platform. There are three common ways to move this data into a billing workflow.
4. Connect usage with the commercial terms
Measured usage alone does not determine what the customer owes. The billing logic may also include:
- included usage;
- volume or graduated tiers;
- minimum commitments;
- prepaid credits;
- caps;
- temporary discounts;
- customer-specific rates;
- annual increases;
- regional pricing;
- contract amendments.
For example, a customer may use 175,000 units, but the first 100,000 may be included and the remaining units may fall into two different pricing tiers. This is the rating step: converting measured activity into a financial amount using the applicable agreement.
5. Build the billing schedule
The billing schedule determines:
- which charges are recurring or one-time;
- whether usage is billed in advance or arrears;
- the start and end of each billing period;
- when an invoice should be created;
- when discounts or pricing phases change;
- how amendments affect future billing.
For bespoke agreements, the schedule should be derived from the final signed contract — not only from a CRM summary or an earlier quote. The schedule should also remain linked to the supporting clauses so Finance can review how each amount was calculated.
6. Choose where billing and payment will happen
Launching usage-based pricing does not always require replacing the existing finance stack. A business may already use Stripe, an ERP, an invoicing platform, a local accounting system, a payment provider or an internal billing solution.
The key question is whether the current platform can receive the approved quantity, rate and schedule.
Some companies need a full metering and billing engine. Others mainly need a reliable way to translate contracts and operational usage into instructions for systems they already use.
7. Add review and approval controls
Automated billing should not mean removing financial oversight. Before a new agreement goes live, Finance or RevOps should be able to review:
- extracted contract terms;
- billable metric definitions;
- data-source mappings;
- discounts and thresholds;
- the calculated billing schedule;
- the destination billing system.
Non-standard terms and uncertain interpretations should be flagged rather than silently applied. A good workflow follows:
8. Prepare for changes
Usage-based agreements rarely remain static. Companies must handle:
- contract amendments;
- additional products;
- rate changes;
- discount expiries;
- annual escalators;
- renewals;
- corrected usage;
- late-arriving operational data.
The billing workflow should preserve the effective date of each change and make clear which contract version applies to each billing period. Without this, the company may have to reconstruct its calculations through old spreadsheets, emails and invoices.
9. Make every charge traceable
Customers may ask why an invoice changed or how a usage charge was calculated. Finance should be able to show a clear line from contract clause to invoice instruction:
This traceability reduces review time and makes billing questions easier to resolve.
Where Verdix fits
Verdix is designed for B2B companies with bespoke customer agreements that want to automate usage-linked billing without replacing their existing billing or payment infrastructure.
Verdix:
- interprets the signed agreement;
- identifies its billing obligations;
- pulls usage from customer-defined endpoints;
- applies the relevant pricing logic;
- creates the billing schedule;
- routes it for approval;
- sends the approved instructions to the preferred billing platform.
The same agreement-to-data approach is used to validate incoming partner invoices before payment or dispute.
The takeaway
Usage-based pricing requires more than a meter.
A complete workflow must connect the commercial agreement, product activity, pricing rules, billing schedule and downstream finance systems.
Before adopting new infrastructure, determine where the real gap lies. You may need a real-time metering engine — or you may need an agreement-operations layer that turns existing usage data into approved billing instructions.