What to Do When You Receive an AI-Written Fake Invoice or Payment Request

TL;DR — If you receive an invoice or payment request that feels slightly off, treat it as suspicious until you verify it using a known-good contact method. The most common reality is not that your systems were hacked, but that someone spoofed (forged) an email, impersonated a real person, or used a lookalike domain; the fastest safe action is to pause payment, verify bank details by phone using a number you already trust, and check the sender domain and email authentication results. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon and an email lands in your inbox with an attached invoice and a note like, "Please use our updated banking details for today’s payment." The wording sounds polished, maybe even more polished than usual, and it references a real project name, a real teammate, or a real amount. Your finance person is about to pay it because the deadline looks urgent, but something is just a little off: the sender address is unfamiliar, the bank account changed, or the tone is unusually pushy. You need to decide quickly whether this is a real request from your software agency or an AI-assisted fraud attempt.

Symptoms

• You receive an email with language like:

Please note our banking details have changed effective immediately.
Kindly settle the attached invoice today to avoid service interruption.

• The sender display name looks right, but the actual address is different, for example:

From: "Alex from Agency" <alex@agency-payments.com>

instead of your known domain.

• The reply-to address does not match the from address, for example:

From: billing@youragency.com
Reply-To: accountsreceivable.consulting@outlook.com

• The invoice PDF has correct branding but new bank details, crypto wallet details, or pressure to pay urgently.
• The email headers show failed authentication, often with lines like:

spf=fail

dkim=fail

dmarc=fail

• The message asks you to bypass your normal process:

Do not call, I am in a meeting / traveling / unavailable.

• A teammate says, "This looks real enough," but nobody can find the same request in your agency’s billing portal, contract thread, or earlier invoice chain.

Likely causes

Step-by-step diagnosis

1. Pause the payment immediately.

   • Action: put the invoice into your normal payment queue as "On hold - verification required" in your accounting tool, or tell your finance teammate not to send funds yet.
   • This is your problem if: the request includes new bank details, urgency, or a change from your normal process.
   • Jump to: Fixes → Internal process gap if you do not already have a hold-and-verify step.

2. Check the real sender address, not just the display name.

   • Menu path: in your mail provider, open the message and use the option usually named Show original, View source, or View message details.
   • Look for lines like:

From: Alex <alex@agency-payments.com>
Reply-To: wireupdate@proton.me

• This is your problem if: the domain is not your agency’s normal domain, or the reply-to points somewhere unrelated.
• Jump to: Fixes → Simple email spoofing or impersonation or Fixes → Lookalike domain.

1. Check email authentication results.
   • In the same original/source view, look for:

Authentication-Results: ... spf=fail ... dkim=fail ... dmarc=fail

• This is your problem if: one or more of SPF, DKIM, or DMARC fail for the sender domain. (These are standard email checks that help prove a message was allowed by the real domain owner.)
• Jump to: Fixes → Simple email spoofing or impersonation.

1. Compare the sender domain carefully against a known real one.
   • Action: copy the domain from the suspicious email and the domain from a known-good past email into a plain text note.
   • Example:

Real: youragency.com
Fake: your-agency.com
Fake: youragency.com
Fake: youragency.co

• This is your problem if: the domain differs by even one character, punctuation mark, or top-level domain.
• Jump to: Fixes → Lookalike domain.

1. Verify the payment request out-of-band.

   • Action: call your agency using a phone number from a signed contract, your vendor record, or a past paid invoice you already trust. Do not use the number in the suspicious email.
   • This is your problem if: your agency says they did not send the invoice, did not change bank details, or their mailbox may be compromised.
   • Jump to: Fixes → Compromised mailbox or Fixes → Legitimate thread hijack.

2. Check whether the invoice exists in your records.

   • Menu path: search your accounting tool, shared drive, or procurement system for the invoice number, amount, and purchase order.
   • This is your problem if: the invoice number does not exist, the amount does not match, or the PDF metadata and details do not line up with prior invoices.
   • Jump to: Fixes → Fake invoice attachment generated from public information and AI.

3. Review the conversation history.

   • Action: compare the suspicious message with the last real billing thread. Look for a sudden bank-detail change, a new reply-to address, or a break in tone.
   • This is your problem if: the thread contains real history but the newest message introduces changed payment instructions.
   • Jump to: Fixes → Legitimate thread hijack.

[You] ---- 1. hold payment ----> [Invoice Request]
  |                                   |
  | 2. show original/source           | 3. compare domain
  v                                   v
[Headers/Auth] ---- 4. fail? ----> [Spoof/Lookalike]
  |
  | 5. call known contact
  v
[Agency Confirms] ---- 6. no ----> [Fraud Attempt]
  |
  | 7. yes but mailbox issue
  v
[Compromised Mailbox]

Fixes

Simple email spoofing or impersonation

• Do not reply to the suspicious email.
• Mark it as phishing in your mail provider.
• Forward the full message source to your internal finance/security contact and your agency’s known support address.
• If your mail app supports it, include the original headers.
• Template you can send internally:

Subject: Suspected fake invoice/payment request

We received a payment request that appears suspicious.
Status: payment on hold
Reason: sender/authentication mismatch
Action taken: verified via known contact method, not via email reply

• Verify it worked: the payment remains on hold and your agency confirms the message was not legitimate.

Lookalike domain

• Block the sender domain in your mail system if you manage it, or ask your IT provider to block it.
• Add the fake domain to your vendor incident notes so finance knows it is malicious.
• If you control a secure email gateway, create a block rule for the exact domain.
• Example blocklist entry to give IT:

Block sender domain: agency-payments.com
Reason: impersonation of youragency.com

• Verify it worked: future messages from that domain are quarantined or rejected.

Compromised mailbox at the sender or recipient side

⚠️ If a real mailbox is compromised, the attacker may be reading ongoing conversations. Do not continue sensitive verification in the same email thread.

• Move verification to phone or a fresh email thread to a known address from your vendor record.
• Ask your agency to reset the affected mailbox password, revoke active sessions, and review forwarding rules.
• If your own mailbox may be involved, ask your IT provider to check for suspicious forwarding rules and recent sign-ins.
• In Microsoft 365 or Google Workspace, the exact screens vary, but ask for: recent sign-in review, mailbox forwarding review, and MFA (multi-factor authentication) reset.
• Verify it worked: your agency confirms the mailbox is secured and sends corrected payment details through a trusted channel.

Legitimate thread hijack using a stolen email conversation

• Treat all payment instructions in that thread as untrusted until re-verified.
• Ask for a fresh invoice from a known billing contact and compare it to the last paid invoice.
• Require bank-detail confirmation by phone with a second person present.
• Record the verified bank details in your vendor master record so future invoices are checked against it.
• Verify it worked: the newly issued invoice matches your vendor record and is confirmed out-of-band.

Fake invoice attachment generated from public information and AI

• Compare the PDF against a known-good invoice: logo placement, legal entity name, tax ID, bank details, invoice numbering pattern, and line items.
• Check PDF metadata if your viewer exposes it; many fake invoices have generic creator fields.
• Save the suspicious file in your incident folder and do not use the payment details from it.
• Example checklist:

[ ] Invoice number exists in accounting system
[ ] Amount matches contract or statement of work
[ ] Legal entity name matches vendor record
[ ] Bank details match previously verified record
[ ] Purchase order matches internal approval

• Verify it worked: the invoice is either matched to a real approved record or rejected as fraudulent.

Internal process gap: payment changes accepted by email alone

• Update your process so bank-detail changes cannot be approved from email only.
• Add a required callback step using a stored phone number, not one from the request.
• Add a two-person approval rule for first payment to a new bank account.
• Simple policy text you can copy:

Any request to change vendor bank details must be verified by phone using a previously recorded number and approved by two people. Email-only approval is not valid.

• Verify it worked: your finance checklist now blocks payment until callback and dual approval are completed.

Prevention

1. Store verified vendor payment details in one place and compare every invoice against that record.
   • Add fields in your accounting or vendor system:

{
  "vendor_name": "Your Agency Ltd",
  "verified_bank_account_last4": "1234",
  "verified_on": "2026-10-30",
  "verified_via": "phone callback",
  "verified_by": ["finance-1", "finance-2"]
}

1. Require a callback for any payment-detail change.
   • Put this in your AP (accounts payable) checklist:

If bank details changed: stop, call known number, document who confirmed, then request second approval.

1. Train staff to inspect the real sender and headers on invoice emails.
   • Keep a short internal note with the exact menu path for your mail provider:

Open message -> More actions -> Show original / View source
Check: From, Reply-To, Authentication-Results

1. Ask your IT provider to tighten email authentication and anti-impersonation rules.
   • Useful controls to request:

- Quarantine messages that fail DMARC from domains claiming to be key vendors
- Flag external messages clearly
- Block newly observed lookalike domains when reported

1. Add a "known-good channel" rule to contracts and onboarding.
   • Example contract note:

Payment detail changes are valid only when confirmed by phone with an authorized contact already on file.

1. Keep a fraud evidence folder for quick incident response.
   • Save these items for each suspicious request:

- Original email source/headers
- PDF attachment
- Screenshot of sender details
- Notes from callback verification
- Final disposition: fraudulent / legitimate

This makes it much faster to report patterns to your IT provider, bank, insurer, or law enforcement if needed.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.