Glossary Term

Digital signature (e-invoicing)

A cryptographic signature applied to an e-invoice (or its XML/PDF carrier) to guarantee authenticity of origin and integrity of content. In several EU CTC regimes — notably Italy's SDI and France's Chorus Pro — a qualified or advanced electronic signature is mandatory; in EN 16931 itself it is optional.

Quick Facts

Levels
Simple, Advanced (AdES), Qualified (QES)
Legal basis
EU VAT Directive 2006/112/EC, Art. 233; eIDAS (EU 910/2014)
Signing key
Qualified certificate from EU Trusted List QTSP
Mandatory in
Italy (SDI), Spain (FacturaE), Public sector across EU
Common formats
XAdES, CAdES, PAdES, ASiC
Not required by
EN 16931, Peppol BIS 3.0
Profile baseline
ETSI TS 101 903 / EN 319 122 / EN 319 132 / EN 319 142
Long-term archival
AdES-LTA with archival timestamps

Definition

What it is

A digital signature in the e-invoicing context is a cryptographic artefact bound to an invoice that proves two things at the same time: the invoice was issued by the entity it claims to be from (authenticity of origin), and it has not been altered since signing (integrity of content). The same two requirements appear verbatim in EU VAT Directive 2006/112/EC, Article 233, which is the legal anchor every Member State implements in its own way.

Under eIDAS (Regulation (EU) 910/2014), an electronic signature can be one of three levels:

  • Simple electronic signature (SES) — any electronic mark, including a typed name. Rarely sufficient for tax compliance.

  • Advanced electronic signature (AdES) — uniquely linked to the signatory, capable of identifying them, created with means under their sole control, and detectable if the data is altered.

  • Qualified electronic signature (QES) — an AdES backed by a qualified certificate issued by a Qualified Trust Service Provider (QTSP) listed on the EU Trusted List, and created with a Qualified Signature Creation Device (QSCD). Only QES is legally equivalent to a handwritten signature across all Member States.

    • Signature formats ERP developers actually encounter

    ETSI defines four AdES baseline profiles, each suited to a different carrier:

  • XAdES (ETSI TS 101 903 / EN 319 132) — XML signatures, typically enveloped inside the invoice XML. Used for FatturaPA in Italy, FacturaE in Spain, and several public-sector XML formats.

  • CAdES (ETSI EN 319 122) — CMS/PKCS#7 binary detached signatures. The original FatturaPA signed-file extension .xml.p7m is a CAdES-BES container wrapping the XML.

  • PAdES (ETSI EN 319 142) — PDF embedded signatures. Used when the invoice is a PDF or a hybrid PDF/A-3 (ZUGFeRD/Factur-X), or when an archival visual representation must remain visibly signed.

  • ASiC (ETSI EN 319 162) — Associated Signature Container, a ZIP wrapping an arbitrary payload plus its detached signature. Used for some Peppol attachments and increasingly for cross-format archival.

    • Each profile has "levels" stacked on top: -BES (basic), -T (with timestamp), -LT (long-term, with revocation data), and -LTA (with archival timestamps). Mandates typically require at minimum the -T level so the signature can be validated long after the certificate expires.

    Where signatures are mandatory in Europe

  • Italy (SDI / FatturaPA) — XAdES-BES or CAdES-BES with a qualified certificate. The SDI rejects unsigned or wrongly-signed files at submission time. Signature is on the entire FatturaElettronica element.

  • France (Chorus Pro / PPF) — Originally required a qualified seal for the public sector; under the September 2026 B2B mandate, the certified Plateforme Agréée model effectively delegates signature/seal responsibility to the platform rather than the issuer. Hybrid Factur-X invoices may be signed with PAdES.

  • Spain (FacturaE) — XAdES-EPES with a qualified certificate, mandatory for public-sector invoicing.

  • Poland (KSeF) — The platform itself signs and timestamps each invoice on acceptance; issuers authenticate via API token or qualified certificate but do not sign the XML.

  • Hungary (NAV RTIR) — Real-time reporting; no per-invoice signature, but secure transport with a qualified certificate is required.

    • Peppol BIS Billing 3.0 does not require an invoice-level signature — Peppol relies on transport-level security (mTLS with eDelivery) between Access Points, plus signed message-level metadata. EN 16931 likewise treats the signature as optional and out of scope.

    How an ERP usually implements it

    For a typical mid-sized ERP that needs to sign Italian FatturaPA, the moving parts are: a qualified signing certificate (HSM, smart card, or remote QSCD); a XAdES library (Apache Santuario, xades4j, .NET CryptoXMLSign extensions, or DSS from EU's CEF Digital); the canonicalisation algorithm (xml-exc-c14n#); the digest algorithm (SHA-256 minimum since 2016); and validated reference URIs that point to either the document root or a fragment ID. Common implementation pitfalls include double-canonicalisation, wrong namespace declarations on the Reference element, missing KeyInfo/X509Certificate, and clock drift on the timestamp.

    Relation to EN 16931

    EN 16931 is a semantic and syntactic standard for the structured invoice data; it intentionally does not define how authenticity and integrity must be proven. Member States choose the means: signature, mandated platform clearance, business-controls model, EDI agreement, or some combination. So when a CTC country requires a signature, it is layered on top of EN 16931 conformance, not in conflict with it.

    Related Content

    Learn
    E-Invoicing DeadlinesWhat is EN 16931?
    Countries
    E-Invoicing in France
    Glossary
    QR code (e-invoice)e-Reporting
    Blog
    ZUGFeRD 2.5 and Factur-X: What ERP Vendors Need to Ship Before the May 20, 2026 Release
    Validators
    ZUGFeRD ValidatorXRechnung Validator