Operations → Utilities → /utilities · Operations → Smart Meters → /iot
Utilities are billed from consumption: a reading is taken, consumption is derived, a tariff converts it to money, and a billing run turns it into invoices. Whether the reading comes from a person with a clipboard or a connected meter, the rest of the chain is the same.
The two surfaces
| Surface | Use it for |
|---|---|
Utilities (/utilities) | Utility accounts and manual readings per unit and period. |
Smart Meters / IoT (/iot) | Connected meters: polling, consumption, tariffs, billing runs, valve control and vendor integrations. |
The IoT workspace
The smart-meter dashboard is built around the operational cycle rather than around database tables. It shows:
- a health banner — whether polling, consumption and billing are currently healthy;
- workspace cards for each stage of the cycle, with the guided playbook for that stage;
- shortcuts into the tab where the work is done.
Each stage has its own guide — the IoT playbooks in the sidebar. They are written as procedures, not reference: what to do, in what order, and how to tell you are done.
The utility billing cycle
Set up meters
Assign meters to units, with vendor credentials configured. See Smart meters setup.
Configure tariffs
The rate structure that converts consumption to money. See Tariffs.
Collect readings
Poll meters, or enter readings manually. Check for stale, missing or outlier values before going further. See Meter readings.
Derive consumption
The difference between readings, after quality checks. Fix reading problems here, not after invoices exist. See Consumption.
Run billing
Turn the period's consumption into invoices. See Billing runs and Billing run items.
Review run items before posting
Per-unit items are inspectable before and after posting. A bad tariff or a misassigned meter is obvious here and expensive later.
Monitoring
| Surface | Watch for |
|---|---|
| Poll failures | Meters that stopped reporting. |
| Webhook events | Inbound vendor events and their processing. |
| Vendors | Credential and integration health per vendor. |
| Valve commands | Disconnect and reconnect instructions and their outcomes. |
Arrears enforcement
Where enabled, unpaid utility balances can drive an enforcement ladder:
warn → warn again → disconnect → (payment) → reconnect
The engine holds its own safety invariants: both warnings must be provably sent, a grace period must elapse, and the balance is re-checked immediately before any disconnect. It defaults to shadow mode, staging actions for a human to confirm rather than acting alone.
Enforcement creates real invoices for any reconnection charges, so the money side flows through normal billing rather than a side channel.
Utilities without smart meters
The manual path is the same cycle without the polling:
Record the reading
Enter the current reading per unit and period; the previous reading is already held.
Check consumption
A consumption figure far outside the unit's history is usually a transcription error, a meter rollover, or a leak — all worth catching before billing.
Bill
Consumption is priced by tariff and billed as an invoice line against the lease's utility service type.
Readings can also be imported in bulk — Admin → Bulk Upload with the Utility Readings type. See Bulk upload.
Common problems
| Symptom | Cause |
|---|---|
| No new readings | Vendor credentials, meter mapping, or the meter is inactive. Check poll failures. |
| Consumption looks impossible | Reading outlier, meter replaced without a baseline, or meter assigned to the wrong unit. |
| Billing run produced nothing | No consumption for the period, or no tariff configured. |
| Tenant billed for another unit's water | Meter-to-unit assignment. Fix the assignment, then credit the wrong invoice. |
| Disconnect did not happen | Shadow mode — the action was staged for confirmation, not executed. |