Utility meters and how consumption becomes a charge

Does AKCS turn meter readings into a maintenance charge automatically?

No. A reading recorded against a flat is a record, not a bill. Nothing in AKCS multiplies consumption by a tariff and raises an invoice for it. The one automated path from utility cost to invoice is the common-area bill splitter, and even that splits a rupee total you type in from the utility invoice, not a number AKCS read off a meter.

That distinction decides how you run your month:

What is the difference between a flat meter and a common-area meter?

They are two separate systems that do not talk to each other. A flat meter holds readings and no money. A common-area meter holds money and no readings.

A flat meter is registered against one flat, with a meter number unique within that flat, a type (electricity, water, gas or other), a unit of measurement that defaults to kWh, an active flag, a smart-meter flag and an optional vendor API endpoint.

A common-area meter is registered against any node in your hierarchy — the whole community, one tower, or a dedicated space for a lift — and every flat below that node is billable for it. It carries a name, an optional serial number, and a system type: general, elevator, water pump, sewage treatment, clubhouse or other. AKCS stores no readings against it.

What does a flat meter record?

Flat meters are API-only today. There is no flat-meter screen in the admin portal or the resident app, so ask us to set them up rather than looking for a screen.

Writes are restricted to community admins — only an admin can create, edit or delete a meter or a reading. A meter carries its type, its unit of measurement and its meter number. A reading carries the reading value, the reading date and time, a source — manual entry, smart meter or bulk import — and optional notes. Every reading is stamped with the admin who recorded it, and saving it copies the value and date onto the meter, so the meter always shows its latest reading.

Be careful what you promise residents about smart meters. The meter has a smart-meter flag and a field for a vendor API endpoint, and a reading can be labelled as coming from a smart meter. No scheduled job inside AKCS calls that endpoint and pulls readings in — something outside AKCS still has to push each reading.

Consumption is only derived after the fact, in an admin-only analytics response, as the last reading minus the first inside the date range requested. It is a number to look at, not a number that bills.

How does a common-area bill become a charge on each flat?

This is the one path that ends in an invoice. It runs as five steps.

1. Register the common-area meter against the node it covers.
2. Create the bill in draft: the total amount from the utility invoice, the period start and end dates, an optional external invoice number, and a split strategy — equal split, or pro-rata by flat area.
3. Run the calculation. It runs in the background, so the request is accepted first and you poll for the result.
4. Review it. Once the status reads ready, you get the eligible flat count, the total eligible area, and the amount allocated to each flat.
5. Commit it. This locks the bill and its allocations, and creates one invoice per flat.

Exemptions apply only when the meter has a specific system type: if a meter is typed as an elevator meter, flats carrying a matching exemption are excluded. A general meter exempts nobody.

The split always sums to the exact total. Under equal split, the leftover paise go to the largest flat by area, flagged as the remainder recipient. Under pro-rata, a flat with no area recorded is allocated nothing but still appears on the split; only when every eligible flat has zero area does the calculation fail, telling you to fix the areas or use equal split.

The invoices are dated the day you commit and due 15 days later, each carrying a single line item for that meter's allocation, with the billing period recorded on the invoice. They arrive as drafts on purpose — a draft invoice cannot accept a payment until it is sent, which is the same step as any other bill run, covered in how to generate maintenance bills.

So how do we bill per-flat electricity consumption today?

There are two honest routes, and neither is automatic.

Email a PDF bill. Upload your monthly electricity sheet. AKCS matches each row to a flat by flat name — rows it cannot match to exactly one flat are held back for you to resolve — then renders a PDF bill and emails it to that flat's resident email addresses. The sheet's total and invoice-number columns are read as authoritative and never recalculated. Every send is logged; a flat already emailed that month is skipped unless you explicitly re-send it, and a flat with no resident email on file is reported back rather than silently dropped. This raises no invoice: the amount is not owed inside AKCS, does not appear on the flat's ledger, and is not picked up by payment reminders or late fees.

Raise the charge yourself. Once you know the amount per flat, raise it as an invoice through the normal billing flow. From there it behaves like any other charge — payable online as described in paying maintenance online, chased by the reminder schedule, and counted in defaulter reporting.

What does a resident see?

Invoices for their own flat, the same as any other charge. There is no meter or consumption screen in the resident app, and a resident's account cannot reach another flat's meters or readings even through the API — reads are scoped to the flats they belong to. Community-wide consumption analytics is admin-only.

The vendor API endpoint is stripped from responses to residents, because those URLs commonly carry a key. Treat the reading series with the same care: a run of consumption figures is an occupancy signal showing which nights a family was away. That is why reads are scoped to the flat. More on those boundaries in who can see my data.

Above all, a resident sees no charge for consumption until your committee raises one. Recording readings every month does not, by itself, put a rupee on anyone's bill.