What each line on a hosting invoice means, which ones can change during the term, and what to check before you pay the first one.
The first hosting invoice arrives and it does not read like the rate you negotiated. There are more lines than you expected, a period that does not match the calendar month, and a figure that is close to but not exactly what you calculated yourself. That does not necessarily mean something is wrong. It means the invoice is doing more work than a single number can carry, and you should know what each part is before you sign off on payment.
The billing period, and why the total will not match a quick calculation
Most agreements bill on a metering cycle, not a calendar one. The cycle might start on the day power was energised to your rack, on a fixed date the host uses across all customers, or on the date of your first draw. Check which one applies before you compare an invoice to a rough mental estimate, because a 28-day cycle and a 31-day cycle produce different totals from the same rate and the same load. If the period on the invoice does not match what you expected, ask for the exact start and end timestamps rather than assuming a typo.
A total that differs from your own nameplate arithmetic is usually not an error either. The invoice reflects what the meter recorded, and a fleet rarely runs at a flat load for a whole period; our piece on nameplate versus actual draw explains what moves it. Before treating a mismatch as a mistake, ask whether the host can show you the underlying interval data, not just the period total, so you can see where the actual profile departed from the flat estimate.
What the line items usually represent, and how they are metered
A hosting invoice is rarely a single number. It typically separates metered energy from everything else, and the split matters because each piece can move for a different reason. The pattern we would expect to see:
- Metered consumption for the period, in kWh, tied to the rate structure in the agreement.
- Any fixed or capacity-based charge that applies regardless of draw.
- Remote hands or other services used during the period, billed separately from hosting itself.
- Credits or adjustments carried from a prior period.
- Taxes, levies or pass-through charges that are not the host's margin.
The point of separating these is that a change in the total does not tell you which underlying number moved. A higher bill from more consumption is a different situation from a higher bill because a pass-through charge changed. The invoice should let you tell them apart. If it does not, ask for a breakdown rather than treating the total as unexplained.
Metering can be read at the rack, at the container, or upstream at a point that includes overhead you did not generate directly. Confirm which point your invoice is metered from, and whether that matches what how a hosting rate is built describes for the rate itself. If billing runs on an estimate that gets corrected against an actual meter reading later, ask when that true-up happens and how large the adjustments have run historically. A true-up that lands two invoices later is normal. One that arrives without warning six months in is a sign the process is not written down anywhere you can see.
Downtime, credits and how they should appear
If the agreement includes a service level with a credit for downtime, check that the credit shows up as a distinct line, tied to a specific incident with a date and duration, not folded silently into a lower total. A credit you cannot trace back to an event is a credit you cannot audit. Ask what qualifies as an outage for these purposes, how the duration is measured, and whether you need to raise a claim or whether it is applied automatically. Operators who apply credits automatically will usually say so in the agreement itself, because it is a commitment they want on record.
Disputing a line and keeping your own record
If a number does not match your own tracking, the useful first step is not an email that says the invoice looks wrong. It is a specific claim: this line, this period, this expected value against that actual value, with your own meter or monitoring data attached. A host that operates the site should be able to pull the same period from their metering and compare it directly. That conversation is short when both sides have records and long when only one side does.
This is easier if you are not starting your own log the day a dispute comes up. Keep a running export of your own consumption and any status data your monitoring gives you, even when nothing looks wrong, so a discrepancy is a five-minute comparison rather than a reconstruction. At our facilities, the customer dashboard shows the same power draw readings our team works from, so a record to check a bill against exists without a separate step.
It also helps to agree in advance, not mid-dispute, what happens while a line is contested. Ask whether you are expected to pay the undisputed portion and withhold only the contested amount, or whether the whole invoice sits open until it resolves. Hosts with a written process for this will tell you without hesitation, because they have had the conversation before and codified the answer rather than improvising it each time.
What to check before you pay
Work through the invoice in this order: confirm the billing period against the agreement, separate consumption from fixed and pass-through charges, check any credit against a dated incident, and compare the metered total against your own reading for the same period if you have one. If a number does not reconcile, raise it as a specific line with specific figures rather than a general question about the total. Ask, in writing, how true-ups are handled and how far back they can reach, so the answer exists before you need it rather than after.
The mechanics differ by operator. Our hosting rate page sets out what sits inside our base rate, with anything billed separately named in the service order.
