Vendors may describe themselves as billing platforms, metering engines, monetisation systems or payment providers, even though they solve different parts of the workflow.
For a simple monthly subscription, those differences may not matter. For a bespoke enterprise agreement, they do.
Consider a contract that says:
The customer pays €20,000 annually, plus €0.04 per successfully completed transaction above 100,000 transactions per month, excluding refunds and test activity.
To bill this correctly, the company must determine:
- what the contract requires;
- which transactions qualify;
- how much qualifying usage occurred;
- which price and threshold apply;
- when the charge should be invoiced;
- how the money will be collected and recorded.
Each part is handled by a different layer.
The modern billing stack
These nine layers each solve a distinct part of the problem. They often rely on different vendors, and a gap or error in one layer carries through to the next.
Commercial agreements
The signed contract is often the commercial source of truth.
It may contain:
- fixed and usage-based fees;
- minimum commitments;
- tiers and discounts;
- prepaid credits;
- implementation charges;
- annual increases;
- amendments and renewals.
Contracts are written for people. Billing systems need structured instructions such as price, quantity, date, cadence and customer. Someone must translate the agreement into those instructions.
Agreement operations
Agreement operations connect the signed contract to the systems that execute it.
This layer identifies:
- the billing obligations;
- the operational data required;
- where that data lives;
- how thresholds and exclusions apply;
- when each charge should run;
- what should be sent to the billing platform.
Extracting "€0.04 per transaction" is only the beginning. The workflow must also define what qualifies as a transaction, how refunds are treated, which customer owns the activity and when the threshold resets.
This translation is often performed manually by Finance, RevOps and Engineering.
Metering
Metering determines how much activity occurred.
Examples include:
- API requests;
- transactions;
- AI tokens;
- active users;
- processed documents;
- compute hours;
- completed workflows.
Many metering platforms use an event-push model, where the customer's application continuously sends usage events to the platform.
Another option is an endpoint-pull model, where the billing workflow retrieves the required data from an existing customer API when the billing calculation runs. Event streaming is useful for real-time balances, high-volume workloads and immediate entitlement enforcement. Endpoint retrieval may be simpler for periodic billing when the required data already exists in a reliable operational system.
Rating
Rating converts measured usage into money.
For example:
- first 100,000 transactions included;
- next 50,000 at €0.04;
- remaining usage at €0.03;
- 10% discount until a specified date;
- monthly minimum commitment of €5,000.
Rating may involve tiers, credits, commitments, dimensions and customer-specific prices. A rating engine can perform these calculations, but the correct contract terms must first be represented in the system.
Billing and invoicing
Billing determines what the customer owes, which period the charge covers, whether it is billed in advance or arrears, and when the charge should be created.
Invoicing turns that charge into a formal document containing the customer, dates, line items, taxes, currency and amount due.
An invoicing platform can accurately issue the amount it receives. It may not know whether the usage, discount or contractual rate behind that amount was correct.
Payments and accounting
Payment providers collect the amount through cards, direct debit, bank transfers or other payment methods. They normally do not determine what the customer contractually owes — they execute the payment instruction they receive.
Accounting platforms then record invoices, payments, taxes and revenue in the company's financial records. These systems remain essential, but they often depend on an upstream process to calculate the correct bespoke charge.
Partner reconciliation
The same problem exists on the cost side. Businesses receive invoices from:
- payment processors;
- cloud and AI providers;
- carriers;
- logistics companies;
- resellers;
- infrastructure and service partners.
Accounts-payable software may capture and route the invoice. Partner reconciliation determines whether the rates, quantities, tiers, rebates and credits actually match the agreement and operational activity.
Where Verdix fits
Verdix is not intended to replace the entire billing and finance stack.
For customer billing, Verdix:
- interprets the signed agreement;
- structures the billing obligations;
- retrieves usage from customer-defined endpoints;
- creates the billing schedule;
- routes it for approval;
- sends approved instructions to the chosen billing platform.
For partner reconciliation, Verdix compares the partner agreement, operational data and incoming invoice to calculate the expected amount and identify discrepancies.
Customers can continue using their preferred billing, payment, ERP and accounting systems. Verdix determines what should be billed or paid. Existing financial systems execute and record the result.
Which approach do you need?
A standard billing platform may be sufficient when every customer uses similar pricing and invoices follow a predictable schedule.
A dedicated metering engine may be necessary when usage must be tracked in real time across very large event volumes.
An agreement-operations layer is particularly useful when:
- the signed contract is the source of truth;
- commercial terms differ by customer;
- usage already exists behind an API;
- billing is periodic;
- the existing finance stack works;
- partner invoices also require validation.
The takeaway
Metering, billing, invoicing and payments are connected, but they solve different problems.
Before replacing your finance infrastructure, identify where the manual work actually happens. The missing capability may not be another billing or payment platform. It may be the layer that translates bespoke agreements and operational data into instructions your existing systems can execute.