MSP Billing and Cloud Licence Reconciliation Software: Where Is Your Margin Actually Leaking Each Month?

Why MSP billing leaks in a direction you never notice

It is the second working day of the month. Someone in finance exports agreements from ConnectWise or Autotask, downloads a seat report from Partner Center, pulls a device list from the RMM, opens the Pax8 invoice, and starts comparing. A client shows 62 seats in the tenant, 58 on the agreement, 54 devices in the RMM, and the distributor billed for 62. Another client offboarded eleven people in March and nobody removed them from the agreement, so you are paying for licences you no longer resell. A third had a new site go live in the middle of last month and the seats were never added anywhere.

Notice the asymmetry. The client always tells you when you overbill. Nobody has ever called to report that they are being undercharged. So the errors that survive are systematically the ones that cost you, and they compound quietly, month after month, on agreements you renew without ever recomputing. This is why MSP owners who finally reconcile properly usually find a number that changes their view of the business, and why they are often annoyed rather than pleased.

What Gradient MSP, Rev.io and Datagate actually leave you doing

Gradient MSP is the closest fit to this problem and genuinely useful. It connects to a set of supported vendors, compares those counts against your agreements, and surfaces variances. Rev.io is a capable billing platform with strong rating and invoicing, and Datagate is well regarded where telecom billing and its tax handling are involved.

Two limits recur. Coverage: the reconciliation is only as good as the supported integrations, and every MSP has a handful of services that matter commercially and are not on anyone's list, whether that is a niche compliance tool, a hosted line of business application, or your own managed service with a seat count you maintain by hand. Those are exactly the ones nobody checks. And model: these tools compare counts to agreement lines, but your commercial reality is bundles, tiers and minimum commitments. When you sell a Complete package at one price per user that contains six underlying products at four different vendor costs, a per SKU variance report cannot tell you whether the bundle is priced correctly, whether a client dropped below their commitment, or what your true margin per client is after distributor cost. Billing platforms invoice beautifully from numbers you give them. The hard part is deciding what the numbers should be.

Problem 1: entity resolution is the actual engineering problem

Everyone assumes reconciliation is subtraction. It is not. It is deciding what belongs to whom. A tenant maps to a client, usually. A device in the RMM maps to a client via a site that was named differently three years ago. A backup job maps to a server whose hostname tells you nothing. A distributor invoice line references a subscription identifier that appears nowhere in your PSA. Meanwhile some counts should legitimately be excluded: shared mailboxes, resource accounts, spare laptops on a shelf, your own internal tenant, a test account, the licence you gifted the client's owner.

What a build does: an explicit mapping layer with client, site, tenant, subscription and device as separate entities, plus exclusion rules that are recorded with a reason and an owner rather than silently applied. Unmapped items go into a queue rather than disappearing, because an unmapped device is either a billing opportunity or a security blind spot and both deserve a human. Every MSP we have built this for underestimates this layer and every one of them ends up saying it was the part that mattered.

Problem 2: your commercial model is bundles, and the data is SKUs

You sell tiers. Essential, Advanced, Complete. Each is a promise made of components: a Microsoft 365 plan, endpoint detection, managed backup, email security, a patching service, maybe a phone seat. Vendors bill you per component. Clients pay you per user per tier. Nothing anywhere holds the mapping between the two except a spreadsheet and your memory.

A build makes the bundle a first class object with a component list, an effective date and a price, so the system can answer the questions that matter: is every user on this client's Complete tier actually receiving all six components, which is a service delivery question as much as a billing one, and what is the cost of that bundle this month given what the distributor actually charged. Clients who are paying for Advanced but missing a component are a churn risk, and clients receiving Complete components on an Essential agreement are pure loss. Neither is visible in a per SKU variance report.

Problem 3: mid month changes and commitment terms fight each other

A client adds nine users on the 12th and removes four on the 26th. What do you bill. Your agreement may say full month on adds and full month on removes, or prorate both, or use a count on a specific day. Underneath, your cost behaves differently: annual term subscriptions in the Microsoft cloud programme carry commitments that cannot simply be reduced mid term, so a seat removed by the client can remain a cost to you until renewal. If your billing prorates the client down while your cost stays flat, you have just funded their downsizing.

A build encodes the billing rule per agreement and the cost behaviour per subscription separately, then shows both. That immediately answers a question most MSPs cannot: which clients are shrinking faster than your commitments can follow, and what that is costing this month. It also flags a change that should trigger a conversation, such as a client reducing seats on a term subscription who might accept a co term extension instead of an argument at renewal.

Problem 4: the variance report nobody acts on

Plenty of MSPs have a reconciliation report. Fewer have a process where variances get resolved. A report with 340 lines every month becomes wallpaper by month three.

What a build does: treat each variance as a work item with a state, an owner, an age and a value. Sort by dollars, not by client name. Group by cause, since twelve variances that all stem from one offboarding process failure are one problem, not twelve. Auto resolve the categories that are safe to automate, such as a seat added in the tenant that simply needs the agreement quantity updated, with an approval step and an audit record. Escalate anything above a threshold. And track aging, because a variance that has been open for four months is a process defect and should be reported as one. The measure of success is not that you produce a variance report, it is that the count of open variances trends down while your client base grows.

Problem 5: you do not know your margin per client

Most MSPs know revenue per client and total cost of goods. Very few can state margin for one client this month including distributor cost, the labour hours that client consumed on tickets, and the licences you are carrying for them that nobody is paying for. That number is the one that decides pricing, renewal strategy and whether a difficult client is actually worth keeping.

A build joins agreement revenue, actual vendor cost from distributor invoice lines, and time logged in the PSA into one margin view per client per month. It usually produces two surprises: the client everyone complains about is fine because the contract is priced right, and a quiet client is unprofitable because they were priced in 2021 and have doubled in size on a per site fee. Once you can see it monthly, renewal conversations change from a negotiation about price to a conversation about scope.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release with count ingestion from your main vendor sources, the entity resolution and exclusion layer, and an actionable per client variance workflow runs $45,000 to $100,000 and ships in 10 to 14 weeks. Adding bundle modelling, proration and commitment handling, automatic agreement sync back into the PSA, distributor cost ingestion and margin reporting brings the total to $130,000 to $320,000 across 6 to 10 months.

What drives cost up: the number of vendor sources, because each has its own interface, its own identifiers and its own idea of what a seat is. Writing back into ConnectWise or Autotask, which is a different order of care than reading, since a bad write hits invoices. Multiple distributors, since Pax8, Sherweb, Ingram and TD Synnex all present cost data differently. Telecom, if you resell voice, because tax and rating are their own discipline and it may be genuinely better to keep Datagate for that piece. And multi currency if you operate across borders.

What keeps cost down: starting read only. A first release that only reports variances, with no write back, ships faster, builds trust in the numbers, and lets you fix the process problems before you automate them. Automating a broken offboarding process just makes the wrong number arrive faster.

Build versus buy, and when buying is right

Buy if you have under about 40 clients and a straightforward stack of two or three vendors. Gradient MSP costs a fraction of a build and will find most of what you are missing. Buy if your gap is invoicing and tax rather than counts, in which case Rev.io or Datagate is the correct answer and building your own rating engine is a poor use of money.

Build when two or more apply. You are past roughly 150 clients or 4,000 billable seats, where a percentage of leakage becomes a real salary. Commercially important services sit outside any packaged tool's integration list. You sell bundles and tiers rather than raw SKUs, so per SKU variance reporting does not answer your questions. You have acquired another MSP and now run two agreement structures, which is the single most common trigger we see. Or you want margin per client monthly and your current answer is an annual spreadsheet.

How to choose a developer

Ask them how they would decide which client a device belongs to. The right answer discusses an explicit mapping layer, an unmapped queue and recorded exclusion rules with reasons. A developer who says they will match on client name has never seen your RMM's site list.

Ask how they would handle writing agreement changes back into your PSA. Listen for an approval step, an audit record and the ability to reverse a change. Anything that syncs silently will eventually put a wrong quantity on an invoice and you will not know which system did it.

Ask what they have actually integrated by name: Partner Center, the specific RMM, the specific distributor. Distributor cost data in particular is fiddly and quite different from vendor seat data, and experience shows fast.

Ask who owns the code and settle it before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. An MSP of all businesses understands what vendor lock in costs, and it would be an odd thing to accept in the system that decides your own revenue.