The endpoints you support but never invoice

Ask a managed service provider whether they are billing for everything they support and you will usually get a slightly uncomfortable pause. Not because anyone suspects a problem, but because nobody is quite certain. The console shows what is managed. The invoice shows what was agreed. Almost nobody has both open at once.

That gap is worth understanding, because it has a specific mechanism, and the mechanism runs in one direction only.

How it opens

A client rings on a Thursday. They have hired three people, the machines land Monday, can you get them onto support. Your engineer says yes, because that is the right answer to a good client with an urgent need and a Monday deadline. The machines are enrolled. From that day they are monitored, patched, supported and backed up like everything else.

No contract variation is raised. Not through carelessness — the engineer solving the problem is not the person who raises variations, and the person who raises variations was not on the call. The request came through a channel that does not touch the commercial system, and there is no event anywhere downstream that will ever notice.

Nothing in that sequence is a mistake. Every participant did their job well. And at the end of it you are delivering three machines of service, indefinitely, for nothing.

Why it never corrects itself

The reason this compounds rather than averaging out is asymmetry. Machines enter the managed estate through many routes: a request to an engineer, a project handover, an acquisition, a site opening. They leave through almost none, because nobody has any incentive to ring their provider and report a decommissioning. The client gains nothing by doing so and it is not their job.

So the delivered estate ratchets upward against the contracted estate, permanently. There is no counter-force. A gap that opened three years ago has been widening every quarter since, quietly, in an entirely reasonable way.

Work the arithmetic with your own numbers rather than anyone else's. Take your per-endpoint monthly rate, multiply by the endpoints you suspect are unaccounted for across your book, multiply by twelve. Then note the important part: this is not revenue you failed to win. The cost is already booked. You are already paying engineers to deliver this service. Only the revenue is missing, which means every unit of it comes straight out of margin.

The same thing happens to licences, in both directions at once. Seats get assigned when people join and released essentially never, because releasing a seat is urgent to nobody. Meanwhile, in products where installation is looser than assignment, consumption climbs past entitlement. The first costs you quietly. The second costs you loudly, during a vendor audit, at a moment somebody else chose.

Why the annual spreadsheet fails

Most providers have tried to solve this with a periodic manual reconciliation. Export the endpoint list, pull the contract schedules, compare in a spreadsheet over a couple of days.

It works once. It fails as a practice for structural reasons rather than motivational ones. The result is accurate on the day it is produced and progressively less so afterwards, and it is expensive enough that nobody will repeat it for months. When it is repeated, it starts from scratch, and the person who built the spreadsheet last time has usually moved on without documenting it.

There is a worse failure mode. A reconciliation run against contract records that have not been maintained produces a large, confident, wrong number. Somebody takes it to a client. The client disputes several items and is right to. The exercise does not survive that meeting, and reconciliation acquires an internal reputation as the thing that causes arguments with customers.

What actually works

Continuous rather than periodic. The comparison should run against current data, so "what is our position" is a query rather than a project.

First run treated as data quality, not commerce. Your first result against unmaintained records is mostly an artefact of the records. Work through it, correct the entitlement data, run again. The second number is the one you act on. Skipping this is the fastest way to destroy the credibility of the whole exercise.

Both directions reported. Findings where you are under-billing pay for the work. Findings where you are billing for something you no longer deliver are what make it survivable. A reconciliation practice that only ever produces invoices in your favour will eventually be described by a client as a revenue exercise wearing an accuracy costume, and they will not be wrong.

The conversation

Providers avoid this work because they are afraid of the client meeting. That fear is well-founded if the meeting is about money. It is unfounded if the meeting is about records.

"These eleven machines came under management between March and June. Here is the enrolment date for each and the request it came from. They are not on the current schedule — shall we add them from next cycle, or would you rather we took three of them off?"

That framing presents evidence rather than an assertion, attributes the drift to a process rather than to anyone's conduct, offers a real choice including reducing scope, and looks forward instead of relitigating the past. Most clients add the machines. They knew the machines were supported. What they will not accept — reasonably — is an unexplained increase on an invoice, because they have no way to check it and it is indistinguishable from being taken advantage of.

On back-billing: generally, do not. The recovery is one-off and the relationship damage is not. The drift was at least partly your process failing, and correcting forward while fixing the mechanism is worth more across a five-year relationship than eight months of arrears.

Where to start

You do not need to buy anything to find out whether this matters to you. Export the managed endpoint list for your three largest clients. Put each beside its contract schedule. Count the difference.

It is an afternoon of work and it will tell you whether this is a rounding error or a structural leak in your business. For most providers past a handful of clients, it is the second, and the number is larger than expected — because the mechanism has been running quietly for years and nothing in the toolchain was ever going to mention it.