Trust-accounting software requirements for property practitioners

Why trust accounting is a statutory requirement, not a feature

When a property practitioner holds money on behalf of someone else — a landlord's rent, a tenant's deposit, a body corporate's levies — that money is not the firm's income. It is client money, held in trust. The Property Practitioners Act 22 of 2019 (generally section 54 and related provisions) frames how practitioners must hold and account for that money, and the consequences of getting it wrong can reach the practitioner's Fidelity Fund certificate and standing.

Because the obligation is statutory, your software is not just bookkeeping convenience — it is part of how you discharge a legal duty. That changes what 'good enough' means. A system that lets client money and operating money blur together, or that cannot prove where each beneficiary's balance sits at any moment, is generally not fit for purpose, no matter how slick the interface. Treat the requirements below as a checklist you can demand of any vendor, and confirm the specifics against the current Act.

Requirement 1: Segregation of client money

The first and most important requirement is structural separation. Client money must sit apart from the practitioner's own business funds — in a designated trust bank account, and just as importantly, in the software's ledger. Good trust software treats the trust ledger as a closed system: money in, money out, and a running balance per beneficiary that always ties back to the trust bank account.

Look for software that makes it difficult or impossible to accidentally pay the firm's expenses from trust money, or to over-distribute a landlord beyond their available balance. Separation should be enforced by design, not left to operator discipline.

• A distinct trust ledger, separate from operating/commission ledgers
• Per-beneficiary balances (landlord, owner, scheme, tenant deposit) that never go unexpectedly negative
• Controls that block paying out more than a beneficiary actually holds
• Clear handling of commission and fees, transferred out of trust only once properly earned and due

Requirement 2: Deposit handling and Rental Housing Act interest

Rental deposits are a special category of client money. Under the Rental Housing Act 50 of 1999, a tenant's deposit is generally held for the tenant, interest is typically accounted for to the tenant, and the deposit (with interest, less any lawful deductions) is dealt with at the end of the lease. Software that supports rental management should ring-fence each deposit against its lease, not lump deposits into a general pool where they lose their identity.

Practically, that means the system should track which deposit belongs to which tenant and lease, calculate or record the interest attributable to that deposit, and support a defensible deposit reconciliation at lease end — including itemised deductions where the lease and law allow them. Because the precise interest treatment depends on the lease terms and current law, the tool should let you configure it rather than hard-code an assumption you cannot verify.

Requirement 3: Reconciliation you can run on demand

Reconciliation is the heartbeat of a trust account. The classic test is a three-way tie-out: the trust bank balance equals the trust ledger balance, which equals the sum of every individual beneficiary balance. If those three figures agree, the trust is in balance; if they diverge, something is wrong and you need to find it before month-end, not after.

Require software that can perform and evidence this reconciliation both on a regular cycle and on demand. It should import or match bank transactions, surface unmatched items, and flag any drift between the bank, the ledger and beneficiary balances. A system that only reconciles 'when someone gets around to it' leaves you exposed the moment a query, an audit or a dispute arrives.

• Three-way reconciliation: bank balance = trust ledger = sum of beneficiary balances
• Bank statement import/matching with a clear queue of unmatched items
• Alerts when the trust position is out of balance
• A retained record of each reconciliation, so you can show the trust was in balance historically

Requirement 4: A complete, tamper-evident audit trail

An auditor's confidence in a trust account rests heavily on the audit trail. Every movement of client money should be attributable: who initiated it, who approved it, when, from which account to which, and against which beneficiary. Edits and reversals should be recorded as new, traceable events rather than silently overwriting history.

When you evaluate a system, ask to see the audit log for a sample transaction end to end. The trail should be detailed enough to reconstruct what happened without relying on anyone's memory, and protected so that it cannot quietly be altered after the fact. This is also where POPIA intersects: changes to beneficiary banking details are a common fraud vector, so those changes in particular deserve logging and ideally a second-person check.

Requirement 5: Reporting your auditor and clients can rely on

Reporting is where the trust account proves itself to the outside world. At a minimum, the software should produce per-beneficiary statements (what a landlord, owner or scheme is owed and was paid), a trust position summary, and an audit pack you can hand to your auditor without rebuilding it by hand in a spreadsheet.

Exportability matters as much as the on-screen view. Auditors generally want to test underlying data, so the ability to export ledgers, reconciliations and supporting documents in usable formats shortens the annual trust audit and reduces its cost. The same reports double as transparency for your clients — a landlord who can see a clear, reconciled statement is a landlord who trusts you with their money.

Requirement 6: POPIA, access control and security

Trust software holds sensitive personal and financial information about owners, tenants, schemes and beneficiaries, so the Protection of Personal Information Act applies to it. That makes security and access control part of the trust-accounting requirement rather than a separate IT concern. Require role-based permissions so that only the right people can move money or change banking details, and so that view-only roles cannot quietly alter records.

Ask practical questions: where is the data hosted, how is it secured, who can see beneficiary bank details, and how long is data retained. For South African practitioners, data residency and a clear retention position are increasingly part of a defensible answer. Align whatever the vendor offers to your own POPIA obligations, and confirm the specifics rather than assuming.

How to evaluate a tool before you trust it with client money

Treat selection as a controlled test, not a demo you watch passively. Use real-looking data and try to break the controls: attempt to over-pay a landlord, attempt to pay an operating cost from trust, change a beneficiary's bank details, then check whether the system blocked, warned or simply logged it. Run a reconciliation and force it out of balance to see how clearly the tool tells you.

Then look downstream. Generate the audit pack and per-beneficiary statements and ask whether your auditor would accept them. Confirm how deposits and interest are configured against the Rental Housing Act and your leases. Compare approaches — how different systems enforce separation, reconcile and log — rather than comparing brand names, because the controls are what protect you. Regalis is designed to support these trust-accounting requirements for managing agents, schemes and rental portfolios; whichever route you choose, verify the controls against the current legislation and seek professional advice on your specific obligations.