Multi-Client Hosting Billing Should Follow the Contract, Not the Spreadsheet
Many industrial hosts do not lose money because they cannot see miners. They lose it at month-end, when dozens of clients, several contract styles, and two data sources have to become one bill.
A typical hosting floor mixes older and newer fleets. Some halls have meters. Some clients only care about pool hashrate. Some pay for runtime. Meter logs, pool observer data, and the contract live in different places. If the close depends on a spreadsheet, a 1% slip in energy is not rare. In a thin-margin book, that becomes dispute time and a close that consumes operations.
ItsMiner is a Bitcoin Mining Management Software. For hosts, the useful layer is settlement data: each client on one of three methods already in the system, the same line loss and price applied to energy, and an Observer Page so the client sees those numbers too.
The close fails when contracts are not the same
The problem is not “too many miners.” It is that contracts are not the same.
Meter clients should pay for what the meter recorded. Hashrate clients should pay from pool-side average hashrate and the configured power ratio. Duration clients should pay from rated power and runtime. If you force all three into one tab of estimated kWh, someone is overbilled, someone is underbilled, and the next week is spent reconstructing the logic in email.
Monitoring tools help you see whether machines are online. They do not close a multi-client power bill. That is why hosts still export CSV, paste into Excel, and hope line loss was applied the same way as last month.
Three methods, used as they actually work
In ItsMiner, billing method is a client field: meter, hashrate, or duration. Switching the method does not erase history under the other methods. That matters when a contract changes mid-life.
Meter billing uses physical meter readings. Energy = (end reading − start reading) × multiplier. This is the cleanest match for sites that already meter by client or by hall, and for high-efficiency fleets where the invoice should follow actual kWh.
Hashrate billing uses pool data, not a J/TH slogan. Energy = 24-hour average pool hashrate × power ratio (kW/T) × runtime per machine. It needs a valid observer link and revenue permission on the sub-account. If the fleet under-delivers hashrate, billed energy falls with it. That follows pool production; it does not protect the host’s power margin. If the contract charges nameplate draw while machines run, duration billing is the closer fit.
Duration billing is rated power × total runtime. Runtime comes from the pool observer’s 24-hour online miner runtime. It is not a flat all-in hosting fee or an availability package. You still get energy, then an electricity fee.
In all three cases, electricity fee = energy × line loss × price. Price is a client field in CNY or USD per kWh. It is not a custom formula that pulls ERCOT 15-minute real-time prices into the invoice. Those price series are used in Load Control (Deluxe Edition) to decide when to change miner work modes. They are not the billing engine.
Month-end starts from one energy number per client
What hosts actually fight about is not the invoice template. It is whether each client’s kWh was calculated the way the contract says, so finance is not rebuilding three exports.
That number lives in energy statistics: meter readings, pool hashrate, or runtime, plus line loss and price. The fee formula is the same as above. The page also shows actual vs. estimated energy, and site total vs. client total. Those two comparisons are usually enough to catch a missing meter interval, a dead observer link, or a client whose machines were moved and never reassigned.
A worked example, estimated: a host with about 40 mixed meter/hashrate clients used to spend days matching CSV dumps from meters and pools. Once each client has a method, a price, and a complete period in energy statistics, month-end is reviewing those figures—then issuing the invoice in the host’s own finance process. The time you save is in the reconciliation, not in skipping finance.
Clients should see the same numbers you settle on
Most disputes are not about a missing decimal. They are about two versions of the truth: the host’s spreadsheet and the client’s pool screenshot.
ItsMiner does not ship a separate consumer portal. It gives an Observer Page: a read-only view of pool, revenue. Authorized accounts can log in to the system to view miner data; they cannot run write operations. That is usually enough to stop the “your hashrate compliance rate is wrong” thread, because both sides are looking at the same period.
The other leak is operational. A miner hashing outside the sub-account whitelist is marked Not Whitelisted and can be restored automatically. Newly scanned sub-accounts sit in pending review before switch, push, or auto-restore. Pools include AntPool, ViaBTC, and Poolin, among others. Local energy statistics are 5-minute; pool curves are around 10 minutes. Settlement should follow the billing method’s source, not a blended “5-minute scan” story.
Repair tickets and shift records exist as operations modules. They help a host restore uptime. They do not calculate the bill. If the site also runs Load Control during high-price or demand-response windows, billed kWh still follows the client’s meter, hashrate, or duration method. The two jobs should not be mixed.
For a host, the practical standard is short. Every client has a method, a price, and a line-loss factor. Period energy is complete. The Observer Page shows the same numbers. If those are true, month-end is a review of data both sides already share—not a reconstruction in Excel. If any of these is missing, a spreadsheet will not save you. It will only hide which one failed.
Contact us for a demo:
- Email: sales@powsell.com
- Telegram: @ItsMinerOfficial
Subscribe to ItsMiner's Blog
Get the latest posts delivered right to your inbox