Almost every MSP we've ever looked at is under-billing. Not by fraud, not by laziness — by drift. A client adds twelve workstations over a quarter. A new hire gets onboarded and picks up a Microsoft 365 license. Someone provisions an extra security agent for a server that wasn't in the original scope. None of those are dramatic. None of them trip an alarm. But your tools all know they happened, and your invoice doesn't.
That gap between what your stack reports and what your client pays is billing leakage. It's quiet, it compounds, and it's almost always larger than the owner thinks.
Where the money leaks out
When we sat down to map this for the MSP that Morton Command Center was first built for, the leaks fell into a handful of repeatable buckets. You'll recognize most of them.
- Endpoints added without a contract bump. Your RMM — NinjaOne, Datto, or whatever you run — happily onboards new devices the day a tech installs the agent. The managed-device count on the contract was set six months ago and nobody went back to update it. Your RMM knows you're managing 712 endpoints; the invoice still bills 680.
- Seats that grew. A client hired five people. Five new users showed up in your identity platform — Microsoft 365, say, with E3 licenses. If your agreement bills per-user, that's five seats of revenue that depend on someone noticing the headcount changed.
- Licenses and subscriptions that drifted. Backup coverage, EDR agents, identity protection, distributor subscriptions — each is a count that moves on its own schedule. The amount you're paying the vendor moved; the amount you're charging the client didn't.
- Block hours and billable work that never made it onto an invoice. Time gets logged, the month closes, and the unbilled entries sit there because nobody cross-checked the timecards against what actually got invoiced.
Individually these are rounding errors. Across forty clients and twelve months, they're a salary.
Why it's so hard to catch by hand
The information needed to catch every one of these leaks already exists — it's just scattered across systems that don't talk to each other. The device count lives in your RMM. The seat count lives in your identity platform, like Microsoft 365. The security agent count lives in your EDR tool — Huntress, for example. The invoice lives in your accounting system — QuickBooks, Xero, Sage, or anything with an API. The contracted quantities live in a spreadsheet, a PSA field, or somebody's memory.
To reconcile by hand you'd have to log into each tool, export each count, open the agreement, and compare line by line — per client, every month. Nobody does that consistently, which is exactly why the drift accumulates. The first month you skip it, you don't notice. By the time you do a real audit, you're looking at a year of compounded gaps and trying to decide whether you can even back-bill them.
What reconciliation actually does
This is the part worth being precise about, because "reconciliation" can sound like magic and it isn't. What Morton Command Center does is compare the live counts your tools report against the quantities your billing config says each client should be charged for, and flag the differences. It surfaces the drift. It does not silently rewrite anyone's invoice.
Concretely: it pulls managed-device counts from your RMM (we build your RMM integration custom to your stack), license and seat counts from your identity platform such as Microsoft 365 (read-only — CC reads those numbers, it doesn't change your tenant), security agent counts from the security vendors we connect for you, and your unbilled timecards from your time-tracking tool — we wire in eBillity or whatever tracker you run, or you can use the native timer. It lines those up against each client's billing configuration and shows you, per company, where the numbers disagree and by how much. Because every integration is built to fit your stack, the same applies to whatever you actually run in each of those categories — if your tool has an API, we build it for you.
The output is a list a human reviews. You see "this client is contracted for 40 seats and Microsoft 365 shows 47" and you decide what to do: bump the agreement, write it off, confirm seven of those are shared mailboxes that shouldn't be billed. The judgment stays with you. The tedious part — gathering, normalizing, and comparing the counts across half a dozen systems — is what gets automated.
That distinction matters because billing is the one place an MSP cannot afford a tool that "just fixes it." A wrong auto-adjustment is a wrong invoice, and a wrong invoice is a hard conversation with a client. So the design rule we held to was simple: the system finds and flags, the person approves. When you're ready to act on a confirmed gap, the same platform can turn that into a real invoice — we build your accounting integration as part of your engagement, and because every integration is built to fit your stack, any accounting system with an API connects the same way. Either way it can generate the invoice from your unbilled timecards rather than re-keying anything.
The numbers move on a schedule, not on a guess
The counts CC compares against aren't pulled the moment you happen to open the page. They're warmed on a schedule by background jobs — Microsoft 365 license data overnight, security incidents every couple of minutes, RMM and backup data on their own cycles — so what you see is near-real-time, refreshed within minutes rather than live to the second. There's also a manual refresh when you want to force the latest read before closing a billing period.
That's a deliberate trade. Hammering every vendor API on every page load would be slow, expensive, and rude to the APIs. Warming the data on sane intervals means the reconciliation view loads fast and the numbers are recent enough to bill from, without pretending to a precision that the underlying tools don't actually deliver.
It reads your existing stack — nothing to migrate
Worth saying plainly, because it's the thing people assume can't be true: none of this requires you to switch tools. CC sits on top of the stack you already run and reads from it through adapters. If you're on NinjaOne for RMM, Microsoft 365 for licensing, and QuickBooks Desktop for accounting, those stay exactly where they are — CC reads the counts, compares them, and writes the corrected invoice back into your accounting system when you approve it. We build each of those integrations custom to your stack, and the same holds for whatever you run in each category: a different RMM, a different identity platform, a different accounting package — if your tool has an API, we build it for you.
Every integration is built to fit your exact stack — that's the whole advantage over rigid all-in-one suites that force you onto their fixed set of connectors. We cover the common MSP categories — RMM, identity, security, distributor, accounting, and time tracking — and proven patterns stand up faster. Running something different — a different distributor, a less common backup vendor, your own PSA? We build that integration custom to your stack too. As long as it exposes an API, we connect it. The point is that reconciliation works against the tools holding your real data, built to match your workflows, not against a copy you had to migrate into yet another system.
How to find your own leakage this week
You don't need a platform to start. Pick your three largest clients and do the manual version once: pull the managed-device count from your RMM, the active user/license count from Microsoft 365, and the security agent count from your EDR vendor. Put those next to the quantities on each client's current invoice.
If even one of those three shows a meaningful gap — and in our experience it usually does — you've found leakage on your highest-revenue accounts, which is where it hurts most. Multiply the per-client pattern across your whole book and you have a real number for what reconciliation is worth to you. For most MSPs we've walked through this, the recovered revenue from billing what they're already delivering pays for the platform many times over, and it shows up as a one-time correction plus a permanently higher recurring baseline.
The clients aren't the problem here. You're delivering the work — the endpoints are managed, the seats are protected, the licenses are live. The only thing missing is the line on the invoice that says so. Reconciliation is just the habit of making sure that line keeps up with reality, run consistently instead of once a year when someone finally has time.
If you want the deeper mechanics, we wrote up how reconciliation compares and flags drift across your stack, how that flows into generating the corrected invoice in your accounting system, and — for the distributor side of the seat-count problem — keeping Pax8 subscriptions reconciled with what you bill.