Bank statement import in Serbia: every bank, zero retyping

Building money in Serbia runs on surprisingly modern rails. Every stambena zajednica has its own bank account. Residents pay from mobile banking apps. The National Bank’s IPS QR standard means a payment can be a three-second scan. And then the money arrives, and the modern part ends: the manager downloads the izvod, opens a spreadsheet, and starts retyping.

That retyping is the single biggest time sink in Serbian building management. For a resident-manager with one building it costs an evening a month. For a profesionalni upravnik with ten buildings and accounts at three different banks, it is a part-time job that produces nothing except a copy of information the bank already had.

This article is about deleting that job. Not improving it, deleting it: the statement goes in as a file, the payments come out matched to apartments, and the statuses update themselves. Here is what that looks like in practice, and what to demand from any tool that claims to do it.

Every bank issues izvodi. No two look alike.

The reason statement work survived this long is not that managers enjoy it. It is that Serbian banks never agreed on a format. Banca Intesa’s PDF statement looks nothing like AIK’s. Erste exports HTML. Some banks offer XML, others only a print-ready layout. A generic “CSV import” feature, the kind bolted onto accounting tools, chokes on all of them.

So the first question for any tool is blunt: can it read the statement my bank actually produces? Not a cleaned-up sample, the real file from the real e-banking portal. A serious importer handles the formats of Serbian banks as they are, AIK, Banca Intesa, UniCredit, NLB Komercijalna, OTP, Erste, ALTA and the rest, and when it meets a file it cannot parse, it says so clearly instead of importing garbage.

There is a nice local detail that makes this smoother than it sounds: in Serbia, the account number itself announces the bank. The leading three digits of the building’s account are the bank’s code, so a well-built tool knows which parser to reach for before you tell it anything. You pick the file, the rows appear. That is the entire workflow.

Naplata that reconciles itself

Import solves half the problem: the transactions are now rows instead of paper. The other half is knowing what each row means, and for incoming payments Serbia has had the answer for decades: the poziv na broj.

When you raise a collection, every apartment gets its own reference number. The resident gets a notification, and their payment details, amount, account, purpose, and poziv na broj, appear in their app next to a scannable NBS IPS QR code. They scan, the mobile banking app pre-fills everything, and the transfer arrives machine-readable. No mistyped reference, no rounded amount, no “uplatio sam, proveri”.

When the next izvod is imported, the credit rows match themselves to apartments by reference. What you see is not a list of bank transactions to decipher but a per-apartment answer: who has paid, who paid partially, who has not paid at all. The “did you pay?” conversation disappears, because the question no longer has an unknown answer. We covered why references beat name-matching in detail in the building finances guide; the short version is that “S. Jovanović” on an izvod could be three residents, and reference 97-4402-118 is exactly one.

Expenses: statuses you never set by hand

The outgoing side works the same way in reverse. The building’s costs, the cleaning service, the elevator contract, the electrician, live as expenses with a status. When you link a debit row from the statement to an expense, the status computes itself: linked rows covering the full amount mean paid, covering part of it means partially paid, shown as “paid / total”. Nobody updates a cell, because there is no cell. The status is a fact derived from the bank record, not an opinion typed into a spreadsheet.

This distinction sounds small until the skupština meeting. “The elevator invoice is 80% settled per the March statement” is a different sentence from “I think we paid most of it.” One is a record. The other is a memory.

The saldo check: how missing months get caught

Every izvod declares an opening and a closing balance. A well-built importer verifies the file’s opening balance against the building’s recorded balance before saving anything. If they disagree, a statement is missing, and the import stops and says so instead of letting the gap slide silently into your records. Import the missing month, then continue; the balance snaps to the statement’s closing saldo and the chain stays continuous.

A continuous chain means that at any moment, for any building, you can prove where every dinar went. That proof is exactly what the annual conversation with the building needs, and it is the foundation the whole year-end accounting cycle builds on, a cycle we walk through in the owner accounting playbook.

Transparency is a feature, not a virtue

Here is the part that changes the relationship with the building rather than just the workload: residents can see the same numbers you see. The building’s balance. The expenses and their statuses. Their own payment details and reference. The imported transaction list itself, read-only, in the app.

Serbian buildings have a long memory of money questions: “gde ide naš novac” is the default mood of a skupština, and managers spend real energy answering it defensively, one Viber message at a time. Open books invert that. When any resident can open the app and see that the March cleaning invoice was paid on the 14th from the account they contribute to, the question stops being asked, because it answers itself. (If those conversations currently live in a group chat, that is a problem worth solving on its own.)

For professional managers this is also a commercial weapon. Since the housing law made building management a profession, buildings choose their upravnik, and they can choose a different one. The manager who can show every dinar, live, to every resident, walks into a renewal conversation, or a pitch for a new building, with something the incumbent notebook cannot match.

The statement never leaves your computer

One more question to ask directly, because a building’s izvod contains every resident’s name and payment history: where does the file go? The strongest answer is nowhere. The statement is parsed locally, in your browser or on your phone, and is never uploaded or stored anywhere as a file; only the transaction rows you choose to save leave the device. When a vendor cannot answer “where does the statement file go?” in one sentence, that is your answer about the vendor.

What a month looks like afterwards

Concretely, the monthly loop for one building shrinks to this:

• Raise or reuse the collection. Every apartment already has its reference and QR code; residents get notified and pay by scan.
• Download the izvod, import it. Minutes, regardless of which bank the building uses.
• Link the handful of rows that need a decision. Referenced payments matched themselves; you link the outgoing rows to their expenses.
• Answer nothing. Who-paid, statuses, and the balance are visible to everyone who needs them, computed from the statement.

The spreadsheet era of Serbian building management was never a choice, it was the absence of tools that could read Serbian banks. That absence is over. The banks did their part years ago: the account is digital, the QR standard exists, the izvod is complete. All that was missing was the layer that reads it.