Business email compromise (BEC) and fake invoice scams succeed when a plausible request moves through a normal payment process without independent verification. This operational checklist helps finance, IT, and business teams track payment-change requests, supplier invoices, executive messages, and urgent transfers; establish reliable approval steps; and maintain an incident log that can be reviewed monthly or quarterly.
Overview
A BEC scam is an attempt to manipulate an organization into sending money, changing payment details, disclosing information, or taking another sensitive action. The message may appear to come from an executive, supplier, customer, attorney, or internal finance employee. A fake invoice scam is a related tactic in which an attacker submits a fabricated invoice, alters a legitimate invoice, or redirects payment to a new account.
These scams do not always depend on obvious spelling errors or suspicious domains. An attacker may use a compromised mailbox, a lookalike domain, information gathered from public websites, or a stolen email thread. The request can therefore look familiar while still being unauthorized.
The strongest defense is a process that treats unusual payment instructions as a verification event rather than as a routine email task. Technical controls such as multifactor authentication, mailbox monitoring, and phishing protection are important, but they work best alongside clear financial controls. No single employee should be expected to identify every sophisticated message unaided.
Start by documenting who can request, approve, release, and reconcile payments. Then define which changes require a second channel of verification. A useful rule is that an email alone should not authorize a new beneficiary, a changed bank account, an urgent wire, or an exception to normal approval limits.
For related checks, see the Vendor Verification Checklist and How to Check if a Link Is a Scam Before You Click.
What to track
Payment and vendor changes
Maintain a register of every request involving a new supplier, a new beneficiary, changed bank details, changed remittance instructions, or an unusual payment route. Record:
- Vendor or beneficiary name and the employee who submitted the request.
- Date and time received, requested effective date, and payment amount.
- What changed from the previous approved record.
- Verification method, including the trusted phone number or contact used.
- Names of the requester, reviewer, approver, and payment releaser.
- Whether supporting documents were independently confirmed.
Do not use contact details supplied only in the suspicious message for verification. Compare them with an existing vendor record, a previously used statement, a signed contract, or another trusted business source. If the request cannot be verified independently, pause it.
Message and request indicators
Track the patterns that appear in suspicious messages, not just whether money was lost. Useful fields include:
- Urgency, secrecy, pressure to bypass controls, or claims that the usual approver is unavailable.
- Requests to change an account, pay outside the normal process, or split a payment.
- Unexpected replies in an existing thread or a message from a newly registered lookalike domain.
- Differences in signature, writing style, time zone, or normal communication habits.
- Attachments, links, QR codes, or requests to move the conversation to a personal channel.
- Use of executive authority, legal threats, confidential-project language, or a claimed emergency.
These are indicators for review, not proof that a message is fraudulent. A legitimate supplier may change banks, and a genuine executive may send an urgent request. The control is independent confirmation, not an assumption based on tone alone.
Control performance
Track whether your process worked as designed. Review the number of payment-change requests, the number independently verified, exceptions granted, blocked or reported messages, failed verification attempts, and reconciliation discrepancies. Also record how long it took to contain a suspected incident and whether access credentials or mailbox rules required investigation.
A simple incident log can use these columns: date, channel, alleged sender, vendor or account affected, request type, amount or data involved, warning signs, verification result, actions taken, owner, escalation status, and lessons learned. Avoid placing unnecessary sensitive account numbers or personal data in a broadly accessible spreadsheet.
Cadence and checkpoints
Before approving a payment or change
- Stop and identify exactly what the message is asking the organization to do.
- Check the sender address, reply-to address, links, attachment names, and conversation history.
- Compare the request with the vendor master record, contract, purchase order, or prior invoice.
- Call a known, trusted number or use an established supplier portal. Do not rely on contact details in the request.
- Use a second person to review high-risk changes and confirm that the approval is recorded.
- Release funds only after the required approvals and verification evidence are complete.
A callback script can be short and neutral: “We received a request to change the payment details for your account. Before we process it, please confirm whether you made this request. We will not read back the new account information from the email; please provide the approved details through our established verification process.” If the person who answers cannot confirm through a trusted channel, escalate rather than improvising.
Monthly review
Once a month, finance and IT should review the incident log and payment-change register together. Look for repeated vendors, repeated senders, changes requested near payroll or closing periods, approvals completed outside normal hours, and exceptions that were granted because of urgency. Confirm that terminated employees and inactive vendors no longer retain unnecessary access or payment authority.
IT can review reported phishing messages, unusual mailbox forwarding rules, suspicious sign-ins, newly created inbox rules, and attempts to authenticate from unexpected locations. The exact signals available will depend on the organization’s systems, so the goal is to compare current activity with the organization’s normal pattern rather than apply a universal threshold.
Quarterly review
Each quarter, test the workflow with a controlled exercise or tabletop scenario. Use cases such as a supplier bank-change request, an urgent executive wire request, and an invoice received from a new contact. Check whether employees know whom to call, whether approvers can reject a request without fear of delay, and whether the audit trail shows who verified each step.
Update contact records through a trusted process, review payment permissions, confirm that multifactor authentication is enabled for relevant accounts, and remove unnecessary access. Refresh the internal guidance when the organization changes banks, accounting software, approval limits, vendors, or communication channels.
How to interpret changes
An increase in reported suspicious messages does not necessarily mean the organization is less secure. It may indicate better reporting, a seasonal campaign, a newly exposed domain, or a change in email filtering. Interpret the number alongside outcomes: Were requests stopped? Were users reporting them earlier? Did any message bypass technical controls? Did the verification process delay legitimate payments without improving safety?
A rise in payment-change requests from one supplier may justify a direct vendor review, especially if the requests use different contacts or channels. A rise in urgent executive requests may point to impersonation targeting, while repeated mailbox-rule alerts may indicate account takeover risk. Connect these observations rather than treating each event as isolated.
Pay particular attention to control exceptions. One approved exception may be reasonable; a pattern of exceptions can become the real vulnerability. If employees routinely bypass callbacks because vendor records are outdated, improve the records and ownership instead of simply reminding staff to be cautious.
When a suspected BEC event occurs, preserve the original message and relevant headers where possible, pause pending transfers, notify the designated incident owner, and contact financial institutions through official channels if funds may have moved. Reset potentially exposed credentials and investigate mailbox access or forwarding rules according to the organization’s response plan. For broader account takeover indicators, consult Account Takeover Warning Signs.
When to revisit
Revisit this checklist monthly for operational review and at least quarterly for a formal control check. Update it sooner after a suspicious payment request, confirmed phishing message, vendor banking change, executive impersonation attempt, accounting-system migration, staffing change, or change to approval limits.
Schedule an immediate review when a trusted mailbox may have been compromised, when a supplier reports an unauthorized request, when an employee used a personal channel for payment instructions, or when reconciliation identifies an unexplained discrepancy. The purpose is not to assign blame; it is to determine which step failed or was unavailable and to close that gap.
End each review with three concrete actions: one process change, one technical or access-control check, and one communication or training update. Assign an owner and due date for each action, then carry unresolved items into the next review. A maintained log and a practiced callback process provide more durable protection than a one-time warning about fake invoices.
For a related impersonation workflow, review Bank Impersonation Scams: How to Verify Calls, Texts, and Emails Claiming Fraud. Keep this page with your finance and incident-response procedures so the checklist is available when an urgent request creates pressure to move quickly.
