Revenue Intelligence for MSPs

Revenue Intelligence for MSPs means continuously comparing what you manage, what you buy and what you bill: the devices and users in your RMM and PSA, the licences held with your vendors and distributors, the tickets and hours your team spends, and the contracts and invoices per customer. Every difference between those sources is either a cost you are not passing on or a service you deliver without the customer paying for it. At an MSP with hundreds of customers and thousands of licences, there are always more of them than you think.

A managed service provider has an unusual business model. Most of the revenue is recurring and predictable, but the underlying quantities change every month: users come and go, devices are replaced, licences are added, vendors adjust their prices. If billing is not aligned with that reality every month, revenue leaks. Not once, but again every month.

How does an MSP make revenue?

Each stream has its own source for the quantity and its own route to the invoice. Managed services are billed on a count held in the contract or the PSA. Licences on what the distributor invoices, or on what someone entered. Out-of-contract work on tickets flagged as billable. If those sources are not compared, they drift apart.

The four comparisons

Revenue Intelligence for an MSP comes down to four comparisons that have to reconcile every month.

1. What you manage versus what you bill

The number of devices with an active agent in your RMM, the number of users in the customer's environment, the number of sites. Put that next to the number the customer pays for under the contract. If you manage 140 devices and bill 120, you are supporting twenty devices for free.

This gap almost always opens gradually. The customer hires people, laptops are added, someone on your team installs the agent as they should. The contract is not updated, because nobody passes the signal to whoever maintains billing. The reverse happens too: devices that have been offline for months but are still billed. That is not leakage, but it is a risk to the relationship that you would rather discover yourself.

2. What you buy versus what you resell

For every licence you resell, you pay your vendor or distributor. The number of licences you buy should match the number you bill, plus any licences you deliberately keep for your own use or as a buffer.

In practice this rarely reconciles. Licences are added in the vendor portal without billing being updated. A customer moves to a more expensive plan, and you keep billing the old one. An employee leaves the customer, the licence is no longer billed to the customer, but it keeps running with the vendor. This is the territory of SaaS billing leakage at MSPs, where it is covered in detail.

3. What you do versus what the contract covers

Every managed services contract has a scope. Whatever falls outside it is billed separately: projects, work on systems not under management, office moves, training, sometimes out-of-hours work. In practice the boundary is interpreted generously. An engineer picking up a ticket does not look at the contract. They fix the problem.

The comparison: tickets per customer by category, next to the scope of the contract. Which tickets should have been flagged as billable? Which customers structurally consume more hours than the contract covers?

4. What your contracts say versus what you bill

The contract states a unit price, an indexation clause, a term and sometimes a minimum commitment. Is indexation applied every year? Are vendor price increases passed on where the contract allows it? Does the unit price on the invoice match the one in the contract? The general pattern of recurring revenue that does not add up is covered in how do you find errors in recurring revenue.

Where does the data sit?

An MSP has many systems, and most of them are well structured. That is an advantage: the comparisons are technically straightforward to make.

The problem is not missing data. The problem is that it sits in six or more systems, each with its own customer number and its own way of counting. Comparing them requires you to match customers, products and units across systems. That is one-off work, but it does have to be done.

The leaks at a glance

The individual leaks are worked out in revenue leakage at MSPs. Here is the overview:

1. Devices and users above the contract. The customer grows, the contract does not.
2. Licences bought but not billed. Added with the vendor, not with the customer.
3. Licences at the wrong tier. The customer uses a more expensive plan than you bill.
4. Vendor price increases not passed on. The cost price rises, the selling price does not.
5. Out-of-scope work handled as contract work. The ticket is resolved, not billed.
6. Hour bundles overrun unnoticed. The bundle is used up, the work continues.
7. Onboarding and migration projects that run over budget. The fixed price was too low or the scope grew.
8. Contracts without indexation. The price is still at the level of years ago.
9. Vendor commitments that do not match the customer. You have an annual commitment with the vendor, the customer can cancel monthly.
10. Hardware without margin or without an invoice. A replacement laptop leaves the building and is never billed.

Worked example

Worked example: take an MSP with EUR 4 million in revenue and 150 customers. Revenue consists of EUR 2 million in managed services, EUR 1.4 million in resold licences and EUR 600,000 in projects and out-of-contract work.

That is around 3.8 percent of revenue. The licence amount is based on the purchase value: with a resale margin, the missed revenue is higher. And because everything is recurring, each of these leaks costs the same amount again next year if it is not corrected.

The assumptions are illustrative. There is no reliable industry average for leakage at MSPs. What the example shows is where the weight lies: at most MSPs, the largest amount sits in the gap between what is managed and what is billed.

What are the signs that your MSP is leaking revenue?

A few signs are so common at MSPs that they almost always point to leakage:

1. Licence margin fluctuates month to month for no clear reason. If purchases and sales moved in the same proportion every month, the margin would be stable. Fluctuations mean the two are out of sync.
2. The number of managed devices grows faster than managed services revenue. Then devices are being added without contracts growing with them.
3. Engineers say certain customers "always call". Customers who raise many tickets cost more than their contract. The question is whether that work falls within the scope.
4. The back office adjusts billing on request, not on signal. When a customer calls to say an employee has left, the invoice is adjusted. When an employee joins, nobody calls.
5. Nobody knows offhand when contract prices were last adjusted. Then it was probably too long ago.

The fourth sign is the most important. It reveals an asymmetry that exists at almost every MSP: decreases are processed quickly, because the customer asks for them. Increases are processed slowly, because nobody asks for them. That asymmetry alone is enough to lose revenue every month.

Why doesn't a PSA solve this on its own?

A good PSA brings a lot together: tickets, contracts, hours and often billing too. So why doesn't it reconcile?

The PSA bills what is in it. If the device count in the contract is 120, it bills 120. That the RMM sees 140 is another module, and updating the contract is an action someone has to take.

Licences are not in the PSA, or arrive late. Vendor portals can often be connected, but not always completely. And a connection that pulls in the quantity does not tell you whether the selling price is right.

A contract's scope sits in a document, not in a field. The PSA knows a customer has a contract. Which systems, which types of work and which hours it covers is often in a PDF. An engineer picking up a ticket does not see it.

Nobody compares. The biggest problem is organisational. The service desk resolves tickets, the account manager sells, the back office bills. Nobody is tasked with checking every month whether the four comparisons reconcile.

Revenue Intelligence takes over exactly that task: reading the systems together and listing the differences, with an amount per customer. It does not replace the PSA or the RMM. What Revenue Intelligence is in general is explained in what is Revenue Intelligence.

Related patterns outside the MSP world

Many of these patterns also occur at companies that sell their own software on a subscription basis. The mechanisms are similar: quantities that change without billing following, price tiers that do not match actual usage. For further reading: SaaS billing leakage covers it from the software vendor's side, and revenue leakage from wrong subscriptions from the subscription itself.

A five-step approach

Step 1: match your customers across systems

Build a table with one row per customer and that customer's ID in every system: PSA, RMM, each vendor portal, billing. This is the dull part and the most important one. Without this mapping you cannot compare anything.

Step 2: compare devices and users

Per customer: number of active devices in the RMM, number of users in the environment, number under the contract, number billed. Choose a definition of active, for example seen in the last thirty days, and apply it consistently.

Step 3: compare licences

Per customer per licence type: quantity with the vendor, quantity billed, cost price, selling price. Every line where the quantity bought is higher than the quantity billed, or where the selling price is below cost plus your target margin, is a finding.

Step 4: analyse out-of-scope tickets

Take three months of tickets. Have someone who knows the contracts assess a sample: did this fall within the scope? Extrapolate to a year. Also look at which customers structurally consume more hours than their contract justifies.

Step 5: make it monthly, or continuous

The first four steps are a baseline. The value lies in repeating them. Because the underlying quantities change every month, an annual check is too slow: within a year they have drifted apart again. Many MSPs build this comparison with exports and a spreadsheet, and find that after a few months it is no longer kept up. Continuous monitoring, with the systems themselves connected, prevents that. RiOS is a platform being built for this: it is in beta, connects to existing systems, monitors revenue leakage continuously and is priced per company, never per seat. Which systems it connects to is shown on the system page.

Checklist

1. Is there a mapping per customer between PSA, RMM, vendor portals and billing?
2. How many devices do we manage in total, and how many do we bill?
3. How many licences do we buy, per type, and how many do we bill?
4. Have our vendors' price increases from the past year been passed on to our customers?
5. When were our managed services contracts last indexed?
6. What percentage of tickets is flagged as billable, and has that changed in recent years?
7. Which customers structurally consume more hours than their contract covers?
8. Which hour bundles have been overrun without a new bundle or invoice?
9. Which licences carry a longer commitment with the vendor than with the customer?
10. Who owns the monthly reconciliation?

Frequently asked questions

Why does an MSP leak more than an ordinary IT supplier?

Because its revenue consists of quantities that change every month: users, devices, licences. Every change has to be processed in billing. A supplier that sells one-off does not have that problem.

Isn't a PSA with integrated billing enough?

It helps, but it does not solve it. The PSA bills what is in the contracts. Leakage arises because the contracts are not updated when reality changes. For that you need to put the PSA next to the RMM, the vendor portals and the customer's environment.

How often should you reconcile licences?

Monthly, with every billing run. Licences change constantly, and a difference left standing for a month costs a month of margin. For large customers with a lot of movement, checking more often makes sense.

What do you do with devices that are managed but not in the contract?

Discuss it with the customer. It is usually a logical consequence of growth, and the contract is adjusted accordingly. Set out in your contracts in advance how this works, for example a monthly count based on your RMM, so it does not become a negotiation.

Where do you start if you have never done this?

With the licences from your largest vendor. It is a well-defined comparison, the data is readily available, and every difference is money straight away. Then devices, then tickets.