The billing tooling landscape has expanded quickly. Metering engines, billing platforms, revenue recognition systems, CLM tools, and now a new category called agreement-operations or billing intelligence. It can be hard to know which problem each one solves—and whether you have that problem.
This post draws a clear line between two categories that are often conflated: metering engines, which solve a data-capture problem, and agreement-operations layers, which solve a contract-interpretation problem. They are not alternatives to each other. They answer different questions. But most B2B companies only need one of them, and building the wrong one tends to leave the harder problem unsolved.
What a metering engine does
A metering engine is infrastructure for recording product usage at scale. You emit events—API calls, AI token counts, compute seconds, active sessions—and the engine captures, deduplicates, aggregates, and stores them reliably. The defining characteristics are volume and real-time availability. A metering engine is designed to handle millions of events per day, make current usage visible within seconds, and enforce limits before a customer exceeds them.
Examples of where metering engines genuinely solve a problem: you want to show a customer their live token usage in a dashboard; you need to cut off API access when a prepaid balance runs out; you are billing per call at sub-cent granularity across a large customer base. The problem is fundamentally one of data infrastructure—collecting raw signal at high frequency without losing events.
What an agreement-operations layer does
An agreement-operations layer starts from a different place: the signed contract. Its job is to read the commercial terms in that contract—rates, tiers, minimum commitments, included allowances, escalation triggers, partner charges—and translate them into a billing run. It does not necessarily need to capture new events. Often, the data it needs already exists in operational systems: a CRM, an internal platform, a data warehouse, a partner API. The hard part is not collecting the data. The hard part is interpreting what the contract requires, knowing which data to retrieve, and applying the right calculation to produce an accurate invoice.
This is the problem Finance teams face every month with enterprise accounts. They have the contract. They have access to the data. They just spend days manually cross-referencing them. An agreement-operations layer automates that process.
Why they are not the same problem
A metering engine solves the question: what happened? An agreement-operations layer solves the question: what should be billed based on the agreement?
These questions are related but they are not the same. You can have perfect usage data and still face enormous billing complexity if your contracts are bespoke. You can have simple contracts and still need robust metering if your product emits billions of events. Many companies struggle to see this clearly because they conflate the billing process with the data problem that one part of that process requires.
The way to diagnose which problem you actually have is to trace where your billing friction originates. Does it come from not having reliable usage data? That is a metering problem. Does it come from someone in Finance spending hours mapping contract language to calculations each month? That is an agreement-operations problem.
A practical example
Consider a B2B SaaS company selling a data platform to enterprise customers. Each contract specifies different data volume tiers, different overage rates, a platform fee, a minimum annual commitment, and sometimes a reseller discount applied on top. Every month, Finance pulls a usage report from an internal dashboard, opens the signed contract in Google Drive, and builds a spreadsheet to calculate what each customer owes. This takes three to four days across the billing cycle.
Does this company have a metering problem? Not really—usage is already tracked and accessible. Does it have an agreement-operations problem? Absolutely. The friction is in interpreting bespoke contracts and applying them to available data, not in collecting the data itself. Adding a metering engine would not change anything. The bottleneck is the manual interpretation step.
Which one do you need?
Use both when you need both
There is a class of company that genuinely needs both. Enterprise SaaS businesses with high-volume product usage and bespoke negotiated contracts are the clearest example. Their product generates millions of events per day and those events must be reliably captured—that is the metering engine's job. But the resulting usage then feeds into a billing process governed by individual customer agreements, each with different commercial terms. That is the agreement-operations layer's job.
In this combined model, the metering engine handles real-time capture and aggregation. The agreement-operations layer reads the contract, knows what to fetch, applies the agreed rates and rules, and produces the billing schedule for Finance to approve. The two systems are complementary, not overlapping.
The mistake to avoid
The most common mistake is building a metering engine to solve an agreement-operations problem. Teams do this because event capture feels more tractable—it is a data engineering task with clear primitives. Contract interpretation feels messy and human, so it gets deferred. The result is a robust metering infrastructure that has not reduced the billing burden, because the metering was never the bottleneck.
The inverse mistake also happens. Some companies invest in an agreement-operations layer before they have an agreement worth interpreting. If your pricing is simple and consistent across all customers, a spreadsheet is probably fine. The agreement-operations problem only becomes real when contracts diverge.
Where Verdix fits
Verdix is an agreement-operations layer. We start from signed contracts, extract the billing obligations they contain, connect to the operational data sources those obligations reference, and produce the invoice ready for Finance approval. We are designed for B2B companies where billing friction begins with bespoke agreements—and where the data to satisfy those agreements already exists somewhere in your stack.
If you are also running a high-volume metering platform, Verdix can pull from it as one of those data sources. If you are not—if your usage data lives in a database, a data warehouse, or a partner API—you do not need a metering engine to use Verdix. The data you already have is enough.