RTIR — Real-Time Invoice Reporting

Hungarian RTIR works in a post-issuance flow: the invoice is legally valid as soon as it is created, the XML push to NAV is asynchronous and purely declarative. It is a fundamentally different architecture from Italian or Polish clearance.

RTIR vs clearance — CTC typology

The generic term Continuous Transaction Controls (CTC) covers several different architectures. Hungary chose the RTIR model, among the lightest in terms of impact on business flows:

• RTIR (Hungary since 2018). The invoice is issued classically between issuer and recipient (PDF, EDI, paper). An XML copy is pushed to the tax authority within a short delay (24h). No clearance before transmission. "Light" architecture: no commercial flow blocking in case of tax platform failure.
• Clearance (Italy SdI, Poland KSeF). The invoice transits mandatorily through the State server, which validates it and assigns a legal identifier before forwarding to the recipient. "Heavy" architecture: without clearance, the invoice has no legal value.
• 5-corner / PEPPOL CTC (France PPF, Belgium 2026). Hybrid model 4-corner PEPPOL + tax authority as fifth corner. The invoice passes through PDPs (accredited dematerialization platforms) that act as intermediaries and report to the authority.
• Periodic SAF-T (Romania, Portugal, partial Polish JPK_VAT). No RTIR but a monthly export of VAT data. The Hungarian RTIR replaces in practice the need for an invoice SAF-T.

Detailed flow of an invoice

Here is the complete sequence of events for a Hungarian B2B invoice issued by an SME via its ERP integrated to NAV Online Számla:

1. Invoice issuance. The accounting software generates the invoice in internal format (business XML, PDF, or both). The issuance timestamp (dátum) is frozen. The invoice is transmitted to the customer via the usual channel (email, EDI, EFB, paper).
2. invoiceData XML generation. The RTIR module of the ERP transforms the invoice into the invoiceData.xsd v3.0 schema, adds the XML signature (XAdES enveloped, optional), and encodes it in base64.
3. tokenExchange. The module obtains an authentication token valid 5 minutes via the tokenExchange service (parameters: adószám, technical login, NAV certificate).
4. manageInvoice. Unit or batch submission (up to 100 invoices). NAV responds immediately with a transactionId (UUID, 36 characters). At this stage, status is RECEIVED — the invoice is not yet validated.
5. queryTransactionStatus. The client periodically polls NAV (every 30 s) to retrieve the final status: DONE (success), ABORTED (validation rejection), or FAILED (technical error).
6. NAV archiving. On DONE, NAV archives the invoice for 11 years (legal VAT retention period) and integrates it into the cross-check pipeline against monthly VAT returns (bevallás).

Issuer                  NAV Online Számla              Recipient
   │                          │                            │
   │── (1) Invoice issued ────┼────────────────────────────>│
   │       (legally valid)    │   PDF/EDI/paper            │
   │                          │                            │
   │── (2) tokenExchange ─────>│                            │
   │       (Basic auth + cert) │                            │
   │<── tokenExchangeResp ─────│   token 5min               │
   │                          │                            │
   │── (3) manageInvoice ─────>│                            │
   │   POST /invoiceService    │   XML base64 + sig         │
   │<── manageInvoiceResp ─────│   transactionId UUID       │
   │                          │                            │
   │── (4) queryTransactionStatus ─>│                       │
   │<── status ABORTED|DONE ──│                            │
   │                          │── (5) archived 11 years ─>│
   │                          │   (cross-check ÁFA tv.)    │

Volumetry and performance

The official statistics published by NAV (annual report onlineszamla.nav.gov.hu) give the following key figures:

Retry policy and incident handling

NAV publishes an official procedure for failure handling and business continuity:

• Automatic technical retry. 3 attempts with exponential backoff: 1 min, 5 min, 30 min. If all 3 fail, the incident is logged on the taxpayer side and a manual report must be made within 24 hours after restoration.
• Documented NAV incident. If NAV publishes an official unavailability notice (uzemzavar) on onlineszamla.nav.gov.hu, the 24h deadline is suspended, and the taxpayer has 5 working days from restoration to catch up arrears, without penalty.
• Degraded mode. No official degraded mode (in the Polish tryb awaryjny sense). In case of prolonged unavailability, NAV publishes ad-hoc instructions.
• Cancellation and correction. A partially declared then cancelled invoice must be handled via the INVOICE_ANNULMENT operation, then resubmitted. The transactionId of the INVOICE_ANNULMENT operation must reference the initial transactionId.

Comparison Hungary / Italy / Poland / France

Common pitfalls

• Believing a NAV failure invalidates the invoice. False: the invoice remains legally valid between parties. Only the fiscal penalty is at stake. Do not cancel / reissue the invoice solely on the basis of an RTIR failure — correct it only after root cause analysis.
• Forgetting to handle INVOICE_ANNULMENT. If a poorly entered invoice has been reported to NAV, an explicit cancellation message must be sent, then a new submission. A silent correction on the ERP side is not enough.
• Stacking manual retries. NAV automatic retry is designed for network outages, not business errors. Resubmitting a schema-invalid invoice 10 times has no effect — you must fix the XML.
• Confusing transactionId and invoiceNumber. The transactionId is the NAV transaction identifier (UUID), not the legal invoice number (issuer sequence, e.g. INV-2026/001234). Confusing both breaks reconciliations.

Cross-links

• Hungary hub — full RTIR
• NAV Online Számla — platform
• XSD schema evolution
• NAV API — technical specifications
• Comparison — Italy SdI clearance
• Comparison — Poland KSeF clearance
• Comparison — France PPF/PDP 5-corner
• NAV documentation — XSD, WSDL