Skip to content
← All insights

What generic accounting software gets wrong about trust funds

Brassica Group · July 21, 2026 · 2 min read

Most property management firms start out on a general-purpose accounting package. It is a reasonable choice: it is inexpensive, everyone’s bookkeeper knows it, and for the first few properties it works.

The point at which it stops working is usually the same. It is the moment you are holding money that is not yours.

The requirement

When you collect rent for a third-party owner or hold a tenant’s security deposit, you are a custodian. Those funds belong to someone else, and in most jurisdictions they carry obligations that operating funds do not:

  • They must be held separately from the firm’s own money.
  • They must be traceable to the specific owner or tenant to whom they belong.
  • The bank balance must reconcile to the sum of individual liabilities, continuously.
  • The separation must survive an examination — meaning it has to be demonstrable, not just intended.

That last requirement is the one that catches people out. A spreadsheet that tracks which portion of a pooled bank account belongs to whom satisfies the intent of separation, but proving it after the fact — for any date in the past — is a different matter.

Where the generic tool falls short

General bookkeeping software models a single business’s books. Custodial accounting needs something it does not have:

Per-beneficiary liability tracking. The trust bank account needs a corresponding ledger of who is owed what within it, maintained transaction by transaction. Bolting this on with classes or tags works until a reconciliation fails and you cannot see which beneficiary is out.

Enforced separation. Nothing in a generic tool stops an operating expense from being paid out of trust funds. The control has to be a habit rather than a rule, and habits fail under time pressure.

Three-way reconciliation. Trust accounting requires the bank balance, the book balance, and the total of individual beneficiary balances to agree. Standard bank reconciliation checks the first two. The third is the one that catches misapplied funds.

Point-in-time defensibility. An examiner may ask what a specific tenant’s deposit balance was on a date two years ago. Answering that from a system with no immutable audit trail means reconstructing it — and reconstruction is not evidence.

What to look for instead

If you are evaluating a change, these are the questions worth asking directly:

  1. Are trust and operating funds separate ledgers, or separate labels on one ledger?
  2. Can the system produce a three-way reconciliation without manual assembly?
  3. Is there a per-beneficiary balance available for any historical date?
  4. Does the audit trail record what a posting looked like before it was changed?
  5. What prevents — not merely discourages — a disbursement from the wrong pool?

A tool that answers these cleanly will feel like more software than you need at ten units. It will feel like the minimum at two hundred.

The underlying point

Trust accounting is not a reporting feature. It is a structural requirement, and structure is difficult to add to a system that was not designed for it. That is why BrassTacks treats it as a property of the ledger itself rather than a module on top — the separation, the per-beneficiary detail, and the audit trail are how the books work, not an option enabled later.

Let’s talk about your portfolio.

Tell us how your portfolio is run today and what isn’t working. We’ll tell you what we’d do about it — whether that’s an engagement, the platform, or a suggestion you can carry out yourself.