SecurityPolicy.com.au
Home/ Australia/ Policy Library/ Invoice and payment fraud policy
Australia Policy Library Policy template Reviewed 2026-10-27

Invoice and payment fraud policy: a practical guide for Australian businesses

Stop payment-redirection scams: verify bank-detail changes by call-back, use dual approval, spot red flags and know what to do if money goes.

42 of 49 claims verified against 19 primary sources. How we verify →

$166.8m
Payment-redirection losses reported in 2025 (combined National Anti-Scam Centre data)
15%
Business cybercrime reports that were BEC fraud with a financial loss, FY2024-25 (ASD)
$56,600
Average self-reported cost per cybercrime report for a small business, FY2024-25 (ASD)
Within 24 hours
When victims who recovered funds had usually reported to ReportCyber and their bank (AFP, 2023)
Invoice and payment fraud policy.docx
SecurityPolicy.com.auAustralia edition

PUT THIS IN YOUR POLICY

Purpose and scope. This policy protects the organisation's money and the money of its customers and suppliers from invoice fraud, payment-redirection scams and business email compromise. It applies to every employee, contractor, bookkeeper, payroll provider and any other person who can create, approve or release a payment, add a payee, or change supplier, customer or employee bank details. No payment may be made and no bank details may be changed except through the verification and approval steps in this policy, regardless of who appears to be requesting it or how urgent the request appears.

A real clause from this template. Every bracket is a decision you make before you sign it.
Why this guide exists

Australian operators ask most about how to check a supplier's 'new bank details' email, whether the bank will get the money back, and what to do in the first hour after a payment has gone.

What is an invoice and payment fraud policy, and does my business actually need one?

An invoice and payment fraud policy sets the rules your business follows before it pays a supplier, changes a payee's bank details, or acts on an urgent payment request. It targets business email compromise, where criminals use a hacked or look-alike email account to send a genuine-looking invoice with their own bank details, or impersonate the owner to have money moved. ASD's ACSC tells organisations to establish a clear and consistent business process to verify requests involving payments and account changes, and payment redirection was the second-largest scam loss category reported in Australia in 2025. No single Australian law requires every private business to keep a document with this exact title, but any business that pays invoices by bank transfer is exposed, and some certification schemes and insurers now ask for one.

How this differs by situation
  • sole trader or micro business (owner pays every bill) — Dual approval may not be possible; replace it with a mandatory call-back on an independently sourced number and a short cooling-off period before paying any new or changed payee.
  • business with a bookkeeper, accounts team or outsourced payroll — Write the policy so it binds the external bookkeeper or payroll provider too, because they hold the payment and bank-detail change permissions.
  • pursuing SMB1001 Silver or higher — An Australian provider summary of SMB1001:2026 lists an invoice-fraud policy among the Silver documentation; confirm the current requirement against the licensed DSI control list.
PUT THIS IN YOUR POLICY

Purpose and scope. This policy protects the organisation's money and the money of its customers and suppliers from invoice fraud, payment-redirection scams and business email compromise. It applies to every employee, contractor, bookkeeper, payroll provider and any other person who can create, approve or release a payment, add a payee, or change supplier, customer or employee bank details. No payment may be made and no bank details may be changed except through the verification and approval steps in this policy, regardless of who appears to be requesting it or how urgent the request appears.

A model clause — adapt the bracketed decisions to your organisation before you use it.

What must it contain — the non-negotiable sections?

The core of the policy is the rule for changing bank details: no new payee and no change to an existing payee's account is accepted on the strength of an email, invoice or letter alone. Scamwatch tells businesses to stop and check any changes to payee information and to contact the business by phone using a number sourced independently, not the number on the suspicious message. Around that rule, the policy needs scope, payment approval and segregation of duties, red flags, staff reporting, the response when money has moved, roles, records and review. ASD's ACSC also expects email account protections (multi-factor authentication) and email authentication (SPF, DKIM and DMARC) to sit alongside the business process.

How this differs by situation
  • business that receives payments from customers — Add an outbound section telling customers how you will and will not notify them of bank-detail changes, because criminals also impersonate you to your customers.
  • business paying staff wages — Cover employee bank-detail change requests; ASD's ACSC names requests to change a worker's banking details as a common impersonation method.
  • business using accounting software with supplier portals or eInvoicing — Record which channel is authoritative for bank details, and still verify any change made outside that channel.
PUT THIS IN YOUR POLICY

Verifying new payees and bank-detail changes. A request to add a payee or change any bank, BSB, account, PayID or remittance detail must not be actioned on the strength of an email, invoice, attachment, text message or letter. Before the change is saved, a person other than the one who received the request must call the supplier, customer or employee on a phone number taken from an independent source, such as a previously verified record, a signed contract or the organisation's official website, and never from the request itself. The caller must confirm the change with a known contact, record the date, time, number called, person spoken to and outcome, and attach that record to the change. Unverified requests must be refused and reported under this policy.

A model clause — adapt the bracketed decisions to your organisation before you use it.

What does the law or a framework require here — and how fast?

For most businesses the expectation comes from guidance and frameworks rather than a statute: ASD's ACSC asks for a verified payment process, MFA and email authentication, and an Australian provider summary says SMB1001's Silver level includes an invoice-fraud policy. The Scams Prevention Framework Act 2025 is real law, but it places obligations on regulated sectors (initially banks, telcos and digital platforms), not on ordinary businesses; ASIC says most obligations commence on 31 March 2027. Small businesses with fewer than 100 employees and under $10 million turnover are among the people the framework protects. The hard clock that can apply to you is privacy: if a business email compromise exposes personal information and you are covered by the Privacy Act, you must take reasonable steps to assess a suspected eligible data breach within 30 calendar days.

How this differs by situation
  • APP entity covered by the Privacy Act 1988 — A compromised mailbox often holds customer or staff personal information; the NDB assessment and notification steps can apply on top of the fraud response.
  • under 100 employees and under A$10m turnover — Counts as a 'small business operator' under the Scams Prevention Framework Act 2025, so it sits among the SPF consumers that banks' future obligations are designed to protect.
  • SMB1001 Silver and above — A provider summary lists an invoice-fraud policy at Silver; DSI's own text for the 2027 edition is not yet public, so check the licensed control list.
PUT THIS IN YOUR POLICY

Payment approval and segregation of duties. Every payment to a new payee, every payment following a bank-detail change, and every payment above [amount set by the business] must be approved by two authorised people before release: one who prepares or enters the payment and a second who checks it against the verified payee record and supporting documents. The person who verified or saved a bank-detail change must not be the only approver of the first payment to that account. Payment limits and approver lists in the banking platform must match this policy. Where the business has only one authorised person, that person must complete the independent call-back and wait at least [one business day] before releasing the first payment to a new or changed account.

A model clause — adapt the bracketed decisions to your organisation before you use it.

Who owns it, and who has to sign it off?

The owner or director should approve the policy, because it sets payment authority and the losses fall on the business. Day-to-day ownership usually sits with whoever runs finance or accounts, working with whoever manages email and IT, since half the controls are process and half are technical. External bookkeepers, payroll providers and accountants who can change bank details should formally acknowledge the policy. ASD's ACSC specifically points to the finance, human resources and senior executive teams as targets, so those people need named responsibilities rather than a general reference to 'staff'.

How this differs by situation
  • owner-operated business — The owner is approver, policy owner and often payer; name a trusted second person (partner, bookkeeper or accountant) who must be called before any first payment to a changed account.
  • business with an outsourced IT provider — Assign the provider written responsibility for MFA on finance mailboxes, SPF/DKIM/DMARC records and mailbox-rule monitoring.
  • company with a board — The board or a director should approve payment-authority limits and receive reports of attempted and successful payment fraud.
PUT THIS IN YOUR POLICY

Roles and responsibilities. The [owner/director] approves this policy and the payment-authority limits in it. The [finance lead] owns the policy, maintains the list of authorised approvers and the verified payee register, and ensures every bank-detail change and payment follows the required steps. The [IT lead or provider] is responsible for multi-factor authentication on email and banking accounts, email authentication records and alerts for suspicious mailbox activity. Every person who handles invoices, payments or bank details, including external bookkeepers and payroll providers, must read and acknowledge this policy before being given access and must follow it without exception.

A model clause — adapt the bracketed decisions to your organisation before you use it.

How does it actually get used by the team?

In practice the policy is a short set of habits: pause on any change of bank details, call back on a number you already had, get a second approval, and report anything odd. Staff need the red flags in front of them; ASD's ACSC lists an unexpected change of bank details, urgent payments or threats, unusual requests from someone senior, and a sender address that does not quite match. Scamwatch notes that scammers rely on impersonation, urgency and emotion, so the policy must give staff explicit permission to delay a payment even when the 'CEO' insists. Short, scenario-based training on real invoices works better than a once-a-year slide deck.

How this differs by situation
  • accounts payable staff — Give them a one-page checklist and authority to refuse or delay any payment that fails verification, with no penalty for a delay.
  • owner and senior staff — Agree in advance that you will never ask for urgent, secret or out-of-process payments by email, so any such request is treated as a red flag.
  • business in property, conveyancing or trades with large one-off payments — Tell clients at engagement how you will confirm bank details and that you will never change them by email.
PUT THIS IN YOUR POLICY

Red flags and staff reporting. Staff must stop and verify before paying when any of the following occur: an unexpected change of bank details; an urgent payment request or a threat of consequences for not paying; an unusual payment request from someone in authority, including the owner or a director; a request for secrecy or to skip normal steps; an invoice that is unexpected, duplicated or for goods or services not ordered; or a sender address, domain or display name that differs in any way from previous correspondence. No one, regardless of seniority, may instruct staff to bypass this policy. Staff who delay a payment to verify it will be supported. Suspicious requests must be reported to the [finance lead] immediately and must not be answered by replying to the message.

A model clause — adapt the bracketed decisions to your organisation before you use it.

What evidence proves it's real to an auditor or insurer?

The strongest evidence is a trail that shows the policy operating: a verified payee register, a call-back log attached to every bank-detail change, and banking-platform settings that enforce two approvers. Add staff acknowledgements, training records and a log of attempted scams that were caught. On the technical side, keep proof that MFA is enforced on finance mailboxes and banking, and that the domain publishes SPF, DKIM and DMARC records; ASD's ACSC notes SPF and DMARC records are publicly visible indicators of good cyber hygiene. If an incident happens, ASD tells victims to keep the ReportCyber reference number (starting CIRS-) and a record of actions, because banks and insurers may ask for it.

How this differs by situation
  • SMB1001 assessment — Expect to show the approved policy plus evidence it is used, not the document alone; keep dated samples of verification records.
  • business with cyber or crime insurance — Check whether the policy wording requires call-back verification for funds-transfer losses and keep records that show it was done for each change.
  • very small business — A simple spreadsheet or a note on the supplier record in the accounting software, completed every time, is better evidence than an elaborate system used inconsistently.
PUT THIS IN YOUR POLICY

Records and evidence. The [finance lead] must keep, for at least [seven years or the period the business sets], a verified payee register, a verification record for every new payee and bank-detail change, approval records for every payment covered by the dual-approval rule, a register of suspected and attempted invoice or payment fraud, staff acknowledgements of this policy, and training records. The [IT lead or provider] must keep evidence that multi-factor authentication is enforced on email and banking accounts and that the organisation's email domains publish SPF, DKIM and DMARC records. Records must be stored so they cannot be altered without trace and must be available for internal review, assessors and insurers.

A model clause — adapt the bracketed decisions to your organisation before you use it.

How often must it be reviewed — and what triggers an off-cycle review?

Review the policy at least annually and test it, for example by checking a sample of recent bank-detail changes for a completed call-back record. Off-cycle triggers include any attempted or successful payment fraud, a compromised mailbox, a change of bank, accounting software or payroll provider, a new person with payment authority, and changes in bank-side protections. Bank measures are moving: the Australian Banking Association lists Confirmation of Payee as live at participating banks, and Scams Prevention Framework obligations on banks are scheduled to start in 2027, so the review should check how those features fit your process without replacing it. ASD's ACSC guidance itself has been revised, with a new business email compromise recovery page published in September 2026.

How this differs by situation
  • business that has had a near miss — Treat a caught attempt as a free test: review which step caught it and whether any step was skipped.
  • SMB1001 holder — Align the review date with the annual recertification cycle, and re-check against the 2027 edition once DSI publishes it.
  • business changing banks or payment platforms — Re-map approver roles, payment limits and payee-change controls in the new platform before going live.
PUT THIS IN YOUR POLICY

Review and testing. The [finance lead] must review this policy at least once every 12 months and test it by sampling recent bank-detail changes and payments to confirm the verification and approval steps were completed. The policy must also be reviewed within [30 days] after any suspected or actual invoice or payment fraud, any compromise of an email or banking account, a change of bank, accounting software, payroll provider or external bookkeeper, a change in the people authorised to approve payments, or a material change in bank-side scam protections. Changes must be approved by the [owner/director], recorded with a version and date, and communicated to everyone covered by this policy.

A model clause — adapt the bracketed decisions to your organisation before you use it.

The common gaps and red flags?

The most common gap is calling the number printed on the new invoice or email, which reaches the criminal. Others are a single person able to change bank details and release payment, finance mailboxes without MFA, no DMARC record on the domain, and no rule for employee bank-detail changes in payroll. Many businesses also assume an email from a supplier's real address is safe, but ASD's ACSC explains invoice fraud often comes from the supplier's genuinely compromised account. Look-alike domains are another gap: ASD's ACSC suggests registering similar domains and monitoring certificate transparency logs, and it warns that SPF alone has a known weakness that DMARC addresses.

How this differs by situation
  • business on a hosted email service — Ask your provider to enforce MFA on all accounts, alert on new forwarding or inbox rules, and publish SPF, DKIM and DMARC with a monitored policy.
  • business that relies on Confirmation of Payee — A name match helps, but criminals can open accounts in plausible names; keep the independent call-back as the deciding step.
  • business with public staff directories — ASD's ACSC suggests protecting contact details of targeted teams such as accounts, finance and HR from the public.
PUT THIS IN YOUR POLICY

Email and account protections. Multi-factor authentication must be enabled on every email account and on every banking, payroll and accounting platform used to create, approve or release payments. The organisation's email domains must publish Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC) records, with DMARC moved to an enforcing policy once legitimate senders are confirmed. Automatic forwarding of email to external addresses must be blocked or alerted, and new inbox rules on finance accounts must be reviewed. Contact details in a request must never be used to verify that request.

A model clause — adapt the bracketed decisions to your organisation before you use it.

What happens when it's invoked or breached?

If money has gone to a scammer, call your bank immediately on its official number and ask it to stop or recall the transaction; ASD's ACSC and Scamwatch both put this first, and the AFP has said victims who recovered funds had usually contacted ReportCyber and their bank within 24 hours. Then report the cybercrime to ASD through ReportCyber at cyber.gov.au/report, report the scam to Scamwatch, and contact IDCARE for free support. Secure the compromised mailbox (change passwords, sign out all sessions, turn on MFA, remove unknown rules) and warn customers and suppliers who may receive fake requests. If personal information was exposed, start the OAIC eligible-data-breach assessment. Separately, a staff member who skipped verification steps should be handled through the normal disciplinary process, with a focus on fixing the process rather than blame.

How this differs by situation
  • business whose own mailbox was compromised — Your customers or suppliers may be the ones who lose money; ASD's ACSC says to tell contacts quickly and encourage anyone who lost money to call their bank.
  • APP entity covered by the Privacy Act 1988 — Assess whether the compromise is an eligible data breach (likely serious harm, not prevented by remedial action) within 30 days, and notify as soon as practicable if it is.
  • 19 or fewer full-time-equivalent employees — IDCARE's free Small Business Cyber Resilience Service is available to eligible small businesses with a valid ABN.
PUT THIS IN YOUR POLICY

When a payment has gone. If anyone suspects a payment has been sent to a fraudulent account, they must immediately tell the [finance lead], who must call the organisation's bank on its official phone number to request that the payment be stopped or recalled, without waiting for confirmation that fraud occurred. The [finance lead] must then report the incident to the Australian Cyber Security Centre through ReportCyber on cyber.gov.au, record the reference number, report the scam to Scamwatch, and consider contacting IDCARE. The [IT lead or provider] must secure any affected email or banking accounts. Affected customers and suppliers must be warned through a verified channel. The [privacy officer] must assess whether personal information was involved and whether the Notifiable Data Breaches scheme applies. Any breach of this policy will be investigated and may result in retraining or disciplinary action, and the policy will be reviewed.

A model clause — adapt the bracketed decisions to your organisation before you use it.

What's my next step?

  1. Download this template — it's part of the free starter pack.
  2. Nominate a policy owner and an approver.
  3. Complete the bracketed decisions and delete anything that doesn't reflect how your business actually operates.
  4. Compare the wording against your real systems and practices before you sign it.
  5. Get it approved and set a review date, normally within 12 months.

Get the starter pack

Common misconceptions

These are things people commonly get wrong — the statement itself is the myth, not the fact.

  • An invoice that comes from the supplier's real email address must be genuine. confirmed myth

    This is a misconception, not the fact — see the guide above and the sources appendix below for what actually applies.

  • If we pay a scammer by mistake, the bank will get the money back. confirmed myth

    This is a misconception, not the fact — see the guide above and the sources appendix below for what actually applies.

  • Calling the phone number on the invoice or email is a proper verification check. confirmed myth

    This is a misconception, not the fact — see the guide above and the sources appendix below for what actually applies.

  • The Scams Prevention Framework puts the anti-scam obligations on my business. confirmed myth

    This is a misconception, not the fact — see the guide above and the sources appendix below for what actually applies.

  • Setting up SPF, DKIM and DMARC on our domain stops fake invoices reaching us. likely myth

    This is a misconception, not the fact — see the guide above and the sources appendix below for what actually applies.

  • Now that banks check the payee name, we no longer need to call suppliers back. likely myth

    This is a misconception, not the fact — see the guide above and the sources appendix below for what actually applies.

Obligations at a glance

The obligations most relevant to this guide, with the regulator, the trigger and the timeframe. Follow the source links in the appendix for the authoritative wording.

OBLIGATION REGULATOR TRIGGER TIMEFRAME PENALTY
NDB suspected eligible data breach assessment Office of the Australian Information Commissioner An entity covered by the Privacy Act 1988 suspects that a business email compromise or payment-fraud incident involved unauthorised access to or disclosure of personal information that may be an eligible data breach. Take all reasonable steps to complete the assessment within 30 calendar days of becoming aware of the grounds for suspicion.
NDB notification of an eligible data breach Office of the Australian Information Commissioner An entity covered by the Privacy Act 1988 has a data breach likely to result in serious harm that remedial action has not prevented. Notify affected individuals and the OAIC; individuals as soon as practicable after preparing the statement for the Commissioner.
Scams Prevention Framework obligations (regulated sectors, not ordinary businesses) ACCC (general SPF regulator and digital platforms), ACMA (telecommunications) and ASIC (banking) Businesses in a designated regulated sector (initially banking, telecommunications and digital platforms) providing regulated services. Ordinary businesses are not regulated entities. Most SPF obligations commence on 31 March 2027; additional obligations expected by the end of 2027.
AFCA membership for SPF regulated entities Australian Securities and Investments Commission Entities subject to the Scams Prevention Framework. Were required to be members of AFCA by 1 September 2026.
SMB1001 Silver invoice-fraud policy (provider summary) Dynamic Standards International (DSI), via licensed certifying bodies A business seeking SMB1001 certification at Silver level or above, as described in an Australian provider's summary of SMB1001:2026 (not DSI's own text). Before assessment for the relevant tier, and maintained for recertification.

Sources

  1. Protecting against business email compromise primary
  2. Recover from business email compromise primary
  3. How to combat fake emails primary
  4. Submit a Report primary
  5. Annual Cyber Threat Report 2024-2025 primary
  6. Business email compromise scams primary
  7. Protect your small business from scams primary
  8. Targeting scams report primary
  9. Scams Prevention Framework Act 2025 primary
  10. Competition and Consumer (Scams Prevention Framework—Regulated Sectors) Designation 2026 primary
  11. Competition and Consumer (Scams Prevention Framework) Rules 2026 primary
  12. Scams Prevention Framework primary
  13. Scam-Safe Accord primary
  14. AFP saves mum and dad business from cyber criminals primary
  15. About the Notifiable Data Breaches scheme primary
  16. When to report a data breach primary
  17. Part 4: Notifiable Data Breach (NDB) Scheme primary
  18. Cyber security and your business primary
  19. SMB1001:2026 changes for Perth businesses (Epic IT provider summary) secondary
Not legal advice

This guide and its templates are a professionally drafted starting point, not legal advice. Your obligations depend on your industry, your contracts and your data. Have a qualified adviser review anything high stakes before you rely on it.

Get this template Get it free