How to Validate an Invoice Digital Signature Before You Pay It

A supplier in Milan sends you a file called Fattura_2026_0187.xml.p7m. Your PDF reader won't open it, your ERP rejects it, and somebody suggests just asking for a normal PDF instead. What you're holding is an invoice digital signature, and discarding it is the one move that costs you later.

So don't. That .p7m wrapper carries the two things a tax auditor will eventually ask you about.

The first is authenticity of origin: assurance that the invoice really came from the supplier named on it. The second is integrity of content: proof that the amounts, the VAT number and the bank details are the ones the supplier put there. Article 233 of the EU VAT Directive names both, in those words, and requires them to hold from the moment the invoice is issued until the end of its storage period.

Now the part that trips up more accounts payable teams than the cryptography ever does.

A signature doesn't say the invoice is correct. A supplier can sign a wrong amount perfectly. It doesn't say the goods arrived, the purchase order matches, or that the bank details are the ones you agreed months ago. And it says nothing about whether the sender is solvent or honest.

An invoice digital signature answers exactly one question: did this precise file come from the holder of this certificate, unmodified? That's narrow. It's also the only question that gets harder to answer the longer you leave it, which is the whole argument for checking on arrival rather than at audit.

Most people assume EU law requires signed invoices. It hasn't since 2013.

Directive 2010/45/EU rewrote the invoicing rules and demoted the electronic signature from requirement to option. Article 233 now gives you three ways to guarantee authenticity of origin and integrity of content:

• Business controls that create a reliable audit trail between an invoice and the supply it relates to. Matching an invoice against a purchase order and a delivery note counts.
• An advanced electronic signature, optionally based on a qualified certificate.
• EDI, where the interchange agreement itself provides the guarantees.

So why does your inbox keep filling up with .p7m files?

National mandates. Brussels made signatures optional, then several member states made them compulsory for invoicing the public sector, and no supplier wants to run two pipelines. Italy requires every FatturaPA file sent to a public body to be signed with a qualified certificate. Spain requires the same for Facturae invoices going through FACe. Once a supplier has built a signing step for its public-sector customers, its ordinary B2B invoices tend to come out signed too.

There's a second reason, less about law and more about self-interest. Business controls are a process argument. When an auditor challenges an invoice from four years ago, "we had a three-way match policy" is a claim about how your team worked back then. A valid signature is evidence about that specific file. One of those is considerably easier to defend.

An invoice digital signature doesn't look the same in every country. Four combinations of format and signature cover almost everything arriving from European suppliers, and which one you're holding decides which validator you need. Guessing wastes an afternoon.

Two ETSI profiles do most of the work here. XAdES, short for XML Advanced Electronic Signatures, signs the XML itself. CAdES, short for CMS Advanced Electronic Signatures, wraps a binary envelope around whatever it signs.

FatturaPA (Italy). XML. The Sistema di Interscambio accepts two signature formats and only two: CAdES-BES Baseline B, which produces an .xml.p7m file, and XAdES-BES Baseline B, which leaves the extension as .xml. Italy's technical rules for signing are strict about the XML variant. Enveloped only, with the signature reference pointing at URI="" or URI="#iddoc". Detached and enveloping XAdES get bounced at the gate.

Facturae (Spain). XML at version 3.2.x, with an enveloped XAdES signature built into the document itself. Invoices to Spanish public bodies travel through FACe and must be signed with a certificate that qualifies under eIDAS. Signed files often arrive with an .xsig extension.

Factur-X and ZUGFeRD (France, Germany). A hybrid: PDF/A-3 with structured XML embedded inside it. When these carry a signature at all it's PAdES, sitting on the PDF rather than on the XML. Plenty arrive unsigned, and that's normal.

Peppol BIS Billing 3.0. UBL XML moving across the Peppol network. Worth knowing what this one isn't. Peppol secures the transport, with AS4 messaging between accredited access points, and the invoice document itself usually carries no signature at all. A Peppol invoice can arrive with nothing for you to validate. That's how the network is designed to work, and it isn't a warning sign.

Checking an invoice digital signature takes about five minutes, once you know which door to knock on.

Work out what you're actually holding

Extension first, because it tells you the signature format. Files ending .p7m or .p7s are CMS, so CAdES. Files ending .xml or .xsig are XAdES. A signed .pdf is PAdES. Containers ending .asice or .asics bundle the invoice and its signature together and turn up in Baltic and Nordic filings.

Not sure what you've got? Don't rename anything to find out. Chaindoc's signature verification takes all four through a single form and works the format out itself.

Upload the signature, plus the invoice if the signature is detached

Most invoice signatures are self-contained. An enveloped XAdES sits inside the XML it signed, and a .p7m carries the invoice within the envelope, so one file is all you need.

Detached signatures are the exception, and they're the reason people give up halfway. A .p7s, or a detached .xml, holds only the signature. The validator needs the invoice alongside it to recompute the digest, and it has to be the exact bytes the supplier signed rather than a copy that's been through your document management system. Get that wrong and you'll see an indeterminate result that looks like failure but isn't.

Read the report, not just the verdict

Anything worth calling a validation report names four separate findings: whether the content hash still matches the signed bytes, whether the certificate chain reaches a root the validator trusts, whether the certificate was revoked or expired at the time it was used, and whether a trusted timestamp fixes when signing happened.

Chaindoc runs those checks through the EU DSS library, the European Commission's own open-source validation code, and treats the EU Trusted List as its primary trust anchor. Major commercial certificate authorities are covered too, and an internal PKI can be handled with custom trust anchors. The check is free. You confirm your email address with a one-time code before the report is produced, and the file itself isn't kept afterwards.

Valid is where the interesting work starts, not where it stops.

Whose certificate is it?

This is the check almost nobody runs, and it's the one that catches invoice fraud. A signature can be cryptographically flawless and belong to the wrong company.

Open the certificate subject. Read the organisation name and the tax or VAT identifier inside it, then compare both against the supplier printed on the invoice and the supplier sitting in your vendor master. Someone running a payment-diversion scam still has to sign as somebody, and that somebody is written down in the certificate. Payment fraud is far more likely to reach you through a plausible sender than through broken maths.

Was the certificate valid when it was signed?

Not today. Certificates typically last one to three years and get revoked when a key leaks or an employee leaves.

An invoice from 2023 signed with a certificate that expired in 2024 is perfectly fine. That same invoice signed with a certificate revoked two weeks before the invoice date is not. Validators that compare against today's status instead of the status at signing time get both cases wrong, in opposite directions, and a trusted timestamp is what pins the date down in the first place.

Is it a signature or a seal?

People sign, companies seal. An electronic seal binds a document to a legal entity rather than to a named human, and it's what most invoicing systems actually apply, because no individual finance clerk wants their personal certificate on 4,000 invoices a month.

Neither is weaker than the other. The difference matters when you need to know who authorised something, since a seal names the company and stops there. Our guide to electronic seals under eIDAS works through where the line falls.

Does your policy need it qualified?

Valid and qualified are separate verdicts. Qualified means the issuing service appears on a national trusted list with qualified status, which is a lookup rather than a property of the cryptography. Italy demands a qualified certificate for FatturaPA going to the public sector. Your own AP policy may not demand it at all. Decide which you need before invoices start arriving, not after one fails. Qualified trust service providers and the EU Trusted List covers how that lookup actually works.

Most failures aren't fraud. They're handling.

The commonest by a distance: the file changed in transit. A mail gateway rewrote the attachment, an archiving system re-saved the XML with different whitespace, or a well-meaning colleague opened the invoice and saved it again. XML is especially brittle here, because canonicalization fixes precisely which bytes were signed, and a reformatting pass breaks the digest without altering a single visible character.

Next most common: the chain doesn't reach a trusted root. Often the supplier used a national or internal certificate authority that isn't on the EU Trusted List. The signature can be entirely sound. What failed is trust, not cryptography, and the fix is a policy decision about that issuer rather than a technical one.

Then there's the detached-signature case, which reports as indeterminate rather than invalid. The validator has a signature and nothing to check it against. Attach the original invoice and run it again.

So what do you do? Ask the supplier to resend the file exactly as it left their signing system, as a direct attachment rather than through a portal that might re-render it on the way out. If the second copy validates, you had a transport problem and no more than that. If it fails in exactly the same way, you now have a conversation worth having, and you're having it before the payment run instead of after.

Validate on arrival. Every part of checking an invoice digital signature gets harder with time.

The practical place is the ingestion gate, before an invoice reaches your ERP, where the signature check runs alongside duplicate detection and purchase order matching. The result should land on the invoice record as a stored artefact, not as a screen somebody looked at once. Teams handling a few signed invoices a month can do this by hand quite happily. Above that it wants an API, so validation happens whether or not anyone remembers to run it.

Retention is the part that gets underestimated. VAT rules across member states keep invoices for anywhere between six and eleven years, and the signature has to stay verifiable across that entire window. It won't manage that on its own. Certificates expire, certificate authorities go offline, revocation responders stop answering, and hash algorithms get retired.

That's the whole reason the long-term profiles exist. XAdES-BASELINE-LT bundles the certificates and revocation data into the file so it can still be checked after the issuing authority has disappeared. XAdES-BASELINE-LTA adds an archive timestamp on top of that. If a supplier sends you a BASELINE-B invoice and you need it defensible in 2033, that gap is yours to close, either by preserving the validation report you generated on arrival or by upgrading the signature yourself.

One rule holds regardless: store the original file. Not the extracted XML, not a PDF rendering, not a screenshot of a green tick. The signed bytes are the evidence.

US companies don't sign invoices, and no US regulator asks them to. The IRS cares about business records being complete and retrievable, which is roughly what its recordkeeping guidance has said for decades. No signature requirement, no mandated format.

So if you're running accounts payable in Chicago or Toronto, you're not in this because of your own tax authority. You're in it because your Italian, Spanish and Portuguese suppliers are, and their invoices show up carrying signatures your systems have never met.

Two things follow, and the second one is the useful one.

First, don't reject what you can't parse. Asking an Italian supplier for "just a PDF" often asks them to break their own compliance, and the convenience copy they send back may not be the file they actually reported to the tax authority. Keep the signed original even if your ERP only ingests the extracted data.

Second, you inherit no legal obligation by receiving a signed invoice, but you do inherit the file, and with it a control you didn't have to build. Validating on arrival takes a minute and tells you whether the bank details on that invoice are the ones your supplier put there. Invoice fraud doesn't respect jurisdictions. A signature that traces back to your supplier's real certificate beats any amount of squinting at the sender's email address.

Four patterns, all cheap to fix.

Treating the signature as an approval

It isn't one. A signed invoice is an authenticated invoice, and authentication says nothing about whether you owe the money. Your three-way match still has to happen, and the signature doesn't shorten it by a single step.

Stripping the wrapper to get the invoice into the ERP

Understandable, and it destroys the evidence. Extract the payload for processing if you must, then archive the original .p7m or signed .xml exactly as it arrived.

Checking the signature and never checking the subject

The expensive mistake. Payment-diversion fraud works by looking legitimate, and a valid signature from an entity that isn't quite your supplier looks extremely legitimate. Read the certificate subject every time.

Validating an invoice digital signature once and assuming it holds

It doesn't, not unaided. A BASELINE-B signature that verifies cleanly today may be unverifiable in five years through nobody's fault at all. Keep the report you generated on arrival.

Here's the summary worth keeping. An invoice digital signature answers a narrow question cheaply, and the answer becomes more expensive to obtain every month you wait. Run the check at ingestion, store the original file and the validation report together, and then go back to arguing about the amount, which was always the part that needed a human.