Invoice bank details changed and payment sent to wrong account
For customers who discover that bank details on an invoice were altered and payment went to the wrong account. This runbook helps you contain the incident, confirm whether the invoice was tampered with, preserve evidence, and take the fastest recovery steps with your bank and the supplier.
TL;DR — If bank details on an invoice changed and you paid the wrong account, treat it as payment fraud and act in the first hour: call your bank's fraud team to request an immediate payment recall/freezing action, then verify the supplier's real bank details using a known-good phone number or contract, not the email thread that carried the invoice. The most common cause is invoice tampering in email, so preserve the original email and PDF, stop any repeat payments, and notify both banks and the supplier right away. Reading time: ~6 min
The scenario
It is Tuesday afternoon and your finance lead messages you: the supplier says their invoice is overdue, but you already paid it this morning. You open the PDF you paid from and the bank account number on it does not match the supplier's usual details. The email looked normal, the logo and wording were familiar, and nobody noticed anything odd until the supplier chased payment. Now you need to work out whether the invoice was altered, whether the email thread was compromised, and what to do in the next hour to improve the chance of getting the money back.
Symptoms
- The supplier says payment has not arrived, even though your bank shows the transfer as sent.
- The bank details on the paid invoice do not match:
- a previous invoice from the same supplier
- the bank details in your signed contract
- the details the supplier confirms by phone
- The invoice email contains wording such as:
Please note our bank details have changed. Kindly remit payment to the updated account below.
- The sender address is slightly different, for example:
accounts@your-supplier.co
accounts@your-suppIier.com
accounts@your-supplier-payments.com
- The email thread has unusual signs:
Reply-To: different address than From
Mailed-by: unrelated domain
- The PDF metadata or file history shows a recent modification date that does not fit the supplier's normal process.
- Your mailbox has forwarding rules you did not create, such as:
If subject contains "invoice" then forward to external address
- Other customers or colleagues report similar fake "updated bank details" messages from the same supplier.
Likely causes
| Cause | How common | Quick check |
|---|---|---|
| Invoice tampering in email: attacker sent a fake or altered invoice with new bank details | Very common | Compare the paid invoice against a previous known-good invoice from the same supplier |
| Business email compromise (BEC) (attacker got into a mailbox and changed payment instructions in a real thread) | Common | In your mail admin portal, review recent sign-ins for the mailbox that received or sent the invoice |
| Sender spoofing or lookalike domain (fake domain made to resemble the supplier) | Common | Open the original email and inspect the full sender address and Reply-To |
| Internal process error: bank details were updated from an unverified request | Sometimes | Check your accounting or ERP audit log for who changed the supplier bank account and when |
| Supplier-side compromise: the supplier's mailbox or invoicing system was breached | Less common | Call the supplier using a known phone number from contract or website and ask whether other customers received changed bank details |
Step-by-step diagnosis
-
Stop any further payments to that supplier
- In your accounting or banking portal, place the supplier on hold or remove the newly added beneficiary/payee.
- What confirms the problem: you find a new beneficiary or edited supplier bank record that was added just before payment.
- Jump to: Fixes → Internal process error if the change was made inside your system without verification.
-
Call your bank's fraud team now
- Use the phone number on the back of your bank card or from your bank's official website. Ask for an urgent payment recall and beneficiary bank freeze request.
- What confirms the problem: the payment has gone to an account not controlled by your supplier, or the supplier confirms the details are wrong.
- Jump to: Fixes → Invoice tampering in email for the immediate containment checklist.
-
Verify the supplier's real bank details out-of-band
- Call the supplier using a known-good number from your contract, vendor master record, or their public website. Do not use the number in the invoice email.
- What confirms the problem: the supplier says they did not change bank details, or they never sent that invoice version.
- Jump to: Fixes → Supplier-side compromise if the supplier reports their systems or mailbox were affected.
-
Compare the suspect invoice with a known-good invoice
- Check: bank account number, sort code/IBAN, beneficiary name, SWIFT/BIC, PDF creation date, and any "bank details changed" note.
- What confirms the problem: only the payment details changed while branding, line items, and wording stayed the same.
- Jump to: Fixes → Invoice tampering in email.
-
Inspect the original email headers and sender details
- In your email app, open the message and choose the option similar to More actions → View original / View source / Show message details.
- Look for mismatches like:
From: accounts@your-supplier-payments.com
Reply-To: remittance.confirmation@proton.me
Return-Path: randomname@unrelated-domain.tld
- What confirms the problem: the sender domain is not the supplier's real domain, or Reply-To points elsewhere.
- Jump to: Fixes → Sender spoofing or lookalike domain.
-
Check mailbox sign-ins and forwarding rules
- In your mail provider's admin portal, review the affected user's recent sign-ins and mailbox rules. In Microsoft 365 this is typically Admin center → Users → Active users → select user → Mail / Sign-in logs. In Google Workspace, use Admin console → Directory → Users → select user → Security / Gmail settings.
- What confirms the problem: impossible-travel sign-ins, unfamiliar IPs, MFA (multi-factor authentication) disabled, or forwarding rules you did not create.
- Jump to: Fixes → Business email compromise (BEC).
-
Review your accounting audit trail
- In your accounting/ERP system, open the supplier record and view change history/audit log for bank details.
- What confirms the problem: a user changed the supplier's bank details based only on an email request, or there is no second-person approval.
- Jump to: Fixes → Internal process error.
View as text
[You] ---- 1. call fraud team ----> [Your Bank] | | 2. verify bank details by phone v [Supplier] ^ | 3. compare invoice/email evidence | [Mailbox & PDF]
Fixes
Invoice tampering in email
- Preserve evidence before deleting anything:
Save the original email as .eml or .msg
Save the PDF invoice
Take screenshots of the payment confirmation, invoice, and sender details
- Ask your bank for these exact actions:
- Immediate payment recall
- Fraud marker on the beneficiary account
- Contact with the receiving bank to freeze remaining funds
- Written case/reference number
- Notify the supplier from a fresh email or by phone:
We received an invoice with altered bank details and paid the wrong account. Please confirm your correct bank details by phone and preserve your email logs for investigation.
- Mark the invoice as disputed/unpaid in your accounting system so it is not paid again automatically.
- Report the fraud to your local police/cybercrime reporting channel if your bank asks for a crime reference.
Verify it worked: your bank gives you a fraud case number and confirms a recall/freeze request was sent.
Business email compromise (BEC)
⚠️ Changing passwords and sessions will sign the user out of email on all devices. Do this after preserving the suspicious messages and rules.
- Reset the affected mailbox password in your mail admin portal.
- Revoke active sessions/tokens. In provider dashboards this is usually under the user's Security page.
- Re-enable or enforce MFA for the user.
- Remove malicious inbox/forwarding rules.
- Review sent mail, deleted items, and mailbox delegates for unauthorized changes.
- Search for other payment-change emails sent from or to that mailbox in the same date range.
Verify it worked: no unknown sign-ins remain after the password reset, and no unauthorized forwarding rules are present.
Sender spoofing or lookalike domain
- Block the fake sender domain in your mail gateway or admin portal.
- Warn staff not to trust bank-detail changes sent by email alone.
- If you manage your own domain's email security, publish or tighten these DNS records with your DNS provider's dashboard (for example, your provider's dashboard, e.g. Cloudflare: DNS → Records):
Type: TXT
Host: @
Value: v=spf1 include:_spf.your-mail-provider.example -all
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.example; adkim=s; aspf=s
- Ask the supplier to confirm they also use SPF, DKIM (email signing), and DMARC (domain-based anti-spoofing policy).
Verify it worked: future messages from the fake domain are quarantined or rejected, and staff have the exact fake domain recorded in the incident notes.
Internal process error
- Revert the supplier bank details in your accounting system to the last verified values.
- Add a note on the supplier record:
Do not change bank details from email alone. Verify by phone using known number and require second approver.
- If your system supports approvals, enable two-person approval for supplier master-data changes.
- Review all supplier bank-detail changes from the last 30 days for similar requests.
Verify it worked: the supplier record shows the correct bank details and any new change now requires a second reviewer or documented phone verification.
Supplier-side compromise
- Ask the supplier to investigate their mailbox/invoicing system and send a signed statement or written confirmation of their correct bank details.
- Request a list of affected invoice numbers and dates if they have other impacted customers.
- Keep all communication off the compromised thread; start a new thread or use phone.
- Coordinate with both banks using the supplier's written confirmation that the beneficiary account was fraudulent.
Verify it worked: you have written confirmation from the supplier of the correct bank details and whether their systems were compromised.
Prevention
- Require out-of-band verification for any bank-detail change. Put this exact note in your finance procedure:
Any change to supplier bank details must be verified by phone using a number from the signed contract, vendor master record, or official website. Do not use contact details from the change request email.
- Enable dual approval for supplier bank changes and payments over a threshold. In your accounting system, turn on approval workflow for vendor master-data edits and high-value payments.
- Keep a known-good supplier bank record. Store the original signed onboarding form or contract attachment in your document system and link it to the supplier record.
- Harden email security. Publish DMARC with reporting and review the reports weekly:
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.example; fo=1
- Alert on mailbox forwarding rules and risky sign-ins. In your mail admin portal, create alerts for:
- New inbox forwarding rule to external address
- MFA disabled for any finance user
- Sign-in from new country for finance users
- Add a payment-release checklist. Before releasing payment, require a checkbox or note:
Bank details match previous verified invoice / contract: Yes
If changed, phone verification completed: Yes
Second approver name: __________
If the payment was sent very recently, speed matters more than perfect forensics. Call the bank first, preserve the email and invoice second, and verify the supplier's real details through a trusted phone number before doing anything else.
This article was written by an AI system and published pending human review. Verify anything you intend to act on.
Have a project in mind?
Get an instant AI price estimate for it, or talk directly to our team.
One email a month on what we learn building with AI