Meter-based utility billing is one of the more defensible things a PG can do — a tenant who used more electricity pays more, and the reading is the evidence. All of which depends on being able to record the reading in the first place.
Quick answer (for the impatient)
Every meter-reading endpoint was returning a server error for part of this year, on every property.
It's fixed, and meter-based utility billing works as described in the original post.
This is the second time a published PG capability broke after publication. That pattern is the point of this post as much as the fix is.
What actually happened
A helper function used by the meter-reading routes was called but never imported. The practical effect: every meter-reading endpoint failed with a server error, every time, for every tenant. Not degraded — entirely non-functional.
If you tried to record readings during that window, you couldn't. Some PG owners will have concluded the feature was confusing, or that they'd done something wrong, and gone back to a notebook. That was a reasonable inference and it was the software's fault, not theirs.
What to check
Gaps in your reading history. Months where readings simply aren't there.
Utility bills raised on estimates during that period, which may need reconciling against actual consumption.
Whether you have opening readings for tenants who moved in during the window — without a start reading, their first real bill has no basis.
The third one is the most likely to cause an argument, because a tenant asked to pay for consumption with no recorded starting point has a legitimate objection.
Rebuilding a reading trail
If you have gaps, the honest approach is usually the cheapest:
Take current readings now for every meter, dated. That's your reliable baseline going forward.
Where you have a notebook record from the gap period, enter it with the actual date rather than backfilling guesses.
Where you have nothing, don't invent readings. Apportion the gap period by some transparent method and tell affected tenants what you did and why.
Don't try to recover the full amount retroactively from a tenant with no evidence behind the charge. Defending an unprovable utility bill costs more goodwill than the electricity is worth.
Telling tenants plainly that a system issue caused a gap, and how you're handling it, is a stronger position than presenting a reconstructed bill as though the data was always there.
The pattern worth naming
This is now the second occasion where a PG capability described in a published post subsequently broke. The first was the self-service booking claim in the batch-3 audit; this is the second.
The standing practice this reinforces: this module ships fast, and a claim verified today is a claim verified today — not a permanent statement. That's why every PG content batch is preceded by a fresh live-code audit rather than trusting the previous one. It's also why these posts state limits explicitly instead of describing capabilities in the abstract.
For a PG owner the practical version is: if a feature you rely on stops behaving, report it rather than working around it. The workaround is how a broken feature stays broken for months.
A practical operating workflow for this PG
The useful way to apply When Every Meter Reading Screen Was Broken and Nobody Said So is to turn the idea into a repeatable operating rhythm. Start with the current process, not the software screen. Write down who begins the task, what information they need, where the record is kept, who checks an exception, and what the resident is told. That prevents a common PG mistake: digitising an unclear process and discovering that the same argument now happens faster.
Step 1 — establish the starting record. Every meter-reading endpoint was returning a server error for part of this year, on every property. The owner or warden should decide which field, document or confirmation is the source of truth. Existing residents, rooms, balances or requests should be checked before a new workflow is switched on. If the starting record is incomplete, note the gap openly instead of filling it with an assumption.
Step 2 — define responsibility. It's fixed , and meter-based utility billing works as described in the original post . Name the person who enters the record, the person who can approve a change, and the person who follows up when something is overdue. In a small PG those roles may belong to one person, but writing them down still matters. It stops a cook, caretaker, accountant and owner from each believing that somebody else handled the same exception.
Step 3 — test one real case end to end. This is the second time a published PG capability broke after publication. That pattern is the point of this post as much as the fix is. Use one room, one resident or one billing cycle first. Follow the record from the first action to the final acknowledgement. Check the owner view, staff view and resident-facing result separately. A backend record or internal screen is not enough if the person expected to act cannot reach it.
Step 4 — keep an exception path. Decide what happens when information is late, a resident disputes the record, a staff member lacks permission, or the usual approver is absent. Record the reason for any manual correction. Do not quietly overwrite history simply to make a dashboard look tidy.
What the weekly review should cover
Fifteen focused minutes is enough when the team brings the same evidence each week. Review what was completed, what remains open, which cases needed manual intervention, and whether residents received the message or document they were meant to receive. The objective is not a perfect-looking count. It is to find repeated friction while it is still small enough to fix.
Review question Evidence to check Action if it fails
Did the process start with a complete record? The original entry, document or resident confirmation Correct the source and note who verified it
Did the right person act? User, timestamp and permission trail where available Clarify responsibility or access before the next cycle
Did the resident receive a clear outcome? Receipt, message, portal view or signed acknowledgement Send the missing confirmation and repair the template
Did an exception repeat? Open cases and manual corrections from the week Change the process; do not keep relying on memory
For What actually happened, ask whether staff explain the process consistently. For What to check, compare the operating record with what the resident experienced. For Rebuilding a reading trail, look for cases handled outside the agreed path. These checks do not assume an automated report, alert or capability that the article has not established.
A safe rollout checklist
Confirm the property, room and resident scope before changing any record.
Check that only the intended role can create, approve, reverse or view the relevant information.
Run a real test with the people who perform the work, not only an administrator.
Keep the previous record available until the new result has been checked.
Tell residents what changes, what does not, and where they can raise a dispute.
Review the first week and document every manual workaround.
This checklist protects both sides. Residents get a process they can understand and question. Owners get a record that can be checked later instead of an argument reconstructed from memory. It also respects the boundary between guidance and capability: use only screens, permissions and resident surfaces actually reachable in your Hotel/Hospitality tenant.
One more question operators ask
Should we move every existing case into the new process at once?
No. Start with a controlled group or the next clean cycle, reconcile the result, and then expand. A staged rollout is slower for a few days and far safer than correcting every resident record after a rushed migration.
Where AXOIX is honest about its limits
Nothing reconstructs missing readings. A gap is a gap; the system can't infer what the meter said in March.
Readings are manual entry. No smart-meter integration — someone walks around and reads the meters.
A wrong reading entered is a wrong bill. No plausibility check catches a digit typed twice.
FAQ
Is meter billing working now?
Yes — readings record, and the proration and separate electricity/water paths work as described in the meter billing post.
Should I switch to flat utility charges instead?
Flat charges are simpler and less defensible. See the methods compared before changing your model.
How often should I take readings?
Monthly, on a consistent date, aligned to your billing cycle. Irregular reading intervals make every bill arguable.
The bottom line
Meter billing works. It didn't for a period, on every property, and saying so is more useful to a PG owner than quietly fixing it — because the owner is the one holding a gap in their reading history and deciding what to bill.
See how meter billing works, the alternatives, or pricing.
Readings that record, every time. Start free →
Comments