Colocation Billing Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does scoping a full billing replacement in one go fail so often?

Because the specification gets written from the invoice run rather than from the leak. Everything the finance manager touches on the fourth working day goes into release one: power rating, cross connects, remote hands, bandwidth burst billing, tax, revenue recognition, a customer portal, multi entity consolidation and an accounting integration. That is a 6 to 12 month programme, and during all of it the workbook with a tab per customer is still producing the invoices.

The specific trap is revenue recognition. It looks like a reporting feature and it is a design constraint, because escalators and free periods generally have to be straight lined across the term rather than recognised as billed. Teams put it in phase one, spend weeks in conversations with the auditor about presentation, and arrive at the cross connect problem in month five.

Sequence it differently. Ship structured contracts, power rating against your actual circuit mapping, and cross connect billing driven from the work order first. That is $60,000 to $140,000 over 12 to 16 weeks and it stops the largest leak while the rest is still being scoped. Ask the auditor how they want revenue recognition presented before you build it, but build it in phase two, and design the contract object in phase one so the schedule can be derived later without restating anything.

What goes wrong when you migrate contracts and circuit mapping?

Contracts are the item nobody prices. They exist as signed documents in a folder, with terms negotiated years apart by different sales leads, and turning them into structured objects means somebody reads every active agreement and extracts term, start date, escalation rule and date, committed quantities per service, ramp schedule, allowances and notice period. That is uncomfortable and it is always worth it, because it is also the exercise that finds the escalators that should have fired and did not.

Circuit mapping fails differently. Cabinets get recabled, suites get subdivided, and the current mapping between branch circuits and customer cabinets does not describe what was true fourteen months ago. If you migrate only the current state, every historical invoice becomes unreproducible the first time a customer queries an old bill, and the answer you give is a recalculation rather than a record.

Two fixes. Treat contract extraction as named discovery work with a person and a number of days against it, not as an assumption inside the build. And version the circuit to cabinet mapping from day one with effective dates, loading whatever historical state you can reconstruct and marking the rest as unknown rather than assuming today's mapping applied. Traceability is either designed in at the start or bolted on badly later, and this is the decision that determines which.

Why do power monitoring, ticketing and accounting integrations break after launch?

Power monitoring breaks on estate diversity. A building that grew through acquisition carries three or four monitoring vendors and several firmware generations, and each reports at a different cadence with different units and different behaviour on a gap. The failure is not an outage, it is a missing interval that gets treated as zero, which quietly understates a customer's peak for the month and only shows up if somebody compares against the previous month.

Ticketing breaks on scope. Remote hands time lives in helpdesk-alternative-to-zendesk/">Zendesk or Jira Service Management because operations chose the tool for operational reasons, and it has no concept of a rate card, an out of hours band or an allowance balance. Engineers add time entries in whatever form suits them, and if the billing side accepts free text durations you will be reconciling by hand within a quarter.

Accounting breaks slowest. A posting model into NetSuite or Sage Intacct with the right dimensions is a design conversation rather than a connector, and the dimension structure usually changes once during the project.

The fixes are operational. Store readings as a raw series with explicit gap handling and alert on missing intervals rather than interpolating silently. Constrain time entry at the source so durations and categories are structured, and present remote hands charges next to the ticket reference, timestamps and engineer note, because that is the most disputed line on a colocation invoice. And have finance sign off the posting dimensions before anyone builds against them.

What happens when invoice traceability is not covered?

A customer queries a power charge from fourteen months ago. The honest position in most facilities is that the number came out of a workbook that has been overwritten monthly since, so the answer is a fresh calculation using today's mapping and today's understanding of the contract. If either has changed, and over fourteen months at least one usually has, the new number does not match the invoice, and you are now in a credit conversation you did not need.

The same gap has a quieter version at renewal. If nobody can show the meter data behind a charge, disputes get settled with discounts rather than evidence, and the discount becomes the baseline for the next term.

The fix is to store the rated result alongside the inputs that produced it: the raw readings used, the mapping version in force, the contract rule version applied, and the derivation. Then any invoice line reproduces exactly, years later, without recalculation. That traceability is the feature that ends disputes and it is the thing spreadsheets structurally cannot provide, because a spreadsheet holds a result rather than a derivation. Build it into the data model in the first release, since retrofitting provenance onto records already written is not really possible.

Should you build custom or configure what you already own?

Under roughly 200 cabinets on a single site with flat or simple committed power billing and a cross connect count one person can track reliably, configure. Ubersmith is a genuine billing platform and handles recurring services well, EasyDCIM suits smaller operators, and either will cost you a fraction of a build. There is no prize for engineering your way out of a problem you do not yet have.

There is also a middle path worth naming. FNT Command and Sunbird dcTrack hold the physical truth about cabinets, circuits and connections properly and should stay the record for that. What you may need to build is only the commercial layer that consumes them: contract constructs, rating, and the step that turns a connect work order into a billing line. That is a smaller project than replacing your billing platform and it targets the actual gap.

The clearest build signal is not a cabinet count. It is that a single person is quietly keeping the billing layer alive with custom fields and maintenance scripts, or that your finance manager is the only person who understands the invoice run and the month she is on leave is the month invoices go out late. When the workaround has become a role, the product has been outgrown.

How do hidden costs get into the quote?

Five items drive the overrun. The number of genuinely distinct contract constructs in your book, which nobody knows until somebody reads every active agreement, and which is the single largest driver. Meter estate diversity, since each monitoring vendor and firmware generation is a separate integration rather than a configuration. Accounting integration depth, because posting dimensions and revenue schedules are a design conversation with your finance team rather than a connector. Multi currency and multi entity, if you operate across borders. And tax on power resale, which varies by jurisdiction and needs a ruling from your finance lead before anyone writes code.

Make them visible by asking for contract discovery as a named line with days attached, each monitoring vendor as a separate integration line, and the accounting posting model as a design deliverable with a sign off. Then ask what happens when a customer is recabled: does the historical invoice still reproduce, or does it recalculate. That one question separates people who have billed a facility from people who have not.

What separates a build that works from one that fails here?

The working ones make the measurement rule data attached to the contract rather than a global setting, because your book almost certainly contains more than one convention for handling A and B feeds on dual corded cabinets, signed by different people in different years. Readings are stored raw and the rated result is stored with its inputs. The connect order is the billing trigger, so the recurring charge starts on the date the technician marks it patched and stops on the date it is pulled, without a human step in either direction. The contract is a structured object, so escalators fire and free periods end without anyone remembering.

The failing ones share one shape: an operations person is still expected to remember something. A connect gets billed because somebody tells finance. An escalator fires because somebody diarised it. A tier applies because somebody read the meter. Each of those looks like a small process step and each is a recurring leak, because the whole point of the project was to remove exactly those steps.

The test before signing is to ask how the developer will model an A and B feed on a dual corded cabinet, then ask how the cross connect work order becomes a billing line without a human in between. If a person appears in either answer, the problem you are paying to remove has been rebuilt with better screens.