XAdES Digital Signatures Explained: How E-Invoices Are Signed and Verified

XAdES (XML Advanced Electronic Signatures) is the ETSI standard — EN 319 132-1 — that extends the XML Digital Signature (XML-DSig) specification with the additional properties needed for long-term legal validity. It defines four baseline levels — B-B, B-T, B-LT, B-LTA — that progressively add timestamps, validation material, and archive timestamps. ZATCA Phase 2 uses XAdES-B-B-Sig with the CSID; Peppol signs the AS4 envelope and optionally the UBL payload; many EU qualified e-signature flows use XAdES-B-LT or B-LTA for 10-year retention.

Why XAdES matters

Almost every current e-invoicing mandate that signs documents at rest — ZATCA Phase 2, Peppol for some flows, MTD UK for VAT submissions — relies on XAdES. Knowing the levels is what lets you diagnose "signature invalid" rejections.

Almost every current e-invoicing mandate that signs documents at rest — ZATCA Phase 2, Peppol for some flows, MTD UK for VAT submissions — relies on XAdES. Knowing the levels is what lets you diagnose "signature invalid" rejections.

What XAdES actually is

XAdES — XML Advanced Electronic Signatures — is the ETSI standard ETSI EN 319 132-1 (current version v1.

XAdES — XML Advanced Electronic Signatures — is the ETSI standard ETSI EN 319 132-1 (current version v1.3.1, July 2024) that extends W3C XML-DSig with the properties needed for long-term legal validity: signed and unsigned properties for signing certificate, signing time, timestamps, validation data, and archive timestamps. It is the XML cousin of CAdES (for binary data, used by Brazil's NF-e) and PAdES (for PDFs, used by France's Factur-X human-readable layer).

The baseline signature levels

The baseline signature levels includes: XAdES-B-B (Baseline): Signature with the signer's certificate. Proves the document was signed by the holder of that certificate at some unspecified moment.

• XAdES-B-B (Baseline): Signature with the signer's certificate. Proves the document was signed by the holder of that certificate at some unspecified moment.
• XAdES-B-T (with Timestamp): Adds a trusted timestamp from a TSA (Time-Stamping Authority). Proves the signature existed at a specific point in time.
• XAdES-B-LT (Long-Term): Embeds the full certificate chain and revocation data (CRL/OCSP) needed to validate the signature years later, even if the issuing CA is gone.
• XAdES-B-LTA: Adds archive timestamps for indefinite preservation; the archive timestamp is renewed periodically to chain cryptographic strength across decades.

Each higher level is a strict superset of the one below.

How each regime uses XAdES

ZATCA Phase 2 (Saudi Arabia): XAdES-B-B-Sig embedded in the UBL 2. 1 invoice's UBLExtensions, signed with the Production CSID issued by ZATCA.

• ZATCA Phase 2 (Saudi Arabia): XAdES-B-B-Sig embedded in the UBL 2.1 invoice's UBLExtensions, signed with the Production CSID issued by ZATCA. The signed digest is bound into the TLV QR. Algorithm: SHA-256 with RSA-PSS.
• Peppol: The AS4 transport layer signs the SOAP envelope with the AP's Peppol certificate. Some receivers additionally require XAdES on the UBL payload itself for non-repudiation at rest.
• NF-e (Brazil): Uses XAdES with country-specific CAs (ICP-Brasil A1/A3 certificates). NFC-e uses the same chain.
• ZIMRA (Zimbabwe): ZIMRA-issued certificates with country-specific trust anchors.
• eIDAS qualified signatures: XAdES-B-LT or B-LTA with a qualified certificate from an EU Trust Service Provider listed in the EU Trusted List.

Certificates, chains, and trust anchors

A XAdES signature is only as trustworthy as the certificate that signs it.

A XAdES signature is only as trustworthy as the certificate that signs it. Three building blocks:

• End-entity certificate — the signer's certificate (e.g. ZATCA Production CSID, Peppol AP certificate).
• Certificate chain — intermediate CAs linking the end-entity to a trusted root.
• Trust anchor — the root the verifier trusts (ZATCA Root CA, Peppol Root, eIDAS EU Trusted List, ICP-Brasil Root).

For B-LT and B-LTA the verifier must also have access to revocation information (CRL or OCSP responses) captured at signing time, not at verification time — otherwise a revoked-since cert breaks validity.

Canonicalisation — the silent killer

XML can be serialised multiple ways for the same logical content (attribute order, whitespace, namespace prefixes).

XML can be serialised multiple ways for the same logical content (attribute order, whitespace, namespace prefixes). The signature is over a canonicalised form, so signer and verifier must use the same canonicalisation algorithm. Peppol and most modern profiles require Exclusive C14N (http://www.w3.org/2001/10/xml-exc-c14n#). Re-emitting XML after signing — even with no semantic change — invalidates the signature.

What fails in production

Clock drift: XAdES-B-T fails if the signing host clock differs from the TSA by more than a few seconds. Sync with NTP — most TSAs allow ±5 minutes but some are stricter.

1. Clock drift: XAdES-B-T fails if the signing host clock differs from the TSA by more than a few seconds. Sync with NTP — most TSAs allow ±5 minutes but some are stricter.
2. Canonicalisation mismatches: Signing one canonical form, verifying another. Always sign post-canonicalisation with Exclusive C14N.
3. Certificate expiry or revocation: A Production CSID rotates annually. A platform that does not rotate certificates ahead of expiry will fail clearance overnight.
4. Wrong digest algorithm: Regulators moved from SHA-1 → SHA-256 long ago; ZATCA explicitly requires SHA-256. Using a deprecated digest gets rejected.
5. Namespace prefix shuffling: Some implementations re-emit XML with different prefixes after signing. Even a prefix change invalidates the signature under standard C14N.
6. Missing revocation data on B-LT: Capturing CRL/OCSP at verification time instead of at signing time. If the cert is later revoked, the historic signature loses validity.
7. Wrong reference URI: The signature <Reference> points at a fragment that does not exist or has the wrong transform chain.

What this means for your platform

You should never be implementing XAdES yourself. The right abstraction is "sign this invoice for this jurisdiction"; the platform handles the level, certificate, timestamp, canonicalisation, and revocation capture.

You should never be implementing XAdES yourself. The right abstraction is "sign this invoice for this jurisdiction"; the platform handles the level, certificate, timestamp, canonicalisation, and revocation capture. Invoicemonk handles XAdES end to end for every supported mandate.

Key takeaways

Key takeaways includes: XAdES = XML-DSig + the metadata needed for long-term legal validity. Four baseline levels: B-B → B-T → B-LT → B-LTA, each a superset.

• XAdES = XML-DSig + the metadata needed for long-term legal validity.
• Four baseline levels: B-B → B-T → B-LT → B-LTA, each a superset.
• Canonicalisation is the most common silent failure — always use Exclusive C14N.
• Capture revocation data at signing time for any signature that needs to last beyond cert validity.

Related reading

Pillar: e-invoicing. Siblings: UBL 2.

Pillar: e-invoicing. Siblings: UBL 2.1 explained, what is a Peppol Access Point, Peppol EU explained. Mandate context: ZATCA Phase 2.

Sources

• ETSI EN 319 132-1 v1.3.1 — XAdES digital signatures (July 2024)
• W3C — XML Signature Syntax and Processing (Version 1.1)
• W3C — Exclusive XML Canonicalization Version 1.0
• ZATCA — E-Invoicing Systems Developers (XAdES profile)
• eIDAS Regulation (EU) 910/2014
• EU Trusted List Browser — Trust Service Providers