Build Log #2: Automating the Billing Workflow From Hell

Every colo operator knows the billing ritual. It eats 25 hours a month, it's wrong half the time, and it hasn't fundamentally changed since 2005. We decided to kill it.

The Monthly Ritual

If you've never worked billing at a mid-market colo, allow us to walk you through the monthly joy. This is real. This is what most 100-200 rack facilities still do in 2025:

1. Walk the floor with a clipboard. Yes, a clipboard. A human being walks to every PDU in the facility and writes down the current kWh reading from the LCD display. Some facilities have 200+ PDUs. This takes 2-3 hours and usually happens on the 1st of the month, give or take whenever someone remembers.
2. Enter readings into Excel. Someone — usually the same person, because God forbid they're out sick — sits down and manually types every reading into the master billing spreadsheet. Another hour, minimum. Hope their handwriting was legible.
3. Calculate usage per customer. Each customer has a rate schedule. Some are metered (pay for what you use). Some have committed power with overage charges. Some have blended rates that change at different tiers. The spreadsheet has formulas for this. The formulas were written by someone who left two years ago. Nobody fully understands them. Everyone's afraid to touch them.
4. Cross-reference against contracts. Did Customer Y's rate change last quarter? Is Customer Z still on the promotional rate? When does that promo expire? Check the contract PDF. Check the amendment email. Check the sticky note on the monitor.
5. Generate invoices in QuickBooks. Manually create each invoice, line by line. Power charges, space charges, cross-connects, remote hands from last month that the tech finally submitted a timesheet for. 100 customers = 100 invoices = several hours of data entry.
6. Email each customer individually. Because QuickBooks batch emailing is either broken or nobody set it up. Copy, paste, attach PDF, send. Repeat 100 times.
7. Handle disputes. Within a week, you'll get 5-10 customers questioning their numbers. "My PDU shows different numbers than yours." "I thought I was on the $0.11 rate, not $0.13." "You billed me for 16kW but I'm only committed for 12." Each dispute requires pulling raw data, re-checking calculations, and writing a polite email explaining the math. Or issuing a credit because, yeah, the spreadsheet was wrong.

Total time: 15-25 hours per month for 100 customers. That's half a full-time employee doing nothing but billing. And the output is still unreliable.

Where It Breaks

Every step in that workflow is a failure point, and failures compound.

The guy reading PDUs transposes a digit — writes 18.3 instead of 13.8. That's a $400 billing error on a single customer for a single month. Nobody catches it until the customer complains, which might be three months later, at which point you owe them a credit and an apology and they're already shopping for a new colo.

Your rate schedule spreadsheet has a formula referencing cell F14, but someone inserted a row last month and now it's referencing F15 — which is a different customer's rate. That formula has been wrong for three billing cycles. You've been charging Customer A Customer B's rate. You owe credits. Maybe Customer B has been getting a discount they didn't earn. Good luck explaining that one.

Your committed power thresholds are in one spreadsheet. Your actual consumption data is in another. The overage calculation references both. When someone changes the format in one sheet — adds a column, reorders customers, renames a tab — the overage calc silently breaks. It doesn't error out. It just returns wrong numbers. And you won't know until someone checks.

Nobody checks.

What We Built

The billing engine in PowerPoll wasn't the first thing we built — but it's the reason we started building at all. Here's how it works:

SNMP-Polled Data → Rate Engine → Invoice

PDU data comes in via SNMP every 5 minutes. No clipboards. No humans reading LCD displays. No transposed digits. The raw kWh data feeds directly into the rate engine, which knows each customer's contract terms — committed power, metered rates, overage thresholds, demand charge windows, power factor penalties, the works.

Committed power billing? The system knows Customer A has 15kW committed at $0.12/kWh. If they use 12kW, they still pay for 15. If they use 18kW, the overage kicks in automatically at whatever rate the contract specifies. No lookups. No cross-referencing. It just happens.

Demand charges? Calculated from actual peak 15-minute intervals, the same way your utility calculates them. Not estimated. Not averaged. Measured. If a customer spikes to 22kW for one 15-minute window, that's their demand for the month — exactly like it works on your utility bill. Most spreadsheet-based billing either ignores demand charges entirely or estimates them from average consumption, which means you're either not billing for them or billing the wrong amount.

Power factor penalties? Measured from real PDU data, not assumed. If a customer's power factor drops below 0.95 — meaning they're pulling more apparent power than they're actually using — the system flags it and calculates the penalty per the contract terms. Most mid-market colos don't even track power factor because their tools don't surface it. They're eating the cost of reactive power and don't even know it.

The Excel Import (Because We're Not Naive)

Here's the thing about building a new tool: nobody's going to adopt it if they have to re-enter 200 customers by hand. We've seen enough software launches die at the data migration step to know that. "Just import your data!" the vendor says. "It's easy!" Then you spend a week reformatting CSVs and debugging field mapping errors.

So we built a drag-and-drop importer with fuzzy column matching. You take your existing billing spreadsheet — the ugly one, the one with inconsistent column names and merged cells and that one row that's highlighted yellow for reasons nobody remembers — and you drop it in.

The importer scans your column headers and matches them to our data model. Your column says "Cust Name"? We know that's customer_name. "kW Commit"? That's committed_power_kw. "Rate ($/kWh)"? Got it. "Cab #"? That's cabinet_id. We tested this against 14 real billing spreadsheets from different facilities. 86% of columns match automatically. The remaining 14% get a dropdown for manual mapping. Total import time for 200 customers: about 4 minutes.

We even handle the weird stuff. Multiple rate tiers in a single cell? We parse those. Notes columns with contract dates embedded in free text? We flag them for review. Blank rows between sections? Ignored. We built this for real spreadsheets, not clean demo data.

The Moment We Knew It Worked

Not because anyone was cheating. Not because the ops team was incompetent. Because humans make mistakes at scale and spreadsheets can't catch them.

Here's what we found:

• Three customers were consistently 2-3kW over their committed power and hadn't been billed overages in months. Combined missed revenue: ~$1,900/month.
• Two customers had rate schedule errors — they were being billed at a rate from a contract that had been amended, but nobody updated the spreadsheet. One was overpaying by $220/month (credit owed). One was underpaying by $340/month.
• One customer had a PDU assigned to them that actually served an adjacent cabinet belonging to a different customer. They'd been paying for someone else's power for four months. $680 in credits owed.
• Several demand charges were being calculated from monthly averages instead of peak 15-minute intervals. Undercharges totaling ~$1,500/month across the facility.

$4,800 a month. $57,600 a year. At a single facility. And this wasn't an outlier — it was a well-run operation with competent people. The tools were the problem, not the team.

What Billing Looks Like Now

On the 1st of the month, PowerPoll generates a billing summary for every customer automatically. No clipboard walks. No spreadsheet formulas. No manual invoice creation. You review the numbers, approve the batch, and invoices go out. Total time: about 30 minutes for 150 customers — and most of that is the review, not the generation.

When a customer disputes a charge, you pull up their real-time dashboard. Here's your SNMP data. Here's every 5-minute reading for the billing period. Here's exactly how the overage was calculated. Here's the contract terms it was calculated against. No more "let me check the spreadsheet and get back to you." The data is right there, timestamped, auditable, and inarguable.

Is it perfect? No. We're still iterating on the invoice formatting, the export integrations with accounting software, and the customer-facing portal. But the core engine — SNMP data in, accurate invoices out — that works. And it works every damn month without someone spending a week on it.

The Real ROI

People ask about ROI when you pitch them a new tool. Here's the math we care about:

• Time saved: 20+ hours/month of billing labor eliminated
• Revenue recovered: $4,800/month at the first facility that tested it (your mileage will vary, but if you find zero discrepancies, you're either very lucky or very small)
• Disputes reduced: When you can show a customer their own data in real time, disputes drop by about 70% in our experience
• Credits eliminated: No more "sorry, the spreadsheet was wrong" credits. The data is the data.

The tool isn't free. But if your billing process looks anything like what we described above — and if you're honest with yourself, it probably does — the payback period is measured in weeks, not months.

Next up: how we built device discovery that finds every SNMP device on your network in 90 seconds, including the ones you forgot you had.