Payment-Change Verification for Invoices and Payroll

Published October 23, 2026 · Last reviewed October 23, 2026

What the rule must cover

Write the rule for four events, and name the role responsible for each:

• A new supplier or customer refund recipient is added.
• An existing supplier asks to change bank details, remittance email or contact.
• An employee asks to change direct-deposit details or to receive an advance.
• Anyone asks for an urgent or off-cycle payment, a gift-card purchase or a wire.

The procedure in six steps

1. Record the request in a log with the date, who asked, by what channel and the amount, before doing anything else.
2. Do not reply to the message and do not use any phone number, link or portal in it.
3. Look up the contact in your own records, from before the request arrived: the signed contract, the supplier record, the employee file, or a number from a previous call.
4. Call, and ask the person to read back the detail that is changing, not to confirm one you recite.
5. Have a second person, who was not on the call, approve the change in the accounting or payroll system.
6. For the first payment after a change, send a small test amount or delay it one cycle where the supplier agrees, and confirm receipt.

Controls, in priority order

Action

Restrict who can edit supplier bank details and employee deposit details in the accounting, payroll or banking system. In most products this is a permission or role under user settings; names differ by product, so check the vendor documentation.

Why it helps

If many people can change a bank detail, many people can be fooled. A short list of editors makes the call-back rule enforceable.

Verification

Export the user list for the accounting or payroll system and count who holds the edit permission. It should match the roles named in your rule.

Fallback if delayed

If the system cannot restrict editing, require the second approver to confirm every change by checking the log entry.

Action

Require dual approval for payments above a threshold you choose, and for any payment to a payee added in the last 30 days. Set the threshold with the owner, based on what the business could not absorb.

Why it helps

Fraud losses are usually one large payment. Two people in the chain means the attacker has to deceive two people independently.

Verification

Make a test payment of a trivial amount in the system and confirm that it stops for second approval.

Fallback if delayed

Use the bank’s own dual-authorisation feature, which many business accounts offer, if the accounting system cannot enforce it.

Action

Tell your suppliers and staff how you will verify. Put one sentence in supplier onboarding and on the payroll form: “We confirm any change of bank details by phone before acting.”

Why it helps

Suppliers who know the rule are less likely to be offended, and are more likely to call you if they suspect their own mailbox was compromised.

Verification

Check that the sentence appears in the supplier form and the HR pack.

Fallback if delayed

Add it to the signature of the finance mailbox.

Common failure mode

The rule exists on paper but is bypassed for urgent requests from senior people, because the check feels rude. Attackers rely on this. Write the exception out loud in the rule: urgency and seniority are reasons for the check, not reasons to skip it. A second failure is the call being made to a number found in the message or in a signature block.

The ten-minute test

Once a quarter, with the owner’s consent, send the finance team a harmless test request for a bank-detail change from a look-alike address. Do not publicise the date. If they follow the rule, tell them so; if they do not, treat it as a process gap, not a personal failing, and fix the process. Avoid any real payee, and keep the test inside the company.

How it works

The rule is a form of separation of duties: the person who receives a request is never the only person who can act on it, and the evidence used to verify is never supplied by the requester. Each step removes a different path for the attacker. Logging first creates a record that can be shown to a bank or insurer. Using your own records defeats a hijacked mailbox, because the attacker can change an email but not your files. The read-back defeats a caller who merely says “yes” to a script. The second approver defeats a single deceived or coerced employee.

The same structure protects payroll. A request to change a deposit account should be confirmed in person or by calling the employee on a number held by HR, since mailbox compromise of the employee is the usual route in. For the wider fraud picture see business email compromise.

Worked example

Suppose, as a hypothetical, an employee emails payroll from what looks like her usual address: “I have a new bank, can you update my deposit before Friday?” Payroll logs the request, does not reply, and phones the employee on the mobile number in her HR file. She says she sent nothing. Payroll reports the message and asks IT to check her mailbox for forwarding rules and unusual sign-ins.

All details here are invented to show the sequence. Note that the check took a few minutes and needed no special software, which is why it is the most reliable defence on this page.