Trust accounting software development, from the ledger up.
I led the architecture of Homtrust, a multi-tenant trust accounting platform that Australian agencies use to hold and account for client money. If you’re building or rebuilding trust accounting software, I’ll design the ledger, bank feeds and reconciliation with you and build the critical parts myself.
Remote across Australia and New Zealand. On-site in South East Queensland.
Who this is for
Proptech and fintech teams whose software holds other people’s money in trust.
Trust money isn’t the business’s money. Australian real estate trust accounts are regulated state by state, and auditors expect every receipt, transfer and disbursement to be traceable and to reconcile with the bank. Software that’s mostly right isn’t good enough: a retried request that debits twice, or a report that disagrees with the ledger, is a compliance problem, not just a bug.
- You’re adding trust accounting to a property management or real estate platform and don’t want to learn ledger design the hard way.
- Your trust accounting runs on a legacy system and you’re planning a rebuild or a migration.
- Reconciliation is still partly manual, and month-end takes longer every month.
- You’ve had a balance that didn’t add up, a duplicated payment or a reversal that made things worse, and want to know why.
- An audit is coming, and you’re not sure the system can show where every cent came from and where it went.
What I design and build
The core that everything else in a trust accounting product depends on.
The ledger
A double-entry ledger with accounting periods, reversals instead of edits, and charge and fee rules, modelled on the trust domain rather than bolted onto an invoices table.
Money movement that’s safe to retry
Receipts, transfers and withdrawals guarded by idempotency keys, unique constraints and transactional posting, so a double-submit or a crash can’t double-debit an account.
Bank feeds and reconciliation
CDR / Open Banking feeds with per-account consent, matching bank transactions to ledger entries automatically and putting only the exceptions in front of a person.
Disbursements and reports
Disbursement batches, bank payment files, owner statements and trial balance, all derived from the ledger so the numbers agree everywhere they appear.
Multi-tenant architecture
Data separated per agency or enterprise with schema-per-tenant PostgreSQL, and heavy ledger processing run asynchronously on AWS so it never slows the app down.
How a build runs
Usually a design and build engagement: I own the architecture and build the critical core alongside your developers.
Map the money
A working session on which accounts exist, what moves between them, the rules your state and your customers impose, and what an auditor needs to see.
Design the ledger
I design the ledger, the posting rules and the data model, and write the decisions down so your team can question them before any code exists.
Build the core
I build ledger posting, idempotency and reconciliation myself, with your developers pairing on it from the first day.
Integrate and test the failures
Bank feeds, payment files and reports, with tests for the cases that matter in trust accounting: retries, duplicates, partial outages and period close.
Hand over
Your team owns the code and understands why it’s shaped the way it is. I can stay on as a fractional architect if you want a senior eye on it.
Already have a trust accounting system that worries you? An architecture review focused on the ledger and reconciliation is often the right first step. Architecture review
The platform behind this page
Everything on this page comes from building Homtrust, not from reading about it.
Trust accounting SaaS platform
From 2023 to 2026 I was solution architect and project lead on Homtrust, and owned its double-entry ledger.
- Domain-driven GraphQL API on schema-per-enterprise PostgreSQL, with ledger posting, bank feeds and reporting running asynchronously on AWS.
- Owned the double-entry ledger, with ACID online mutations and dedicated ledger processors with dead-letter handling.
- Idempotency keys and unique constraints so a double-submit or crash can never double-debit a ledger.
- CDR / Open Banking bank feeds with per-account consent and automated reconciliation.
- TypeScript
- NestJS
- GraphQL
- PostgreSQL
- MikroORM
- AWS CDK
Questions I’m often asked
Do you sell trust accounting software?
No. I’m an independent architect and developer. I help you build or fix your own software, and I have no product to sell you.
Do you know the trust accounting rules for my state?
I’ve built for Australian property trust accounting, covering rent, bonds and sale proceeds. I work alongside your compliance adviser and auditor on the specific rules for your state rather than replacing them.
Does it have to be your stack?
No. My recent ledger work is TypeScript, NestJS and PostgreSQL on AWS, but the design carries over to any stack with real database transactions.
Other ways I help
Building or fixing trust accounting software?
Tell me where the product is today and what has to be true for your customers and their auditors. I’ll tell you where I’d start.