From averages to actual contract logic

A forecast built on averages

MeridianLink's finance team was forecasting revenue the way many usage-based businesses do: take the volume forecast, apply an average rate per item, and roll it up. The rate sat at the division level. A division might hold hundreds or thousands of items at different prices, and all of them were forecast at one blended number, then adjusted up or down by a percentage.

It looked reasonable. It didn't reflect how MeridianLink bills. Their revenue is contract-driven: 12,500 contracts, each with its own term, renewal date and revenue recognition profile, and, above all, its own commitments. A customer might owe a fixed amount every month or every year whatever their volume. Above a minimum, volume starts billing at a per-item rate, or crosses into a different pricing tier. On many contracts several items are grouped and billed together on a separate line, and the combined volume sets the tier for all of them.

An average-rate model can't see any of that. Raise volume 10% and it raises revenue 10%. In reality the answer might be 10%, 2% or zero, depending on where that volume lands against each customer's commitment. Finance had a number, but not one grounded in the billing logic their own team understood, and no way to tell which contracts were driving a miss.

Forecasting happened quarterly. By the time a miss showed up, it was too late to do anything about it.

The billing logic, rebuilt in Anaplan

PlanFlamingo rebuilt the revenue model in Anaplan to replicate MeridianLink's NetSuite contract logic at the individual contract level, across all 12,500 contracts.

1. Every contract carries its own terms. Commitments, minimums, per-item rates, tier thresholds, item groupings, term and renewal dates, and the revenue recognition profile. Contract data loads into the model directly, so there is no re-keying.

2. Volumes run through contracts, not averages. Pipeline adjusts the volume forecast. Volumes then flow into each contract, where the model applies the commitment, checks the minimum, groups the items that contract groups, finds the tier the combined volume lands in, and bills at that tier's rate. The output is revenue calculated the same way the billing team calculates it.

3. Committed and overage revenue, kept separate. Finance can see what a customer owes regardless of usage and what moves with volume. That distinction is exactly what an average-rate model hides.

4. Revenue recognition on top. Once contract revenue is calculated, each contract's recognition rules delay or allocate it across the right months.

5. Sensitivity and variance by contract. Move volumes by 2%, 5% or 10% and see whether revenue moves by 2%, 5%, 10% or not at all, and which contracts make the difference. Variance analysis runs at the contract level, so a miss traces back to the customers behind it.

6. Twice-monthly refresh. The model is fast and accurate enough to trust, so the forecast moved from quarterly updates to running twice a month.

A forecast that matches the bill, and churn caught early

The biggest change came out of the volume forecast itself. Because volumes were tracked item by item inside each contract, the model could flag patterns the aggregate never showed: a customer whose contract was still active but who had stopped billing on several items two months in a row. Finance flagged those accounts to product. Product opened a conversation with the customer. In some cases what looked like a customer quietly heading for the exit turned into a sale of a product that fit them better. Before, the first signal would have been the cancellation.

Those saved and expanded accounts added revenue that would otherwise have walked out the door. Finance can now distinguish committed revenue from overage revenue, run sensitivity on volume customer by customer, and answer "what happens to revenue if this customer's volume drops" with the contract's own terms instead of an average.

As the model matured, we also worked with MeridianLink to redefine how they measure and report ARR. With contract-level data flowing through the model, the team moved from a high-level ARR approximation to a definition grounded in actual contract terms: committed minimums, active tiers, and renewal visibility. Finance and the board got a more accurate picture of recurring revenue and how it's growing.