Moving your society off spreadsheets without losing history

The reason most societies stay on spreadsheets is not that the spreadsheet is good. It is that migrating looks risky, and the treasurer who built the workbook is the only person who understands it. Both concerns are legitimate. Neither is a reason to stay — but they do dictate the sequence.

Start with what you must not lose

Before touching any software, list what genuinely has to survive the move:

The honest answer on historical bills: most societies do not need seven years of line-item history inside the new system. They need the audited statements for past years (which they already have as PDFs) plus accurate opening balances as at the cutover date. Trying to reconstruct five years of transactions is where migrations stall and get abandoned.

Clean the unit list first

This is the step committees want to skip and cannot. Every downstream problem — misbilled flats, notices to the wrong person, quorum counted against a wrong total — traces back to a bad unit list.

Common problems in a society spreadsheet:

• Inconsistent flat numbering. A-101, A101, A/101, 101-A all

appearing for the same flat across different sheets.

• Wing letters missing where a society has more than one building.
• Carpet area blank or wrong for a handful of flats — usually the ones with

irregular layouts, which are exactly the ones members query.

• Owner and occupant conflated, so a tenanted flat has the tenant's name in

the owner column.

• Stale contact details for flats that changed hands two years ago.

Pick one canonical format for flat numbers and apply it everywhere before you import anything. Sorting the list by flat number in a spreadsheet exposes most inconsistencies instantly — anything that sorts to an unexpected position is formatted differently from its neighbours.

Opening balances are the real work

Here is where migrations actually get difficult, and where a rushed cutover produces a year of disputes.

You need, for every flat, as at the cutover date:

• outstanding principal by billing head,
• interest accrued and unpaid,
• any advance the member has paid,
• and any credit note or waiver approved but not yet applied.

Three rules that save a lot of grief:

1. Cut over at a month boundary, ideally the start of a quarter or the

financial year. Mid-month cutovers require splitting a bill and nobody enjoys explaining that.

1. Reconcile arrears to the bank before you import, not after. If your

spreadsheet says a flat owes ₹18,400 and the bank shows a ₹6,000 receipt you had not applied, importing first means the discrepancy is now in two systems.

1. Get the opening balance list signed off by the treasurer and, ideally,

noted in a committee resolution. When a member disputes a balance eight months later, the answer should be a document, not a memory.

A workable sequence

Week 1 — extract and clean. Export the unit list, member list and current arrears to a single spreadsheet. Standardise flat numbering. Fill in missing areas from the sale deeds or the approved plan. Separate owners from tenants.

Week 2 — import and configure. Import units and members. Set up billing heads to match what you bill today — not an improved version, the actual current one. Reproducing the current bill exactly is what proves the migration worked; redesign it in month two.

Week 3 — parallel run. Generate the month's bills in the new system without sending them. Compare line by line against the spreadsheet bill for the same month. Investigate every difference. Expect a handful: they are almost always a wrong area figure or a head that was being applied manually as an exception.

Week 4 — cut over. Once the parallel bill matches, send from the new system. Keep the spreadsheet read-only as a reference for one full quarter. Do not maintain it in parallel — dual maintenance is how societies end up with two divergent sets of books.

Bring the members with you

The technical migration is the easy half. A committee that migrates cleanly and tells nobody gets a month of "I didn't get my bill" calls.

• Announce the change before the first bill, with the date.
• Explain what members gain specifically — their own ledger, digital receipts,

payment without a cheque — not "we are modernising".

• Expect that some members will not adopt immediately. Keep the old payment

route open for at least a quarter.

• Nominate one committee member as the contact for migration questions, so

queries do not scatter.

What to check before you commit to a platform

Whichever system you choose, verify these before migrating rather than after:

• Can you import from a spreadsheet, or is data entry manual? For a 200-flat

society, manual entry is weeks of work.

• Can you export everything back out, in a standard format, on demand? If

you cannot leave, you did not choose a vendor — you acquired a dependency.

• Does it produce the statutory statements your auditor expects, with

head-wise fund schedules?

• Where does collected money go? Maintenance collections should settle to

the society's own bank account. Ask the question explicitly and get the answer in writing.

• Is there an audit trail of who changed what?
• What happens to your data if you stop paying?

Societly imports a society's unit and member list from an Excel or CSV file, and lets you export members, units and billing history back out at any time — the export question above is the one worth asking of every vendor you evaluate, including us.

Related: what transparent society accounts look like for what the new system should be able to produce, and choosing society management software for the wider evaluation. If you have not yet decided you need to move at all, spreadsheets vs software makes the case for staying put where staying put is the right call.