A contract may define charges based on API calls, transactions, active users, AI tokens, documents processed, completed workflows or delivered outcomes. Before the amount can be calculated, that usage must reach the billing workflow.
There are three common approaches:
- continuously push usage events to a metering platform;
- pull the required data from an existing endpoint;
- upload usage through a file.
1. Push usage events
With an event-push model, the product continuously sends individual usage records to a metering or billing platform. A typical event may contain a customer identifier, event type, timestamp, quantity, product or service, and additional dimensions such as region or model. The platform stores and aggregates the events before applying pricing.
Event streaming is a strong choice when:
- usage must be tracked in real time;
- the product generates very large event volumes;
- customers need live usage dashboards;
- credits or limits must update immediately;
- pricing depends on detailed event-level dimensions;
- historic usage may need to be re-rated.
The main challenge is that the customer must build and maintain the pipeline that sends usage to the platform. That may require product instrumentation, event schemas, retry and failure handling, deduplication, customer attribution, monitoring and ongoing engineering ownership. For businesses that need real-time metering, this investment may be justified. For monthly enterprise billing, it may be more infrastructure than necessary.
2. Pull usage from an endpoint
With an endpoint-pull model, the customer identifies an existing API containing the relevant operational data. The billing workflow retrieves that data automatically when the charge needs to be calculated.
For example, an endpoint might provide completed transactions for a billing period, active seat counts, API consumption by customer, successfully processed documents, achieved milestones, or refunds and reversals.
Endpoint retrieval works particularly well when:
- billing is daily, monthly or otherwise periodic;
- the required data already exists through a reliable API;
- the company does not need real-time credit enforcement;
- product teams want to avoid creating a separate event pipeline;
- each agreement may require a different operational definition.
The endpoint must still be configured correctly. The workflow needs to manage authentication, pagination, customer identifiers, field mappings, retries, duplicate prevention, schema changes and missing or corrected data.
3. Upload usage through a file
A file-based process usually involves Finance or Operations exporting usage into a CSV or spreadsheet and uploading it to the billing platform.
File uploads can be useful when testing a new billing workflow, processing a small number of customers, no reliable API exists, billing is infrequent or the company is transitioning from a manual process.
The process remains dependent on people. Each period may require someone to produce the export, check the date range, format the columns, remove irrelevant activity, upload the file, resolve errors and retain evidence of the source. This can work at low volume but becomes difficult to scale.
Side-by-side comparison
The billing model should determine the architecture
No single approach is always better. The right choice depends on how frequently billing runs, how much data is generated and whether real-time controls are required.
Contract terms still matter
Whichever data model is used, usage alone does not determine the invoice. The workflow must still apply:
- included allowances;
- volume tiers;
- minimum commitments;
- discounts;
- credits;
- caps;
- pricing phases;
- amendments.
It must also connect the operational definition with the signed agreement. For example, “successfully completed transactions” must map to a specific status, timestamp, customer identifier and set of exclusions in the source data. A technically accurate usage feed can still produce the wrong charge if the commercial logic is configured incorrectly.
Where Verdix fits
Verdix is designed for companies that already have operational data available through APIs but still rely on Finance, RevOps or Engineering to connect that data with bespoke agreements.
Verdix:
- interprets the signed agreement;
- identifies the required usage;
- retrieves it from customer-defined endpoints;
- applies the agreement-specific pricing rules;
- creates the billing schedule;
- routes it for approval;
- sends the approved instructions to the preferred billing platform.
The same model is used to reconcile partner invoices against agreements and operational activity.
The takeaway
The right usage architecture depends on how frequently billing runs, how much data is generated and whether real-time controls are required.
Many companies need a full event-metering platform. Others already have the data they need and simply require a reliable way to retrieve it, connect it with the agreement and produce the correct billing instructions.