How to run building finances without a spreadsheet

Ask a building manager how they track money and you will hear the same stack everywhere: a banking portal in one tab, a spreadsheet in another, and a phone full of “did you pay yet?” conversations gluing the two together.

The spreadsheet is the problem. Not because spreadsheets are bad at math, but because a spreadsheet only knows what you last typed into it. Every payment that arrives after you close the file makes it wrong. So you re-open the banking portal, scan the new transactions, match them against apartment numbers by memory, retype the results, and repeat next week. For one building this costs an evening a month. For six buildings it becomes the job.

Building finances have a specific shape, and once you model that shape properly, most of the manual work disappears. Here is the system.

Money moves in two directions. Track them separately.

Every building has exactly two kinds of money flow:

• Outgoing costs. The cleaning company, the elevator service, the electrician, insurance. The community pays these from the building account.
• Incoming collections. Common-cost contributions, a one-off collection for a roof repair, reserve payments. Residents pay these into the building account.

Most spreadsheets mash both into one sheet, which is why they turn into archaeology. Outgoing costs need an answer to “have we paid this, and from which statement row?” Incoming collections need a different answer entirely: “who exactly has paid, who is partial, and who do I chase?” One is a checklist. The other is a per-person ledger. Keep them separate and both questions become one glance.

The reference trick: let payments identify themselves

Utilities and telecom operators reconcile millions of payments a month with a tiny back office. Their secret is boring: every payer gets a unique payment reference, and the reference comes back on the bank statement with the money.

The same trick works for a building. When you raise a collection, every apartment gets its own reference number. When the payment lands, the reference tells you exactly which apartment paid, with no name-guessing. “S. Jovanović” in the statement could be three different residents. Reference 97-4402-118 is exactly one.

The failure mode is typos, and the fix for that is a payment QR code. Standardized bank QR formats exist across Europe (the EPC QR code, also called GiroCode, in euro countries; national formats like Serbia’s NBS IPS elsewhere), and every mobile banking app can scan them. The resident scans, the amount and reference are pre-filled, and the transfer arrives machine-readable. No mistyped references, no rounded amounts, no “I think I paid the right thing.”

If you set up nothing else from this article, set up references. They are the difference between reconciliation being a matching job and being a guessing job.

The bank statement is the ledger. Import it, don’t retype it.

Here is the mental shift that kills the spreadsheet: the bank statement is already the authoritative record of your building’s money. Every payment in, every cost out, timestamped and complete. Retyping it into a second document creates a copy that is worse in every way, and then you spend hours keeping the bad copy in sync with the good original.

So import instead. Every bank issues statements in a parseable format: PDF, camt.053 XML, MT940, CSV. A proper tool reads the file and turns each transaction into a row you can link to a cost or a collection. Incoming rows match to residents automatically by reference. Outgoing rows link to the cost they settle. (If you manage buildings in Serbia, where every bank has its own statement layout, we walk through exactly that zoo in the Serbian statement import guide.)

Statuses then compute themselves. A cost with linked transactions covering the full amount is paid. Covering part of it: partially paid, shown as “paid / total”. A collection shows exactly which apartments have paid and which have not, because the statement said so, not because you remembered to update a cell.

The balance check: how you catch missing months

A subtle failure ruins more building bookkeeping than any typo: a missing statement. You import January, skip February in the chaos of a burst pipe, import March, and now every number you compute is quietly wrong. You find out a year later, during the worst possible conversation.

The guard is simple: track the building account’s running balance, and verify every statement against it. Each statement declares an opening and a closing balance. If the file’s opening balance does not match your recorded balance, records are missing, and the import should stop and say so rather than let the gap slide through. Import the missing statement, then continue. Your recorded balance snaps to the statement’s closing balance, and the chain stays continuous.

A continuous chain is worth more than tidiness. It means that at any moment you can prove where every dinar, euro, or forint went, which is exactly what you need at the annual meeting, and exactly what a spreadsheet built from memory can never prove. It is also what makes the year-end statement build itself instead of consuming your January: we cover that whole cycle in the owner accounting playbook.

A note on privacy, because statements are sensitive

A bank statement of a building account contains every resident’s name and payment history. Be deliberate about where that file goes. The strongest setup is one where the statement is parsed locally, on your own computer or phone, and never uploaded or stored anywhere as a file; only the transaction rows you choose to save leave the device. When you evaluate tooling, ask this question directly. “Where does the statement file go?” is a question every vendor should be able to answer in one sentence.

What this replaces

The payoff is not abstract. A reference-plus-import system replaces, concretely:

• The reconciliation evening. Matching becomes automatic for referenced payments and two clicks for the rest.
• The “did you pay?” messages. The who-paid view answers it, so you contact only the actual non-payers, with the numbers in front of you. (If those conversations currently happen in a group chat, that is its own problem.)
• The awkward wrong accusation. Chasing someone who paid three weeks ago costs more goodwill than any late payment. Reference-matched records make it impossible.
• The handover black hole. A manager change hands over a linked, continuous record instead of “the spreadsheet, mostly current as of some point.”

Where this leads

Once payments identify themselves and statements import cleanly, two upgrades become nearly free. The first is collecting by direct debit instead of waiting for transfers, which flips the work from chasing to a monthly file upload: we cover it in the SEPA direct debit guide. The second is the annual statement, which stops being a project and becomes a report you generate, because the transaction chain it summarizes already exists.

The spreadsheet had a good run. But it was always a manual copy of a record your bank keeps better. Link the record instead of copying it, and building finances shrink from an evening a week to minutes a month.