Accounts payable invoice automation is the process of capturing, validating, coding, and routing supplier invoices through a structured workflow before they reach the accounting ledger. Most tools stop at extraction: they pull data from a PDF and push it into Xero or MYOB. What they skip is the validation stage that sits between receipt and approval - and that gap is where the majority of invoice fraud and payment errors actually occur. The question is not whether to automate. It is whether your automation has a control layer, or just a faster conveyor belt.
Where does invoice automation fail most often?
An invoice arrives. It looks legitimate. It carries the correct ABN, the right supplier name, and a familiar format. A processing tool extracts the data. It gets routed to an approver. The approver authorises payment.
Somewhere between receipt and that authorisation, a bank account number changed. Nobody checked it against the supplier’s historical payment records. The payment went to a fraudster’s account. By the time anyone noticed, the funds were gone.
This is not a hypothetical. A Victorian construction company lost AU$900,000 in 2024 when attackers compromised a supplier’s email account and sent a fake invoice with altered bank details. The email came from the supplier’s genuine address. To anyone reviewing it manually, there was nothing obviously wrong. The fraud succeeded because the pre-approval stage had no automated verification of supplier banking details against prior payment history.
That window - from the moment an invoice is captured to the moment it clears validation and reaches an approver - is the highest-risk phase in the entire AP cycle. It is also the phase that most automation tools handle least carefully.
What the Pre-Approval Stage Actually Involves
Finance teams often describe AP automation as “getting invoices into the system faster.” That description understates how much happens, or should happen, before an invoice is legitimate to approve.
The pre-approval stage includes:
- Supplier identity verification: Is this invoice from who it claims to be from? Does the ABN match what is on file?
- Bank detail validation: Do the payment details match what the supplier used last time? If they have changed, was a change request received and verified through a separate channel?
- Duplicate detection: Has this invoice number, amount, and supplier combination appeared before? Duplicate invoices are one of the most common forms of payment error - and intentional fraud - in AP.
- PO matching: Does the invoice correspond to a purchase order that was actually raised? Two-way matching catches invoices for goods or services never ordered.
- Line-item coding accuracy: Are the individual lines correctly coded to the right accounts and GST treatment, based on what this supplier typically invoices for?
- Exception flagging: Do any of the above checks produce a mismatch? If so, the invoice should stop here for human review - not continue to the approver queue as if everything is fine.
Most businesses running basic invoice automation have solved parts of this list. They have OCR extraction, maybe automatic coding, and a routing rule that sends invoices above a threshold to a senior approver. What they typically do not have is a consistent, systematic check of supplier details and PO matching at the line level before the invoice reaches the approver’s queue.
The result is that approvers are asked to sign off on invoices that have not been fully validated. They are the last line of defence, operating without the information they need.
Why are changed bank details the most exploited gap?
Of all the pre-approval checks, bank detail validation is the one that Australian businesses most consistently fail to automate. And it is the one that costs them the most.
Payment redirection scams cost Australian businesses AU$152.6 million in 2024, a 66% increase from AU$91.6 million in 2023, according to the National Anti-Scam Centre. These scams work almost exclusively by exploiting the moment when a supplier’s bank details appear to have changed on an invoice.
The mechanics are straightforward. An attacker compromises a supplier’s email account, identifies a current invoice, and sends a modified version with new payment details. In some cases, they contact the victim business directly to notify them of a “bank account change” before the invoice arrives. If the victim verifies the change by replying to the same compromised email, the attacker confirms it. Every part of the communication appears legitimate.
Around 50% of business email compromise emails are now AI-generated, making them grammatically correct and contextually accurate. A finance team relying on visual review to catch these cannot keep up with the volume or the sophistication.
The Australian Federal Police has specifically identified the construction industry as a prime target for BEC attacks due to high-value transactions, frequent invoicing cycles, and limited cybersecurity resources in small, family-run businesses. The ACCC identifies construction, real estate, and legal services as the most frequently targeted industries for fake invoice scams.
A Queensland organisation lost over AU$1 million after scammers impersonated a construction company with detailed knowledge of the business relationship. The knowledge came from prior email access - the attacker had been reading legitimate correspondence before making contact.
When Automation Makes Fraud Easier, Not Harder
This is the counterintuitive reality of AP invoice automation: a poorly designed system increases fraud risk rather than reducing it.
The reason is speed. A manual AP process has friction built in. Someone physically touches each invoice. They notice if something looks different. They might call the supplier to confirm. The friction is inefficient, but it creates natural checkpoints.
An automated system removes that friction. Invoices move through extraction, coding, and routing in minutes. If the automation layer has no controls on supplier identity or bank detail changes, a fraudulent invoice travels through the pipeline faster than a manual process would have allowed it to. It reaches the approver’s queue looking clean and coded, with no flags raised.
The approver sees a formatted, coded invoice with a familiar supplier name. They click approve.
This is why the control layer in AP automation is not a feature - it is the point. Automation that handles extraction and routing without validating the substance of each invoice does not reduce exposure. It accelerates it.
Most businesses comparing AP automation tools focus on extraction speed, Xero or MYOB integration quality, and approval routing flexibility. Very few ask: what does this platform do when a bank account number appears on an invoice that does not match what the supplier used last quarter?
The Duplicate Invoice Problem in the Pre-Approval Queue
Bank detail fraud is the highest-profile risk in the pre-approval stage. Duplicate invoices are the most common.
Without duplicate detection in the pre-approval stage, duplicates reach the approver queue and often get approved. Approvers reviewing 30 or 40 invoices in a queue are not cross-referencing every invoice number against prior payment history. A supplier invoices twice for the same delivery. An invoice is re-sent after a payment query. A PDF is attached to two separate emails and captured twice by an OCR tool.
The problem compounds in businesses with high invoice volumes. A wholesale distributor processing 200 invoices per month across multiple suppliers and purchase orders has no practical way to catch duplicates manually. By the time a duplicate payment appears in a reconciliation review, the funds are gone and recovering them from the supplier requires an awkward conversation and a delay that affects cash flow.
Duplicate detection belongs in the pre-approval stage, not in a monthly audit. An invoice that matches a prior invoice number, supplier, and amount within a recent date range should be flagged before it is routed to an approver - not approved and then investigated.
A Scenario from the Ground Level
A financial controller at a Brisbane wholesale distributor manages AP for a business that processes around 150 invoices per month. The business runs Xero for its ledger and uses a basic OCR tool to extract data from emailed PDFs.
Every week, she receives a batch of extracted invoices in a shared inbox, reviews the coding, corrects anything the OCR tool misread, and forwards the batch to the relevant approvers. Invoices above AU$5,000 go to the business owner.
One month, a supplier they had worked with for three years sent an invoice with a note at the bottom: “Please note our bank account details have changed.” The financial controller received the invoice, saw the familiar supplier name, saw the note, and updated the supplier’s payment details in Xero. She then approved the invoice.
The payment went to a fraudster’s account. The supplier had no idea their email had been compromised. The financial controller had no way to know either - she had done exactly what the process asked of her. The problem was that the process had no checkpoint for validating a bank detail change against historical supplier records or requiring a verification step outside the email thread.
That verification step is not difficult to automate. It is a comparison of the bank details on the incoming invoice against what is stored on file for that supplier. If they do not match, the invoice should stop and be flagged for manual confirmation via a phone call to a verified number - not by replying to the same email chain.
How Accounts Payable Invoice Automation Should Handle the Pre-Approval Stage
The control layer in an AP automation workflow should operate before any invoice reaches the approval queue. That means:
Supplier detail validation at the point of capture: comparing the ABN, supplier name, and bank account details on the incoming invoice against historical records. Any discrepancy triggers an exception flag, not a silent pass-through.
Duplicate detection against the invoice register before routing: checking invoice number, supplier, amount, and date range against prior submissions. A potential duplicate should be held, not forwarded.
PO matching at the line level before approval: for businesses that raise purchase orders, each line on the invoice should be matched to a corresponding PO line. Mismatches are flagged. Invoices without a matching PO for a supplier that always uses them are treated as exceptions.
Exception routing: flagged invoices should follow structured approval workflows and go to a named reviewer for resolution before proceeding. They should not pass through to the standard approval queue mixed in with clean invoices.
Audit trail: every check, every flag, and every resolution decision should be recorded against the invoice. If a bank detail change is verified and cleared, that decision - who made it, when, and how - should be documented.
Exception flagging should occur before an invoice reaches the ledger. Pulsify handles this within its validation layer, comparing supplier details against history before invoices are published to Xero or MYOB. When bank details change, the invoice stops and surfaces for manual review rather than passing through to the approver queue silently.
What Xero and MYOB Do Not Cover Here
Neither Xero nor MYOB provides native pre-approval validation of the kind described above. Both platforms function as ledgers: they record and report what is published to them. They do not examine whether the invoice that arrives in the approval queue has been checked against supplier history, duplicate records, or PO matching at the line level.
Many businesses that have recognised this limitation run Dext for extraction and ApprovalMax for approval controls. This addresses part of the problem: ApprovalMax adds financial controls and approval routing that Xero alone does not provide. But neither Dext nor ApprovalMax was built specifically to validate supplier identity and bank details against historical behaviour in the pre-approval stage. The exception flagging that sits between capture and approval remains a gap in that stack.
What to Check in Your Current AP Automation Workflow
If you are evaluating your current setup or considering a change, these are the specific questions to ask about the pre-approval stage:
- When a supplier’s bank account details change on an invoice, does your current system flag it before routing the invoice to an approver?
- Does your system run duplicate checks against prior invoice numbers before the invoice reaches the approval queue?
- If you raise purchase orders, does your system match invoice lines to PO lines automatically, or does an approver handle that comparison manually?
- When an invoice is flagged as an exception, does it stop and route to a named reviewer, or does it continue to the standard approval queue?
- Is there a documented audit trail of every pre-approval check, flag, and resolution decision that can be reviewed in an audit?
If the answer to most of these is “we do that manually” or “we check sometimes,” the pre-approval stage is where your exposure lives.
Sources: ACCC - Targeting Scams Report 2024 · AFP - Business Email Compromise
Further reading: How to Build an Audit-Ready Approval Matrix · Why Delegation of Authority Matters More Than Automation Speed · Best AP Automation Software Australia 2026