A Bitcoin mining hosting invoice combines several distinct categories of data: the machines billed, the electricity metered, the contract fees applied, and any credits, repairs, or taxes added during the period. Pool dashboards and mining-income reports are useful corroborating evidence, but they measure a different stage of the mining process — submitted work and pool-account settlement — not site-level power consumption. An invoice cannot be validated by comparing it to a single pool-side number. It must be reconciled, line by line, against records that cover the same machine list, the same meter boundary, and the same billing period.
This article sets out a three-layer reconciliation approach: site and billing records, ASIC operating records, and pool and payout records. Each layer answers a different question, and the layers must be checked in the right order to isolate the actual source of a variance.
Collect Records for the Same Billing Window
Before comparing any figures, assemble documents that cover the identical period and time zone as the invoice: the hosting agreement and invoice itself, meter readings or utility usage reports, the ASIC serial-number inventory and deployment log, maintenance and curtailment notices, and pool records covering hashrate, settled income, and payments.
A reconciliation performed across mismatched periods produces discrepancies unrelated to billing accuracy. An invoice dated in one time zone compared against a pool export generated in UTC, for example, can shift several hours of activity into the wrong day. Confirm the invoice's stated billing-period start and end timestamps, including time zone, before extracting any other figure.
Verify the Machine List and Energized Dates
Compare the invoice's billed machine count, and any listed models or serial numbers, against the ASIC inventory and deployment log. For each billed unit, verify its site or circuit assignment and energized dates, then compare those records with the contract’s billing start and end conditions.
This step catches common discrepancies before they are mistaken for a metering or rate error: a machine billed after it was shipped out for repair, a replacement unit billed under the original unit's identifier, or a miner that was never energized during the period in question. If machines were added or removed mid-period, check the contract’s provisions for billing start and end dates, minimum commitments, downtime, and proration. Metered energy charges, fixed hosting fees, and capacity reservation fees may follow different rules. A removal or period without power does not by itself establish that every charge should be reduced; request an adjustment where the contract supports one.
Reconcile Metered Electricity Before Evaluating Mining Income
Where the invoice provides raw cumulative meter readings that require a multiplier, calculate energy use as:
Metered energy (kWh) = (Ending meter reading − Beginning meter reading) × Applicable meter multiplier
Both readings must come from the same meter and use the same register and units for the billing period. Confirm the applicable multiplier against the meter or billing documentation. If the readings have already been converted to actual kWh, subtract them directly without multiplying again. Commercial meters can require multipliers greater than 1 (Tucson Electric Power). Compare the resulting energy use with the billed kWh for the agreed meter boundary.
Where the invoice lists a simple energy charge:
Energy charge = Billed kWh × Contract energy rate
If the agreement also includes demand charges, power-factor charges, taxes, curtailment charges, or a fixed hosting or per-machine fee, verify each of those separately. For analysis, you can divide total charges by billed kWh to calculate an effective cost per kWh, provided you clearly identify the charges included. Keep that figure separate from the contract energy rate, and do not add an itemized fee again if it is already included in the rate or total being used.
As a reasonableness check, an operator can estimate expected energy use from operating records:
Estimated energy (kWh) = Σ (average measured power of miner i in kW × energized hours of miner i)
Two limitations apply here. First, a site or circuit meter typically includes load beyond the ASICs themselves — fans, pumps, networking equipment, transformers, or immersion-cooling infrastructure — so an ASIC-only estimate will generally run below the metered total. Second, this estimate uses measured power readings where available and energized hours from operating logs; it is a reasonableness check on energy consumption, not a J/TH efficiency calculation, and it should not be presented as one.
Compare Billing Records With ASIC Operating History
Operating records can explain a kWh or machine-count variance once the arithmetic itself has been confirmed. Relevant events include planned curtailment, a utility or site outage, a breaker trip or power-supply failure, a thermal shutdown or firmware issue, scheduled maintenance or redeployment, and changes to frequency settings or cooling systems that affect auxiliary load.
It is useful to distinguish energized time from productive mining time. A miner can draw power and appear online while submitting little or no accepted work, because of a hardware fault, a misconfiguration, or a connectivity problem. An energy meter records electricity consumed over time; operating logs help explain changes in power draw and energized hours. Pool records show submitted work and help identify periods of productive mining. Confusing the two can lead an operator to assume incorrectly that a metering error exists when the underlying issue is a hardware or network fault.
Use Pool Records to Investigate, Not to Recalculate the Power Bill
Pool records help confirm whether machines were actively submitting work during the invoiced period, but they measure a different quantity than a power meter and should be read with that distinction in mind.
ViaBTC's documentation notes that its real-time hashrate figure is calculated from the preceding 10 minutes, while its daily hashrate figure is a 24-hour average; a local miner's displayed average may cover a different running period entirely (ViaBTC Help Center). Comparing a short-interval local display against a full-month invoice, or a daily pool average against an instantaneous machine reading, will produce an apparent mismatch that has nothing to do with the invoice itself.
Rejected shares are also worth reviewing as a diagnostic, not as proof of a billing error. A share provides evidence of work submitted to the pool (Bitcoin Developer Guide: Mining). A rejection rate outside a pool's typical range may point to network latency, elevated temperature, or firmware issues, but it does not by itself establish that a hosting invoice was billed incorrectly.
Finally, separate pool-account settlement from an on-chain withdrawal. Mining income can be credited to a pool account under a given payout method before any withdrawal is requested or broadcast. Payout rules and fee schedules can also change between billing periods — ViaBTC's current fee schedule, for instance, lists separate terms for its PPS+ and PPLNS payment methods, including different settlement timing (ViaBTC fee schedule). An operator reconciling several months of pool-account history should confirm which payout method and fee terms applied in each period rather than assume they were constant throughout.
| Record | What it can help verify | What it cannot prove on its own |
|---|---|---|
| Site or circuit meter | Energy billed within that meter's boundary | Pool earnings or ASIC health |
| ASIC local interface | Device status, reported hashrate, temperature, faults, and in some cases power draw | Site-level energy use or pool-account credits |
| Pool dashboard | Submitted work, worker activity, rejection data, and pool-account income | Actual site kWh or instantaneous ASIC hashrate |
| On-chain transaction | A withdrawal transaction and its confirmation status | Whether the underlying mining income was calculated correctly |
A Practical Sequence for Investigating Variances
When an invoice does not match expectations, working through the layers in order helps isolate the cause rather than jumping to a single explanation:
- Confirm the billing period and time zone stated on the invoice.
- Confirm the machine list and each unit's energized dates against the deployment log.
- Recalculate the metered usage and the invoice's own arithmetic.
- Check how the contract treats demand charges, credits, and fixed fees.
- Review outage, curtailment, repair, and maintenance records for the period.
- Use pool records to check whether machines were submitting work during any disputed interval.
- Raise remaining questions with the host, citing the specific meter readings, machine identifiers, and timestamps involved.
A Worked Example
Consider a hypothetical site hosting 20 ASICs on a single circuit meter for a 30-day billing period. The meter readings are already expressed in actual kWh, so no additional multiplier is needed. The invoice states an opening meter reading of 100,000 kWh and a closing reading of 142,000 kWh, giving billed energy of 42,000 kWh (142,000 − 100,000). At a contract rate of $0.06 per kWh, the energy charge is $2,520 (42,000 × 0.06), separate from any fixed hosting fee listed on the invoice.
Suppose the deployment log shows that two of the 20 machines were removed on day 15 for repair and were not reinstalled before the billing period ended. All else equal, this reduces the expected energy draw for the second half of the month relative to the first half — a pattern the operator should see reflected in the meter trend, not treated as an unexplained shortfall.
For this hypothetical contract, assume a fixed monthly capacity reservation fee of $400 remains payable while two machines are away for repair. An approved repair work order supports a separate $150 charge, and a credit memo confirms a $100 adjustment for a prior billing error. Assume no other fees or taxes apply in this example.
| Invoice item | Supporting record and calculation | Amount |
|---|---|---|
| Metered energy | 42,000 kWh × $0.06/kWh | $2,520 |
| Fixed capacity reservation fee | Monthly fee specified in the contract | $400 |
| Repair charge | Approved work order and repair record | $150 |
| Prior billing adjustment | Credit memo identifying the corrected charge | −$100 |
| Total payable | $2,520 + $400 + $150 − $100 | $2,970 |
The repair removal explains a change in energy use, while the contract determines whether the fixed fee changes. Check that the repair charge matches the approved work and that the credit appears once in the invoice total. Under a different agreement, proration or downtime credits may apply; verify those terms before requesting an adjustment.
Suppose further that the maintenance log records a four-hour curtailment event during the period, and that the pool dashboard shows a corresponding drop in pool-estimated hashrate for the same window. Here, the pool record serves its proper role: corroborating that the curtailment affected submitted work, rather than being used to recalculate the kWh figure itself, which remains governed by the contract meter.
FAQ
Can I validate a hosting invoice using only my pool dashboard?
No. A pool dashboard measures submitted work, pool-estimated hashrate, and account-level mining income; it does not measure the electricity recorded by a site or circuit meter. Use pool records to investigate specific periods of reduced activity, not to recalculate billed kWh.
Why does my local miner hashrate differ from the pool's reported figure?
The two are typically calculated over different time windows and from different vantage points. A local display may average over a different running period than a pool's daily or real-time statistic, and the pool only observes shares actually submitted and accepted. A difference between the two does not, by itself, indicate a billing problem.
Should I treat nameplate miner wattage as my expected electricity bill?
No. Nameplate wattage is a manufacturer specification, not a metered reading, and a site meter typically includes auxiliary load such as cooling and networking equipment beyond the ASICs themselves. Use metered readings as the basis for billed energy, and use measured power data only as a reasonableness check where it is available.
What should I do if the machine count on the invoice does not match my deployment log?
Identify the specific serial numbers in question and their energized dates before contacting the host. Partial-month deployment, removals for repair, and temporary substitutions may explain the difference. Check the contract’s billing dates, minimum commitments, downtime provisions, and proration terms for each affected charge. Request a correction where the records and contract support it; a machine’s absence does not automatically reduce a fixed hosting or capacity reservation fee.
References
- ViaBTC Help Center, "Why is the Hashrate Shown in the Mining Pool Lower than that of the Mining Machine"
- ViaBTC, Fee and Payment Schedule
- Bitcoin Developer Guide, "Mining"
- Tucson Electric Power, "Read My Meter"