ProofRelay
All guides

A bookkeeper's guide to stopping client payment fraud

6 min readUpdated 31 July 2026

When a client pays a fraudulent invoice, the loss is theirs — but the first question is yours. You process their payables, you saw the invoice, and "didn't you check?" arrives in your inbox, not the attacker's. Fair or not, a bookkeeping firm sits exactly where the blame lands.

This guide is written for practices that pay suppliers on behalf of clients, or prepare the payment runs their clients release. It is most pointed for firms with building and construction clients, because that is where the attack works best — but the mechanics apply to every client on your list.

Why your builder clients are the exposed ones

Payment-redirection fraud needs one thing to work: a change of bank details that does not look strange. In most industries a supplier changing their account is rare enough to be a small event. In construction it is routine — new entities between jobs, factoring arrangements, a different account for a different site. Subcontractors genuinely do this all the time.

Add the rest of the shape: progress claims arriving by email as attachments, on a predictable monthly cycle, in batches large enough that no single line gets attention, under timeframes that make delay expensive. A fraudulent change request in that environment is not fighting your client's suspicion. It is joining a queue of legitimate ones.

In most industries a changed bank detail is a surprise, and the surprise is the safety. For your builder clients it is routine — so the safety has to come from verification, not from surprise.

Yes — you could do all of this by hand

Nothing in payment-detail verification is secret. The patterns are published by the ACSC and every bank; the checks are things a careful person can do with a phone and a browser.

  • Read the sender's address character by character, not just the display name your mail client shows.
  • Call the supplier on a number from your own records — an earlier invoice, their website typed in yourself — never a number in the email asking for the change.
  • Look the ABN up on abr.business.gov.au and compare the registered name against the invoice. A listing tells you the ABN exists and who holds it — it does not tell you who sent the email.
  • Compare the account against what you actually paid this supplier last time, from your own accounting file rather than from the document in front of you.
  • Have a second person approve the payment — someone other than whoever handled the email.
  • Write down what was checked, by whom, and on which number, so the answer to "did anyone verify this?" is a record rather than a memory.

The attack does not beat this checklist. It beats the afternoon the checklist was skipped — BAS week, a claim deadline, a Friday run, the one line in forty nobody read twice. Vigilance is a property of people. A control is a property of a system.

The four things hand-checking cannot give you

Suppose your practice genuinely did every check above, on every payment, for every client. Four gaps remain, and they are precisely the ones attackers use.

Eyes. Some lookalike domains are built so that careful reading fails. An internationalised domain can render as ordinary text while being encoded from another alphabet entirely — visually identical, mechanically unrelated. A domain one character from the real one is engineered to survive exactly the character-by-character read you are relying on.

Memory. The account your client's organisation rejected as fraudulent in March does not announce itself when it reappears in July under a different supplier's name. No one doing a manual check remembers a BSB and account pair across four months of payment runs — and the same account claimed by two different suppliers is one of the strongest signals there is.

Enforcement. A written procedure says the person who received the email should not approve the payment. On the busiest afternoon of the month, a procedure is a suggestion. A control enforced by the system — where the requester cannot verify or approve their own request, mechanically — does not have busy afternoons.

The record. When a client, their insurer, or a liquidator asks whether a payment was verified, "we are always careful" is not an answer. A tamper-evident record showing who verified what, when, against which pre-established phone number, is. For a professional practice the record is not the by-product of the control — it is most of the value.

Why this works better run by a firm than by any single client

There is a structural reason a bookkeeping practice is the right place for this control, beyond convenience: separation of duties needs two people, and many of your clients do not have two people.

A sole-trader builder cannot both request and approve a payment change with any meaning — a control one person satisfies alone is theatre, and it is why serious verification workflows refuse to pretend otherwise. But a builder plus their bookkeeper is two people. The firm handles the change request and the verification call on a pre-established number; the client, who knows the subcontractor personally, gives the approval. Each client keeps their own supplier records, their own policies and thresholds, and their own audit trail; your practice keeps one view across all of them, ranked by what actually needs attention today.

That division — firm verifies, client approves — is not a workaround. It is the control working as designed, and it is something a practice can offer that no software alone, and no client alone, can.

Where to start, without boiling the ocean

Do not begin with your whole client list. Begin with the two clients whose payment runs would scare you most if a line went wrong — usually the builders, usually the ones with the biggest single payments and the most supplier churn.

Load their suppliers with the account details you already trust, from your accounting file, and establish now — by phone, while nothing is urgent — the number you will call when details change. The point of doing this early is that it removes the moment the attacker is waiting for: the pressured change request with no baseline to compare against.

Then make one rule stick, for clients and staff alike: any email that changes payment details gets logged and checked, never actioned from the inbox. Every check ends the same way regardless of what any tool found.

Call the supplier on a number you already had — from an earlier invoice, their website that you navigated to yourself, or your own records. Never a number written in the email or invoice you are checking. The person who wrote that document chose that number.

Common questions

Can't we just call the supplier ourselves and skip the software?

The call is the control — nothing replaces it, and any tool that claims to has misunderstood the problem. What a system adds is making sure the call actually happens on every change, to a number established before the pressure started, by someone other than whoever received the email, with a record that it was done. The failure mode of manual verification is not that anyone doubts the call matters; it is the week nobody made it.

Is a bookkeeper liable when a client pays a fraudulent invoice?

It depends on your engagement terms and the facts, and it is frequently disputed — which is exactly why records matter. A practice that can show a documented verification process was followed is in a very different position from one relying on recollection, both with the client and with its own professional indemnity insurer. Ask your broker specifically whether social engineering losses are covered, and take proper advice on your own terms of engagement.

Our clients are on Xero or MYOB — does this replace the accounting file?

No, and it should not try. The accounting file records what was paid; a verification workflow controls whether a changed payment detail is checked before anything is paid. Supplier details can be loaded from a CSV export of the accounting file, and the decision record is kept alongside it, not instead of it.

Won't verifying every change slow down payment runs?

Only the exceptions, and only briefly. Details that have not changed are not re-verified — the check runs on changes and firsts, which for most clients is a handful of events a month. Approve the work on time, verify the account in parallel, release when both are done. Against one redirected progress payment, it is not a close comparison.

Check the invoice in front of you

Paste it into the free checker and it will run every structural check on this page in about a second — the ABN, the bank details, the sender's domain and the wording. No account, and nothing you paste leaves your browser.

Check an invoice

Related guides