Beyond Cyber: Spotting Financial Red Flags in Supplier Billing and Procurement Processes

An email arrives from a supplier you've paid a dozen times, asking to update their bank details. The logo matches. The invoice number follows the sequence. Only the BSB and account number are new.

This isn't a sophisticated cyber breach; it's a process failure exploited at scale. Modern accounts payable teams process hundreds of invoices weekly, relying on routine checks that fraudsters know how to mimic. The vulnerability lies not in the technology, but in the human-operated gateways designed for efficiency, not adversarial scrutiny.

The fraud succeeds not because the deception is invisible, but because the process invites trust. Accounts payable clerks, under pressure to clear queues treat familiarity as verification. A changed BSB slips through when the eye expects continuity, not sabotage. This is the flaw in high-volume, low-friction processing: efficiency becomes the exploit.

The Anatomy of a Payment Scam: Beyond Phishing

The fraud begins not with a hack, but with a request that mirrors routine supplier communication. An email arrives from a known vendor’s address, referencing a current invoice number and requesting an update to banking details due to an internal accounts restructure. The message is polite, lacks urgency, and contains no suspicious links or attachments—only a new BSB and account number.

What follows is a test of process, not perception. The accounts payable clerk checks the invoice number against the open items ledger, confirms the supplier name matches the master file, and notes the request aligns with the expected payment cycle. No red flags are triggered because the deviation is microscopic: a single transposed digit in the account number, or a BSB shifted by one branch, both of which remain valid under the bank’s formatting rules.

Standard controls fail here because they rely on surface-level validation—matching names, numbers, and dates—without verifying the authenticity of the change request itself. In environments processing hundreds of invoices weekly, this subtle manipulation exploits the very efficiency meant to streamline payments, turning routine verification into a point of silent compromise.

The deception often begins not with a forged email, but with a compromised supplier portal or a lookalike domain registered weeks in advance—accounts-payable-update[.]net mimicking the genuine supplier’s subdomain. The attacker monitors payment cycles, waiting for the moment a legitimate invoice is due, then sends the change request from an address that passes casual visual inspection: the display name is correct, the email header lacks obvious spoofing tells, and the request references a real, outstanding invoice pulled from public tender notices or delayed supply chain disclosures.

What makes this particularly effective against small-to-midsize businesses is the asymmetry of effort: crafting one convincing change-of-bank-details request takes under an hour, while the target’s AP team may spend seconds per invoice under pressure to clear queues. A single transposed digit—062-000 becoming 062-001—or a BSB shifted from 012-345 to 012-354—creates a destination account that clears formatting checks but diverts funds. Standard ERP validations (modulus checks, length verification) pass because the numbers are structurally sound; they do not, and cannot, confirm intent or ownership.

The fraud succeeds not because controls are absent, but because they are misplaced. Verification often happens too late—after payment is initiated—or relies on the same compromised channel: an email reply to the attacker’s address. Even when a callback is attempted, fraudsters frequently provide a legitimate-sounding phone number, answered by a co-conspirator or a VoIP line ready to confirm the fake details. This creates a closed loop of deception where every step the victim takes to feel secure actually reinforces the scam.

Small businesses are disproportionately exposed not due to negligence, but resource constraints. Without dedicated fraud analysts or segregated duties, the same person who enters the invoice may also approve the payment and reconcile the bank statement. A single transposed digit in a BSB—063-000 becoming 063-001—can siphon tens of thousands before month-end close, and recovery is rare once funds leave Australian jurisdiction. The attack exploits the very efficiency AP teams are praised for: speed and trust in routine.

Hardening the Gateways: Mandating Multi-Layered Verification

Stop relying on a single verification touchpoint. A phone call to a number supplied in the fraudulent email is not a control—it is a ritual that confirms the attacker’s narrative. Effective defence requires layered, independent checks: one person enters the change request, a second, segregated officer approves it only after matching the new banking details against the immutable vendor master record held in the ERP, and a third party—often in treasury—confirms the match before the payment file is released.

This tripartite separation disrupts the fraudster’s closed loop. The attacker cannot compromise all three channels simultaneously without detection, and the process forces reliance on pre-vetted, internally held data—not the potentially spoofed communication attempting to override it. Crucially, this shifts verification from reactive (did we pay the right account?) to proactive (does this change align with our trusted source of truth?).

The segregation of duties must be codified, not suggested. A procurement officer who approves a banking detail change without verified cross-reference to the ERP vendor master record is not merely negligent; they may be breaching their duty of care under general corporate governance principles, potentially exposing themselves to personal liability if the payment flows to a fraudulent account and the company suffers loss. Courts increasingly scrutinise whether officers took reasonable steps to prevent foreseeable financial harm, and reliance on email alone fails that test.

Implementing this control is not burdensome. The average time to detect fraud after payment exceeds two days, during which funds are often irrecoverable. In contrast, embedding a mandatory dual-control check—where one officer enters the change and a second, independent officer verifies it against the pre-vetted vendor record—takes approximately eight minutes at the point of entry. This tiny time investment creates a verifiable audit trail and shifts liability away from the individual processor by demonstrating adherence to a defined, reasonable process.

Beyond the dual-signature requirement, the verification step itself must be anchored to an immutable source. Cross-referencing a change-of-bank-details request against the vendor master record in the ERP is necessary but insufficient if that master record was itself compromised during onboarding. The control loop requires validating the new banking details against a primary source—such as an official bank confirmation letter or a verified ABA directory entry—before updating any internal system. This breaks the cycle where fraudulent details entered at onboarding propagate through every subsequent payment change.

Consider a scenario where a supplier’s legitimate banking details are intercepted and altered via email spoofing. If the AP team’s only check is comparing the new details to the (already fraudulent) vendor record in the system, the control is circular and useless. Mandating verification against an external, trusted source—even for low-value, high-frequency suppliers—creates a break-glass moment that forces human judgment and documentation. The eight-minute dual-control check gains its integrity only when the second officer’s task includes this external validation, transforming a procedural step into a substantive fraud barrier.

Procedural hardening begins with decoupling verification from the change request itself. A dual-sign-off matrix requires one officer to initiate the bank-detail update based on the supplier’s communication, while a second, independent officer must confirm the change against a pre-vetted vendor record and an external source such as the bank’s ABA directory or a signed letter on bank letterhead. This is not a redundancy; it is a sequence where the second officer’s task is substantively different—validating origin, not replicating input.

The legal exposure for procurement officers arises not from the payment error itself but from failing to exercise reasonable care in the procurement process. Under general corporate governance principles, approving a payment based on unverified banking details may constitute a breach of the duty of care if it results in avoidable financial loss, particularly where standard controls like dual verification were bypassed or inadequately documented.

Uncommon Insights

Regulatory gaps are not just loopholes; they are often designed pathways exploited by fraudsters who weaponise speed. A supplier can obtain an ABN and register for GST in under 24 hours via the Australian Business Register, creating a veneer of legitimacy that bypasses traditional vendor onboarding checks reliant on historical trading data or credit reports. This rapid establishment allows fraudsters to pose as high-growth startups, exploiting procurement teams' desire to onboard innovative suppliers quickly, while avoiding deeper scrutiny that would require weeks of verification.

The signing officer’s liability extends beyond recovering misdirected funds. Under general corporate law principles, approving a payment to a vendor with unverified, rapidly established credentials may breach the duty of care if it fails to meet the standard of a reasonably diligent officer in the same position. This is particularly acute when standard due diligence—such as confirming the entity’s duration of registration or cross-referencing the ABN with active GST status—is omitted in favour of expediency, turning procedural haste into legal exposure.

Beyond the ABN, the GST registration timeline itself becomes a tactical tool. Fraudsters often time their invoice submissions to coincide with the 28-day window after GST registration, when the ATO’s systems may still reflect a 'pending' or 'recently added' status that basic ABN lookups do not flag as anomalous. This creates a dangerous blind spot: procurement systems showing a valid GST registration may inadvertently validate an entity that has only existed for weeks, yet lacks any operational history, physical premises, or verifiable supply chain — critical gaps that standard KYC protocols fail to interrogate when speed is prioritised.

The liability exposure intensifies when payment approval hinges solely on matching an invoice to a purchase order, without validating the vendor’s ongoing operational legitimacy. Courts have increasingly recognised that the duty of care under corporate governance requires officers to make enquiries that are proportionate to the risk — and a payment to a vendor registered fewer than 30 days prior, especially for atypical goods or services, demands scrutiny beyond a PO match. Ignoring this escalation of risk transforms administrative convenience into a breach of the diligence expected of a reasonable officer, exposing signatories to personal liability for negligent approval under general common law principles, not just statutory penalties under the Corporations Act.

Consider the scenario where a vendor’s ABN shows active GST registration, yet their BAS lodgements consistently report zero taxable supplies for consecutive quarters. This pattern—maintaining registration while declaring no commercial activity—is a recognised loophole exploited to create the facade of legitimacy for shell entities used in invoice fraud. Standard onboarding checks that merely confirm an ABN is ‘registered for GST’ fail to interrogate the substance behind the registration, allowing payment approvals to proceed on the basis of a technical compliance that masks operational absence.

The legal peril for approving officers arises not from the fraud itself, but from the failure to apply proportionate enquiry. When a payment is made to an entity with a freshly minted ABN and a history of nil BAS lodgements, especially for high-value or atypical goods, the signing officer’s reliance on a PO match alone may be deemed insufficient under the objective standard of care. A court could reasonably expect enquiries into the vendor’s operational footprint—such as verifying physical premises, seeking trade references, or confirming the legitimacy of the goods/services described—transforming a routine approval into a potential breach of duty that attracts personal liability for negligent misstatement or reckless indifference, independent of any criminal fraud finding against the vendor.

This is where the 'rapid growth' narrative becomes a weapon: fraudsters incorporate entities with ABNs obtained in days, lodge minimal or nil BAS statements to avoid scrutiny, and present themselves as agile startups securing their first major contracts. Standard KYC processes, calibrated for established suppliers, often flag nothing amiss—the ABN is valid, the GST registration is active, and the entity passes automated checks. The gap lies in the absence of any requirement to prove substantive trading activity; regulators assume registration implies operation, creating a permissive environment for shell companies to invoice for goods or services they never had the capacity to deliver.

For the approving officer, liability attaches not when the fraud is discovered, but when the payment is authorised on inadequate grounds. Relying solely on a valid ABN and a PO match—without seeking evidence of operational substance such as a physical business address, verifiable trade references, or consistency in the scope of goods/services relative to the vendor’s stated capacity—fails the objective test of due care. Courts have held that signing officers must inquire into whether the vendor is merely a paper entity, especially when the transaction is anomalous or high-value, transforming a routine approval into a breach of duty that exposes the officer to personal liability for negligent misstatement, irrespective of any criminal outcome against the fraudulent vendor.

Vendor Onboarding as a Control Point

Vendor onboarding is where payment fraud is stopped or enabled—not at invoice processing, but at the moment a supplier is first entered into the master file. Treating this as a clerical exercise assumes that a valid ABN and GST registration equate to operational legitimacy, a gap exploited by shell entities that invoice for non-existent goods. The control point must shift from administrative checklist to substantive risk assessment, requiring evidence that the vendor actually trades, not merely exists on paper.

Mandatory verification begins with proof of ASIC registration status, but cannot end there. Banking details must be confirmed against primary source documents—such as a bank-issued letter or verified ABA file—not supplied invoices or email attachments. Cross-referencing the ABN with the ATO’s ABN Lookup for active GST status adds a layer, yet still does not prove substance. The non-bypassable step is documented verification of trading activity: recent BAS lodgements, verifiable trade references, or a physical business address consistent with the vendor’s claimed capacity to deliver.

The failure point often lies in accepting vendor-supplied documentation at face value. A bank statement or invoice header showing the correct BSB and account number is insufficient; these can be forged or altered with minimal effort. True verification requires initiating a confirmation directly with the financial institution using independently sourced contact details—such as the bank’s published customer service number for business accounts—not the phone number or email provided by the vendor. This mirrors the process used for confirming large trade finance instruments and shifts the burden from passive receipt to active validation.

For under-resourced or newly established suppliers, the threshold for acceptable proof must remain high but pragmatic. A statutory declaration from the vendor’s director confirming banking details, witnessed by a Justice of the Peace or solicitor, provides a legally enforceable record that can be relied upon in recovery efforts. Coupled with a search of the ASIC Connect register to confirm the entity’s current status and officeholders, this creates a layered defence that is difficult to circumvent without leaving a traceable trail of misrepresentation.

This verification must occur before any payment is authorised, with results documented and retained for the duration of the commercial relationship plus the statutory limitation period. Treating onboarding as a one-off administrative task—completed once and never revisited—creates a persistent vulnerability where changes to ownership, structure, or banking details go undetected until funds are misdirected.

The control point is not merely collecting documents; it is actively challenging their authenticity through independent verification. For CFOs, this means embedding onboarding checks into the payment workflow as a gatekeeper function, not a back-office formality. Only when the vendor’s identity and banking details are confirmed against authoritative sources can the procurement process proceed with reasonable assurance against fraud.

Key Takeaways

Mandate an immediate audit of all payment change requests processed via email in the last 30 days, flagging any instance where banking details were updated without concurrent verbal confirmation using a pre-registered phone number on file.

Require dual sign-off for any new vendor payment or banking detail change, with one approver independently verifying the request against the ASIC Connect register and a recent bank statement or voided cheque supplied directly by the vendor.

• Audit all email-sourced banking detail changes from the past 60 days — cross-reference each against the vendor’s pre-registered contact file and flag any update lacking a concurrent verbal verification via known phone number.
• Enforce mandatory dual approval for new vendor setup and payment detail amendments — one approver must validate the request against the ASIC Connect register and a contemporaneous bank document supplied directly by the vendor, not via email.
• Block all payments to vendors lacking verified ABN/ACN status in the last 90 days — trigger an automatic hold in the ERP until current ASIC extract and bank account ownership confirmation are uploaded and reviewed.