Utilities billing, collection and purchasing control

One computed charge, one collection model across every channel, one controlled purchasing path

• Domain: Finance & Accounting
• Moment: Before the money moves
• Customer: A property operator billing tenants for metered utilities across multiple sites

Calculate each charge and match every receipt to the right account.

The situation

A property operator buys utilities in bulk and resells them by consumption. Meters are read on a cycle. The charge comes from a contracted rate that varies by tenant, band and period. Money comes back through more than seven collection channels.

Alongside that runs purchasing: vendors compared before award, contracts carrying renewal and rate-change dates, spend that has to match what was awarded.

All of it ends in two target systems. Each is keyed by hand, and nothing checks that the two agree.

What breaks today

Billing, collection, and purchasing are joined by hand.

A meter reading still needs a calculation. Readings arrive as photographs, handwritten sheets, and per-building spreadsheets. The charge combines consumption, tariff bands, common-area allocation, minimum charges, and tax. A transcription error may surface later as a tenant dispute.

The rate logic lives in the person who bills. Which tenant sits on which tariff, which band applies at which consumption, which floor charge is contractual. Written down nowhere that can be executed, versioned or approved.

Every channel reports differently. Bank transfer, direct debit, bank counter, convenience store, QR from a mobile app, card on a portal, cheque, cash at the site office. Each has its own file layout, its own settlement timing and its own idea of where the tenant reference belongs. One truncates it. One nets its fee before remitting, so the amount received never equals the amount invoiced.

One payment rarely settles one invoice. A tenant clears three invoices with one transfer. Another pays rent and utilities together. Another short-pays by exactly the transfer fee. A one-to-one match returns unmatched on all three.

Purchasing leaves no decision record. Quotes are compared in a spreadsheet that is later superseded, so which vendor won, on which criteria, is rebuilt from an email thread. Renewal dates sit in a calendar, so a contract rolls at an old rate and the first signal is an invoice at a price nobody approved.

What Manuel does

It turns meter evidence into a computed charge. Readings are read in whatever form they arrive and tied to the meter, the meter to the unit, the unit to the tenant, and the tenant to the rate in force for that period. Consumption, bands, apportionment and minimum charges are configured as business rules. Every charge carries the reading, the previous reading, the rate version and the calculation behind it.

Readings are checked before they are billed. A reading below the previous one, consumption outside an agreed multiple of that tenant's trailing average, or a meter with no reading this cycle is held as a named exception before an invoice exists.

It normalises every channel into one collection model. Each channel file becomes the same record: value date, amount received, channel fee, reference as given, and the source line kept as evidence. Matching is written the way the business states it. Match on payment reference first. If unmatched, match tenant plus amount plus value date inside the agreed window. If still unmatched, test the one-to-many case where one receipt clears several invoices, and the short-payment case where the difference equals the channel fee. Anything outside tolerance becomes a named exception.

It controls the purchasing path. Vendor comparison uses criteria set before the quotes arrive, with documents attached to the decision. Expiry, notice, and rate-change dates trigger alerts.

It produces one validated result for both systems. The same figure is formatted for each system. Any difference becomes an exception before close.

What the customer gets

This work is at proposal stage and has no measured result yet.

Billing uses versioned rate rules. Collection becomes one queue ordered by age and value, with a reason on each open item. Contract renewals trigger alerts before the notice date.

What we would measure in a paid discovery, on your data: invoices produced without a human touching the calculation, first-pass match rate per channel, time from last reading to issued invoice, and the age profile of unapplied receipts. Those become the acceptance criteria in the contract.

What stays with your existing systems

Both target systems stay. The accounting ledger remains the book of record. The property system remains the record of units, leases and tenants. The meter estate and the reading routine stay as they are, including the parts done on paper.

Manuel holds no funds. The existing systems and data remain in place.

What a first scope looks like

One property, one billing cycle, files first, read-only.

We take a cycle you have already billed and collected, recompute every charge from the readings and the rates, re-match every receipt across every channel, and show where our result disagrees with what went out. Nothing is written to either target system.

Acceptance criteria are measured on your own cycle.

Related: Cash-in-bank reconciliation at scale / AP invoice control / Settlement and fee integrity