Condominium management software in Sri Lanka: the records you have to be able to produce

The honest way to specify condominium management software is to sit through an AGM.

Every difficult question asked in that room is, underneath, a question about a record. Why is my service charge higher than 4B’s. Why am I paying for the gym meter when my unit type has no gym access. Who authorised the lift contract. The tenant moved out on the 14th, so why am I billed for the whole month. Show me the arrears list. Show me last year’s, and explain the difference.

A management corporation that can answer those in the room keeps its mandate. One that says we will look into it loses a little of it each time. The software’s actual job is to make the first outcome the default.

This article is about the records that make that possible, written from building and running this system rather than from a feature list. It deliberately avoids telling you what the law requires, because that is a question for your lawyer and your management corporation rather than your software vendor. It sticks to what has to be producible on request.

Five registers, and the order they matter in

Almost every failure we have seen in condominium administration traces back to one of five registers being kept badly, or kept in a spreadsheet, or kept in somebody’s head.

1. The property register

Block, floor and unit as real records with their own history, not columns in a list somebody maintains by hand.

What it has to hold: a unit code unique within the community, net and gross area, unit category, and a lifecycle that runs from draft through active, under maintenance, inactive and archived. Common areas modelled as first-class records, not as an afterthought.

Why area matters so much: the moment you allocate a shared cost by entitlement, net area stops being a description and becomes the multiplier on somebody’s invoice. A wrong figure is not a data-quality issue, it is a billing error that repeats every month until someone notices.

2. The ownership register

Any number of owners per unit, each with a percentage and dates.

The single most common modelling mistake in this domain is a “current owner” field. Real communities have joint ownership, investor syndicates, inherited units held by several family members and mid-year transfers. A percentage-based, date-bounded ownership register handles all four; a single field handles none of them, and the workaround is a spreadsheet nobody else can see.

The system should hold the active total at or under 100% and refuse to let it drift.

3. The tenancy register

Not a “current tenant” field either. Every lease, with its move-in and move-out dates, kept after it ends.

That history is not archival tidiness. It is what makes retrospective pro-rata billing possible at all, and it is the first thing anyone reaches for when a charge from four months ago is disputed. Delete the ended tenancies and you have destroyed your own ability to answer.

4. The meter register

Every meter as a record, with a life: active, temporarily disabled, disconnected or faulty, each with dates and notes. Only an active meter should be billable, and an import that encounters a faulty meter should block rather than quietly charge it.

Meters attached to common areas need the same treatment as unit meters, plus an entitlement rule, which is the subject of its own section below.

5. The credential register

Key cards, physical keys, biometrics and temporary passes, each issued to a named holder, with expiry, status and a reissue action that closes the old card and records why.

This is the register most often absent, and it produces the most common security gap in managed buildings: a tenant moves out and their card still opens the lobby. The fix is not vigilance, it is a workflow. The move-out billing run should list every active credential held by the departing tenant and deactivate the ticked ones as the final invoice is generated.

The shared meter problem

Shared consumption is where goodwill goes to die.

The pool pump, the lift lobby, the gym and the corridor lighting are usually metered together, split by whoever is doing the spreadsheet that month, and impossible to explain when a resident asks.

The spreadsheet version, faithfully:

1. Amenity meter read
2. Split evenly across every unit
3. Units with no access to that amenity charged anyway
4. Each share rounded to two decimals
5. The total no longer matches the meter
6. The difference explained on the phone, unit by unit

Three of those six steps break. Step 3 is unfair, step 4 creates a rounding residue, and step 5 means the allocation cannot be reconciled to the source reading, which is exactly what a sceptical owner asks for.

The version that survives an AGM:

1. Amenity meter read
2. Only entitled unit categories included. Entitlement lives on the unit category, so a studio without gym access is never charged for the gym meter
3. Shared out by net area, not evenly, because that is what the entitlement actually is
4. The last unit absorbs the rounding remainder, so the allocation reconciles to the meter to the cent

And the resulting charge line names the common area it came from, so the answer is on the invoice rather than in a phone call.

The month, as nine stages

Most mid-sized property management companies run the monthly cycle on a shared workbook and an email chain. Written out as stages, it is the same nine every month, and each one is a place something can go wrong:

The reason to write it out is that the failure is almost never in one stage. It is in the seams a reading approved in stage 03 that becomes a charge in stage 05 under a tariff that was changed in stage 04 after the readings were taken. A workbook has no seams to inspect. A system with states and validation does.

Readings: the part that has to be checked before it becomes money

A wrong meter reading costs you twice: once in money, and once in trust, because a resident who has been over-billed once reads every future invoice differently.

Manual reading is error-prone in entirely predictable ways: a digit transposed, a meter read on the wrong unit, a reading taken from the previous month’s photograph, a vacated flat still drawing water that nobody thought to question.

What a system should do with a month’s readings, before any of it becomes a charge:

• Accept a bulk import and validate it line by line, matching each row to its meter
• Run more than one anomaly test, because they catch different things: a peer comparison against the rest of the block, a distribution-free fence for when consumption is heavily skewed, and the unit’s own consumption history
• Give every flagged row a score and a sentence in plain language, such as usage is 4.2× last period, so a reviewer triages five hundred rows in the right order instead of reading all of them
• Store previous usage, percentage change and direction of travel on each line
• Refuse to turn a batch into charges while an error is outstanding

That last rule is the one that matters. A batch that can become invoices with unresolved errors in it will, eventually, on a busy month.

Tariffs, and why they need dates

Utility tariffs change, they change mid-period, and they change retrospectively more often than anyone would like.

A tariff held as a single number on a settings screen cannot bill February correctly in March. Tariffs need to be date-effective, held per utility and per block, with as many steps as the supplier’s structure actually has, and each one approved before it can be used in a billing run.

The approval step is not bureaucracy. It is the difference between “the rate changed” and “somebody changed the rate”, which is a question that gets asked.

Who pays what: the five-level chain

In unit 4B the tenant pays electricity and the owner pays the service charge. In 4C the owner pays everything because the flat is empty. In 4D there are three owners with 40/40/20 percentages and a tenant who pays water only.

Resolving the payer for each charge type is a rule, and it should be a rule the system applies not a decision a person makes each month while looking at a spreadsheet. The output should be one consolidated invoice per payer per unit, so a landlord with four units receives four invoices they can pass on, not one aggregate they have to unpick.

Mid-month change of hands

The hardest ordinary case in the domain, and the fastest way to tell a real system from a demo.

A tenant leaves on the 14th. The electricity for that month has one meter reading covering both occupants. The service charge is monthly and the tenancy was half a month. The incoming tenant disputes an opening balance they did not create.

What has to happen: a pro-rata engine that can split the period, apportion metered consumption between the outgoing and incoming holders, bill each of them separately, and leave an audit trail explaining the split, because it will be questioned, and “the system did it” is not an answer.

Ask any vendor to demonstrate exactly this scenario. It is not an edge case; in a community of any size it happens every month.

Disputes as records, not emails

A challenged charge should be logged against the exact line it disputes: numbered, threaded, and worked through to a recorded resolution with an agreed amount and the person who signed it off.

The alternative is an email chain, and email chains do not aggregate. Once disputes are records, the committee can be shown the thing that actually matters at an AGM: how many disputes were raised this year, against what, how many were upheld, and what changed as a result.

Bill into an accounting system, do not write one

A temptation in this domain is to build billing inside the property tool and export a summary to the accountant each month. It demos well and it fails at the first audit, because the property system and the books then hold two different versions of the same money.

The better architecture is that the property logic, covering units, meters, entitlements, tariffs, pro-rata and disputes, produces real customer invoices in a real accounting system, with the receivable, the tax treatment and the ageing handled by software built for it - which is most of the argument for building this on a full ERP rather than beside one. The property tool decides what is owed and by whom. The ledger decides everything after that.

The practical test: ask whether the arrears list comes from the property tool or from the receivables ledger. If it comes from the property tool, ask what happens when a payment is recorded in the accounts and not in the property tool. There is only one right answer, and it is that the question cannot arise.

The reports that get asked for

Five views cover almost everything a committee actually asks for, and the fifth is the one that matters most:

• Overview. The community at a glance for the period
• Financial. Billed, collected, outstanding
• Utilities. Consumption and cost by block and utility, with the anomalies visible
• Occupancy. Owner-occupied, tenanted, vacant, and how that moved
• The per-unit property ledger. Every charge, payment and adjustment against one unit, in order

The last one doubles as the arrears list, and it is the report that ends arguments. Filtered by community, year and month, and able to drill through to the record behind each figure, because a number a resident cannot trace back to a document is a number they will keep questioning.

Every one of the registers above is modelled as a real record in our condominium ERP, for the reason given at the top: the questions asked at an AGM are questions about records.

What to ask a vendor

1. Show me a unit with three owners at different percentages and a tenant.
2. Show me a tenancy that ended in March and the invoice it still explains.
3. Import a readings file with three bad rows and show me what the system does.
4. Show me how a studio with no gym access is excluded from the gym meter.
5. Change a tariff effective from the 15th and re-run the month.
6. Move a tenant out on the 14th and show me both invoices.
7. Show me the arrears list, and then show me the same list as it stood last quarter.
8. Deactivate a departing tenant’s key card as part of the move-out run.

If most of those need a services engagement to demonstrate, you are being sold a general accounting package with a property label on it. How we run an implementation sets out what a demo of that depth should look like before anything is signed.

One thing worth being clear about

Software does not settle a governance question. If your community disagrees about how a cost should be allocated, no system will resolve that, and a vendor who implies otherwise is overselling.

What the software can do is make the allocation you agreed on apply the same way every month, show its working, and reconcile to the meter. That is a smaller claim than most brochures make, and it is the one that actually keeps AGMs short.