Factures et facturation électronique

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

En un coup d’œil

Une facture moderne réunit deux documents dans un même fichier : une page lisible par une personne et une charge utile XML lisible par machine, qu’un système fiscal analyse. Cette page suit le scénario de la facture hybride, de l’obligation jusqu’au fichier produit — ce qu’exigent réellement ZUGFeRD et Factur-X, la façon dont NextPDF attache et contrôle la charge utile structurée, et la limite où la conformité cesse de relever du moteur pour devenir ta responsabilité.

Pourquoi c’est important

Plusieurs juridictions imposent désormais des factures structurées pour la facturation entre entreprises ou entre une entreprise et l’administration. Le piège, c’est qu’une facture hybride peut sembler parfaite à l’écran et être malgré tout rejetée. Le rejet porte sur le XML intégré, pas sur les pixels. Si la charge utile structurée n’a pas l’identifiant de spécification, déclare le mauvais profil ou est attachée avec une relation incorrecte, la plateforme réceptrice la rejette. De ton côté, l’échec est souvent silencieux et n’apparaît que plusieurs jours plus tard, avec un paiement bloqué à la clé.

Bien traiter le sujet une fois, dans la couche qui produit le fichier, coûte beaucoup moins cher que de découvrir le problème facture par facture.

En bref

• Une facture hybride conforme est un porteur PDF/A avec une charge utile XML conforme intégrée comme fichier associé. Les métadonnées du porteur doivent déclarer le profil.
• Le champ qui conditionne le plus souvent l’acceptation est BT-24, l’identifiant de spécification. La règle de gestion BR-1 d’EN 16931 impose que chaque facture le porte. La valeur est une URN qui nomme le profil exact — par exemple l’urn:cen.eu:en16931:2017 du profil EN 16931 (COMFORT).
• Le rôle de NextPDF est l’intégration et la validation structurelle du XML fourni par l’appelant. Il ne rédige pas le contenu de la facture et n’est pas un validateur d’administration fiscale.
• L’émetteur reste responsable de l’exactitude juridique et fiscale. Un résultat de validation sans erreur est un élément de cette décision, pas un certificat.

L’approche de NextPDF

NextPDF traite la facture structurée comme un contrat inter-niveaux, pas comme une fonctionnalité isolée. Le moteur central définit les interfaces — un intégrateur, un descripteur de profil, un validateur — et le niveau Premium en fournit les implémentations. Cette séparation est délibérée. La surface publique est figée dans le central, de sorte que les points d’appel et les tests manipulent le profil et le résultat de la même manière, quel que soit le niveau sous-jacent.

Le flux comporte quatre étapes, et l’ordre importe car chaque étape dépend de la précédente.

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.

Le scénario de la facture électronique hybride de bout en bout : tu rédiges le XML et tu réponds de son exactitude juridique ; NextPDF le transporte et le contrôle structurellement ; la plateforme réceptrice prend la décision finale d’acceptation.

Le contrat de l’intégrateur tient en deux flux : octets entrants, octets sortants. Un porteur PDF/A et une charge utile XML entrent ; les octets du PDF hybride sortent. Avant qu’un élément soit attaché, le XML est analysé par un garde-fou renforcé qui rejette un DOCTYPE, plafonne la taille de l’entrée et refuse les caractères de contrôle interdits par XML 1.0. Cela élimine par construction les attaques XML External Entity et Billion-Laughs, car le XML de facture vient souvent de l’extérieur de ta frontière de confiance.

Le descripteur de profil répond aux quatre questions que pose un système en aval : l’URN canonique du profil, la valeur BT-24 à déclarer, un nom stable pour les journaux et un discriminant indépendant du niveau pour que les tests de parité puissent regrouper les résultats. Le descripteur ne masque pas les lacunes. Le profil ZUGFeRD MINIMUM ne porte aucun identifiant de spécification BT-24, et le descripteur renvoie null pour lui plutôt que d’en fabriquer un. C’est aussi pourquoi MINIMUM et BASIC WL ne sont pas conformes à EN 16931. Le moteur encode la réalité de la cardinalité plutôt que de la masquer.

Human-factors note: Human-factors note

Le validateur a deux modes, et celui par défaut est le plus prudent. Dans le mode par défaut, un BT-24 manquant est signalé comme un avertissement afin qu’un pipeline existant qui se déclenche sur un booléen ne régresse pas silencieusement. Le mode strict promeut le même constat en erreur bloquante, conformément à la sémantique des validateurs externes. Le mode est un choix délibéré que tu fais à chaque appel. Le moteur ne choisit pas ta posture de risque à ta place, et il t’indique quelle posture est active au lieu de te laisser la déduire.

Ce que disent les preuves

Le comportement ci-dessus s’appuie sur trois sources, chacune avec un type de preuve différent.

La norme fixe l’obligation. Spec Spec: EN 16931-1:2026, BR-1 EN 16931-1:2026 BR-1 rend l’identifiant de spécification obligatoire pour chaque facture. L’annexe technique de Factur-X fixe les valeurs d’URN par profil, dont celle du profil EN 16931 urn:cen.eu:en16931:2017. Le porteur lui-même est une question de PDF : Spec Spec: ISO 32000-2:2020, §9 ISO 32000-2:2020 §9 note que le rendu le plus prévisible et le plus fiable se produit lorsque toutes les polices sont intégrées — un point directement pertinent, car une facture qui doit rester lisible dans dix ans ne peut pas dépendre de l’environnement de polices du lecteur.

Le code porte le contrat. Evidence { } Code-backed Evidence: Code-backed Les EmbedderInterface, ProfileInterface et ValidatorInterface du central sont de vraies interfaces, indépendantes du niveau. ProfileType::isEn16931Conformant() encode l’exclusion de MINIMUM / BASIC WL dans le système de types. ValidationResult est un DTO immuable dont isValid est la conjonction de « aucun constat d’erreur » et « aucune violation de règle fatale ».

Le comportement est documenté comme capacité du niveau Premium : Evidence § Standard-backed Evidence: Standard-backed l’intégrateur attache le XML CII ZUGFeRD 2.4 / Factur-X 1.08 ou UBL Peppol fourni par l’appelant à un porteur PDF/A-4f ou PDF/A-3b avec la relation de fichier associé correcte. Le validateur vérifie le modèle sémantique EN 16931 et l’identifiant BT-24. L’étape Schematron exécute les jeux de règles CEN compilés en XSLT. Rien de tout cela ne génère ni ne corrige le contenu de la facture.

Exemple pratique

L’exemple ci-dessous illustre l’assemblage ; ce n’est pas une intégration à copier-coller. La construction du porteur et l’intégrateur relèvent du niveau Premium, et le XML est le tien.

<?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’ordre est essentiel. La validation est peu coûteuse au regard d’une facture rejetée et d’un paiement retardé : elle s’exécute donc avant que la charge utile soit attachée.

Idée fausse courante

L’idée fausse la plus coûteuse est « NextPDF rend mes factures conformes. » Il ne le fait pas, et il le dit clairement. Le moteur intègre et contrôle structurellement le XML que tu rédiges. Un résultat de contrôle structurel positif signifie que la charge utile a la forme qu’attend EN 16931 et déclare le profil que tu as demandé. Cela ne signifie pas que la facture est juridiquement suffisante, approuvée par l’administration fiscale ou garantie d’être acceptée par une plateforme de dédouanement quelconque. Les extensions nationales et les transports de dédouanement sont hors périmètre au niveau du moteur. Comme le formule EN 16931-1 elle-même, le modèle central porte l’information nécessaire pour appuyer la conformité. L’émetteur est responsable du respect de la législation applicable.

Un second piège, plus discret : la prise en charge d’une norme n’est pas la conformité à celle-ci. La conformité est une propriété du fichier final associé à un validateur, pas une propriété de la bibliothèque qui l’a produit.

Limites et frontières

• NextPDF ne rédige ni ne corrige le contenu de la facture. L’appelant fournit un XML valide et reste l’émetteur de la facture. Une liste de constats vide ne rend pas conforme une charge utile non conforme.
• L’intégration structurée et la validation Schematron sont des capacités du niveau Premium. Le central définit les contrats ; les implémentations nécessitent le paquet commercial. Voir la frontière ci-dessous.
• 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’administration fiscale. Les transports SDI, Chorus Pro et XRechnung sont hors périmètre au niveau du transport.
• Les profils MINIMUM et BASIC WL ne sont pas conformes à EN 16931 et ne portent aucun identifiant de spécification BT-24 — par conception, reflétant la cardinalité de la norme et non une limitation du moteur.
• Le moteur Schematron a besoin de ext-xsl. Les jeux de règles sont compilés au moment du build. À l’exécution, seul le XSLT pré-compilé est lancé, avec le chargement de ressources réseau et système de fichiers désactivé.
• Cette page décrit le comportement au niveau des capacités. Elle n’affirme pas l’acceptation par une autorité ou une plateforme particulière.

Structured e-invoice embedding and validation — edition availability

Edition	Availability
Core	○ Le central définit les contrats inter-niveaux (EmbedderInterface, ProfileInterface, ValidatorInterface) mais ne fournit aucune implémentation de facture structurée. Un porteur PDF simple sans charge utile structurée est le résultat central seul.
Pro	○ L’intégration CII Factur-X 1.08 dans un porteur PDF/A et les descripteurs de profil EN 16931 sont disponibles.
Enterprise	○ Ajoute l’intégration UBL Peppol BIS 3.0, le CIUS XRechnung B2G, la validation XML COMPAT/STRICT et le moteur de règles Schematron en cours de processus.

Documents associés

• Archivage et PDF/A — pourquoi le porteur de la facture est un fichier PDF/A et ce que cela garantit pour la lisibilité à long terme.
• Le guide de décision d’intégration — quel paquet de l’écosystème convient à un pipeline de facturation (génération en file d’attente, pont de framework ou Connect).
• Exploiter NextPDF en production — comment observer les constats et les échecs de validation une fois que les factures circulent à grande échelle.

Glossaire

• Facture hybride — un seul fichier PDF qui contient à la fois une page lisible par un humain et une charge utile XML de facture intégrée, lisible par machine.
• ZUGFeRD / Factur-X — les noms allemand et français de la même approche de facture hybride : une charge utile XML Cross Industry Invoice (CII) UN/CEFACT intégrée dans un porteur PDF/A.
• EN 16931 — la norme européenne définissant le modèle de données sémantique des éléments centraux d’une facture électronique.
• BT-24 (Identifiant de spécification) — le terme de gestion EN 16931 dont la valeur est une URN nommant le profil exact auquel la facture est conforme. Requis par la règle de gestion BR-1.
• Profil — aussi appelé niveau de conformité (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG). Détermine quels termes de gestion une facture doit porter.
• Fichier associé — un fichier attaché à l’intérieur d’un PDF avec une relation déclarée (AFRelationship) décrivant son lien avec le document visible ; le mécanisme qui transporte le XML de la facture.
• Schematron — un langage de règles utilisé pour exprimer les règles de gestion EN 16931. NextPDF exécute les jeux de règles CEN compilés en XSLT.