gPdf
Blog

PDF/A e Factur-X spiegati agli ingegneri, senza gergo legale

Che cosa vincolano davvero i profili PDF/A, perché Factur-X diventa obbligatorio nell'UE entro il 2026 e il percorso minimo per ottenere PDF conformi da un motore JSON.

gPdf Engineering
#pdf-a#factur-x#zugferd#fattura-elettronica#conformita

Se siete ingegneri e vi hanno appena detto “dal prossimo trimestre le fatture devono essere PDF/A-3 con Factur-X”, ma l’unico contesto è che qualcuno del team legale ha pronunciato quei termini, questo articolo è per voi.

Lasciamo da parte il tono dei documenti normativi e vediamo che cosa limitano davvero questi profili, perché le amministrazioni pubbliche hanno iniziato a renderli obbligatori e qual è il percorso tecnico minimo per emettere un PDF conforme da un motore che parte da dati strutturati.

PDF/A in due paragrafi

PDF è un formato flessibile. Troppo flessibile: la stessa specifica PDF permette di incorporare JavaScript, puntare a risorse esterne che potrebbero non esistere fra 50 anni, cifrare contenuti con crittografia reversibile, richiamare font esterni e molte altre cose che impediscono a un documento di essere autosufficiente.

PDF/A (“A” sta per Archival) è un profilo di PDF che vieta le parti che impedirebbero al documento di essere riprodotto nello stesso modo fra 50 anni. Le regole principali sono:

  • Tutti i font devono essere incorporati.
  • Niente JavaScript, collegamenti esterni, audio o video.
  • Niente cifratura.
  • Ogni trasparenza deve essere appiattita o supportata dalla versione del profilo.
  • I colori devono essere indipendenti dal dispositivo (serve un profilo ICC).
  • Tutto il contenuto deve stare nel file: nessun riferimento che dipenda dalla rete.

Esistono diverse versioni, ognuna con maggiore tolleranza per funzionalità più recenti:

Profilo Anno Che cosa aggiunge
PDF/A-1b 2005 Base originale, la più restrittiva
PDF/A-2b 2011 Consente JPEG2000, trasparenza e livelli
PDF/A-3b 2012 Consente allegati di file arbitrari (la base di Factur-X)
PDF/A-4 2020 Base ISO 32000-2 (PDF 2.0), livelli di conformità semplificati

Il suffisso “b” indica la conformità “basic” (fedeltà visiva). Esistono anche varianti “u” (mappatura Unicode) e “a” (tag per l’accessibilità). Per la maggior parte dei processi di fatture e ricevute, “b” è ciò che serve: la conservazione fiscale guarda alla riproducibilità visiva, non alla semantica per gli screen reader.

In pratica: se il vostro motore dichiara supporto per PDF/A-3b, dovrebbe bastare un singolo flag di configurazione ({ profile: "PDF/A-3b" } o equivalente). Se dovete eseguire un secondo strumento (Ghostscript, qpdf, Acrobat) per convertire dopo la generazione, quello è un punto operativo da mettere in conto.

Perché PDF/A-3 conta: è il contenitore delle fatture elettroniche

PDF/A-3 ha introdotto una capacità che si è rivelata decisiva: allegati di file arbitrari dentro il PDF.

Sembra un dettaglio noioso. Non lo è. È la base tecnica dei mandati di fatturazione elettronica che stanno arrivando in Europa.

L’architettura è un singolo file PDF che contiene sia

  1. Una fattura leggibile da una persona (layout visivo, totali, branding), cioè la parte che legge l’utente.
  2. Una fattura XML leggibile da software, cioè la parte analizzata dai sistemi dell’autorità fiscale.

Entrambe dentro lo stesso file, entrambe riferite alla stessa fattura, con il contenitore PDF/A-3 a garantire che il file resti interpretabile anche a distanza di decenni.

I principali formati XML:

  • Factur-X (Francia): profilo XML basato su UN/CEFACT Cross Industry Invoice
  • ZUGFeRD (Germania): sostanzialmente identico a Factur-X (i due standard sono stati unificati tecnicamente nel 2018)
  • EN 16931: la norma europea a cui entrambe le implementazioni si conformano

Per molti processi, “Factur-X” e “ZUGFeRD” sono termini intercambiabili: condividono uno schema, condividono il meccanismo di incorporazione e un singolo PDF conforme a uno dei due è in genere conforme anche all’altro.

Che cosa è obbligatorio, dove e quando

Uno snapshot non esaustivo per team tecnici che pianificano rilasci nel Q2/Q3 2026:

Paese Stato Formato richiesto
Germania B2B obbligatoria dal 2025-01-01 per la ricezione delle fatture; dal 2027 anche per l’emissione EN 16931 (Factur-X / ZUGFeRD / XRechnung)
Francia Emissione obbligatoria per grandi imprese da 2026-09; PMI da 2027-09 Factur-X via Chorus Pro
Italia B2B obbligatoria dal 2019 FatturaPA via SDI
Polonia Obbligatoria dal 2024-07 KSeF
Spagna Obbligatoria dal 2026 (B2B) Facturae via FACe
Belgio Obbligatoria dal 2026-01 Peppol BIS 3

Il modello è chiaro: ogni Stato membro dell’UE sta implementando una qualche variante di fatturazione elettronica conforme a EN 16931 lungo una finestra 2024-2027. Se i vostri clienti operano in questi mercati, il vostro generatore PDF dovrà produrre XML allegato insieme alla fattura visiva.

Il percorso pratico minimo

Dimenticate per un momento il linguaggio dei documenti normativi. Dal punto di vista ingegneristico, il percorso è questo:

   ┌─────────────────────┐
   │  Your invoice data  │  (already a JSON object somewhere)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Build EN 16931 XML  │  (deterministic mapping; well-tested libs exist)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Render PDF/A-3b +   │
   │ attach the XML      │  (single API call to gPdf — or two-step elsewhere)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │  Hand off to        │
   │  Chorus Pro / SDI / │
   │  Peppol / etc       │
   └─────────────────────┘

I due passaggi non banali:

Passaggio 1: costruire l’XML

È fastidioso, ma meccanico. Mappate i dati della fattura (righe, imposte, totali, parti) sui campi XML EN 16931. Esistono librerie Java, Node e Python che lo fanno per voi: cercate “factur-x library” nel linguaggio che usate. Non scrivetelo da zero, a meno che le specifiche XML Schema non siano davvero il vostro passatempo preferito.

Passaggio 2: generare PDF/A-3 e allegare l’XML

Qui la scelta del motore di rendering conta.

Senza supporto integrato: generate un PDF ordinario, poi lo post-elaborate con uno strumento che lo converte in PDF/A-3 e incorpora l’XML come file allegato. Stack comuni: Ghostscript + qpdf, oppure uno strumento a pagamento come Aspose. Due passaggi in più, due punti di errore in più, e dovete assicurarvi che la post-elaborazione non modifichi il layout visivo.

Con supporto integrato (l’approccio di gPdf): una chiamata.

curl -X POST https://api.gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "settings": {
      "profile": "pdfa-3b",
      "e_invoice": {
        "standard": "factur_x",
        "profile": "en16931",
        "document_type": "invoice",
        "xml": {
          "format": "cii",
          "encoding": "utf8",
          "content": "<?xml version=\"1.0\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
        }
      }
    },
    "pages": [{ "size": "a4", "elements": [/* invoice layout */] }]
  }' \
  --output invoice-with-einvoice.pdf

Questo è l’intero percorso. Il motore emette PDF/A-3b, incorpora il vostro XML come factur-x.xml (o zugferd-invoice.xml, entrambi riconosciuti dai sistemi che consumano questi formati) e restituisce i byte.

Errori comuni

Alcuni punti si imparano spesso nel modo peggiore:

“PDF/A” e “con font conformi a PDF/A” non sono la stessa cosa

Un file PDF/A-3 richiede che tutti i font siano incorporati con copertura completa dei glifi usati. Se la fattura contiene il nome di un cliente giapponese e il motore ricade su un font non completamente incorporabile, gli strumenti di verifica rifiuteranno il file. Controllate che il vostro motore incorpori i font CJK in modalità PDF/A: molti non lo fanno per impostazione predefinita.

Il visivo e l’XML devono coincidere

La fattura XML e la fattura visiva devono rappresentare la stessa fattura. I revisori fiscali le confronteranno. Se il codice emette XML con total: 119.00 e il PDF mostra Total: 120.00 per un bug di arrotondamento o un template non aggiornato, avete una discrepanza fiscale registrata. Generate entrambe dalla stessa fonte di verità, idealmente nello stesso percorso di codice.

Livelli di profilo in EN 16931

Factur-X ha profili: MINIMUM, BASIC, EN 16931, EXTENDED. Cambiano in base alla quantità di dati presenti nell’XML. Usate BASIC a meno che il cliente richieda esplicitamente altro: copre codici fiscali, righe, parti e totali, abbastanza per circa il 95% della fatturazione B2B. Il profilo EN 16931 aggiunge dettagli per casi limite.

Verifica prima dell’invio

Verificate sempre il PDF generato con un validatore PDF/A (veraPDF è lo standard open source) e verificate l’XML rispetto allo schema EN 16931 prima di inviare all’autorità fiscale. Invii falliti a Chorus Pro / SDI incidono sulle metriche di affidabilità verso il regolatore.

TL;DR

PDF/A è un profilo per documenti autosufficienti. PDF/A-3 permette di allegare file. Factur-X / ZUGFeRD significa “un XML EN 16931 allegato dentro un PDF/A-3”. I mandati di fatturazione elettronica nell’UE rendono questa combinazione il formato B2B di fatto tra il 2025 e il 2027.

Se il vostro motore tratta PDF/A-3 + Factur-X come un singolo flag di configurazione, la migrazione è meccanica. Se non lo fa, state costruendo un percorso operativo a più passaggi. /api/v1/e-invoice/render di gPdf è la versione a flag singolo: il riferimento API contiene lo schema completo, oppure potete provare una generazione di esempio nel Playground.