# How a fake invoice slips into an accounts-payable queue A step-by-step breakdown of how fraudulent invoices infiltrate accounts-payable workflows, why the standard defences keep failing, and how preset onchain routing removes the bank-detail variable that fraudsters depend on. --- Every accounts-payable professional has a version of the same nightmare: a payment goes out on time, the paperwork looks clean, and three weeks later the real supplier calls asking why they haven't been paid. By the time anyone understands what happened, the money is gone. Once paid, the money is sent to an untraceable account and is nearly impossible to recover. This is not a niche problem affecting poorly managed businesses. Even the most technically savvy companies in the world — Facebook, Google, and others — have been scammed out of hundreds of millions of dollars through fake invoices. The mechanics of how a fraudulent invoice moves through an approval queue deserve a serious, step-by-step examination — not because the answer is simple, but because the failure points are specific, repeatable, and largely preventable once you can name them.
86%of the transaction types reported in business-email-compromise complaints were wire transfer or ACH
58%of attempted-theft dollars frozen by the FBI's Recovery Asset Team in 2025, only in cases reported within hours
14%of BEC scam victims recovered none of their financial losses

Figures cited in stages 5 and 6 of the attack walkthrough below.

## The scale of the problem, in plain numbers Before walking through the anatomy of an attack, it is worth grounding the discussion in current data, because the numbers clarify the urgency. The FBI's Internet Crime Complaint Center recorded more business email compromise complaints and more reported losses in 2025 than in 2024. | Year | Business email compromise complaints | Reported losses | | --- | --- | --- | | 2024 | 21,442 | $2.77 billion | | 2025 | 24,768 | $3.05 billion | Those are only reported figures. These figures significantly understate the actual cost because the majority of incidents go unreported. Incidents of attempted or actual invoice fraud increased by 10 percentage points year over year, from 14% in 2023 to 24% in 2024, according to a report from the AFP. And the trend is accelerating: AFP said 76% of U.S. organizations experienced attempted or actual payments fraud in 2025, and about 74% were affected by business email compromise. The average loss per incident is not trivial. According to the FBI's 2025 Internet Crime Report, business email compromise drove $3.05 billion in reported U.S. losses across roughly 24,800 cases, averaging about $123,000 per incident. For mid-market businesses — the construction firms, freight companies, property groups, and professional-services practices that make up the backbone of B2B commerce — a single $123,000 USD (approximately $190,000 AUD) loss can wipe out an entire quarter's margin. In AFP's 2026 survey, 48% of organizations under $1 billion in revenue took actual losses from payments fraud in 2025 — and smaller firms are the least equipped to claw anything back. ## What a fraudulent invoice actually is The phrase "fake invoice" covers a wide spectrum, and treating it as a single phenomenon leads to under-engineered defences. There are at least five distinct attack patterns, each exploiting a different crack in the accounts-payable process. **Phantom vendor invoices.** The fraudster — sometimes an outside actor, sometimes a dishonest employee — registers a shell company and submits invoices for goods never delivered or services never performed. A fraudster might set up a shell company with a similar name to a real supplier — for example, "Cotton Company" versus "Cotton Company Co" — and send an invoice for goods that the legitimate company never ordered. **Payment-detail substitution.** This is the most common and most damaging variant. Invoice fraud commonly works by an illegitimate fraudster posing as one of your genuine suppliers, telling you their payment details have changed. A request to update the account number, routing number, or payment method is the single most dangerous red flag in accounts payable. Fraudsters know that once they redirect where money goes, the rest of the invoice can be completely accurate and it won't matter. **Email thread hijacking and account compromise.** Another method is when your supplier's email gets hacked and the fraudster tries to change bank details to divert the funds their way. The email address is legitimate, so it isn't always straightforward to spot. Modern campaigns now use real compromised email accounts to carry out fraud because a message from a real account is most convincing. **Duplicate invoice submission.** Duplicate invoice fraud occurs when the same invoice is submitted multiple times for payment. In high-volume AP environments, duplicate submissions can slip through when invoice validation practices vary across systems, entities, or payment cycles. A fraudster submitting a second copy of a legitimate invoice — with a minor change to the invoice number or date — is betting on precisely that inconsistency. **Insider-assisted fraud.** An accounts-payable employee might work with a vendor to create fake invoices, and then the employee ensures the invoices are approved. They then share the proceeds after the payment is issued. This variant is the hardest to detect because the fraud originates from inside the approval chain itself. ## The anatomy of an attack: a step-by-step walkthrough To understand why defences fail, it helps to trace a realistic attack from reconnaissance to payout. The scenario below is a composite of publicly documented patterns — it is not hypothetical. ### Stage 1: Reconnaissance The attacker identifies a target company and a supplier that the target already uses regularly. This information is often publicly available — from LinkedIn, from a company's own website, from court filings, or from a prior data breach that exposed vendor lists. The goal is to understand two things: the name and format of invoices from that supplier, and the name of the AP contact who processes them. ### Stage 2: Infrastructure setup The attacker creates a fake URL that is similar to the vendor company name, setting up email addresses for vendor employees with the new domain. A domain like `acme-supplies.com` becomes `acme-supplles.com` or `acme-supplies-billing.com`. The new domain is registered days or hours before the attack. Fraudsters impersonate corporate finance departments and claim they are updating their official contact information. The specified email address uses a newborn domain, and the telephone number has no public records. ### Stage 3: The invoice itself The attacker impersonates the vendor and creates a fake invoice that looks identical to a real invoice, and sends it to the target client. The email stresses new, changed banking or transaction details with an urgency for quick response or payment. The production quality of these documents has increased dramatically. Where it once required skill and time to craft a convincing request, tools are now widely available that automate the research, writing, and contextual tailoring that make fraud blend into normal AP workflows. By mid-2024, an estimated 40% of BEC phishing emails were already AI-generated, with that share expected to grow significantly. Modern business-email-compromise emails are grammatically correct and written in the specific tone of the executive or supplier being impersonated. They reference active projects, current invoice numbers, and upcoming payment runs. For AP teams processing high volumes of routine communications, that level of familiarity is exactly what lowers the guard. The email passes spam filters. The email references real projects by correct name, cites actual invoice numbers, and uses the vocabulary and sentence rhythm of the person it impersonates. It arrives from a lookalike domain — one letter different, one character swapped — that passes a visual check. ### Stage 4: The urgency layer Some reports show that attackers may call the accounting department first to announce the supposed change in contact details, to help build credibility. This is the social-engineering layer. A phone call from "the supplier's new billing team" primes the AP contact to expect the incoming email and reduces their critical evaluation of it. We are now starting to see more blended attacks where an email sets up a phone call, or a text message preys on urgency. The use of AI voice clones and video deepfakes is still relatively rare but growing. As the technology becomes more accessible, high-value targets may face extremely convincing impostors via Zoom, Teams, or voicemail. ### Stage 5: The payment The targeted client makes a payment on the invoice to the bank account owned by the attacker. Fraudsters often push for a wire transfer instead of the standard ACH transaction because wires are faster and harder to reverse. 86% of the transaction types reported in business-email-compromise complaints were wire transfer or ACH. ### Stage 6: Discovery — and the gap Fake invoice fraud often goes unnoticed until the supplier follows up about the unpaid invoice. By that point, the attacker's bank account has already been drained. Recovery depends on speed — the FBI's Recovery Asset Team froze 58% of attempted-theft dollars in 2025, but only in cases reported within hours. Most businesses discover the fraud days or weeks later, well outside that window. Nearly 30% of insurance claims involved business-email-compromise funds transfer fraud — and only about 25% of claims see any meaningful recovery. Meanwhile, 14% of BEC scam victims recovered none of their financial losses. ## Why standard defences keep failing The three-way match — comparing a purchase order, a receiving report, and an invoice — is the cornerstone of AP fraud prevention. The three-way matching process prevents several common fraud schemes, including fictitious vendor invoices, inflated pricing, phantom shipments, and duplicate billing. On paper, it is a solid control. In practice, it has structural gaps that fraudsters have learned to navigate. **The process only controls what it can see.** It leaves a chunk of invoices unmatched, including non-PO invoices, utility bills, and Purchase Card spending. If those missed transactions aren't addressed, it leaves the organisation vulnerable. **Bank-detail changes happen outside the matching logic.** Three-way matching confirms that the quantity, price, and description on an invoice align with a PO and a receiving note. It does not confirm that the bank account on the invoice is the same one used last month. A fraudster substituting bank details on an otherwise perfect, matchable invoice sails straight through. **Manual processes degrade under volume.** Manual matching often faces issues like data entry errors, missing documents, and delayed approvals, which can lower efficiency. When an AP team is processing hundreds of invoices a week, the cognitive bandwidth available for each document drops. Without a system that cross-references every invoice against an approved vendor list and an existing PO, fraudulent invoices from fictitious vendors can enter the payment queue. In spreadsheet workflows, the only control is the person reviewing the queue — and that control fails under volume or when the reviewer is the person committing the fraud. **Retrospective purchase orders undermine the logic entirely.** Post-receipt creation of purchase orders circumvents the logic behind three-way matching. When a PO is raised after goods are received to legitimise a payment, the entire audit trail runs backward — and a fraudulent invoice inserted into that backward trail can be indistinguishable from a legitimate one. **Vendor master files are weakly guarded.** The vendor master file is the centralized database that contains all approved vendor information, including names, addresses, tax identification numbers, payment terms, and banking details. It determines who is authorised to receive payments from the organisation. If controls over the vendor master file are weak, fraudulent vendors could enter the system and receive unauthorised payments. Vendor setup and changes are high-risk points. Controls here often include independent verification of bank details, dual approval for changes, and regular reviews of inactive or duplicate suppliers. But in practice, these controls are applied inconsistently. A single email from a "supplier" requesting a bank-account update is still actioned by a junior AP clerk at thousands of organisations every week. ## The specific mechanics of payment-detail fraud Because payment-detail substitution is the most prevalent and most costly attack type, it warrants its own close examination. The attacker's goal is not to create a fictional vendor from nothing. That requires getting a new vendor approved — a harder task at most organisations. The goal is to redirect an existing, trusted payment relationship. A criminal poses as a supplier you already work with — usually from a compromised or lookalike email address — and asks you to update bank details or pay a pending invoice to a new account. Consider a realistic scenario: a construction company is owed a final progress payment of $280,000 USD (approximately $432,000 AUD) from a developer. The developer's AP team receives an email from what appears to be the construction company's accounts team, explaining that they have switched banks and all future payments should be directed to a new BSB and account number. The email arrives three days before the scheduled payment run, includes the correct invoice reference, and is signed by a name the AP team recognises. The payment goes out. The real construction company never receives it. This attack pattern works because it exploits a single systemic vulnerability: the destination of a payment is mutable up to the moment it is sent. Nothing in the payment infrastructure itself enforces a fixed relationship between an invoice and the bank account that receives its proceeds. The attacker needs only to insert themselves into that gap — and the gap is wide. That is sound operational advice, and it is advice that is routinely ignored when an AP team is under deadline pressure and the email looks completely normal. ## The role of trust, volume, and timing Three conditions make AP queues unusually vulnerable to fraud, and they all reinforce one another. **Trust.** A payment request may reference a known supplier, match expected timing, and include documentation that appears complete, which makes it difficult to distinguish from routine activity. AP professionals build working relationships with suppliers over months and years. That familiarity is operationally valuable — and it is precisely what fraudsters study and exploit. Placing too much trust in long-term vendors can lead to reduced invoice scrutiny. **Volume.** As organisations scale vendor ecosystems and accelerate payment cycles, accounts-payable workflows have become faster, more distributed, and more dependent on digital inputs. A team processing 40 invoices a week has very different detection capacity than a team processing 400. Fraudsters submit their invoices during high-volume periods — end of month, end of quarter, pre-holiday payment runs — when scrutiny is lowest. **Timing.** Many attacks combine multiple elements — emails, invoices, and supporting documentation — into a single request designed to move through approval processes without friction. The fake invoice is not submitted alone. It arrives with a covering email, sometimes with a follow-up from a "relationship manager," and often with an implicit or explicit deadline. Accounts payable sits at the intersection of trust and timing. AP teams process invoices, manage supplier details, and execute payments, often under pressure to keep operations running smoothly. For attackers, that combination is ideal. ## Where the settlement layer itself creates risk Most fraud-prevention discussion focuses on the verification steps before payment. That focus is correct — stopping fraud before the payment leaves is far better than chasing it afterward. But there is a parallel problem that receives less attention: the payment infrastructure itself is mutable in ways that fraud depends on. In a conventional wire-based or ACH payment workflow, the bank-account details entered at the moment of payment execution are authoritative. Whatever was verified three days earlier during the invoice-approval process is irrelevant if a fraudster changes those details between approval and execution. The settlement system simply sends money where it is told to send it. The mechanics are constant: a fraudster impersonates a supplier or executive, sends a convincing invoice or a bank-detail change, and the victim's own finance team authorises the payment. This mutability is structural. It is not a bug in any particular bank's system; it is how traditional payment rails are designed. The instruction to pay and the destination of payment are two separate data points that can be manipulated independently. The second structural problem is speed of discovery. Wire transfers via Fedwire represent the strongest form of finality in traditional finance. Fedwire is a real-time gross settlement system: each payment settles individually and is final and irrevocable upon acceptance by the receiving bank. This is excellent for legitimate transactions — it means your supplier receives cleared funds quickly. But it also means that the finality that benefits legitimate payments equally benefits fraudulent ones. Once the wire hits the fraudster's account, recovery requires law-enforcement coordination, bank co-operation across jurisdictions, and speed that most businesses cannot mobilise. The cruelty of the situation: the same finality that makes wire transfers professionally reliable is what makes them so useful to fraudsters. The answer is not to make payments reversible — that creates a different set of problems. The answer is to eliminate the window in which bank-destination details can be substituted. ## What onchain routing changes about the destination problem The vulnerability that makes payment-detail fraud possible is the gap between verification and execution. A payment is approved against one set of bank details; those details can be changed before the transaction fires. The attack lives in that gap. Onchain routing, as implemented by a tool like shaka.deal, addresses this structurally rather than procedurally. When settlement parties agree on a deal — whether that is a property transaction split between a selling agent, a law firm, and a title company, or a B2B payment split between a supplier and their freight broker — the destination addresses and the distribution shares are encoded into the routing contract on Ethereum at the time the deal is structured. They are not re-entered at execution time. They cannot be altered by an email. When the payer sends funds, shaka.deal routes the total amount and distributes it instantly to every party at their preset share, in a single transaction. The routing is simultaneous and final. There is no human data-entry step between approval and execution where a fraudster can substitute a destination. The contract does not accept ad-hoc changes to its payout addresses — an email claiming "please update our bank details" has no mechanism through which it can affect where an onchain disbursement lands. Onchain settlement replaces the multi-day, intermediary-heavy process of moving money and assets with a single blockchain transaction that transfers value and records final ownership at the same time. Onchain settlement is the process of transferring final ownership of an asset and its payment on a blockchain, where the ledger update itself is the settlement. Instead of a network of banks, clearinghouses, and custodians confirming a trade over days, the transaction records the change of ownership and completes payment in a single step. Once the block is finalized, the transfer is done, and no separate reconciliation is required to prove who owns what. For the settlement agents, closing attorneys, escrow officers, and OTC desks that manage complex multi-party disbursements, this matters enormously. The verification work those professionals do — confirming identities, reviewing documentation, checking that amounts match agreed terms — is exactly the kind of rigorous front-end process that onchain routing is designed to sit behind and honour. The verified outcome of that professional work gets encoded into the contract. Shaka.deal then executes that outcome precisely, without a second point of human entry where fraud can intervene. The parties receive their funds simultaneously, in the amounts that were agreed, with on-chain proof of the transaction that is permanent and publicly auditable. There is no settlement window during which a fraudster can redirect the payment, because the payment executes atomically — all at once, to all parties, in the same block. ## Practical detection: what AP teams can do right now Onchain routing is not yet the standard for every B2B payment, and most organisations will be running hybrid processes for years to come. In the meantime, the following detection disciplines address the specific mechanics of each attack type: **Treat every bank-detail change as a high-risk event.** Vendor setup and changes are high-risk points. Controls should include independent verification of bank details, dual approval for changes, and regular reviews of inactive or duplicate suppliers. The verification call should be made to a number sourced independently — not from the email requesting the change, and not from the invoice itself. **Segment invoice approval by risk level.** Approval workflows should control who can approve what and at which value. Low-value invoices may need one manager sign-off, while higher amounts require both department and finance approval. Bank-detail changes should always trigger the highest approval tier, regardless of invoice value. **Enforce the three-way match without exceptions for known suppliers.** Placing too much trust in long-term vendors can lead to reduced invoice scrutiny. Familiarity is precisely the social condition that fraud exploits. Long-standing suppliers should receive no lighter scrutiny than new ones; if anything, they should receive more, because their names and invoice formats are known to attackers. **Check for lookalike domains systematically.** The contact email or website looks slightly different — like .com changed to .org. An AP team reviewing dozens of emails a day will miss a transposed letter. A domain-verification step embedded in the approval workflow, rather than left to individual perception, catches this mechanically. **Watch for urgency language.** Fraudulent invoices stress new, changed banking or transaction details with an urgency for quick response or payment. Any invoice accompanied by a request to expedite, to bypass normal approval steps, or to process before the end of a business day deserves the opposite of what it asks for: slower, more deliberate review. **Audit for duplicates across the full vendor history.** Duplicate invoice fraud occurs when the same invoice is submitted multiple times for payment. Automated duplicate detection should cross-reference invoice numbers, amounts, and dates against the full vendor history — not just the current payment run. Fraudsters exploit the assumption that AP teams only look back 30 days. ## The compounding cost: paying twice One often-overlooked consequence of invoice fraud is that the victim organisation typically ends up paying the legitimate invoice as well. If one of your employees accidentally pays a fraudulent invoice, will your business be on the hook for the real invoice — thus paying twice? Yes — almost always. The real supplier has not been paid and has a valid claim. The fraudster has been paid and the money cannot be recovered. The cost of a successful fake-invoice attack is therefore closer to double the face value of the invoice, once you account for the legitimate payment that still has to be made, the internal cost of the investigation, and any reputational damage to the supplier relationship. For organisations managing large, multi-party transactions — property deals, M&A closings, freight settlements — the stakes are higher still. A $500,000 USD (approximately $770,000 AUD) disbursement split between five parties is not five separate risks; it is one payment event that, if compromised, produces five simultaneous failures and five parties demanding resolution. ## The structural answer: remove the mutable step Every piece of practical advice in this article — verify bank details, enforce dual approval, call vendors directly, watch for urgency — is valuable. These controls reduce exposure and should be implemented. But they are all procedural controls layered on top of a payment infrastructure that remains structurally vulnerable because it separates verification from execution. The enduring problem is that bank-account details are re-entered at execution time by human beings working under time pressure. Fraud lives in that re-entry step. The question for AP teams is no longer whether they can identify suspicious requests. It is whether the processes around payments make fraud difficult regardless of how convincing it looks. That is the right framing. And the structural answer is to eliminate the re-entry step — to make the destination of a payment a function of a verified contract, not a data-entry event that happens the afternoon a payment run is scheduled. When settlement professionals use shaka.deal to route a complex disbursement, they are not bypassing the verification work they do. They are encoding the outcome of that work into an immutable instruction set. The split is preset. The parties are preset. The execution is instant and simultaneous. There is no gap between approval and settlement in which a fraudster can operate, because the payment flows directly from the routing contract to the verified recipients — all at once, in one transaction, with finality. For the AP professionals, closing attorneys, and settlement agents reading this: your expertise in verifying transactions, managing documentation, and protecting your clients is exactly what needs to stand behind a payment system like this. The technology handles the execution layer with certainty; you handle the human and legal layer with professionalism. That combination — rigorous front-end verification plus onchain execution that cannot be redirected by email — is the answer to the attack pattern this article has described. The fake invoice gets into the queue because the queue has a gap. Close the gap, and the invoice has nowhere to go.