IustumBill

Meter readings entered in the field by a restricted recorder role, anomaly review before anything is billed, batch invoice generation with a rent-cycle guard, two generated documents per unit, and delivery by email or Telegram with every send logged verbatim.

Billing the same rent twice is the failure this product exists to prevent, and we came close. Not everyone is billed on the same cycle — tenants move in on different days, so one reads the meter on the first of the month and another on the eighth. A generation run iterated every unit rather than only the units with a confirmed reading for the period being billed, so tenants on one cycle picked up a rent-only draft inside every other cycle's run. Each of those drafts advanced their rent position forward another month. We found it in real data, by which point several rent positions had been carried months ahead of where the tenancies actually stood. Nothing had been sent, which was luck as much as design, and not a defence.

Repairing the affected records was the easy half. The harder question was whether the cause was permanently closed, and stress-testing the fix turned up a second route to the same outcome: a unit whose readings arrive under two different dates inside one cycle produced two invoices, each carrying its own rent line. Rent now attaches to an invoice only when the next unbilled cycle starts no later than the day after the billing period ends; otherwise it is held, and the run says so in plain language instead of quietly omitting it. The rule is written so that the order runs happen in cannot matter, and the proof is the simulation — a following billing cycle driven through the interface across staggered cycles and a late straggler reading, confirming one rent charge per cycle.

In production against live data, with live tenants.