ValidateFin

NAV Online Számla Validator Hungary

Vérifiez le XML d’une facture hongroise avec le schéma et les codes de rejet de la NAV elle-même — dans le navigateur, sans upload.

Online Számla 3.0Official NAV XSD (MIT)Rejection codes100% local
100% Local

Qu’est-ce que NAV Online Számla, et qui doit l’utiliser ?

Online Számla est le système de déclaration en temps réel des factures de l’administration fiscale hongroise, la NAV (Nemzeti Adó- és Vámhivatal). Depuis 2021, toute facture émise sous le régime de TVA hongrois y passe — sans seuil, et sans exemption pour les petits montants ou les particuliers. La version 3.0 du schéma est celle en vigueur. Quand le XML transmis porte completenessIndicator à true, ce n’est pas un accusé de dépôt : ce XML *est* la facture électronique au sens des §169 b) et §170 (1) b) de la loi hongroise sur la TVA. Ce validateur gratuit contrôle le fichier contre le XSD officiel de la NAV entièrement dans votre navigateur : la facture ne quitte jamais votre machine.

En bref

  • XSD officiel de la NAV (Online Számla 3.0) — publié par l’administration fiscale hongroise sous licence MIT
  • Codes de rejet cités mot pour mot depuis la NAV, avec leur ValidatorFaultType
  • Confronté aux 30 factures d’exemple que la NAV publie elle-même
  • 100 % dans votre navigateur — la facture ne quitte jamais votre machine

Le schéma de la NAV, et les codes de rejet de la NAV

La première couche est le XSD officiel publié par la NAV elle-même sur github.com/nav-gov-hu, sous licence MIT — c’est l’administration fiscale qui a écrit la licence, et celle-ci autorise expressément l’usage, la modification et la redistribution. C’est aussi ce qui permet à cet outil de citer mot pour mot les 237 codes de rejet officiels de la NAV, chacun avec le ValidatorFaultType que la NAV renvoie. Structure, types, cardinalités et énumérations fermées ne sont jamais réencodés à la main.

La seconde couche exécute les contrôles décidables sur le seul document, et les signale avec le type de faute de la NAV : lignes manquantes, numérotation qui n’est pas strictement croissante, vendeur identique à l’acheteur (numéro de TVA, nom ou IBAN), code TVA 4 interdit, période de livraison inversée, ligne qui se référence elle-même — et l’arithmétique, au forint près : quantité × prix unitaire = net de ligne, Σ des nets = net de la facture, Σ TVA par taux = TVA de la facture, net + TVA = brut.

Trois des trente factures d’exemple que la NAV publie sont arithmétiquement fausses, et cet outil le dit plutôt que de regarder ailleurs. Termékdíjas számla déclare une TVA de 280 000 là où les lignes, la somme par taux et le brut disent tous 280 800 ; Belföldi értékesítés több ÁFA típus a un brut inférieur de 600 à net + TVA ; Gyűjtőszámla 1 porte une ligne de taux à 1 304 000 alors que 27 % de 4 832 000 font 1 304 640. Ces fichiers sont antérieurs aux contrôles qui les rejettent. Quand la règle et le fichier viennent de la même institution et se contredisent, c’est le fichier de démonstration qui est périmé.

À retenir

  • Toute facture hongroise passe par Online Számla — depuis 2021, sans le moindre seuil.
  • Quand completenessIndicator vaut true, le XML n’est pas un compte rendu de la facture : il EST la facture électronique, juridiquement.
  • La NAV publie son schéma sous licence MIT — la situation de licence la plus propre de toutes les administrations fiscales que nous traitons.
  • La clé de contrôle du numéro fiscal hongrois n’est PAS vérifiée ici : la formule qui circule sur les blogs n’apparaît dans aucune source officielle, et la NAV valide en interrogeant son registre.
  • Trois des trente factures d’exemple de la NAV échouent à l’arithmétique de la NAV. C’est un fait sur les exemples, pas un bug du validateur.

Questions fréquentes

Le XML envoyé à Online Számla est-il un compte rendu ou la facture elle-même ?

Tout dépend d’un champ. Quand completenessIndicator vaut true, le XML transmis est la facture électronique elle-même au sens des §169 b) et §170 (1) b) de la loi hongroise sur la TVA — la spécification le dit au §2.6.2. Quand il vaut false, le XML déclare les données d’une facture émise ailleurs. La distinction compte : dans le premier cas, il n’existe aucun autre document de facture, nulle part.

Pourquoi cet outil ne vérifie-t-il pas la clé du numéro fiscal hongrois (adószám) ?

Parce qu’aucune source officielle ne publie la formule. Les poids 9-7-3-1-9-7-3 mod 10 circulent sur les blogs et les forums, mais n’apparaissent dans aucun document de la NAV. Le XSD de la NAV ne contraint que la forme du numéro, et la NAV valide l’existence en interrogeant son registre de contribuables (queryTaxpayer) — ce qu’aucun outil côté client ne peut faire. Une règle qu’on ne peut pas sourcer ne s’invente pas ici.

Que seule la NAV peut-elle vérifier ?

Quatre choses, et l’outil les affiche à l’écran plutôt que de les cacher derrière un badge vert : l’unicité du numéro de facture, l’existence du client au registre des contribuables, la cohérence de la chaîne des documents de modification, et l’autorisation du déclarant. Les quatre exigent la base de données de la NAV.

Une facture de modification peut-elle n’avoir aucune ligne ?

Oui, et la rejeter serait une erreur. Un document qui porte un invoiceReference est une modification : il peut ne rectifier que l’en-tête sans toucher à aucune ligne — deux des exemples officiels de la NAV font exactement cela. Seule une facture d’origine doit porter des lignes.

Ma facture est-elle envoyée à un serveur ?

Non. Le moteur XSD et tous les contrôles tournent dans votre navigateur, en WebAssembly. Le fichier ne quitte jamais votre machine — ce qui compte ici plus qu’ailleurs, puisque avec completenessIndicator à true, ce fichier est la facture elle-même.

ValidateFin est un outil indépendant, ni certifié ni approuvé par la Nemzeti Adó- és Vámhivatal. « Officiel » qualifie le schéma utilisé — le XSD Online Számla 3.0 publié par la NAV sous licence MIT — et non une quelconque accréditation de cet outil. Valider un fichier ici ne le déclare pas à la NAV.