La règle croate de 2026 sur la facturation électronique force les développeurs PHP à réinventer la validation – le fichier Schematron de l'administration fiscale repose sur XSLT 2.0, alors que le moteur XSLT dominant en PHP ne supporte que XSLT 1.0. Résultat : la plupart des applications de comptabilité ne peuvent pas exécuter les 62 contrôles de règles métier obligatoires sans solution de contournement, et une facture rejetée peut paralyser les flux de trésorerie B2B.
Pourquoi cet obstacle technique est crucial
À partir du 1er janvier 2026, chaque transaction B2B en Croatie devra être échangée sous forme d'e-Račun conforme à 62 règles de validation spécifiques. L'administration fiscale publie ces règles sous la forme d'un fichier Schematron – essentiellement une feuille de style XSLT 2.0 qui signale les violations. La bibliothèque intégrée libxslt de PHP, qui alimente le populaire xsltproc et la plupart des paquets Composer, ne prend en charge que XSLT 1.0. Sans le support de XSLT 2.0, le Schematron ne peut pas être appliqué, ce qui signifie qu'un système de facturation basé sur PHP produira soit des factures rejetées par le portail fiscal, soit devra faire appel à un autre langage ou service.
Trois voies possibles pour les développeurs
| Option | Ce que cela implique | Inconvénients pratiques |
|---|---|---|
| Extension PECL SaxonC | Installer le processeur Saxon-C en tant qu'extension PHP native, puis invoquer le Schematron directement. | L'extension ne fait pas partie du flux de travail typique de Composer ; la compilation et le déploiement de binaires natifs sur différents serveurs ajoutent de la complexité. |
| Service de validation externe | Envoyer le XML à un service web qui exécute le Schematron pour votre compte. | Chaque facture dépend désormais de la latence réseau et de la disponibilité du service ; une interruption temporaire peut bloquer entièrement la facturation. |
| Réimplémenter les règles en PHP | Traduire les 62 assertions Schematron en code PHP natif. | Nécessite un effort initial, mais une fois codé, le validateur s'exécute localement, s'intègre proprement à n'importe quelle pile PHP et élimine les dépendances externes. |
La logique cachée qui piège les implémentations simples
Une traduction naïve du Schematron peut encore passer à côté de subtilités sémantiques. Prenons la règle HR-BR-4 : « Une date d'échéance doit exister si le montant payable est supérieur à zéro. » Le Schematron définit une variable qui multiplie le montant de la facture par –1 pour les notes de crédit. Dans le XML brut, une note de crédit affiche un montant positif, mais la variable l'inverse en négatif, de sorte que la condition « supérieur à zéro » est fausse. Si le validateur ne lit que le texte de l'assertion, il rejettera chaque note de crédit.
La leçon est claire : lisez les définitions de variables dans le Schematron avant de coder la condition PHP correspondante. Le même schéma apparaît dans plusieurs autres règles où des manipulations arithmétiques ou de chaînes de caractères se cachent derrière une variable $.
Déclencheurs de rejet courants
Même avec des règles correctement codées, les développeurs négligent souvent des éléments de la facture que le système fiscal traite comme des erreurs fatales :
- Détails de l'opérateur manquants – chaque facture doit contenir le nom complet de l'opérateur et son OIB (numéro d'identification personnel croate). Laisser l'un ou l'autre de ces champs vide déclenche un rejet immédiat.
- Balises XML vides – des balises telles que
<cbc:Note></cbc:Note>provoquent le plantage du validateur. Supprimer les éléments vides ou les remplir avec une chaîne de remplacement résout le problème. - Codes KPD incorrects – le code Klasifikacija proizvoda i usluga (KPD) doit comporter au moins six chiffres. Les codes trop courts sont signalés comme malformés.
- Dates invalides – toute facture datée d'avant le 1er janvier 2026 échoue à la règle de la date obligatoire, indépendamment de la justesse des autres éléments.
Pièges lors des tests
L'administration fiscale publie des fichiers e-Račun d'exemple pour les développeurs. Ces exemples contiennent encore des dates de 2025 et des OIB qui ne passent pas le jeu de règles de 2026. Les utiliser comme seule source de vérité donne un faux sentiment de conformité. Considérez les échantillons officiels comme un simple test de bon fonctionnement du parseur, puis exécutez votre propre suite de contrôle des règles sur des données réalistes générées par votre application.
La solution exclusivement PHP déjà disponible
Un développeur a choisi la voie de la réimplémentation complète, en encapsulant les 62 règles de validation dans une bibliothèque installable via Composer pour les projets Laravel. La bibliothèque gère l'arithmétique, la portée des variables et les vérifications de cas limites que le Schematron dissimule, permettant de valider les factures entièrement au sein de l'environnement d'exécution PHP. En éliminant XSLT 2.0 et les appels externes, le paquet offre une voie de conformité déterministe et à faible latence.
Le code source et le guide d'utilisation sont disponibles sur le dépôt public de l'auteur (lien fourni dans le message original).
À surveiller ensuite
- Validateurs PHP communautaires – à mesure que davantage de développeurs adoptent l'approche de réimplémentation, attendez-vous à des forks et des extensions ajoutant des fixtures de tests unitaires, le support d'autres frameworks ou des optimisations de performance.
L'essentiel
L'obligation de facturation électronique de la Croatie pour 2026 oblige les développeurs PHP à faire face à une incompatibilité entre un Schematron XSLT 2.0 moderne et le moteur XSLT 1.0 hérité du langage. Traduire les 62 règles métier en PHP natif, surveiller la logique des variables cachées et éviter les pièges XML courants permet de garder la facturation en interne, d'éviter les échecs liés au réseau et de préparer les logiciels de comptabilité à un déploiement fluide et conforme lorsque l'échéance arrivera.