ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

Hongrie — Online Számla et le reporting NAV

La Hongrie pratique un Real-Time Invoice Reporting (RTIR) depuis 2018 : la facture commerciale peut rester papier ou PDF, mais ses données structurées doivent être déclarées au NAV dans la foulée de l'émission, par envoi XML sur l'API Online Számla.

Timeline réglementaire

  • 2007. évi CXXVII. törvény (Loi CXXVII de 2007 sur la TVA). Base légale de la facturation hongroise, refondue par le décret ministériel 23/2014. (VI. 30.) NGM.
  • 23/2014. (VI. 30.) NGM rendelet. Décret ministériel relatif à l'identification des factures et aux conditions d'usage de la facturation électronique.
  • 1er juillet 2018. Mise en service du RTIR pour les factures B2B avec TVA > 100 000 HUF, via l'API Online Számla v1.0 / v1.1.
  • 1er juillet 2020. Suppression du seuil 100 000 HUF : toutes les factures B2B intérieures doivent être déclarées. La période transitoire sans sanctions court jusqu'au 31 mars 2021.
  • 1er janvier 2021. Extension aux factures B2C intérieures et à toutes les opérations exonérées. Schéma v3.0 introduit.
  • 1er avril 2021. Fin de la tolérance et application des sanctions (jusqu'à 500 000 HUF par facture non déclarée).
  • 2023-2025. Évolutions techniques régulières du schéma Online Számla v3.0 (sous-versions 3.0.x) avec adaptations aux changements de TVA et au régime des opérations transfrontalières post-Brexit.

Approfondissements — 10 pages dédiées

Dix pages dédiées approfondissent chaque dimension du mandat hongrois RTIR — le déploiement 2018-2021 de NAV Online Számla, les spécifications techniques (API, évolution XSD, QueryTaxpayer, pénztárgép), et l'usage B2B réel qui pré-existe et coexiste avec le RTIR (EDIFACT retail/automotive, Termékdíj environnemental).

RTIR 2018-2021

  • NAV Online Számla — RTIR depuis 2018 · Plateforme NAV de reporting temps réel des factures (RTIR), obligatoire 1ᵉʳ juil 2018 (B2B > 100 K HUF TVA), universelle 4 janv 2021. Base légale 2007. évi CXXVII. törvény + 23/2014. (VI. 30.) NGM rendelet.
  • RTIR — architecture détaillée · Reporting post-émission (pas clearance), push XML async sous 24h, ~99,9% acquittement, retry 3 tentatives, ~6,5 Md factures déclarées depuis 2018.
  • Évolution XSD v1.0 → v3.0 · 4 versions : v1.0 (juil 2018), v1.1 (juil 2019), v2.0 (avr 2020 intra-UE), v3.0 (janv 2021 universel). Schémas publiés sur onlineszamla.nav.gov.hu/dokumentumtar.
  • Régimes TVA (ÁFA) hongrois · Standard 27% (record UE), réduit 18% (lait UHT, hôtellerie, restauration), super-réduit 5% (livres, médicaments, lait frais, chauffage urbain), KATA TPE, reverse charge art. 142 ÁFA.

Specs techniques

  • API NAV Online Számla — endpoints · REST + XML, TokenExchange (5 min), ManageInvoice (batch 100), QueryInvoiceData/Check/Digest, QueryTaxpayer. Prod api.onlineszamla.nav.gov.hu + test api-test.
  • QueryTaxpayer — validation adószám · Validation temps réel des numéros fiscaux hongrois (8 chiffres root + vatCode + countyCode), statuts ACTIVE/SUSPENDED/DELETED, groupes TVA csoportos áfa, latence < 1 s.
  • Online pénztárgép — caisses NAV · Caisses fiscales certifiées AEE depuis 2014, ~200 000 dispositifs, communication SIM M2M dédiée vers pt.nav.gov.hu, périmètre B2C retail + restauration + taxi.

Usage B2B réel

  • EDIFACT retail hongrois · Spar, Tesco (Sparkle Foods), Lidl, Aldi, Penny, Auchan, CBA, Coop, Príma — EANCOM 2002 subsets GS1 Hungary, ~500 M messages/an, VANs Comarch + EDITEL + GXS.
  • EDIFACT automotive hongrois · Audi Győr (1ᵉʳ site moteur mondial), Mercedes Kecskemét, Magyar Suzuki Esztergom, BMW Debrecen (Neue Klasse 2024), Opel Szentgotthárd — VDA + Galia + Odette, OFTP2 sur ENX.
  • Termékdíj — taxe environnementale · Redevance environnementale NAV sur 9 catégories (emballages, piles, EEE, pneus, lubrifiants, papier pub, panneaux PV, plastiques usage unique), bloc productFeeSummary intégré au XSD v3.0, coexistence EPR MOHU depuis 2023.

Schéma technique

Le format commercial de la facture reste libre : papier, PDF, EDI ou PEPPOL. Ce qui est imposé est le format de la déclaration envoyée au NAV : XML conforme au schéma Online Számla v3.0 publié sur onlineszamla.nav.gov.hu. Le document XML déclare l'invoice complète (en-tête, lignes, TVA, parties) et s'intègre dans un wrapper ManageInvoiceRequest qui contient un en-tête commun (common:header), un bloc utilisateur authentifié, et une liste d'invoiceOperations.

Exemple synthétique d'un appel API NAV avec un invoiceOperation CREATE (le payload réel est encodé en base64 ou compressé) :

xmlonline-szamla-v3.xml
<?xml version="1.0" encoding="UTF-8"?>
<ManageInvoiceRequest xmlns="http://schemas.nav.gov.hu/OSA/3.0/api"
                     xmlns:common="http://schemas.nav.gov.hu/NTCA/1.0/common">
  <common:header>
    <common:requestId>RID2026051600187</common:requestId>
    <common:timestamp>2026-05-16T10:30:00.000Z</common:timestamp>
    <common:requestVersion>3.0</common:requestVersion>
    <common:headerVersion>1.0</common:headerVersion>
  </common:header>
  <common:user>
    <common:login>userLogin</common:login>
    <common:passwordHash>5C7CFA…</common:passwordHash>
    <common:taxNumber>12345678</common:taxNumber>
  </common:user>
  <invoiceOperations>
    <compressedContent>false</compressedContent>
    <invoiceOperation>
      <index>1</index>
      <invoiceOperation>CREATE</invoiceOperation>
      <invoiceData>PD94bWwgdmVyc2lvbj0iMS4wIj8+ ...</invoiceData>
    </invoiceOperation>
  </invoiceOperations>
</ManageInvoiceRequest>

Flux de soumission

L'émetteur envoie la facture commerciale au destinataire par les voies habituelles (papier, e-mail, EDI, PEPPOL). En parallèle, le logiciel comptable de l'émetteur publie un XML Online Számla sur l'API NAV via REST/HTTPS authentifiée par technical user (login + mot de passe SHA-512 + clé d'échange XML).

textflux-nav.txt
┌────────────┐                       ┌────────────┐
│ Vendeur HU │──── facture ──────────>│ Acheteur HU│
│ (ERP)      │ (PDF, EDI, papier ok)  │ (ERP)      │
└────────┬───┘                       └────────────┘

         │ XML Online Számla v3.0

┌──────────────────┐
│  NAV (Online     │
│  Számla)         │  ← report quasi temps réel,
└──────────────────┘     déclaration sous 5 minutes

Le délai légal est de 5 minutes après émission pour les factures automatisées, et immédiat pour les factures manuelles. Le NAV retourne une réponse de type transactionId ; un poll permet de récupérer le statut final (ACCEPTED, WARNING, ERROR) avec les diagnostics.

Validation

Pièges courants

  1. Reporting ≠ e-invoicing. Le NAV n'est pas un portail clearance. Beaucoup d'équipes assimilent la Hongrie à un mandat e-invoicing complet ; c'est inexact. La facture commerciale circule librement, c'est les données qui sont déclarées en parallèle.
  2. Délai 5 minutes strict pour les factures automatisées. Un job batch déclenché en fin de journée pour rapporter toutes les factures du jour tombe en infraction. L'audit NAV vérifie l'écart entre la date d'émission et la date d'arrivée du XML.
  3. Authentification par technical user + token XML. Le NAV refuse l'authentification de l'utilisateur final : il faut un technical user dédié dont le mot de passe est haché SHA-512 et combiné avec une clé XML transmise dans un bloc spécifique. Un changement de mot de passe bloque tous les jobs si la clé n'est pas régénérée en parallèle.
  4. Schéma v3.0 vs v2.0 sortie 2020. Le schéma v3.0 a introduit des champs supplémentaires (statut auto-billing, mode de paiement détaillé, certaines références cross-border). Une intégration qui pointe encore vers v2.0 retourne une erreur incompatible request version.
  5. Sanctions à 500 000 HUF par facture non déclarée. La hauteur des amendes (jusqu'à ~1 250 € par facture) en cas de non-déclaration systématique grimpe vite. Les équipes négligent souvent les NotInvoice operations (annulations, modifications) qui doivent aussi être déclarées sous le même délai.

Liens transverses