RTIR — Real-Time Invoice Reporting

Le RTIR hongrois fonctionne en flux post-émission : la facture est juridiquement valide dès qu'elle est créée, le push XML vers NAV est asynchrone et purement déclaratif. C'est une architecture fondamentalement différente du clearance italien ou polonais.

RTIR vs clearance — typologie CTC

Le terme générique Continuous Transaction Controls (CTC) recouvre plusieurs architectures différentes. La Hongrie a choisi le modèle RTIR, parmi les plus légers en termes d'impact sur les flux métier :

• RTIR (Hongrie depuis 2018). La facture est émise classiquement entre émetteur et destinataire (PDF, EDI, papier). Une copie XML est poussée à l'autorité fiscale dans un délai court (24h). Pas de visa avant transmission. Architecture « léger » : pas de blocage du flux commercial en cas de défaillance de la plateforme fiscale.
• Clearance (Italie SdI, Pologne KSeF). La facture transite obligatoirement par le serveur d'État, qui la valide et lui attribue un identifiant juridique avant qu'elle ne soit transmise au destinataire. Architecture « lourde » : sans visa, la facture n'a aucune valeur juridique.
• 5-corner / PEPPOL CTC (France PPF, Belgique 2026). Modèle hybride 4-corner PEPPOL + autorité fiscale en cinquième coin. La facture passe par des PDPs (plateformes de dématérialisation partenaires) qui font office d'intermédiaires et reportent à l'autorité.
• SAF-T périodique (Roumanie, Portugal, partielle Pologne JPK_VAT). Pas de RTIR mais un export mensuel des données de TVA. Le RTIR hongrois remplace en pratique le besoin d'un SAF-T factures.

Flux détaillé d'une facture

Voici la séquence complète d'événements pour une facture B2B hongroise émise par une PME via son ERP intégré à NAV Online Számla :

1. Émission de la facture. Le logiciel comptable génère la facture au format interne (XML métier, PDF, ou les deux). L'horodatage d'émission (dátum) est figé. La facture est transmise au client par le canal habituel (email, EDI, EFB, papier).
2. Génération du XML invoiceData. Le module RTIR de l'ERP transforme la facture vers le schéma invoiceData.xsd v3.0, ajoute la signature XML (XAdES enveloppée, optionnelle), et l'encode en base64.
3. tokenExchange. Le module obtient un token d'authentification valable 5 minutes via le service tokenExchange (paramètres : adószám, login technique, certificat NAV).
4. manageInvoice. Soumission unitaire ou par batch (jusqu'à 100 factures). NAV répond immédiatement avec un transactionId (UUID 36 caractères). À ce stade, le statut est RECEIVED — la facture n'est pas encore validée.
5. queryTransactionStatus. Le client interroge régulièrement NAV (polling 30 s) pour récupérer le statut final : DONE (succès), ABORTED (rejet validation), ou FAILED (erreur technique).
6. Archivage NAV. En cas de DONE, NAV archive la facture 11 ans (durée légale de conservation TVA) et l'intègre dans le pipeline de cross-check avec les déclarations TVA mensuelles (bevallás).

Émetteur                NAV Online Számla            Destinataire
   │                          │                            │
   │── (1) Émission facture ──┼────────────────────────────>│
   │   (juridiquement valide)  │   PDF/EDI/papier           │
   │                          │                            │
   │── (2) tokenExchange ─────>│                            │
   │       (Basic auth + cert) │                            │
   │<── tokenExchangeResp ─────│   token 5min               │
   │                          │                            │
   │── (3) manageInvoice ─────>│                            │
   │   POST /invoiceService    │   XML base64 + sig         │
   │<── manageInvoiceResp ─────│   transactionId UUID       │
   │                          │                            │
   │── (4) queryTransactionStatus ─>│                       │
   │<── status ABORTED|DONE ──│                            │
   │                          │── (5) archivage 11 ans ──>│
   │                          │   (cross-check ÁFA tv.)    │

Volumétrie et performance

Les statistiques officielles publiées par NAV (rapport annuel onlineszamla.nav.gov.hu) donnent les chiffres clés suivants :

Politique de retry et gestion d'incident

NAV publie une procédure officielle pour la gestion des échecs et la continuité d'activité :

• Retry technique automatique. 3 tentatives avec backoff exponentiel : 1 min, 5 min, 30 min. Si les 3 échouent, l'incident est consigné côté contribuable et un report manuel doit intervenir dans les 24 heures suivant le rétablissement.
• Incident NAV documenté. Si NAV publie un avis officiel d'indisponibilité (uzemzavar) sur onlineszamla.nav.gov.hu, le délai 24h est suspendu, et le contribuable a 5 jours ouvrés à compter du rétablissement pour rattraper son arriéré, sans sanction.
• Mode dégradé. Aucun mode dégradé officiel (au sens polonais du tryb awaryjny). En cas d'indisponibilité prolongée, NAV publie des consignes ad hoc.
• Annulation et correction. Une facture partiellement déclarée puis annulée doit être traitée via l'operation INVOICE_ANNULMENT, puis nouvelle soumission. Le transactionId de l'opération INVOICE_ANNULMENT doit référencer le transactionId initial.

Comparatif Hongrie / Italie / Pologne / France

Pièges courants

• Croire qu'un échec NAV invalide la facture. Faux : la facture reste juridiquement valide entre les parties. Seule la sanction fiscale est en jeu. Ne pas annuler / rééditer la facture sur la seule base d'un échec RTIR — la corriger uniquement après analyse de la cause.
• Oublier de gérer l'INVOICE_ANNULMENT. Si une facture mal saisie a été déclarée à NAV, il faut envoyer un message d'annulation explicite, puis une nouvelle soumission. Une simple correction silencieuse côté ERP ne suffit pas.
• Empiler les retries manuels. Le retry automatique de NAV est fait pour les pannes réseau, pas pour les erreurs métier. Re-soumettre 10 fois une facture rejetée pour cause de schéma invalide n'a aucun effet — il faut corriger l'XML.
• Confondre transactionId et invoiceNumber. Le transactionId est l'identifiant de la transaction NAV (UUID), pas le numéro juridique de la facture (séquence émetteur, ex. INV-2026/001234). Confondre les deux casse les rapprochements.

Liens transverses

• Hub Hongrie — RTIR complet
• NAV Online Számla — plateforme
• Évolution des schémas XSD
• API NAV — spécifications techniques
• Comparatif — Italie SdI clearance
• Comparatif — Pologne KSeF clearance
• Comparatif — France PPF/PDP 5-corner
• Documentation NAV — XSD, WSDL