Fattura

In sintesi

NextPDF Enterprise produce fatture ibride strutturate ZUGFeRD / Factur-X / Peppol-UBL e convalida l’XML delle fatture rispetto al modello dati EN 16931 e ai set di regole Schematron. Produce fatture strutturate conformi al modello dati definito nella EN 16931; non è un validatore di un’autorità fiscale e non certifica alcun documento.

Disponibilità e licenze

Questa funzionalità è distribuita in NextPDF Enterprise (nextpdf/enterprise) e si attiva con un envelope di licenza di livello Enterprise. Una distribuzione priva di tale entitlement non carica le classi della funzionalità. Confronta le edizioni e ottieni una licenza.

Installazione

composer require nextpdf/enterprise:^3

Il motore Schematron usa l’estensione PHP ext-xsl. Installarla e abilitarla prima di eseguire la convalida Schematron.

Panoramica concettuale

Il modulo Invoice ha tre superfici indipendenti: incorporamento di fatture strutturate, convalida XML EN 16931 ed esecuzione di regole Schematron.

Incorporamento. ZugferdEmbedder allega un payload XML ZUGFeRD 2.4 / Factur-X 1.08 UN/CEFACT CII fornito dal chiamante a un carrier PDF/A, producendo una fattura ibrida. Sono supportati due formati di carrier: PDF/A-4f (ISO 19005-4:2020), il carrier moderno preferito, e PDF/A-3b (ISO 19005-3:2012) per compatibilità all’indietro. ZugferdXmpSchema inietta la dichiarazione dello schema di estensione XMP Factur-X di cui il carrier ha bisogno. PeppolEmbedder svolge lo stesso ruolo per l’XML di fattura o nota di credito Peppol BIS Billing 3.0 UBL 2.1 fornito dal chiamante, allegandolo con la corretta relazione di file associato e il corretto tipo MIME. NextPDF non sintetizza l’XML della fattura; il chiamante fornisce un XML valido e resta l’emittente della fattura.

Convalida. InvoiceXmlValidator verifica l’XML della fattura rispetto al modello dati semantico EN 16931 e alle aspettative del contenitore ZUGFeRD / Factur-X, incluso l’identificatore di specifica BT-24 imposto dalla regola di business BR-1 della EN 16931. Viene eseguito in una delle due modalità: COMPAT (l’impostazione predefinita; i rilievi limite sulla cardinalità EN 16931 sono riportati come avvisi per preservare la compatibilità all’indietro con le fixture esistenti) e STRICT (la cardinalità BT-24 è un errore bloccante, che rispecchia la semantica dei validatori esterni). La modalità è selezionabile per ciascuna chiamata, tramite override d’ambiente o tramite politica di conformità.

Schematron. SchematronValidator esegue set di regole Schematron pre-compilati (le regole CEN EN 16931 .sch compilate in XSLT in fase di build) sull’XML della fattura usando il processore XSLT PHP in-process e analizza il report SVRL in rilievi strutturati. L’enum ZugferdProfile modella i profili di conformità — MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED e il CIUS tedesco XRechnung B2G su EN 16931.

Che cosa questo modulo asserisce e che cosa non asserisce

Questo modulo produce e verifica dati di fattura strutturati. Non asserisce che un documento sia una fattura conforme alla legge, che sia approvato da un’autorità fiscale o che ne sia garantita l’accettazione da parte di una qualsiasi autorità.

• Il validatore verifica esclusivamente il modello semantico EN 16931 e il contenitore ZUGFeRD / Factur-X / UBL. Non è un validatore di un’autorità fiscale. Le estensioni nazionali e le piattaforme di clearance — per esempio l’italiano SDI, il francese Chorus Pro, il trasporto tedesco XRechnung — sono fuori ambito a livello di trasporto.
• Come afferma la stessa EN 16931-1, il modello semantico di base trasporta le informazioni essenziali di cui una fattura elettronica ha bisogno per supportare la conformità legale e fiscale; l’emittente della fattura è responsabile del rispetto delle regole della legislazione applicabile. Questo non è un validatore di un’autorità fiscale.
• Il supporto di uno standard non equivale alla conformità a esso. Consultare i propri consulenti fiscali e di conformità per valutare la sufficienza normativa nella propria giurisdizione.

Perché funziona così

Il modulo deliberatamente non sintetizza mai l’XML della fattura. Incorporamento, convalida EN 16931 ed esecuzione Schematron sono tre superfici indipendenti sull’XML che il chiamante fornisce e possiede. Questo mantiene NextPDF un produttore e un verificatore, mai l’emittente, perché la responsabilità legale non può essere delegata a una libreria. La convalida assume come impostazione predefinita COMPAT, così un rilievo limite sulla cardinalità è un avviso anziché una regressione. STRICT è opt-in quando serve la semantica dei validatori esterni. Il risultato è una separazione netta: NextPDF riporta ciò che osserva, e l’emittente decide se il documento soddisfa la legge. Contesto progettuale: Fatture e fatturazione elettronica.

Superficie API

Classe	Responsabilità
ZugferdEmbedder	Allega l’XML CII ZUGFeRD / Factur-X a un carrier PDF/A-4f o PDF/A-3b.
ZugferdXmpSchema	Inietta la dichiarazione dello schema di estensione XMP Factur-X.
ZugferdProfile	Enum dei profili di conformità (MINIMUM … EXTENDED, XRECHNUNG).
PeppolEmbedder	Allega l’XML di fattura / nota di credito Peppol BIS 3.0 UBL a un carrier PDF/A.
InvoiceXmlValidator	Verifica l’XML rispetto al modello dati EN 16931; modalità COMPAT o STRICT.
InvoiceValidatorMode	Enum della modalità di convalida: COMPAT (predefinita) o STRICT.
SchematronValidator	Esegue set di regole Schematron pre-compilati; analizza i rilievi SVRL.
InvoiceValidationResult / SchematronResult	Risultati strutturati: profilo, rilievi, severità.

Esempio di codice — Avvio rapido

use NextPDF\Enterprise\Invoice\ZugferdEmbedder;
use NextPDF\Enterprise\Invoice\ZugferdProfile;

$pdf = ZugferdEmbedder::basic($pdfAManager, $fileAttachment, $ciiXml)
    ->embed(ZugferdProfile::EN16931);

Esempio di codice — Produzione

use NextPDF\Enterprise\Invoice\InvoiceXmlValidator;
use NextPDF\Enterprise\Invoice\InvoiceValidatorMode;

$result = $validator->validate($ciiXml, InvoiceValidatorMode::STRICT);

foreach ($result->findings as $finding) {
    $logger->warning('invoice.finding', [
        'rule'     => $finding->ruleId,
        'severity' => $finding->severity->value,
    ]);
}
// A clean result is one input to your decision, not a compliance verdict.
// The invoice issuer remains responsible for relevant legislation.

Casi limite e insidie

• Un PDF ben formato che non porta alcun payload di fattura riconoscibile produce un risultato “non è una fattura” anziché sollevare un’eccezione.
• COMPAT è la modalità di convalida predefinita: un identificatore di specifica BT-24 mancante è riportato come avviso, perciò i punti di chiamata che basano la decisione su un flag booleano di validità non regrediscono. Usare STRICT per rendere BT-24 un errore bloccante che corrisponde alla semantica esterna di KoSIT / Mustang.
• Il chiamante fornisce l’XML della fattura. NextPDF non lo genera né lo corregge; un elenco di rilievi vuoto non rende conforme un payload non conforme.
• Il motore Schematron richiede ext-xsl. I set di regole sono compilati in fase di build; in fase di esecuzione viene eseguito esclusivamente l’XSLT pre-compilato.

Prestazioni

Il costo della convalida cresce con la dimensione dell’XML incorporato e il numero di regole Schematron. Il costo dell’incorporamento cresce con la dimensione del carrier ed è dominato dalla serializzazione PDF/A. Il budget di prestazioni della pagina riflette il rendering della documentazione, non il throughput delle fatture.

Note di sicurezza

Tutto il parsing XML passa attraverso la guardia XML rafforzata: la risoluzione delle entità esterne è disabilitata (sicura rispetto a XXE), il DOCTYPE è rifiutato e la decompressione è limitata. Il processore XSLT viene eseguito con il caricamento delle risorse di rete e di file system disabilitato e non registra mai funzioni PHP, perciò document(), xsl:include, xsl:import e result-document non possono raggiungere la rete o il disco. Trattare come ostile l’XML di fattura proveniente da fonti non attendibili.

Residenza dei dati e mitigazioni dei dati personali (PII)

L’XML di fattura può contenere dati personali, commerciali e finanziari. L’elaborazione è in-process e locale; il modulo non effettua alcuna chiamata di rete in uscita durante l’incorporamento o la convalida. Applicare i propri controlli di conservazione e minimizzazione all’XML estratto e ai rilievi.

Telemetria sicura e sanificazione dei log

I rilievi e i log di convalida possono includere identificatori di regole e valori di tag. Non includono i payload completi delle fatture. Sanificare o oscurare i valori dei campi prima di inoltrare i log a destinazioni condivise se tali valori sono sensibili.

Conformità

Comportamento	Riferimento	Stato
Modello semantico di base della fattura	EN 16931-1:2026 §4	Sviluppato su tale base; l’emittente resta responsabile della legislazione applicabile
Identificatore di specifica (BT-24)	EN 16931-1:2026 BR-1	Verificato (avviso in COMPAT, errore in STRICT)
Binding di sintassi UN/CEFACT CII	CEN/TS 16931-3-3:2020	Incorporamento supportato
Binding di sintassi UBL 2.1	CEN/TS 16931-3-2:2020	Incorporamento supportato
File associato PDF/A-3	ISO 19005-3:2012 §6.7.8	Carrier supportato
File incorporato PDF/A-4f	ISO 19005-4:2020 Annex A	Carrier supportato

Questa tabella registra le specifiche su cui NextPDF Enterprise è sviluppato e ciò che verifica. Non è una dichiarazione di certificazione, di approvazione di un’autorità fiscale o di sufficienza normativa. L’emittente della fattura è responsabile del rispetto delle regole della legislazione applicabile; questo non è un validatore di un’autorità fiscale.

Comportamento in modalità FIPS

Questo modulo non esegue alcuna firma crittografica. La firma di una fattura ibrida e la custodia delle chiavi in modalità FIPS sono fuori ambito qui; vedere il modulo Signature.

Modello di minaccia

L’XML di fattura non attendibile è l’input principale. Mitigazioni: parsing sicuro rispetto a XXE, rifiuto del DOCTYPE, decompressione limitata, un processore XSLT con il caricamento delle risorse di rete e di file disabilitato e nessuna sintesi di asserzioni — il chiamante fornisce e possiede il contenuto della fattura.

Contratto di comportamento

• ZugferdEmbedder / PeppolEmbedder allegano l’XML di fattura fornito dal chiamante a un carrier PDF/A-4f o PDF/A-3b; NextPDF non sintetizza mai l’XML della fattura.
• InvoiceXmlValidator viene eseguito in COMPAT (predefinita; la cardinalità limite EN 16931 è un avviso) o STRICT (la cardinalità BT-24 è un errore bloccante).
• SchematronValidator esegue set di regole pre-compilati tramite il processore XSLT in-process e analizza i rilievi SVRL; un elenco di rilievi vuoto non rende conforme un payload non conforme.
• Tutto il parsing XML è sicuro rispetto a XXE: risoluzione delle entità esterne disabilitata, DOCTYPE rifiutato, decompressione limitata.

Confine di pubblicazione

Questa pagina documenta solo il comportamento osservabile dall’esterno e la superficie dell’API pubblica supportata. I percorsi di namespace interni, le classi helper, le tabelle dei meccanismi, i nomi di file di runbook e i prefissi di ticket sono fuori ambito.

Fallback di Core

NextPDF Core non genera né convalida fatture strutturate. Una distribuzione solo Core può produrre un PDF ma non dispone dell’incorporamento ZUGFeRD / Factur-X / Peppol, di alcun validatore EN 16931 né di alcun motore Schematron.

Fallback di Pro

In una distribuzione solo Pro, la superficie supportata è il rilevamento e la convalida di livello Pro delle fatture elettroniche dei payload Factur-X / ZUGFeRD. Pro non genera carrier ibridi ZUGFeRD / Factur-X o Peppol-UBL, non aggiunge il profilo CIUS XRechnung e non esegue il motore Schematron in-process; una configurazione che richiede la generazione, il profilo CIUS XRechnung o Schematron in una distribuzione solo Pro non ha alcuna componente Enterprise che la soddisfi. Vedere Pro Compliance per la superficie Pro di rilevamento e convalida.

Nota sul confine Enterprise

Il dettaglio interno dei meccanismi resta nella documentazione interna del repository sorgente ed è fuori ambito per questo manuale.

Confine di distribuzione

Il motore Schematron richiede l’estensione PHP ext-xsl; il provisioning e l’abilitazione sono responsabilità dell’operatore. L’elaborazione è in-process e locale; il modulo non effettua alcuna chiamata di rete in uscita durante l’incorporamento o la convalida. Il trasporto nazionale di fatturazione elettronica, le piattaforme di clearance e i sistemi di archiviazione sono esterni a questo modulo e sono responsabilità dell’operatore.

Confine di conformità legale

NextPDF produce fatture strutturate conformi al modello dati definito nella EN 16931 e riporta i rilievi delle regole. Non produce “fatture conformi alla legge”, non fornisce un output “approvato da un’autorità fiscale” e non garantisce che una qualsiasi fattura sarà accettata da un’autorità fiscale, da un tribunale o da un registro. L’emittente della fattura è responsabile del rispetto delle regole della legislazione applicabile; questo non è un validatore di un’autorità fiscale. Le piattaforme nazionali di fatturazione elettronica, i modelli di clearance, gli obblighi di archiviazione e i requisiti di firma digitale variano per giurisdizione e sono responsabilità dell’emittente. Consultare i propri consulenti fiscali e legali.

Vedere anche

• Riferimento Fattura — riferimento a livello di API per gli embedder, i validatori e il motore Schematron.
• Pro Compliance — rilevamento e convalida di fatture elettroniche di livello Pro.
• Archiviazione elettronica dei documenti — ottimizzazione del recapito verso tribunali/registri.
• Panoramica di Enterprise
• Matrice delle funzionalità Core vs Pro vs Enterprise