Society Maintenance Billing Software: What It Must Do

What society billing software has to do

Most societies bill from a spreadsheet the treasurer built and only the treasurer understands. It works, in the sense that bills go out. It fails at handover, at audit, and at any moment a member disputes a figure — because the arithmetic is somewhere in a formula and the reasoning is nowhere.

Billing software is worth buying if it removes that fragility. Most of it does not, because vendors build for the demo — a nice-looking invoice — rather than for the messy parts, which are arrears, part payments and corrections.

Here is what to require, and how to test it.

Charge heads on their correct basis

The non-negotiable requirement. A society bill is not one number; it is several heads, each computed on its own basis. Service charges divide equally per flat. The repairs and sinking funds go by built-up area. Water follows inlets, property tax follows municipal assessment.

Software that only supports a single per-square-foot rate, or only an equal split, will force the society into a billing basis its bye-laws do not support. This is common and disqualifying.

Test it: ask the vendor to configure a bill with service charges equal per flat and sinking fund by area, in the same invoice, and show you the working.

Arrears, interest and allocation

Where spreadsheets genuinely break.

• Ageing. Outstanding balances bucketed 30/60/90+ per flat, for the balance sheet and the AGM.
• Interest on arrears, at the society's configured rate, simple not compound, accruing from the due date, shown as its own line.
• Allocation policy. When a member pays less than the total, the system must apply it by a configured rule — oldest first is the usual and most defensible — rather than leaving a human to decide each month.
• Advances. Round-figure overpayments must land in a visible advance balance and auto-apply next cycle, not vanish into miscellaneous receipts.
• Holds. The ability to pause interest or escalation for a flat with a recorded reason and a review date, so hardship is a documented committee decision rather than a quiet favour.

Test it: give the vendor a flat with three months of arrears and a part payment, and ask for the resulting ledger and the next bill.

Receipts that satisfy an auditor

• Unbroken numbered sequence, with no gaps
• Immutable once issued — corrections by documented reversal, never a silent edit
• Society name, registration number, flat, member, period, and the amount split by head
• Payment method and reference
• GST details only where the society is actually registered and liable

Ask directly: can a receipt be edited after issue, and what happens in the audit trail if it is. If the answer is that an admin can just change it, the system will not survive an audit question.

Payments and reconciliation

The point of online collection is that the payment arrives already attached to a bill, a flat and a period, so reconciliation happens at payment rather than a fortnight later.

Require: payment initiated from the bill itself; an explicit pending state while a bank confirmation is in flight, so residents do not pay twice; reconciliation against the gateway rather than only the callback, so a lost callback is caught; and a way to record payments made outside the system — a direct NEFT, a cheque — against the bill, or the ledger drifts from the bank.

Also: late fees judged by payment time, not settlement time. A resident who paid before the due date and whose payment settled after it must not be penalised.

GST handling

Only relevant if the society is registered and liable, which depends on turnover and the per-member threshold. But if it applies, the system must handle it as a configurable rule rather than a hardcoded percentage — the treatment of the ₹7,500 threshold has been litigated and societies take different positions on their auditor's advice.

It must also exclude pure-agent recoveries such as property tax and water charges from the computation.

The unglamorous requirements

• Bulk generation with review before issue. Generate the cycle, review the exceptions, then issue. Never generate-and-send in one irreversible step.
• Corrections after issue. Bills are wrong sometimes. There must be a credit-note path, not a delete.
• Mid-cycle ownership change. A flat sold on the 14th needs the bill apportioned or assigned by rule.
• Export for the accountant, in a format their software ingests, so year-end is not re-keyed.
• Data export on exit. Full history, in a usable format. A billing system you cannot leave owns the society.
• Audit trail. Who generated, who approved, who edited, when — append-only.

Questions to ask before you buy

1. Can different charge heads use different bases in the same bill?
2. How are part payments allocated, and is the rule configurable?
3. Can a receipt be edited after issue?
4. What happens when a payment callback is lost?
5. How does a mid-cycle ownership change work?
6. Can we export our full history, and what format?
7. Where is the data stored, and who at the vendor can read it?
8. What does the audit trail record, and can an administrator alter it?

Answers to 3, 4 and 8 tell you most of what you need to know about whether the product was built for societies or adapted from something else.

How this works on Plinth

Charge heads are configured with their own basis — equal, per square foot, or per unit — so a single bill can divide service charges equally while the sinking fund follows built-up area, without a parallel spreadsheet.

A cycle is generated for review and approved before issue rather than sent in one irreversible step. Arrears age into buckets, interest accrues simply from the due date as its own line, part payments allocate by the society's configured rule, and overpayments hold as a visible advance. Receipts run from an unbroken sequence and cannot be edited after issue — corrections go through a documented reversal.

Payments initiated from the bill carry the flat and period with them, an explicit pending state prevents double payment while a bank confirmation is in flight, and payments made outside the system can be recorded against the bill so the ledger matches the bank. Everything writes to the append-only audit log.

Frequently asked questions

What should society billing software support that a spreadsheet cannot? Per-head calculation bases, arrears ageing, simple interest from the due date, configurable part-payment allocation, immutable numbered receipts, and an audit trail — the parts that break at audit and handover.

Can billing software handle different charges for different flats? It must. Area-based heads vary by flat while equal heads do not, and both appear in the same bill.

How should part payments be applied? By a written policy, usually oldest outstanding first, applied automatically rather than decided each month.

Do we need GST support? Only if the society is registered and liable. If so, require configurable treatment rather than a hardcoded rate, and exclusion of pure-agent recoveries.

What happens if a bill is issued with a mistake? Issue a documented credit note or reversal. Never silently edit an issued bill or receipt a member is already holding.

Can we get our data out if we leave? Ask before you sign, and require full history export in a usable format.

Related: how maintenance charges are calculated · billing cycle approval workflow · online payment via UPI · housing society accounting · billing on WhatsApp vs a billing system