Billing problems do not always require a billing replacement
When billing becomes manual, companies often assume the answer is a new billing platform.
Sometimes that is correct. But many businesses already have systems that can:
- generate invoices;
- collect payments;
- manage subscriptions;
- record transactions;
- post financial data into the ERP.
The real gap may be earlier in the workflow: translating bespoke agreements and operational usage into the correct billing instructions.
There are three main approaches:
- Replace the billing platform
- Extend the existing stack
- Add an agreement-operations layer
1. Replace the billing platform
A full replacement moves billing logic, subscriptions, usage calculations, invoicing and sometimes collections into a new platform.
Replacement may make sense when:
- the current system cannot support usage-based pricing;
- real-time metering is required;
- pricing models are becoming significantly more complex;
- several disconnected billing tools need to be consolidated;
- the company needs native credit balances, entitlements or re-rating;
- the existing platform creates frequent operational failures.
A migration may require:
- moving customer and subscription data;
- rebuilding pricing plans;
- instrumenting usage events;
- integrating CRM, payments and ERP systems;
- testing historic and future billing;
- retraining Finance and Operations teams;
- managing the transition between platforms.
Replacement can solve a broad infrastructure problem, but it is usually the most expensive and disruptive option.
2. Extend the existing stack
A company may keep its billing platform but add a specialised capability around it.
Examples include:
- a metering engine for high-volume usage;
- an entitlement platform for feature access;
- a revenue-recognition tool;
- a collections platform;
- an AP automation system;
- a reporting or reconciliation layer.
Extension may make sense when the existing billing platform works well, one specific capability is missing, the new tool can integrate cleanly, and the company wants to avoid a full migration.
For example, a SaaS company may keep Stripe for invoicing and payments while adding a metering platform to calculate product usage. This approach is often more practical than replacing the whole stack.
3. Add an agreement-operations layer
An agreement-operations layer focuses on the workflow between the signed contract, operational data and the finance systems already in place.
It helps determine:
- what the customer agreed to pay;
- which data are required;
- how usage should be calculated;
- when discounts or thresholds apply;
- what billing schedule should be created;
- what instructions should be sent downstream.
This approach is useful when the company's invoicing and payment systems work, but Finance still manually interprets contracts and prepares billing inputs.
Agreement orchestration may make sense when:
- enterprise agreements differ by customer;
- signed contracts are the commercial source of truth;
- billing is periodic;
- operational data already exists behind an API;
- Finance relies on spreadsheets or Engineering support;
- the company wants to retain its ERP or payment provider;
- partner invoices also require contractual validation.
A simple decision framework
Example
Suppose a B2B SaaS company already uses Stripe and an ERP. Its Finance team still has to:
- read every enterprise contract;
- identify customer-specific rates;
- request monthly usage from Engineering;
- calculate thresholds and discounts;
- enter the approved amounts into Stripe.
Stripe may not be the problem. It can create the invoice and collect the payment. The missing capability is the connection between signed agreement, operational usage and approved billing instruction. Replacing Stripe would not automatically remove that work unless the new platform also interpreted the agreement and connected it to the relevant data.
When a full metering platform is the better choice
An agreement-operations layer is not a substitute for all billing infrastructure.
A dedicated metering and billing platform is usually better when:
- the product generates very large event volumes;
- usage balances must update continuously;
- customers need real-time spend visibility;
- entitlements depend on current usage;
- late events must be reprocessed;
- metering is part of the product experience.
The right solution may also combine both approaches. A metering engine can calculate usage, while an agreement-operations layer applies customer-specific contractual terms and routes the approved result to invoicing.
Where Verdix fits
Verdix is designed for companies that want to automate bespoke agreement workflows without replacing their existing finance infrastructure.
For customer billing, Verdix:
- interprets the signed agreement;
- identifies the relevant pricing and billing terms;
- retrieves usage from customer-defined endpoints;
- applies the agreement-specific logic;
- creates the billing schedule for approval;
- sends approved instructions to the chosen billing system.
For partner reconciliation, Verdix compares the agreement, operational data and partner invoice to identify differences before payment or dispute.
The takeaway
The question is not simply which billing platform to buy. The better question is: where does the manual work begin, and which part of the stack is actually missing?
Replace the platform when the infrastructure itself is limiting the business. Extend it when one specialised capability is missing. Add an agreement-operations layer when the existing systems work but bespoke contracts still depend on manual interpretation and coordination.