Freelance invoice payment fraud: verify bank-detail changes and protect client payments

A freelancer does not need to assume that every client email is malicious. The useful habit is narrower: distinguish a routine invoice from a change to a payment instruction. An attacker may imitate a client finance contact and ask you to use a new portal; someone may imitate you and ask the client to pay a new beneficiary; or a compromised mailbox may forward a real invoice with one altered line. The message can contain a correct logo, project name, invoice number and polite explanation. Those surface details make it more important to check the detail that moves money, not less important.

Create a simple change threshold. A request that only asks for a copy of an existing invoice may need normal document handling. A request that changes beneficiary details, recipient legal name, payment link, currency, amount, due date, payment purpose, contact channel or refund destination needs independent confirmation. This is a process rule, not a judgment about the sender character. It gives you a calm explanation for pausing: the instruction differs from the approved record, so it must go through the normal confirmation step before anyone sends or redirects money.

At client onboarding, make a small private record of facts you have already verified: client legal or trading entity, project owner, billing contact, finance contact, normal sending domains, preferred approval channel, purchase-order or vendor requirements, agreed currency, invoice numbering format, payment rail and the recipient name expected by that rail. Store this record where only appropriate people can change it. It is not an invitation to collect more personal data than needed; it is a reference point for the relationship you already have.

Version control applies to invoices as much as to design files. Issue one original invoice number. If a legitimate correction is needed, create a clear revision such as INV-104-R1, say what changed, preserve the original and send the revised document through the established channel. Never silently replace a PDF, edit an old invoice after it was sent or use an ambiguous file name such as final-new-really-final. A client should be able to identify which version is payable, and you should be able to tell later whether an alleged payment matches that version.

When a client asks you to pay a different account, or when you need the client to adopt your changed details, pause and use a second route. Call a number in the signed agreement, vendor profile or official website that you reached independently; open the client portal from a saved bookmark; or contact a known project and finance owner at their previously verified addresses. Explain only that a payment instruction changed and needs confirmation. Ask the contact to verify the change and identify the correct invoice version. Do not copy a newly supplied number into a call request and call it independent verification.

Make the confirmation easy for a legitimate client. Agree during onboarding who may authorize a payment-detail change, which channel is valid, and what minimum information the confirmation should include. For example, a known finance owner can confirm that a change notice is genuine and that a revised invoice will follow through the normal portal. Avoid reading full bank details aloud on a call, asking a client to share account login information or turning a confirmation conversation into a collection of sensitive data. The goal is to authenticate the process, not to expose more information.

Read the full sender address, not just the display name. Look for a domain with one changed character, a different top-level domain, an unusual reply-to address, a new chat account, a forwarded message without the original headers or a request that bypasses the normal client system. Also notice process clues: pressure to pay before verification, an unexplained switch from a client portal to a file-share link, a request to use a personal account, or a demand for passwords, authentication codes, remote access or recovery information. One clue alone can be a harmless change; several deserve a pause.

Keep the response neutral and useful. You can say: this instruction differs from the payment record we have on file, so I need to confirm it through our agreed contact route before processing it. That wording protects the relationship if the client simply changed staff or systems. It also alerts a real security team if the message is not genuine. Avoid forwarding suspicious messages widely, publishing a claim online or replying with sensitive documentation. Send the evidence only to the real client security, finance or vendor contact that you independently identify.

For each invoice, put the invoice number, exact gross amount, currency, approved recipient name, expected rail and due date in one reconciliation record. If the client says it paid, ask for the minimum non-sensitive facts needed to locate the transaction: date, amount, currency, rail, invoice reference and a traceable transaction reference where available. Compare those facts with the invoice and your own official account view. A screenshot may help identify a discrepancy, but it can be incomplete, old, edited or show initiation rather than settlement. Do not mark a payment final simply because a message says completed.

If money arrives short, late or in an unexpected currency, separate the arithmetic from the question of authenticity. Check sender, amount, currency, fees, intermediary deductions, foreign-exchange conversion, withholding, rejection notices and any contractual adjustment. If the client paid the wrong destination, do not ask it to duplicate the transfer until its sending institution explains the available trace or recall process. If an unexpected payment reaches your account, do not send a refund to a new address from an email; verify the original transaction and use the bank or provider official process for the actual facts.

Open a case folder when a material instruction differs from the baseline. Preserve the original email or portal notification, attachments, headers if available, invoice versions, screenshots of the official account view, contact notes, transaction references and the time you took each action. Keep originals read-only where practical and make working copies for annotation. Record observations such as: the message came from this address at this time and asked for this change. Avoid writing that a named person is a criminal or that a payment is irretrievable unless an appropriate institution has established that fact.

Do not quietly edit the invoice, delete the suspicious message, rename a file to hide which version came first, or ask a client to change the description of an already sent payment. Those actions make both security review and ordinary reconciliation harder. If a document must be corrected, issue a new dated version and state why. If personal information is involved, share it only with the relevant verified client, provider or adviser and follow their secure channel. Keep records long enough for your business, tax and contractual needs, but do not collect or circulate unrelated sensitive data.

If you discover a suspicious instruction before payment, stop the affected invoice workflow and tell the known client contact that confirmation is pending. If a payment may already have been sent, the payer should contact its own bank or payment provider immediately through an official phone number, app or website it reached independently. You should contact your receiving provider through its official route if your own account, payment link or personal data may be involved. Give each institution the factual transaction reference, dates, amount, currency and documentation it requests. Follow their current procedures; they may vary by rail and jurisdiction.

Contain account risk at the same time. Change passwords through the real account site, review active sessions and recovery methods, apply available multi-factor authentication, and preserve relevant logs before deleting a compromised mailbox or device. Do not install remote-control tools because an unsolicited helper asks, share authentication codes, send money to a so-called safe account, or try to access another person account. If data exposure, theft or a serious dispute is possible, use the appropriate official reporting route and seek qualified local advice for the facts. A report and a case number are not a promise that funds will be recovered.

Use language that is both clear and non-accusatory. A useful note says that an invoice or beneficiary instruction differs from the last approved record, that you have paused action to protect both parties, and that you need confirmation from the named contact or portal. Do not frame the question as a test of trust. Genuine clients and finance teams normally benefit from the same control, because their own employees can be impersonated too. Keep the discussion focused on the invoice, version, contact route and next action instead of speculating about motives in a broad group thread.

After the matter is resolved, run a short retrospective with the client where appropriate. Decide which changes need dual confirmation, which domains and contacts are authoritative, whether a portal or vendor record should carry the current instruction, how invoice revisions are labelled, who receives a pre-payment callback, and what to do if a message looks wrong. Review access to your own templates, mailbox rules, file sharing and payment-provider settings. These controls reduce avoidable confusion but cannot guarantee that a future payment will be safe, available or recovered. For material contracts or a real incident, obtain advice suited to the parties and country involved.