Your Invoice Fraud Controls Probably Never Look at the Signature

Business email compromise took $3 billion in reported losses during 2025, the second-largest category in the FBI's Internet Crime Complaint Center annual report after investment fraud. The same report logged 1,008,597 complaints and $20.877 billion in total losses, up 26% on the year before.

The control most organisations built in response is a callback procedure. Payment details changed? Phone the supplier on a number you already had. That control works, and it's worth having.

It also stops at the payment instruction. The document that carried the instruction usually goes unexamined.

Where invoice fraud actually slips through

Walk through what happens when a signed invoice arrives from a compromised supplier mailbox.

The attacker has access to real correspondence, so the thread looks right. They have real documents to work from, so the layout looks right. They edit the payment block in a PDF that was originally signed by the supplier, and they send it on.

The finance team opens it. The reader shows a signature panel, because there is still a signature object inside the file. Some readers show a warning, some do not, depending on which trust list they consult and whether they even attempt the check. What almost nobody does is read that panel carefully, because the panel is a technical artefact and the person opening the invoice is processing forty of them.

Here is the part worth sitting with: editing that PDF breaks the signature's integrity check every time. It isn't a subtle forensic question. A single altered byte fails the hash comparison. The evidence that the document was tampered with is sitting inside the file, and nobody looks.

Four questions, one icon

Signature validation is usually discussed as if it were a single yes or no. It's four separate checks, and they fail for different reasons.

Integrity asks whether the file changed after signing. This is the one that catches the edited invoice, and it is a straight hash comparison with no ambiguity.

Chain and trust asks whether the signing certificate leads back to an authority the validator recognises. This is configuration, not forensics, and it's the check most likely to throw a warning on a perfectly good document.

Revocation asks whether the certificate was live at the moment of signing, which is a different question from whether it is live now.

Timestamps ask whether there is proof of when the signing happened.

A reader that collapses all four into one yellow triangle is why teams learn to ignore the triangle. They see it on legitimate documents from legitimate suppliers, conclude it means nothing, and then miss the one occasion when integrity actually failed.

Turning verification into an invoice fraud control

The practical move is to separate the checks and put the integrity result somewhere a human will act on it.

For documents above a payment threshold, or from any supplier whose details changed recently, an independent PDF signature check takes under a minute. Chaindoc runs signed PDFs through the EU Digital Signature Service library against the EU Trusted List and reports integrity, the certificate and its chain, revocation status, embedded timestamps and the PAdES level as separate pass-or-fail lines rather than one verdict. Files up to 50 MB. The first check in a session asks for an email address and a one-time code, and the file is not retained afterwards.

Here's why the breakdown matters operationally: integrity failing and trust failing require opposite responses. Integrity failure means the file was altered after signing, and that's an incident. Trust failure usually means your validator does not know the issuing authority, which is an administrative gap, not a reason to hold a payment. Teams that can't tell these apart either escalate everything or escalate nothing, and both cost money. There is a longer walkthrough of which of the four checks failed when a reader shows a warning, if you're writing the runbook.

What this does not solve

Most invoices are not digitally signed at all. They are PDFs generated from an accounting system, with no signature object of any kind. Nothing described here applies to them, and pretending otherwise would be the wrong lesson to take away.

For that majority, the controls remain what they were: out-of-band confirmation of payment details, supplier bank data held in a system of record rather than pulled from the latest email, and separation of duties on changes. Document verification is an addition to that stack for the subset of documents that carry real signatures, not a replacement.

Automated document checks have their own limits worth understanding, particularly around what the models actually check versus what they infer. A system that scores a document as authentic from layout and typography is answering a different question from one that recomputes a hash.

How companies can protect against invoice fraud, practically

Pick the last twenty supplier invoices that arrived as PDFs. Count how many carry an actual digital signature. In most organisations the answer is somewhere between two and six, and nobody knows the number before they count it.

Those are the documents where a one-minute check gives a definite answer. For the rest, the honest position is that the PDF proves nothing about its own origin, and the control has to live elsewhere in the process.

Knowing which pile a document belongs to is the whole exercise. It's cheaper than the callback procedure and considerably cheaper than the wire that goes out to the wrong account.