Fatture e fatturazione elettronica

Spec Spec: EN 16931-1:2026, BT-24 EN 16931-1:2026 BT-24 Spec Spec: Factur-X 1.08 Factur-X 1.08 Spec Spec: ISO 32000-2:2020, §14.13 ISO 32000-2:2020 §14.13 Evidence ⊕ Mixed evidence Evidence: Mixed evidence

In sintesi

Una fattura moderna è costituita da due documenti in un unico file: una pagina leggibile da una persona e un payload XML leggibile dalle macchine, analizzato da un sistema fiscale. Questa pagina segue il percorso della fattura ibrida dall’obbligo all’output — che cosa richiedono effettivamente ZUGFeRD e Factur-X, come NextPDF allega e verifica il payload strutturato e dove la conformità esce dal perimetro del motore e resta in capo all’emittente.

Perché è importante

Diverse giurisdizioni impongono ormai fatture strutturate per la fatturazione tra imprese o tra impresa e pubblica amministrazione. L’insidia è che una fattura ibrida può apparire perfetta sullo schermo ed essere comunque respinta. Il rifiuto dipende dall’XML incorporato, non dai pixel. Se al payload strutturato manca l’identificatore di specifica, dichiara il profilo errato o è allegato con la relazione errata, la piattaforma ricevente lo respinge. Sul lato dell’emittente l’errore è spesso silenzioso e si manifesta giorni dopo, con un pagamento bloccato a valle.

Farlo correttamente una sola volta, nello strato che produce il file, costa molto meno che scoprire il problema una fattura alla volta.

In breve

• Una fattura ibrida conforme è un vettore PDF/A con un payload XML conforme incorporato come file associato. I metadati del vettore devono dichiarare il profilo.
• Il campo che più spesso decide l’accettazione è BT-24, l’identificatore di specifica. La regola di business BR-1 di EN 16931 richiede che ogni fattura lo riporti. Il valore è un URN che nomina il profilo esatto — per esempio l’urn:cen.eu:en16931:2017 del profilo EN 16931 (COMFORT).
• Il compito di NextPDF è l’incorporazione e la convalida strutturale dell’XML fornito dal chiamante. Non genera il contenuto della fattura e non è un validatore dell’autorità fiscale.
• L’emittente resta responsabile della correttezza legale e fiscale. Un esito di convalida senza rilievi è uno degli elementi di quella decisione, non un certificato.

Come NextPDF lo affronta

NextPDF tratta la fattura strutturata come un contratto tra livelli, non come una singola funzionalità. Il motore core definisce le interfacce — un incorporatore, un descrittore di profilo, un validatore — e il livello Premium ne fornisce le implementazioni. Questa separazione è deliberata. La superficie pubblica è congelata nel core, così i punti di chiamata e i test trattano profilo ed esito allo stesso modo, indipendentemente dal livello sottostante.

Il flusso ha quattro fasi e l’ordine conta, perché ogni fase dipende da quella precedente.

1. Author the invoice XML You (or your ERP) produce a UN/CEFACT CII or Peppol UBL payload. NextPDF never synthesizes invoice content.
2. Produce the PDF/A carrier A PDF/A-3 or PDF/A-4f document is the human-readable face and the conformant container the standard requires.
3. Embed the payload The embedder attaches the XML as an associated file with the correct AFRelationship, and injects the Factur-X XMP profile declaration.
4. Validate, then ship A structural pass checks the root, the required sections, and BT-24 against the declared profile before the file leaves your system.

Lo scenario della fattura elettronica ibrida dall'inizio alla fine: voi create l'XML e ne possedete la correttezza legale; NextPDF lo trasporta e lo verifica strutturalmente; la piattaforma ricevente prende la decisione finale di accettazione.

Il contratto dell’incorporatore è byte in ingresso, byte in uscita: entrano un vettore PDF/A e un payload XML, escono i byte del PDF ibrido. Prima di allegare qualsiasi cosa, l’XML viene analizzato con protezioni rafforzate che rifiutano un DOCTYPE, limitano la dimensione dell’input e rifiutano i caratteri di controllo vietati in XML 1.0. Questo elimina per costruzione gli attacchi XML External Entity e Billion-Laughs, poiché l’XML delle fatture arriva abitualmente dall’esterno del perimetro di fiducia del chiamante.

Il descrittore di profilo risponde alle quattro domande poste da un sistema a valle: l’URN canonico del profilo, il valore BT-24 da dichiarare, un nome stabile per i log e un discriminante neutro rispetto al livello, così che i test di parità possano raggruppare i risultati. Il descrittore è esplicito sulle lacune. Il profilo ZUGFeRD MINIMUM non riporta alcun identificatore di specifica BT-24 e il descrittore restituisce null per esso anziché fabbricarne uno. Per questo motivo anche MINIMUM e BASIC WL non sono conformi a EN 16931. Il motore codifica la cardinalità reale anziché nasconderla.

Human-factors note: Human-factors note

Il validatore ha due modalità e quella predefinita è la più conservativa. Nella modalità predefinita, un BT-24 mancante viene segnalato come avviso, così un flusso esistente basato su un valore booleano non regredisce silenziosamente. La modalità rigorosa promuove la stessa rilevazione a errore irreversibile, allineandosi alla semantica dei validatori esterni. La modalità è una scelta deliberata per ogni chiamata. Il motore non sceglie la postura di rischio al posto del chiamante e indica quale postura è attiva, anziché lasciarla dedurre.

Cosa dicono le prove

Il comportamento descritto sopra è ancorato a tre punti e ciascuno porta un tipo diverso di evidenza.

Lo standard fissa l’obbligo. Spec Spec: EN 16931-1:2026, BR-1 EN 16931-1:2026 BR-1 rende l’identificatore di specifica obbligatorio per ogni fattura. L’appendice tecnica di Factur-X fissa i valori URN per profilo, compreso quello del profilo EN 16931 urn:cen.eu:en16931:2017. Anche il vettore è una questione PDF: Spec Spec: ISO 32000-2:2020, §9 ISO 32000-2:2020 §9 osserva che la resa più prevedibile e affidabile si ottiene quando tutti i font sono incorporati — un punto direttamente rilevante, perché una fattura che deve essere leggibile tra dieci anni non può dipendere dall’ambiente dei font del lettore.

Il codice custodisce il contratto. Evidence { } Code-backed Evidence: Code-backed Le interfacce core EmbedderInterface, ProfileInterface e ValidatorInterface sono interfacce reali e neutre rispetto al livello. ProfileType::isEn16931Conformant() codifica l’esclusione di MINIMUM / BASIC WL nel sistema di tipi. ValidationResult è un DTO immutabile il cui isValid è la congiunzione di «nessuna rilevazione di errore» e «nessuna violazione fatale di regola».

Il comportamento è documentato come capacità del livello Premium: Evidence § Standard-backed Evidence: Standard-backed l’incorporatore allega l’XML CII ZUGFeRD 2.4 / Factur-X 1.08 o UBL Peppol fornito dal chiamante a un vettore PDF/A-4f o PDF/A-3b con la corretta relazione di file associato. Il validatore verifica il modello semantico EN 16931 e l’identificatore BT-24. La fase Schematron esegue i set di regole CEN compilati in XSLT. Nulla di tutto ciò genera o corregge il contenuto della fattura.

Esempio pratico

Lo schema seguente illustra il punto di giunzione, non è un’integrazione da copiare e incollare. La costruzione del vettore e l’incorporatore provengono dal livello Premium, e l’XML resta a carico del chiamante.

<?php

declare(strict_types=1);

use NextPDF\Contracts\EInvoice\ProfileType;
use NextPDF\Contracts\EInvoice\ValidatorContext;
use NextPDF\Contracts\EInvoice\ValidatorInterface;
use NextPDF\Contracts\EInvoice\EmbedderInterface;
use NextPDF\Contracts\EInvoice\EmbedderOptions;
use Psr\Log\LoggerInterface;

/**
 * Validate first, embed second, never ship an invalid payload.
 *
 * @param non-empty-string $carrierPdf  PDF/A-3 or PDF/A-4f carrier bytes
 * @param non-empty-string $ciiXml      Caller-authored UN/CEFACT CII XML
 *
 * @return non-empty-string Hybrid invoice bytes, ready to deliver
 */
function buildHybridInvoice(
    ValidatorInterface $validator,
    EmbedderInterface $embedder,
    LoggerInterface $logger,
    string $carrierPdf,
    string $ciiXml,
): string {
    // STRICT mode: a missing BT-24 is a hard error, not a warning.
    $context = new ValidatorContext(
        profile: ProfileType::EN16931,
        strictMode: true,
    );

    $result = $validator->validate($ciiXml, $context);

    if (!$result->isValid) {
        foreach ($result->getErrors() as $finding) {
            $logger->error('invoice.structural_finding', [
                'message' => $finding->message,
            ]);
        }

        // A failed structural check is your signal to stop, not to ship.
        throw new \RuntimeException('Invoice XML failed structural validation.');
    }

    $options = new EmbedderOptions(profile: ProfileType::EN16931);

    return $embedder->embed($carrierPdf, $ciiXml, $options);
}

L’ordine è il punto essenziale. La convalida è economica rispetto a una fattura respinta e a un pagamento ritardato, perciò viene eseguita prima ancora che il payload venga allegato.

Equivoco comune

L’equivoco più costoso è «NextPDF rende conformi le mie fatture.» Non è così, e il motore lo dichiara apertamente. Il motore incorpora e verifica strutturalmente l’XML creato dal chiamante. Un esito strutturale positivo significa che il payload ha la forma che EN 16931 si aspetta e dichiara il profilo richiesto. Non significa che la fattura sia legalmente sufficiente, approvata dall’autorità fiscale o garantita come accettabile da qualsiasi piattaforma di clearance. Le estensioni nazionali e i trasporti di clearance sono fuori ambito a livello di motore. Come lo inquadra la stessa EN 16931-1, il modello core porta le informazioni necessarie a supportare la conformità. L’emittente è responsabile del rispetto della normativa applicabile.

Una seconda insidia, più sottile: il supporto di uno standard non è conformità a esso. La conformità è una proprietà del file finale più un validatore, non una proprietà della libreria che lo ha prodotto.

Limiti e confini

• NextPDF non crea né corregge il contenuto della fattura. Il chiamante fornisce un XML valido e resta l’emittente della fattura. L’assenza di rilevazioni non rende conforme un payload non conforme.
• L’incorporazione strutturata e la convalida Schematron sono capacità del livello Premium. Il core definisce i contratti; le implementazioni richiedono il pacchetto commerciale. Vedere il confine riportato sotto.
• Il validatore verifica unicamente il modello semantico EN 16931 e il contenitore ZUGFeRD / Factur-X / UBL. Non è un validatore dell’autorità fiscale. I trasporti SDI, Chorus Pro e XRechnung sono fuori ambito a livello di trasporto.
• I profili MINIMUM e BASIC WL non sono conformi a EN 16931 e non riportano alcun identificatore di specifica BT-24 — per scelta progettuale: riflette la cardinalità dello standard, non un limite del motore.
• Il motore Schematron necessita di ext-xsl. I set di regole sono compilati in fase di build. Il runtime esegue solo l’XSLT precompilato, con il caricamento di risorse da rete e filesystem disabilitato.
• Questa pagina descrive il comportamento a livello di capacità. Non afferma l’accettazione da parte di alcuna autorità o piattaforma specifica.

Structured e-invoice embedding and validation — edition availability

Edition	Availability
Core	○ Il core definisce i contratti tra livelli (EmbedderInterface, ProfileInterface, ValidatorInterface) ma non fornisce alcuna implementazione di fattura strutturata. Un vettore PDF semplice senza alcun payload strutturato è il risultato del solo core.
Pro	○ Sono disponibili l’incorporazione CII Factur-X 1.08 in un vettore PDF/A e i descrittori del profilo EN 16931 .
Enterprise	○ Aggiunge l’incorporazione UBL Peppol BIS 3.0, il CIUS B2G XRechnung, la convalida XML COMPAT/STRICT e il motore di regole Schematron in-process.

Documenti correlati

• Archiviazione e PDF/A — perché il vettore della fattura è un file PDF/A e che cosa garantisce per la leggibilità nel lungo periodo.
• La guida alle decisioni di integrazione — quale pacchetto dell’ecosistema è più adatto a un flusso di fatturazione (generazione in coda, bridge per framework o Connect).
• Gestire NextPDF in produzione — come osservare le rilevazioni e gli errori di convalida quando le fatture scorrono ad alto volume.

Glossario

• Fattura ibrida — un singolo file PDF che è al contempo una pagina leggibile da una persona e un payload XML di fattura incorporato leggibile dalle macchine.
• ZUGFeRD / Factur-X — le denominazioni tedesca e francese del medesimo approccio alla fattura ibrida: un payload XML Cross Industry Invoice (CII) UN/CEFACT incorporato in un vettore PDF/A.
• EN 16931 — lo standard europeo che definisce il modello semantico dei dati degli elementi core di una fattura elettronica.
• BT-24 (Identificatore di specifica) — il termine di business di EN 16931 il cui valore è un URN che nomina il profilo esatto al quale la fattura è conforme. Richiesto dalla regola di business BR-1.
• Profilo — detto anche livello di conformità (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG). Determina quali termini di business una fattura deve riportare.
• File associato — un file allegato all’interno di un PDF con una relazione dichiarata (AFRelationship) che descrive il suo rapporto con il documento visibile; il meccanismo che trasporta l’XML della fattura.
• Schematron — un linguaggio di regole utilizzato per esprimere le regole di business EN 16931. NextPDF esegue i set di regole CEN compilati in XSLT.