Colocation Billing Software: Why Metered Power, Cross Connects and Remote Hands Never Reach the Invoice

Why colocation revenue leaks between operations and finance

It is the fourth working day of the month. The finance manager has three browser tabs open: the power monitoring system, a DCIM asset list, and the ticketing queue where remote hands jobs live. She is building the invoice run in a workbook that has one tab per customer, because every contract is slightly different. One customer committed 8 kW per cabinet with overage above that. Another bought a 250 kW suite at a flat rate with a pass through on the utility. A third has fourteen cross connects, or possibly fifteen, because a technician installed one in the meet me room three weeks ago and the work order never became a billing line. Somewhere in the ticket queue there are eleven hours of remote hands, four of them after midnight at the out of hours rate, and nobody has told her about any of it.

Colocation revenue is unusual because it is assembled from operational events rather than sold as a product. Space is contracted, which is the easy part. Power is measured by hardware. Cross connects are created by a technician holding a patch cable. Remote hands is created by an engineer closing a ticket at 2am. Bandwidth is computed from a traffic sample. Four of those five live in systems that were built to run a facility, not to bill for one. The invoice is the place where operations and finance are supposed to meet, and in most facilities that meeting is a person with a spreadsheet.

The consistent losses we find when we start these projects are the same every time. Cross connects installed but never billed, usually the single largest item and almost always because the order came in by email with a letter of authority attached and the work order closed without a revenue step. Remote hands hours delivered and never invoiced because the contract includes some free hours per month and nobody tracks the balance. Power overage that goes uncharged because reading the meter and applying the tier is manual work that gets skipped in a busy month. Contractual escalators that should have lifted the rate on the anniversary and did not, which then compounds silently for the rest of the term. None of these are dramatic. All of them are recurring, which is what makes them expensive.

Problem one: your power contract does not match how your meters measure

Contracts commit power at the cabinet or suite level. Meters measure at the branch circuit. Those are different objects and the mapping between them is where billing goes wrong. A dual corded cabinet draws from an A feed and a B feed, and the sum of those two readings is not the customer's consumption, it is roughly the same load counted twice under normal operation. Whether you bill the sum, the higher side, or a combined figure is a contractual decision that differs per customer, and encoding it wrongly either quietly undercharges the customer or generates a dispute that costs you the relationship.

Then there is the question of which number the tier applies to. Monthly peak kW, average kW, a 95th percentile sample, or metered kWh with a rate that passes through your utility cost. Operators use all of these, often in the same building because the contracts were signed years apart by different sales leads. A billing system that supports one of them forces the rest into manual adjustments, and manual adjustments are where the errors live.

A custom build treats the measurement rule as data attached to the contract rather than a global setting. Circuit to cabinet mapping is explicit and versioned, because cabinets get recabled and the historic invoice has to still be reproducible when a customer queries a bill from fourteen months ago. Readings are stored as a raw series and the rated result is stored alongside the inputs that produced it, so any invoice line can be traced back to the meter data behind it. That traceability is the feature that ends disputes, and it is the one that spreadsheets structurally cannot provide.

Problem two: the cross connect is a physical object that nobody turns into revenue

Cross connects are among the highest margin recurring items a colocation operator sells and they are created by a work order. The order arrives by email, sometimes with a customer letter of authority, a technician runs the cable, updates the meet me room record if the process is good, and closes the ticket. There is no natural moment in that flow where a billing line is created, so the operator relies on somebody remembering. At scale, somebody does not.

FNT Command and Sunbird dcTrack both hold connection records properly and they are the right kind of tool for the physical side. Neither of them is a billing system, so the connection lives in one product and the invoice is produced in another, with a human in between. Ubersmith is genuinely a billing platform and handles recurring services well, but the colocation contract constructs it models are the common ones, and complex committed power with tiered overage and per customer cross connect pricing tends to end up as custom fields plus scripts that one person maintains.

What a build does is make the connect order the billing trigger. The order carries the customer, the requested endpoints, the media type, the authority document and the price from that customer's rate card. When the technician marks it patched, the non recurring installation charge and the monthly recurring charge start on that date automatically, prorated for the month. Disconnects work the same way in reverse, which matters just as much, because billing a customer for a circuit you already pulled is the fastest route to a credit note and an unhappy renewal conversation.

Problem three: remote hands time never leaves the ticket queue

Remote hands is billed in increments, usually quarter hours, often with an out of hours multiplier, frequently against an allowance of included hours that resets monthly or annually. All of the information needed to bill it exists in the ticket: who requested it, when the engineer started, when they finished, what they did. The problem is that the ticket system was chosen by the operations team for operational reasons and has no concept of a rate card or an allowance balance.

The workable pattern is to keep the ticket where your engineers already work, whether that is Zendesk, Jira Service Management or something older, and pull time entries into the billing system where the contract lives. The billing system applies the increment rounding, decides which entries fall in the out of hours band using that customer's definition of out of hours rather than a global one, draws down the included allowance in the right order, and produces a line the customer can reconcile against their own ticket references. Customers dispute remote hands charges more than any other line item, and the only cure is showing them the ticket number, the timestamps and the engineer note next to the charge.

Problem four: the contract terms are in a PDF and the escalators never fire

Colocation contracts run three to seven years with annual escalators, free months at the start, ramp schedules, minimum commitments and termination for convenience clauses. All of that lives in a signed PDF in a folder. Billing runs off a rate someone typed into a system on day one and never revisited. The escalator that should have lifted the rate three percent on the anniversary quietly did not, and by year four the gap is meaningful across the customer base.

A build makes the contract itself a structured object: term, start date, escalation rule and date, committed quantities per service, ramp schedule, allowances, and the notice period for termination. The billing engine derives rates from that rather than from a static field. This also gives your accountant the revenue recognition schedule they currently build by hand, since escalators and free periods generally have to be straight lined across the term under ASC 606 rather than recognised as billed. Ask your auditor how they want it presented and build to that answer, because retrofitting revenue recognition after go live is genuinely painful.

What this costs and how long it takes

A first release covering structured contracts, power rating against your actual circuit mapping, and cross connect billing driven from the work order runs $60,000 to $140,000 and ships in 12 to 16 weeks. A full platform adding remote hands capture from your ticket system, bandwidth billing on 95th percentile sampling, revenue recognition schedules, tax handling, a customer portal with usage visibility, and accounting integration runs $160,000 to $400,000 over 6 to 12 months.

The cost drivers here are specific. How many distinct contract constructs exist in your book is the biggest one, and the honest way to find out is to have somebody read every active contract before scoping, which is uncomfortable and always worth it. Meter estate diversity is the second: a building that has grown through acquisition can carry three or four monitoring vendors and several firmware generations. Accounting integration matters more than people expect, since a NetSuite or Sage Intacct posting model with the right dimensions is a design conversation, not a connector. Multi currency and multi entity add a layer if you operate across borders. Tax on power resale varies by jurisdiction and your finance lead has to give you the ruling before anyone writes code for it.

Build versus buy, and when buying is right

Buy if you are under roughly 200 cabinets on a single site, your power is billed flat or on a simple committed model, and cross connects are a small enough number that they can be tracked reliably by one person. Ubersmith or EasyDCIM will handle that shape well and cost you a fraction of a build. There is no prize for engineering your way out of a problem you do not yet have.

Build when the contract constructs in your book have outgrown any product catalog, when cross connect volume is high enough that unbilled connects are a known and unquantified number, when you operate multiple sites or entities that need a consolidated invoice, or when a customer dispute cannot be answered because nobody can show the meter data behind the charge. The clearest signal is the one nobody says out loud: your finance manager is the only person who understands the invoice run, and the month she is on leave is the month the invoices go out late.

How to choose a developer for colocation billing

Ask them how they will model an A and B feed on a dual corded cabinet. It is a small question that separates people who have billed a facility from people who have not. Ask how they intend to keep an invoice from eighteen months ago reproducible after cabinets have been recabled, because versioned mapping is either designed in from the start or bolted on badly later.

Ask what they have actually integrated on both ends: which power monitoring vendors, which ticket system, which accounting package and at what level of detail. Ask them to explain how the cross connect work order becomes a billing line without a human step. If the answer involves an operations person remembering to do something, they have rebuilt the problem you are paying to remove.

Settle code and infrastructure ownership before kickoff, in writing. You should hold the repository and the cloud accounts, and be free to bring in another firm at any point. At Digital Heroes the client owns the code from the first commit. A practical next step: pull one month of your invoice workbook and one month of your cross connect work orders, and reconcile them against each other. Whatever gap that exercise exposes is the business case, and it usually takes an afternoon to find.