I want to show you exactly how utility billing automation works — not the marketing version, but the actual mechanics. What happens when a resident submits a meter reading. How the system calculates a bill. Where the time savings come from. Where the errors disappear.
This is the technical follow-up to our earlier practical guide to utility billing. That one covered why you should automate. This one covers how the automation actually works, step by step, with real numbers from a building I manage in Purvciems.
The manual process, timed
Before we automated, here's what a single billing cycle looked like for a 47-unit building:
Day 1-3: Collecting readings. I sent a WhatsApp message to all 47 residents on the 1st of the month. By the 3rd, I'd received maybe 30 readings. The other 17 required follow-up messages, phone calls, or physical visits. Time spent: about 4 hours.
Day 4-5: Data entry. I typed each reading into a spreadsheet. Electricity, cold water, hot water — three readings per apartment, 141 numbers total. Then I cross-checked against last month's readings to catch obvious errors (a reading lower than last month, a reading 10x higher than expected). Time spent: about 3 hours.
Day 6: Calculating bills. Previous reading minus current reading, multiplied by the tariff. But it's not that simple — there's the building's common area consumption to split, the heating cost allocation (which in Latvia follows the Energy Performance of Buildings Directive methodology), and the difference between actual and estimated readings from prior months. Time spent: about 3 hours.
Day 7-8: Generating invoices. Export the calculations, format them as individual PDFs, email each resident. For residents without email, print and distribute. Time spent: about 3 hours.
Day 9-10: Bank reconciliation. Match incoming payments to invoices. Chase the ones that didn't pay. Time spent: about 2 hours.
Total: roughly 15 hours per billing cycle, per building. I managed three buildings. That's 45 hours a month — more than a full work week — spent on utility billing alone.
What changes when you automate
Let me walk through the same cycle with automation in place, using the system we implemented.
Step 1: Reading collection (4 hours → 20 minutes)
Instead of WhatsApp messages, residents receive an automatic notification on the 1st of each month: "Please submit your meter readings by the 5th." The notification includes a link to their resident portal.
They log in, see a form pre-filled with their apartment number and last month's readings, and enter three numbers: electricity, cold water, hot water. Optionally, they can upload a photo of their meters.
The photo matters more than you'd think. About 40% of our residents submit photos, and it has eliminated the most common error: entering the wrong meter reading. When a reading looks off — say, 10x higher than last month — I can pull up the photo and verify before billing. Before automation, this verification required a phone call and a follow-up visit. Now it's a 30-second check.
The system sends an automatic reminder on the 4th to anyone who hasn't submitted. By the 5th, we typically have 85-90% of readings. The remaining 10-15% are billed on estimate (more on that below).
My time: 20 minutes reviewing flagged readings and checking photos. The collection itself is fully automated.
Step 2: Data entry (3 hours → 0)
This step disappears entirely. Readings go directly from the resident portal into the database. No typing, no transcription, no cross-checking against last month's values — the system does that automatically and flags anomalies.
The flagging logic is simple but effective. If a reading is lower than the previous month (impossible for cumulative meters), the system marks it red. If consumption is more than 3x the 6-month average, it's flagged yellow. I review flagged readings before billing — maybe 3-5 per cycle — and the rest flow through automatically.
This is where the biggest time savings come from. Three hours of data entry, gone. Not reduced — eliminated.
Step 3: Bill calculation (3 hours → 10 minutes)
Here's where things get interesting. The calculation that used to take me three hours now runs in about 10 seconds. But the setup — configuring the tariffs and allocation rules — took about 2 hours one time, and maybe 15 minutes per quarter when tariffs change.
Let me break down what the system actually calculates for each apartment:
Electricity: (Current reading − Previous reading) × tariff. In Latvia, Sadales tīkls has day and night tariffs, so if the building has a dual-tariff meter, the system calculates both. Day rate: €0.22/kWh. Night rate: €0.14/kWh. These get updated a couple times a year.
Cold water: (Current − Previous) × tariff. In Riga, the water tariff includes a fixed component (€1.20/m³ for Rigas ūdens) and a variable component. The system handles both.
Hot water: This is where it gets complicated. In buildings with a central heating substation (siltummezgls), hot water cost depends on the heat energy used to warm the water, not just the volume. The building's heat meter registers the total energy, and that cost is allocated between hot water and space heating. The system handles this allocation based on the methodology approved by the Latvian Public Utilities Commission (Regulas padome).
Common area consumption: The building's shared electricity (stairwell lights, elevator, pumps) and shared water (cleaning, garden) get split across all apartments proportional to square meters. The system applies this split automatically.
Heating cost allocation: This is the most complex calculation. Under the EU Energy Efficiency Directive (2012/27/EU) and Latvia's implementing regulations, heating costs in buildings with central heating must be allocated based on a combination of individual consumption (measured by heat cost allocators on radiators) and area-based allocation (typically 30-40% area, 60-70% consumption). The system applies this split, handles buildings where some apartments have allocators and others don't, and generates the heating cost breakdown for each unit.
All of this — which used to be three hours of spreadsheet formulas and double-checking — runs automatically once the tariffs and allocation rules are configured.
My time: 10 minutes reviewing the calculation summary before generating invoices.
Step 4: Invoice generation (3 hours → 5 minutes)
The system generates a PDF invoice for each apartment automatically. Each invoice includes:
- The meter readings (current and previous) for each utility
- The consumption and unit price
- The calculated amount for each utility
- Common area allocation
- Heating cost allocation (with the area/consumption split shown)
- Total amount due
- Payment reference number (so the bank can auto-match the payment)
- Due date
The invoice is clean, itemized, and consistent. No more formatting individual PDFs. No more mail merge. The system emails each invoice to the resident through the portal, and those without email get a printed copy (the system flags these automatically).
My time: 5 minutes clicking "generate and send." That's it.
Step 5: Estimates for non-submitters (handled automatically)
The 10-15% of residents who don't submit readings by the deadline get billed on an estimate. The system calculates the estimate as the average of their last three months of actual consumption. When they eventually submit a real reading, the next invoice automatically adjusts for the difference — either a credit or a top-up.
This is standard practice in Latvia. Sadales tīkls does the same thing for electricity. Residents are familiar with the concept, and it eliminates the need to chase every reading before billing.
The key communication point: residents know that submitting late means an estimated bill, and they know the next actual reading will correct it. Once people understand this, submission rates creep up over time. We went from 64% on-time submissions in month one to 88% by month six.
Step 6: Bank reconciliation (2 hours → 15 minutes)
This is the step that surprised me most. I expected automation to help with reconciliation, but I didn't expect it to be this dramatic.
The system imports bank statements (Swedbank CSV, SEB XML — all the major Latvian banks are supported) and automatically matches payments to invoices using the payment reference number. When a resident pays their invoice, the reference number in their bank transfer tells the system exactly which invoice to mark as paid.
Unmatched payments get flagged. Maybe 3-5 per cycle — usually someone who paid the wrong amount or used the wrong reference. I handle those manually. Everything else is done.
My time: 15 minutes reviewing unmatched payments and handling exceptions.
The total: 15 hours → 50 minutes
Here's the before-and-after for one billing cycle:
| Step | Manual | Automated |
|---|---|---|
| Reading collection | 4 hours | 20 minutes |
| Data entry | 3 hours | 0 |
| Bill calculation | 3 hours | 10 minutes |
| Invoice generation | 3 hours | 5 minutes |
| Bank reconciliation | 2 hours | 15 minutes |
| Total | 15 hours | 50 minutes |
That's 14 hours and 10 minutes saved per building per month. Across three buildings: 42 hours. That's a full-time position, recovered.
Where the errors go
The time savings are obvious, but the error reduction is arguably more valuable. Here's what changed:
Transposed digits. When I typed 4521 instead of 4251, a resident got billed €180 instead of €30. The dispute, the correction, the awkward conversation — all because of a typo. With direct entry by the resident, this error class disappears entirely. The resident types their own reading. If they type it wrong, they see it on their invoice and submit a correction. No intermediary transcription.
Wrong tariffs. I once applied the previous quarter's electricity tariff for two months before noticing. Cost me about €340 in underbilling across the building, which I had to absorb. The system stores tariffs centrally and applies them consistently. When I update a tariff, it applies to all future bills automatically.
Calculation errors. Spreadsheet formulas are fragile. One wrong cell reference and an entire column calculates incorrectly. The system's calculation engine is tested and consistent — the same logic runs for every apartment, every cycle. No formula drift.
Missed estimates. In the manual system, I sometimes forgot to bill a non-submitter entirely. They'd go three months without a utility bill, then get a massive catch-up invoice. Residents hated this. The system never forgets — every apartment gets billed every cycle, either on actual or estimated consumption.
The OCR question: does it actually work?
Some platforms offer OCR (optical character recognition) that reads meter readings from photos automatically. The resident snaps a picture of their meter, and the system extracts the number.
Does it work? In my experience: mostly yes, with caveats.
On clean, modern digital meters with large displays, OCR is reliable — maybe 95% accurate. On older mechanical meters with small dials, it's more like 70-80%. The system should always let the resident confirm the extracted number before submitting, which catches the errors.
Is OCR worth it? If your residents are submitting photos anyway, OCR saves you the step of manually reading the photo. For a 47-unit building with 40% photo submission, that's maybe 19 photos to read per month. OCR turns that into 19 quick confirmations. A time saver, but not a game-changer.
The game-changer is the resident portal itself — the direct entry. OCR is a nice add-on on top of that.
What about smart meters?
Latvia is rolling out smart electricity meters under the EU Energy Efficiency Directive. By 2027, most buildings will have smart meters that transmit readings automatically over the cellular network or powerline communication.
When smart meters are in place, the reading collection step disappears entirely. The meter sends readings directly to the utility and (if integrated) to your property management platform. No resident action needed. No estimates. No photo verification.
But here's the reality: smart meter rollout in Latvia has been slower than planned. Sadales tīkls has installed smart meters in maybe 60% of buildings as of mid-2026, but integration with third-party platforms is still limited. Most property managers will be in a hybrid state — some apartments with smart meters, most still manual — for at least another 2-3 years.
The automation system I'm describing works in this hybrid state. It handles smart meter data when available and manual entry when it's not. That flexibility is what makes it worth implementing now rather than waiting for full smart meter coverage.
Implementation: the first three months
Month one was rough. Residents were unused to the portal. Submission rates were low (64%). I spent extra time on training and reminders. But the system still saved me about 8 hours compared to manual billing, even with the learning curve.
Month two was better. Submission rates hit 78%. Residents who'd been skeptical started seeing the benefit — their invoices arrived on the 6th instead of the 12th, and they could see their consumption history in the portal.
By month three, the system was running smoothly. 85% submission rate. 50 minutes of my time per cycle. The initial 2-hour setup was behind me, and the ongoing maintenance (tariff updates, occasional configuration tweaks) was maybe 20 minutes per quarter.
Is it worth it?
If you manage one building with fewer than 20 apartments, the absolute time savings are modest — maybe 6-8 hours per cycle. Whether that's worth a software subscription depends on how you value your time.
If you manage multiple buildings, or a single building with 30+ apartments, the math is clear. 15 hours per building per cycle is not sustainable on top of everything else property management requires. Automation isn't a luxury at that scale. It's the difference between managing your properties and drowning in them.
Urbaneta handles the full utility billing cycle — resident portal, meter readings, tariff-based calculation, invoice generation, bank reconciliation — in one platform built for the Baltic market. You can try it free and run a full billing cycle alongside your current process to see the difference.
