ReconIQ: Revenue Leakage and Billing Reconciliation
Contract, invoice and usage reconciled continuously instead of discovered in a quarterly audit, with every discrepancy priced before it compounds.
Client
B2B SaaS Enterprise, Multi-System Billing Estate
Industry
Subscription Revenue · Billing Operations
Duration
5 months
Year
2025
Background
Revenue leakage is rarely one large error. It is an expired discount that kept applying, a usage tier that was never billed, a credit issued twice because two people were handling the same ticket, each small enough to pass review, and cumulative enough to matter. The contract terms lived in the CRM, the invoices came out of the billing system, and the usage that was supposed to justify both sat in a third place. Nothing compared them until someone ran an audit, by which point the affected invoices were months old and the customer conversation was awkward.
The Challenge
The hard part is not reading three systems. It is that three systems never agree about time. A contract is effective from a date, a billing cycle closes on a different one, and usage meters aggregate on a third, so a mismatch at any single instant is usually a timing difference rather than an error. Distinguishing the two is the whole problem. Get it wrong in one direction and real leakage stays invisible; get it wrong in the other and finance receives hundreds of flags a day, stops reading them within a week, and the system is worse than nothing because it now provides false assurance.
Our Solution
SageWare built a reconciliation engine that continuously matches three sources against each other: contract terms from the CRM, issued invoices from the billing system, and metered usage from the product. Each entitlement is evaluated against what was actually billed and what was actually consumed, with period boundaries normalised so proration and cycle offsets are understood rather than flagged. Discrepancies are classified by cause (under-billed usage, a discount past its expiry, a duplicate credit, a missing charge) and each one is priced, so finance sees a ranked list in currency rather than a wall of undifferentiated alerts. Confirmed discrepancies generate a correction workflow that routes for approval rather than writing to the billing system directly.
Key Deliverables
- Three-way match across CRM contract terms, billing output and metered usage
- Period normalisation so proration and cycle offsets are understood, not flagged
- Discrepancies typed by cause and ranked by currency impact
- Corrections routed for finance approval rather than written back automatically
Results & Impact
How We Did It
01
Entitlement Model
Mapped what a contract actually entitles a customer to, separately from how the billing system happens to represent it, so the two could be compared rather than assumed equivalent.
02
Period Normalisation
Aligned contract effective dates, billing cycle boundaries and usage aggregation windows onto a common timeline, so a timing difference stops looking like an error.
03
Classification & Pricing
Typed each discrepancy by cause and attached a currency impact, turning an undifferentiated alert stream into a ranked, actionable list.
04
Correction Workflow
Built the approval path so a confirmed discrepancy becomes a reviewed correction rather than an automated write into the billing system.
Decisions & Trade-offs
A late usage event and an under-billed one look identical
Metering pipelines drop events, duplicate them and deliver them late. At the instant of comparison, usage that has not arrived yet is indistinguishable from usage that was never billed — and treating the first as leakage means finance spends its week chasing pipeline lag. We hold a settling window per source before a shortfall is allowed to become a discrepancy. It costs a day or two of latency on the genuine findings. It is the difference between a tool finance trusts and one they mute.
Thresholds relative to the account, not to a constant
A fixed variance threshold has one setting and two failure modes: low enough to catch a subtle under-bill on a small account and it buries the team on large ones, high enough to be quiet on large accounts and the small leaks never surface. We compare each account against its own billing history instead, so “normal” is defined per customer. The cost is that a brand new account has no history to be judged against, and runs on conservative defaults until it does.
Flag it, never fix it
The engine has everything it needs to write the correction straight into the billing system, and it deliberately does not. An automated correction that is wrong is a second billing error on top of the first — except this one was caused by us, at machine speed, across every affected account. Every confirmed discrepancy becomes a proposed correction that a person approves. It keeps a human in the loop on every dollar moved, which is exactly where we wanted them.
Scope & Boundaries
We built the reconciliation engine, the discrepancy model and the approval workflow. The billing system remains the system of record and the only thing that issues credits or invoices — we propose corrections, the client’s finance team applies them. Contract data quality in the CRM stayed the client’s, and we report on it rather than repair it.
Next Case Study
DealSignal: Deal Risk and Pipeline Health Scoring
Revenue Operations · Sales Intelligence