Revenue leakage in an MSP is rarely dramatic. There is no fraud and no incompetence. There is a client who grew from forty seats to fifty-five in March and was invoiced for forty until August.
The reason it persists is asymmetry: a client who is over-invoiced tells you within the week. A client who is under-invoiced tells you never.
One client, one missed change
The individual number is small enough to feel not worth a process. That is exactly why it recurs.
Why the bridge is always a person
The seat count lives in the backup platform, which knows exactly how many mailboxes it is protecting because it protects them. The invoice lives in the accounting system, which knows what you billed last month. Nothing connects the two except somebody at month end.
That person is doing careful work under time pressure across sixty clients, and the failure mode is not error but omission — a client whose count did not obviously change gets carried forward.
Pick three clients. Compare the invoiced seat count against the actual protected seat count. If all three match, your process is working; most people find at least one that does not.
Closing the loop
Live active and archived seat counts are exposed over an API, and the platform connects to Xero and QuickBooks Online so line-item quantities update from the system that knows the answer rather than from somebody's recollection of it.
The point is not the integration. It is that the number on the invoice and the number in the platform have the same source, so drift between them is not possible rather than merely unlikely.
Archived seats matter here too: they bill at half the active rate, so a book with meaningful churn has two counts to track rather than one. Reconciling that by hand is where the second class of leakage lives.