Enterprise édition

Facture

En bref

NextPDF Enterprise produit des factures hybrides structurées ZUGFeRD / Factur-X / Peppol-UBL et valide le XML de facture par rapport au modèle de données EN 16931 et à des jeux de règles Schematron. Il produit des factures structurées conformes au modèle de données défini par EN 16931 ; ce n’est pas un validateur d’autorité fiscale et il ne certifie aucun document.

Disponibilité et licence

Cette capacité est livrée dans NextPDF Enterprise (nextpdf/enterprise) et s’active avec une enveloppe de licence de palier Enterprise. Un déploiement sans ce droit d’accès ne charge pas les classes de la capacité. Compare les éditions et obtiens une licence.

Installation

composer require nextpdf/enterprise:^3

Le moteur Schematron utilise l’extension PHP ext-xsl. Installe-la et active-la avant d’exécuter la validation Schematron.

Aperçu conceptuel

Le module Invoice a trois surfaces indépendantes : l’incorporation de facture structurée, la validation XML EN 16931 et l’exécution de règles Schematron.

Incorporation. ZugferdEmbedder attache une charge XML ZUGFeRD 2.4 / Factur-X 1.08 UN/CEFACT CII fournie par l’appelant à un porteur PDF/A, produisant une facture hybride. Deux formats de porteur sont pris en charge : PDF/A-4f (ISO 19005-4:2020), le porteur moderne préféré, et PDF/A-3b (ISO 19005-3:2012) pour la compatibilité ascendante. ZugferdXmpSchema injecte la déclaration de schéma d’extension XMP Factur-X dont le porteur a besoin. PeppolEmbedder joue le même rôle pour un XML de facture ou d’avoir UBL 2.1 Peppol BIS Billing 3.0 fourni par l’appelant, en l’attachant avec la relation de fichier associé et le type MIME corrects. NextPDF ne synthétise pas de XML de facture ; l’appelant fournit un XML valide et reste l’émetteur de la facture.

Validation. InvoiceXmlValidator vérifie le XML de facture par rapport au modèle de données sémantique EN 16931 et aux attentes de conteneur ZUGFeRD / Factur-X, y compris l’identifiant de spécification BT-24 que la règle de gestion EN 16931 BR-1 impose. Il s’exécute dans l’un de deux modes : COMPAT (le mode par défaut ; les constats de cardinalité EN 16931 limites sont signalés comme des avertissements afin de préserver la compatibilité ascendante des fixtures existantes) et STRICT (la cardinalité BT-24 est une erreur bloquante, reflétant la sémantique des validateurs externes). Le mode est sélectionnable par appel, par surcharge d’environnement ou par politique de conformité.

Schematron. SchematronValidator exécute des jeux de règles Schematron pré-compilés (les règles CEN EN 16931 .sch compilées en XSLT au moment du build) par rapport au XML de facture, à l’aide du processeur XSLT PHP en cours de processus, et analyse le rapport SVRL en constats structurés. L’énumération ZugferdProfile modélise les profils de conformité — MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, et le CIUS allemand XRechnung B2G sur EN 16931.

Ce que ce module revendique et ne revendique pas

Ce module produit et vérifie des données de facture structurées. Il n’affirme pas qu’un document est une facture légalement conforme, qu’il est approuvé par une autorité fiscale ou qu’il est garanti d’être accepté par une quelconque autorité.

Le validateur vérifie uniquement le modèle sémantique EN 16931 et le conteneur ZUGFeRD / Factur-X / UBL. Ce n’est pas un validateur d’autorité fiscale. Les extensions nationales et les plateformes de clearance — par exemple le SDI italien, le Chorus Pro français, le transport XRechnung allemand — sont hors périmètre au niveau du transport.
Comme EN 16931-1 l’indique elle-même, le modèle sémantique de base porte les informations essentielles dont une facture électronique a besoin pour soutenir la conformité légale et fiscale ; l’émetteur de la facture est responsable du respect des règles de la législation applicable. Ce n’est pas un validateur d’autorité fiscale.
Prendre en charge une norme n’équivaut pas à s’y conformer. Consulte tes conseillers fiscaux et de conformité pour juger de la suffisance réglementaire dans ta juridiction.

Pourquoi cela fonctionne ainsi

Le module ne synthétise délibérément jamais de XML de facture. L’incorporation, la validation EN 16931 et l’exécution Schematron sont trois surfaces indépendantes sur un XML que l’appelant fournit et possède. Cela fait de NextPDF un producteur et un vérificateur, jamais l’émetteur, car la responsabilité légale ne peut pas être déléguée à une bibliothèque. La validation utilise COMPAT par défaut, de sorte qu’un constat de cardinalité limite est un avertissement plutôt qu’une régression. STRICT est optionnel lorsque tu as besoin de la sémantique des validateurs externes. Le résultat est une séparation nette : NextPDF signale ce qu’il observe, et l’émetteur décide si le document respecte la loi. Contexte de conception : Factures et facturation électronique.

Surface d’API

Classe	Responsabilité
`ZugferdEmbedder`	Attache le XML ZUGFeRD / Factur-X CII à un porteur PDF/A-4f ou PDF/A-3b.
`ZugferdXmpSchema`	Injecte la déclaration de schéma d’extension XMP Factur-X.
`ZugferdProfile`	Énumération de profil de conformité (MINIMUM … EXTENDED, XRECHNUNG).
`PeppolEmbedder`	Attache le XML de facture / d’avoir UBL Peppol BIS 3.0 à un porteur PDF/A.
`InvoiceXmlValidator`	Vérifie le XML par rapport au modèle de données EN 16931 ; mode COMPAT ou STRICT.
`InvoiceValidatorMode`	Énumération de mode de validation : `COMPAT` (par défaut) ou `STRICT`.
`SchematronValidator`	Exécute des jeux de règles Schematron pré-compilés ; analyse les constats SVRL.
`InvoiceValidationResult` / `SchematronResult`	Résultats structurés : profil, constats, sévérités.

Exemple de code — Démarrage rapide

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

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

Exemple de code — Production

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.

Cas limites et pièges

Un PDF bien formé qui ne porte aucune charge de facture reconnaissable produit un résultat « pas une facture » plutôt que de lever une exception.
COMPAT est le mode de validation par défaut : un identifiant de spécification BT-24 manquant est signalé comme un avertissement, afin que les sites d’appel qui se basent sur un drapeau booléen de validité ne régressent pas. Utilise STRICT pour faire de BT-24 une erreur bloquante qui correspond à la sémantique de KoSIT / Mustang externe.
L’appelant fournit le XML de facture. NextPDF ne le génère ni ne le corrige ; une liste de constats vide ne rend pas conforme une charge non conforme.
Le moteur Schematron exige ext-xsl. Les jeux de règles sont compilés au moment du build ; l’exécution n’exécute que le XSLT pré-compilé.

Performance

Le coût de validation évolue avec la taille du XML incorporé et le nombre de règles Schematron. Le coût d’incorporation évolue avec la taille du porteur et est dominé par la sérialisation PDF/A. Le budget de performance de la page reflète le rendu de la documentation, pas le débit de factures.

Notes de sécurité

Toute analyse XML passe par le garde XML durci : la résolution des entités externes est désactivée (sûr contre les XXE), le DOCTYPE est rejeté, et la décompression est bornée. Le processeur XSLT s’exécute avec le chargement de ressources réseau et système de fichiers désactivé et n’enregistre jamais de fonctions PHP, de sorte que document(), xsl:include, xsl:import et result-document ne peuvent atteindre ni le réseau ni le disque. Traite le XML de facture issu de sources non fiables comme hostile.

Résidence des données et atténuations des données personnelles

Le XML de facture peut contenir des données personnelles, commerciales et financières. Le traitement est en cours de processus et local ; le module n’effectue aucun appel réseau sortant pendant l’incorporation ou la validation. Applique tes propres contrôles de rétention et de minimisation au XML extrait et aux constats.

Télémétrie sûre et nettoyage des journaux

Les constats et les journaux de validation peuvent inclure des identifiants de règles et des valeurs de balises. Ils n’incluent pas les charges de factures complètes. Nettoie ou caviarde les valeurs de champs avant de transférer les journaux vers des destinations partagées si ces valeurs sont sensibles.

Conformité

Comportement	Référence	Statut
Modèle sémantique de facture de base	EN 16931-1:2026 §4	Construit par rapport à ; l’émetteur reste responsable de la législation applicable
Identifiant de spécification (BT-24)	EN 16931-1:2026 BR-1	Vérifié (avertissement en COMPAT, erreur en STRICT)
Liaison de syntaxe UN/CEFACT CII	CEN/TS 16931-3-3:2020	Incorporation prise en charge
Liaison de syntaxe UBL 2.1	CEN/TS 16931-3-2:2020	Incorporation prise en charge
Fichier associé PDF/A-3	ISO 19005-3:2012 §6.7.8	Porteur pris en charge
Fichier incorporé PDF/A-4f	ISO 19005-4:2020 Annex A	Porteur pris en charge

Ce tableau consigne les spécifications par rapport auxquelles NextPDF Enterprise est construit et ce qu’il vérifie. Ce n’est pas une déclaration de certification, d’approbation par une autorité fiscale ou de suffisance réglementaire. L’émetteur de la facture est responsable du respect des règles de la législation applicable ; ce n’est pas un validateur d’autorité fiscale.

Comportement en mode FIPS

Ce module n’effectue aucune signature cryptographique. Signer une facture hybride et la garde de clés en mode FIPS sont hors périmètre ici ; voir le module Signature.

Modèle de menace

Le XML de facture non fiable est l’entrée principale. Atténuations : analyse sûre contre les XXE, rejet du DOCTYPE, décompression bornée, un processeur XSLT avec chargement de ressources réseau et fichiers désactivé, et aucune synthèse de revendication — l’appelant fournit et possède le contenu de la facture.

Contrat de comportement

ZugferdEmbedder / PeppolEmbedder attachent le XML de facture fourni par l’appelant à un porteur PDF/A-4f ou PDF/A-3b ; NextPDF ne synthétise jamais de XML de facture.
InvoiceXmlValidator s’exécute en COMPAT (par défaut ; la cardinalité EN 16931 limite est un avertissement) ou STRICT (la cardinalité BT-24 est une erreur bloquante).
SchematronValidator exécute des jeux de règles pré-compilés via le processeur XSLT en cours de processus et analyse les constats SVRL ; une liste de constats vide ne rend pas conforme une charge non conforme.
Toute analyse XML est sûre contre les XXE : résolution des entités externes désactivée, DOCTYPE rejeté, décompression bornée.

Frontière de publication

Cette page documente uniquement le comportement observable de l’extérieur et la surface d’API publique prise en charge. Les chemins d’espace de noms internes, les classes utilitaires, les tableaux de mécanismes, les noms de fichiers de runbook et les préfixes de tickets sont hors périmètre.

Repli Core

NextPDF Core ne génère ni ne valide de factures structurées. Un déploiement Core uniquement peut produire un PDF mais n’a aucune incorporation ZUGFeRD / Factur-X / Peppol, aucun validateur EN 16931 et aucun moteur Schematron.

Repli Pro

Dans un déploiement Pro uniquement, la surface prise en charge est la détection et la validation d’e-factures de palier Pro des charges Factur-X / ZUGFeRD. Pro ne génère pas de porteurs hybrides ZUGFeRD / Factur-X ou Peppol-UBL, n’ajoute pas le profil CIUS XRechnung et n’exécute pas le moteur Schematron en cours de processus ; une configuration qui demande la génération, le profil CIUS XRechnung ou Schematron dans un déploiement Pro uniquement n’a aucun composant Enterprise pour la satisfaire. Voir Conformité Pro pour la surface de détection et de validation de Pro.

Note sur la frontière Enterprise

Le détail interne des mécanismes reste dans la documentation interne du dépôt source et est hors du périmètre de ce manuel.

Frontière de déploiement

Le moteur Schematron exige l’extension PHP ext-xsl ; la provisionner et l’activer relève de la responsabilité de l’opérateur. Le traitement est en cours de processus et local ; le module n’effectue aucun appel réseau sortant pendant l’incorporation ou la validation. Le transport national d’e-facturation, les plateformes de clearance et les systèmes d’archivage sont externes à ce module et relèvent de la responsabilité de l’opérateur.

Frontière de conformité légale

NextPDF produit des factures structurées conformes au modèle de données défini par EN 16931 et signale des constats de règles. Il ne produit pas de « factures légalement conformes », ne fournit pas de sortie « approuvée par une autorité fiscale » et ne garantit pas qu’une facture sera acceptée par une autorité fiscale, un tribunal ou un registre. L’émetteur de la facture est responsable du respect des règles de la législation applicable ; ce n’est pas un validateur d’autorité fiscale. Les plateformes nationales d’e-facturation, les modèles de clearance, les mandats d’archivage et les exigences de signature numérique varient selon la juridiction et relèvent de la responsabilité de l’émetteur. Consulte tes conseillers fiscaux et juridiques.

Voir aussi

Référence Facture — référence au niveau de l’API pour les incorporateurs, les validateurs et le moteur Schematron.
Conformité Pro — détection et validation d’e-factures de palier Pro.
Document E-Filing — optimisation de la remise vers les tribunaux/registres.
Aperçu Enterprise
Matrice des fonctionnalités Core vs Pro vs Enterprise