Client Money in Australia: A Practical Flow That Auditors Don’t Tear Apart

Designing a clean client money flow in Australia isn’t hard because of the bank account setup—it’s hard because small operational “shortcuts” (mixed funds, weak narratives, missing evidence) compound until your auditor can’t follow the money. The goal is simple: every dollar has a clear purpose, a clear owner (client vs firm), and a repeatable daily process that proves it.

Below is a practical, audit-survivable blueprint you can adapt with your legal/compliance advisers (requirements can vary by licence type, product set, and banking arrangements, and rules change).

1) Start with a “money map” before you open accounts

Before you touch banking, write a one-page money map that defines where funds come from, where they can go, and what must never happen. Audits go smoother when your operations, finance, and compliance teams all reference the same map.

Your money map should define:

• Money types: client money (trust), firm money (operating), fees/commissions, chargebacks, refunds, and “suspense” items.
• Events: deposits, withdrawals, internal transfers, trading P&L movements, swap/commission postings, fees, and adjustments.
• Systems of record: trading platform ledger, CRM wallet/ledger, PSP reports, bank statements.
• Cut-off times: daily reconciliation cutoff (e.g., 5pm AEST) and how you treat late-arriving PSP settlements.

Practical tip: include 2–3 “never events” in writing (e.g., “No operational expenses paid from trust,” “No netting of client withdrawals against firm receivables,” “No manual journal without second approval”). Those become your control anchors.

2) Trust accounts and segregation: design for clarity, not convenience

In Australia, the cleanest operational posture is to separate client money from firm money at the bank level and then enforce segregation again inside your ledgers.

A common, audit-friendly account structure looks like:

• Client Money Trust Account (primary): the default landing zone for client funds.
• Client Money Trust Account (secondary / buffer): optional, used for operational continuity or product segmentation (only if your policy explains why).
• Operating Account: company expenses, vendor payments, payroll.
• Fee/Revenue Collection Account (optional): where firm fees are swept after they are properly due and documented.

Segregation isn’t just “different accounts.” It’s also rules about movement:

• Client deposits should land in trust (directly, where possible).
• Any transfer out of trust must have a defined reason, evidence, and approval.
• If you must use PSP/merchant accounts as an intermediate step, document the settlement path and timing and treat the PSP balance as part of your reconciliation scope.

Operational reality: some payment rails settle into merchant/PSP accounts first. That’s fine—but you need a documented “bridge” process that shows when and how those funds become client money in trust.

3) Build your ledger model: every balance must reconcile three ways

Auditors don’t just want a bank balance that “looks right.” They want a ledger model where client entitlements are provable.

A robust setup uses three aligned views:

1. Bank view: trust bank statement balance (plus/minus timing items).
2. PSP view: processor settlement reports, chargebacks, rolling reserves, and pending payouts.
3. Client ledger view: per-client wallet balances (your CRM/backoffice ledger), mapped to the trading platform where relevant.

Key design choices that reduce audit pain:

• Keep a client sub-ledger: each client has a balance with a clear transaction history.
• Use standard transaction codes (deposit, withdrawal, fee, correction, chargeback, reversal). Avoid free-text as the primary classification.
• Separate posted vs pending states. Pending items must age and resolve, not sit forever.

Example: if a card deposit is accepted at 3:58pm but settles T+1, your ledger should show it as “pending” (or “cleared”) based on your policy, and your daily reconciliation should explicitly list it as a timing item.

4) Daily reconciliation that survives audit: a repeatable checklist

Daily reconciliation is less about math and more about discipline and evidence. Your process should be consistent, time-boxed, and reviewable.

A practical daily checklist:

• Step 1 — Lock the cutoff: define the day’s reconciliation window and export all required files (bank statement lines, PSP reports, CRM ledger, platform ledger).
• Step 2 — Reconcile deposits: match bank/PSP credits to client ledger credits (by reference, amount, date, payer, and payment ID).
• Step 3 — Reconcile withdrawals: match approved withdrawals to bank debits/PSP payouts, including status (requested → approved → paid).
• Step 4 — Identify timing items: unsettled PSP batches, bank processing delays, pending chargebacks, FX conversion delays.
• Step 5 — Prove segregation: confirm trust bank balance (adjusted for timing items) covers total client ledger balances (and any other defined obligations).
• Step 6 — Exceptions log: record breaks, root cause, owner, and expected resolution date.
• Step 7 — Second-person review: a reviewer signs off (not the preparer). Keep the evidence.

What “survives audit” is the trail: exports, matching logic, exception handling, approvals, and sign-offs—every day, not only month-end.

5) Controls auditors look for: approvals, narratives, and “break” hygiene

Most audit issues aren’t fraud—they’re uncontrolled exceptions. Put controls where money moves and where humans can override systems.

Controls that typically matter:

• Maker-checker on withdrawals and manual adjustments (two-person rule).
• Role-based access for ledger edits, bank uploads, and PSP dashboard permissions.
• No silent edits: adjustments require a reason code, ticket link, and immutable audit log.
• Chargeback workflow: clear states (received, represented, lost/won, recovered) and mapping to the client ledger.
• Aging policy for breaks: e.g., anything >2 business days escalates; >5 days requires compliance sign-off.

Also ensure your “narrative” is consistent. If your policy says “fees are charged monthly,” but you sweep fees ad hoc, you create an audit mismatch even if the numbers net out.

6) Common failure modes (and how to design them out)

If you want an audit-resilient flow, design around the failure modes you’ll inevitably see in payments operations.

Typical pain points:

• Third-party deposits: funds coming from a different name than the client. Decide upfront how you handle them (reject, hold, enhanced checks) and document it.
• Partial settlements: PSP settles net of fees or in multiple tranches. Your reconciliation must handle net/gross logic consistently.
• Rolling reserves: funds withheld by PSPs. Treat reserves explicitly as timing items with a schedule.
• FX conversions: if you accept multi-currency deposits, define where conversion happens (PSP, bank, internal) and what rate source is used for ledger posting.
• Manual “quick fixes”: backdating, deleting ledger lines, or “parking” items in suspense without ownership.

Design-out tactics:

• Standardize references (payment ID carried from PSP → CRM → bank narrative where possible).
• Automate matching for the easy 80%; keep a controlled exception queue for the rest.
• Enforce mandatory fields on adjustments (reason code + attachment + approver).

7) How Brokeret supports an audit-friendly client money operation

Technology won’t replace policy, but it can enforce consistency—especially when volume grows and exceptions multiply.

In a Brokeret-style operating model, the goal is to make client money controls native to daily workflows:

• Wallet/ledger discipline inside the CRM: consistent transaction types, statuses, and immutable audit logs.
• Deposit/withdrawal operations: configurable approval flows, role-based permissions, and clear state transitions.
• PSP and platform integrations: unify identifiers so reconciliation isn’t a spreadsheet-only exercise.
• Reporting for finance and compliance: daily exception lists, break aging, and evidence packs that auditors can follow.

Even if you run parts of the process outside the CRM today, defining the data model (IDs, statuses, reason codes) now will save you months later when you scale.

The Bottom Line

An Australian broker client money flow that survives audit is built on three things: clean segregation (bank + ledger), a daily reconciliation with explicit timing items, and controls that prevent “silent” exceptions.

Write the money map, enforce maker-checker where funds move, and keep a daily evidence trail that a third party can replay.

If you want to operationalize this with workflow, ledgers, and reporting in one place, start here: /get-started.