Choosing property management software for an Arab portfolio

Evaluating property management software from Riyadh, Cairo or Dubai has a particular difficulty: most of the mature products in the category were built somewhere else, for a market where rent arrives monthly by direct debit, tenancies roll month to month, and nobody has ever held a cheque dated for next March.

They are not bad products. They are products whose assumptions were formed elsewhere, and the assumptions are load-bearing — they sit in the data model, not in the settings screen. The questions below are the ones that surface that quickly, and they are worth asking in every demo including this one.

Ask what happens to a cheque, not whether cheques are supported

Every vendor selling into this region will say yes to "do you support post-dated cheques". The answer that matters is what the cheque IS in the system.

A cheque is a physical instrument that exists before the money does. It arrives at signing, sits in a safe for months, has its own number and bank and date, and can be replaced, returned to the payer, presented late, presented again, or partially paid. If the system models it as a status on a payment record, all of that is lost the moment something goes wrong — which is the moment you need it.

Questions that separate the two:

• Show me a cheque that has not been banked yet. Where does it live, and what does it do to the tenant's balance? (It should not have settled anything.)
• A cheque bounces. Show me the invoice before and after. Does it go back to owing exactly what it owed?
• Where is the bank's stated reason stored, in the bank's words?
• The tenant hands over a replacement. Is it a new instrument with its own presentation date, or an edit to the old one?
• The bank pays part of it. Can the system represent an instalment that is 60% settled by a cheque that also bounced?
• Show me every cheque due to be banked in the next fortnight, across the portfolio, in one list.

That last one is the operational test. Presentation dates are deadlines, and a system that cannot produce the fortnight's banking list is a system where somebody is keeping that list in a spreadsheet — which is where it was before you bought anything.

Ask to see Arabic, on a screen you did not choose

Arabic support is either in the layout engine or it is a translation file, and a demo will not tell you which unless you push. Right-to-left is not a text direction; it mirrors the entire interface — navigation, tables, form order, icons that imply direction, the side a currency symbol sits on.

What to ask for: switch to Arabic, then go to the most complex screen in the product — usually a ledger, an invoice or a report with numbers in columns — and look at it. Then print or export that screen.

• Do the tables mirror, or does the text just change while the layout stays left-to-right?
• Do numbers and dates stay readable, or does an Arabic paragraph break an amount across the line?
• Is the printed invoice bilingual, or is Arabic an export option?
• Are the tenant-facing documents — statements, notices, receipts — in the language of the contract, automatically?
• Ask a native Arabic speaker to read three sentences of the interface. Machine translation is obvious immediately and it is what a tenant sees.

Ask how tenants are kept apart from each other

If the product has a resident portal, every tenant is a user of a system that also holds every other tenant's ledger. The question is what stops one seeing another.

The weak answer is that the application filters by tenant. That is true of every system ever breached in this way: the filter is correct in ninety-nine places and missing in the hundredth, and the hundredth is a report somebody added last quarter.

The strong answer is that the isolation is enforced below the application — by the database itself, so a query that forgets to filter returns nothing rather than returning everything. Ask which it is, and ask how it is tested.

• Is separation enforced in the database or in application code?
• What happens to a query that forgets the filter — no rows, or all rows?
• Can a resident's session widen itself by changing an identifier in a request?
• Is there a test suite that specifically tries to read across the boundary, and can I see what it covers?
• Where are identity documents and bank details stored, and are they encrypted at rest?

Ask about money the way an auditor would

Property management is a business of holding other people's money — deposits, rent collected for owners, cheques in a safe. The accounting questions are not back-office detail; they are what makes the numbers defensible when somebody disputes them.

• Is a security deposit a liability on the balance sheet, or does it hit income when received? (Income is wrong.)
• Can an issued invoice be edited? (It should not be. Corrections should be credit notes.)
• Can a journal entry be deleted? (It should not be. Reversals are new entries.)
• Is money stored as a decimal at fixed scale, or as a floating-point number? Ask directly — this decides whether the totals drift.
• Show me the trial balance. Does it balance to zero, and can I see it without asking anyone?
• If a bill is issued twice by mistake — the nightly job runs while somebody presses the button — does the tenant get billed twice?
• Can I produce a statement of account for one tenant, on demand, showing every charge and every payment with a running balance?

The double-billing question is worth pressing on. The correct answer is that it is prevented by a constraint in the database, not by the application checking first — because checking first is a race, and rent generation is exactly the workload where two things run at once.

Ask about VAT and registration as a jurisdiction question

A system that hardcodes 5% is a UAE system. A system that hardcodes 15% is a Saudi one. If you operate in more than one market, or intend to, tax treatment has to be configuration keyed by jurisdiction and applied per line — and stored on the invoice as issued, so a document reprinted after a rate change still shows what was actually charged.

Contract registration is the same shape. Ejari, Tawtheeq and Ejar are different systems with different fields and different rules, and a product that models "registration" as a single text box has not engaged with any of them.

Ask what happens on day one, and on the day you leave

Two questions that get skipped in every evaluation and decide how the first month and the last one go.

Getting in: you have units, tenants and live contracts already. Ask to import them — actually import them, in the demo, from a spreadsheet in your format. A vendor who says "our team will handle the onboarding" is telling you there is no import, which means somebody types eight hundred rows and the errors are discovered in month three.

Getting out: ask how you export everything, in a format that is useful without their software. Data you cannot get out is a business you cannot leave, and the answer is much easier to obtain before you sign than after.

• Can I import units, contacts and contracts from a spreadsheet, myself?
• Does the import show me what it will do before it does it?
• What happens to a row with a bad date or a duplicate reference — refused with a reason, or silently skipped?
• Can I export every table, including the ledger and the audit trail?
• What is the notice period, and what happens to the data after it?

A note on this list

This is a checklist for buying property software in this region, and we sell property software in this region. Read it accordingly — though the questions are written so that a competitor could hand it to you and it would still be a fair test.

The two we would most want asked of us are the bounced-cheque walkthrough and the double-billing question, because they are the ones where a product either has an answer in its data model or has a plausible-sounding sentence.