NAVオンラインシャームラ ハンガリーの電子インボイス2026年版：リアルタイム送信、義務化されたコンプライアンスとEコマース統合

1. NAVオンラインシャームラ — システム概要

ハンガリーほど断固としてリアルタイム電子インボイスに移行したEU加盟国は多くありません。イタリア、ポーランド（KSeF）、ルーマニア、スペインがまだパイロットスキームを設計している段階で、ハンガリーのNAVオンラインシャームラは2018年7月1日にB2Bの一斉切替として、ソフトローンチ期間なしで稼働を開始しました。以来、本制度は「継続的取引管理」（CTC）電子インボイスモデルのEUで最も引用される参照実装となり、今後のEU ViDA（デジタル時代のVAT）指令のひな型となっています。

NAV（Nemzeti Adó- és Vámhivatal — 国税関税庁）は、onlineszamla.nav.gov.huで本制度を運用しています。すべてのハンガリーVAT課税事業者 — 居住者または非居住者でハンガリーVAT番号を保有する者 — は、ポータルで技術ユーザーを作成し、必要な4つの資格情報（ログイン、パスワード、署名鍵、交換鍵）を生成し、REST APIへの直接統合を構築するか、それを代行する認定ERPを接続する必要があります。

その規模は膨大です：2026年までにNAVは、60万以上のハンガリー納税者から年間6億件以上のインボイスを処理しています。本制度は、取締り機能（迅速なVAT不正検知）とサービス機能（事前入力されたVAT申告書、NAV-OSA「オンラインレジスター」ストリーム）の両方を果たしています。

2. リアルタイム送信 — B2B（2018年）+ B2C（2021年）の義務化

3段階の義務化ロールアウト

ハンガリーのOnline Számla義務は3つの異なる波で到来し、それぞれが閾値を引き下げて、事実上すべての課税取引をカバーするに至りました：

• 2018年7月1日 — VAT額HUF 100,000超のB2B。 VAT登録されたハンガリー企業間で、VAT部分がHUF 100,000を超えるインボイスは、ほぼリアルタイムでの報告が必要でした。
• 2020年7月1日 — すべてのB2Bインボイス。 HUF 100,000の閾値が撤廃され、ハンガリーVAT番号のもとで発行されるすべての企業間インボイスが、金額にかかわらず報告対象となりました。
• 2021年1月4日 — 完全なB2C＋越境取引。 義務は、個人消費者向けおよび非ハンガリー顧客（EUおよび第三国）向けのインボイスにも拡大されました。これが2026年に適用される制度であり、免税閾値はありません。

5分ルール

本制度の中核となるサービスレベルの約束は、インボイス発行からNAVへの受領まで5分です。時計は、文書に記載されたinvoiceIssueDate＋invoiceIssueTimeから起算され、manageInvoice RESTエンドポイントがトランザクションIDを返した時点で終了します。実務上、ほとんどの認定ERP（Számlázz.hu、Billingo）は1～3秒以内に送信を完了します。5分という枠は規制上の上限であり、運用上の目標ではありません。

5分の時計が停止するのは次の2つの状況に限られます：(a) NAVのAPIが正式にダウンしている場合（NAVポータルで公表されるステータス）、この場合、政令23/2014（VI. 30.）NGM第13/A条により、停止時間に24時間を加えた延長が認められます。および(b) 販売者が特定の適用除外に基づき「データ交換エージェント」ステータスを申請している場合 — Eコマースでは稀です。

手動送信 vs 自動送信

NAVはOnline Számlaポータルに手動のウェブフォームも用意しており、納税者はインボイスデータを手入力で貼り付けることができます。マーケットプレイスの取扱量ではこれは非現実的です：1日200件のインボイスを発行する中規模のeMAG販売者は、それぞれを5分のSLA以内に手動で往復処理することはできません。実務上、1日10件を超えると自動化は必須です。

3. XML形式 — NAV定義のinvoiceData v3.0スキーマ

XSD主導のアーキテクチャ

NAVは任意のXMLを受け付けません — 送信されるすべてのインボイスは、政令23/2014（VI. 30.）NGMのもとNAVが公開する公式のinvoiceData v3.0 XSDスキーマに準拠する必要があります。このスキーマは以下を定義します：

• ヘッダー — サプライヤー識別情報（ハンガリーVAT番号／EU VAT番号／第三国税ID）、顧客識別情報、インボイス番号、発行/完了/支払日、通貨コード、EUR/USD等で発行された場合のHUFへの為替レート。
• invoiceLines — 明細単位の内訳：商品説明、数量、単位、正味単価、VAT税率（27%／18%／5%／0%）、VAT額、総額。各行にはlineNatureタグ（PRODUCT／SERVICE／OTHER）と任意の商品コード識別子（VTSZ、SZJ、KN、CsK、EJ、TESZOR）が付与されます。
• invoiceSummary — 合計：VAT税率ごとの正味額、VAT額、総額、および該当する場合の端数調整行。
• invoiceReference — 過去に送信されたインボイスの修正または取消しに使用；元のインボイス番号と修正の種類（MODIFY／STORNO）を含みます。

Online Számla 3.0 REST API

送信はhttps://api.onlineszamla.nav.gov.huをルートとするOnline Számla 3.0 REST API経由で行われます。7つの主要エンドポイントは以下のとおりです：

• tokenExchange — 納税者の署名鍵で署名された、5分間有効な交換トークンを取得
• manageInvoice — 1件以上のinvoiceData XMLペイロードを送信（バッチ最大100件）
• queryTransactionStatus — 送信済みバッチの処理状況を照会（NOTIFIED／DONE／WARN／ABORTED）
• queryInvoiceData — 過去に送信したインボイスを取得
• queryInvoiceDigest — 日付範囲または取引相手でインボイスを一覧表示（監査／照合用）
• queryInvoiceChainDigest — 特定インボイスの修正チェーン全体を返却
• queryTaxpayer — ハンガリーVAT番号をリアルタイムで検証

SHA3-512署名と4つの資格情報

すべてのリクエストは、Online Számlaポータルで生成される納税者固有の4つの資格情報で認証されます：

• ログイン名 — 技術ユーザーのユーザー名
• パスワード — ハッシュ化された形式で使用され、平文で送信されることはありません
• 署名鍵（XML-DSig） — 各リクエストのハッシュをSHA3-512で署名するために使用
• 交換鍵 — 交換トークンをAESで暗号化するために使用

すべてのペイロードは厳格なXMLエンベロープにラップされ、SHA3-512で署名されます。NAVは、約50ms以内に再計算されたダイジェストと一致しない署名を持つリクエストをすべて拒否します。これをゼロから構築するのは数週間規模のプロジェクトです。認定ERPやZunaproの価値は、署名／リトライ／キューのロジックを販売者のEコマーススタックから抽象化することにあります。

4. NAVポータル vs ERP統合 — Számlázz.hu、Billingo、KBOSS

主要な3つのハンガリーERP

ハンガリーの中小企業販売者の95%にとって、実務上の選択肢は3つの認定クラウド請求プラットフォームのいずれかです：

Számlázz.hu — KBOSS Kft.が運営し、2006年にローンチされたSzámlázz.huは、25万以上のアクティブな中小企業ユーザーを抱え、年間約4千万件のインボイスが発行される、ハンガリー第1位のクラウド請求プラットフォームです。そのREST API（v3/szamla/agent）はハンガリーEコマース統合における事実上の標準です。プランは非常に低い取扱量向けの無料プランから始まり、エンタープライズ向けの上位プランまで段階的に用意されており、NAV送信はすべてのプランで完全自動かつ標準搭載されています。

Billingo — 2014年に設立され、2019年にマジャル・テレコムに買収されたBillingoは、Számlázz.huに代わるモダンでデザイン重視の選択肢として自らを位置付けています。2026年時点で8万以上のハンガリー企業にサービスを提供しており、特にShopify、WooCommerce、Shoprenterのショップで強く採用されています。Billingo Public API v3は市場で最もシンプルなハンガリー請求APIであり、NAV送信、修正、取消し、PDF生成が標準搭載されています。

KBOSS Számla Agent — KBOSS Kft.の別製品であるSzámla Agentは、既存のERP（SAP、Microsoft Dynamics 365、Sage、Oracle）とNAVの間に位置するエンタープライズ級のデスクトップ/サーバーエージェントです。Windowsサービスとして動作し、インボイステーブルを監視し、スケジュールに従ってinvoiceData XMLをNAVに送信します。主に製造業や卸売業で1万以上の企業に利用されています。

直接NAV統合 vs ERP — 意思決定マトリクス

Zunaproのアプローチ — 1つのアダプタ、3つのバックエンド

Zunaproはこの選択を抽象化します：マーケットプレイスの注文は単一のハンガリーインボイスキューに流れ込み、販売者は各テナントのインボイスをSzámlázz.huコネクタ、Billingoコネクタ、または直接NAV RESTのいずれで発行するかを選択できます。オーケストレーターはリトライ、署名鍵のローテーション、NAVのダウンタイムウィンドウを処理し、返却された10桁のNAVトランザクションIDをすべての注文に書き戻すため、マーケットプレイスと販売者のパネルは常に同じコンプライアンス状態を表示します。

5. 罰則 — 未報告インボイス1件あたり最大HUF 1,000,000

法的枠組み — 2017年法第CL号（第220条）

Online Számlaの不遵守に対する罰則は、2017年租税手続法（Adózás Rendjéről szóló Törvény — Art tv.）第220条で定められています。デフォルトの行政罰金は、法人（法的主体）に対しては未報告インボイス1件あたり最大HUF 1,000,000、個人（個人事業主 — egyéni vállalkozó）に対しては未報告インボイス1件あたり最大HUF 500,000です。

罰則が発生する条件

• 遅延送信 — 5分の期限後（正式に宣言されたNAVのダウンタイムウィンドウを除く）に受信されたinvoiceData XML
• 未送信 — インボイスは発行されたがNAVに一切報告されなかった場合
• 不完全なデータ — 必須のXSDフィールドが空欄または不正な形式（例：VAT税率の欠落、顧客IDの誤り）
• 不正確なデータ — 明細合計がヘッダー合計と一致しない、または非HUFインボイスの通貨換算が欠落している場合
• 修正の未報告 — STORNOまたは修正インボイスが発行されたが、対応するinvoiceReferenceがNAVに送信されなかった場合

NAVの実際のエスカレーションパターン

実務上、NAVは小規模な単発的な漏れ（四半期に1～3件の未報告インボイス）にはまず警告書を発行します。四半期に約10件の未報告インボイスから、NAVは正式な罰金へと移行し、50件以上の漏れまたは組織的な未報告の場合、完全なVAT監査、VAT控除権の喪失の可能性、税務倉庫／OSSステータスの見直しへとケースがエスカレートします。過少報告を行う越境販売者は、OSSワンストップショップ制度へのアクセスを失う可能性もあり、その結果、すべてのEU加盟国での国別VAT登録を強いられることになります。

実践的な対策

HUF 100万の罰金に対する最も安価な保険は、永続的なリトライキューを備えた自動送信です。ZunaproはNAVとのすべてのやり取り（リクエストペイロード、応答コード、トランザクションID、署名鍵のバージョン）について90日間の継続的な監査ログを保持しているため、後にNAVから問い合わせがあった場合でも、すべての送信を再構築して証明できます。

6. ÁFA 27%の自動計算とマルチ税率処理

ハンガリー — EU最高の標準VAT

ハンガリーの標準VAT税率は27%（ÁFA — általános forgalmi adó）で、欧州連合内で最も高く、2007年付加価値税法（Áfa törvény、第CXXVII法）で定められています。この税率は2012年1月1日以降27%のままであり、引き下げの発表予定はありません。

特定のカテゴリーには2つの軽減税率が適用されます：

• 18%軽減税率 — 牛乳および一部の乳製品（Áfa törvény附則3/I、第1項）、商業宿泊サービス（ホテル、休暇用貸別荘）、一部のベーカリー製品
• 5%超軽減税率 — 印刷書籍・電子書籍、公式リストに掲載の医薬品、一部の医療用具、地域暖房（távhő）、特定の平方メートル閾値未満の商業建設新築住宅、生演奏音楽イベントチケット
• 0%／非課税 — OSS制度下でのEU域内輸出、第三国への輸出、一部の金融サービス、医療、教育

マーケットプレイスのマルチ税率問題

eMAG.huやVateraの注文には、異なるVAT税率の明細が複数含まれることがよくあります — 1つのカートに27%税率のアクセサリーと5%税率の書籍が混在することもあります。invoiceData XMLは、明細を正しく分割し、各VAT税率のグループをinvoiceSummary内で照合する必要があります。マーケットプレイスの取扱量で手動計算を行うのは非現実的でエラーが起きやすいです。

Zunaproのマスターカタログは、インポート時にすべてのSKUにハンガリーのÁFA税率をタグ付けします。マーケットプレイスの注文が届くと、システムは：

1. マスターカタログからSKUごとの税率を検索
2. 明細レベルの正味額／VAT／総額を計算（NAVの端数処理ルールに従って丸め）
3. XMLサマリー用に明細をsummaryByVatRateグループにまとめる
4. 5分の枠内でinvoiceDataペイロードを送信

通貨処理 — HUF、EUR、USD

EUR、USD、その他の外貨で発行されたインボイスについて、NAVは販売者に対し、インボイス発行日のMNB（ハンガリー国立銀行）公式中間レートで計算したHUF換算額の記録を求めます。XMLには、各VAT税率グループごとに元通貨の金額とHUF換算額の両方が含まれます。ZunaproはCET 11:15（MNBの公表時刻）にMNBの日次レートを取得し、自動的に適用します。

7. マーケットプレイス統合 — eMAG.hu、Vatera、Allegro HU

マーケットプレイス請求の現実

新規参入のハンガリーEコマース販売者に広く見られる誤解は、「マーケットプレイスが請求を処理してくれる」というものです。実際にはそうではありません。eMAGマーケットプレイス・ハンガリー、Vatera（Allegroグループ）、AliExpressハンガリー、Wishハンガリー、そしてハンガリーVATのもとで運営されるその他すべてのプラットフォームは、明示的に請求義務を販売者に課しています。ハンガリーVAT番号のもとでのすべてのB2CまたはB2B注文は、ハンガリー準拠のインボイスを作成する必要があり、そのインボイスは5分以内にNAVオンラインシャームラに送信される必要があります。

eMAG.hu — ハンガリー第1位のマーケットプレイス

eMAGは2001年にブカレストで設立された、ルーマニアに本拠を置く最大のマーケットプレイスで、2013年にハンガリーでeMAG.huとしてローンチされました。2026年までにeMAG.huは400万以上のハンガリー人顧客にサービスを提供しており、取扱量で見るとハンガリーの支配的なマーケットプレイスです — 市場シェアの点でポーランドのAllegroやトルコのTrendyolに匹敵します。eMAGマーケットプレイス・ハンガリーは、注文取得、商品アップロード、注文ステータス更新のために独自のMARKETPLACE APIを使用しています。インボイスは販売者に代わってeMAGが発行することはありません — 販売者がインボイス（通常はSzámlázz.hu / Billingo経由）を生成し、eMAGの注文エンドポイントを通じてPDFリンクを提供する必要があります。

Vatera — オークションの伝統を持つハンガリーのマーケットプレイス

Vateraは2000年にハンガリー初の大手オンラインオークションプラットフォームとしてローンチされ、2017年にAllegroグループに買収されました。2024年にAllegroがallegro.huをローンチした後も、Vateraはオークションおよび中古ロングテール市場に特化した別ブランドとして引き続き運営されています。今日では「今すぐ購入」の出品が主流です（オークションは取扱量の10%未満）が、ブランドの伝統的な購入者層は残っています。NAVオンラインシャームラは同様に適用されます：Vateraのすべての注文は、当日中のNAV送信を伴うインボイスを必要とします。

Allegro.hu、AliExpress HU、Wish HU

• Allegro.hu — AllegroグループのCEE展開の一環として2024年にローンチ。ポーランドのマーケットプレイスと同じAllegro APIを使用し、HUF/EUR建ての価格設定とハンガリー語での出品を採用。請求義務は販売者にあり、NAVオンラインシャームラへの送信が必要です。
• AliExpressハンガリー — アリババ子会社のハンガリー向けストアフロント。AliExpressのIOSS制度を利用する越境販売者も、ハンガリーVAT番号を保有する場合はハンガリー準拠のインボイスが必要です。
• Wishハンガリー — 存在感は縮小していますが依然として存在し、販売者による請求というルールは同じです。

Zunaproのマーケットプレイスフロー

Zunaproがオーケストレーションするエンドツーエンドのフローは以下のとおりです：

1. マーケットプレイス注文の取得 — eMAG / Vatera / Allegro.huのウェブフックがZunaproに届く
2. インボイス下書き — ZunaproがSKU単位のÁFA税率、通貨換算、顧客データを含むハンガリーインボイスを作成
3. ERPへの送信 — インボイスがSzámlázz.hu / Billingo（または直接NAV）に投稿される — RESTの往復は約1～3秒
4. NAVへの送信 — invoiceData XMLが署名され、onlineszamla.nav.gov.huに送信される
5. トランザクションID — NAVの10桁のトランザクションIDが注文に保存され、マーケットプレイスの注文がインボイスPDFのURLで更新される

8. EKAER — リスク物品向けの道路貨物事前通知

EKAERとは

EKAER（Elektronikus Közúti Áruforgalom Ellenőrző Rendszer — 電子道路貨物取引管理システム）は、リスク分類された物品の道路輸送に関するハンガリーの義務的事前通知制度です。EUにおける最初期のリアルタイムVAT不正管理制度の一つとして2015年1月1日に導入されたEKAERは、NAVがekaer.nav.gov.huで運営しており、対象となるすべての出荷について、トラックが動き出す前に登録が必要で、貨物とともに携帯し、道路上の取締りで求められれば提示しなければならない15桁のEKAER番号が発行されます。

2021年1月の適用範囲改革

EKAERは当初、ハンガリー国境を越えるほぼすべてのB2B道路貨物輸送に適用されていました。欧州委員会の違反是正圧力（EUの移動の自由に関する規則）を受け、ハンガリーは2021年1月1日から適用範囲をリスク製品カテゴリーのみに縮小しました。2026年時点でEKAERは以下をカバーしています：

• リスク食品 — 肉類、乳製品、砂糖、EKAER政令13/2020（XII.23.）PM附則1に記載された一部の油脂類
• その他のリスク製品 — 燃料、一部の化学物質、定められたHUF価値閾値内の建築資材
• 2,500kgまたはHUF 1,000,000の貨物価値を超える大口輸送（リスクカテゴリー内）

標準的なEコマース小包（衣料品、電子機器、アクセサリー）は2026年のEKAER適用範囲外です。DHL、GLS、FoxPost、Magyar Postaを通じてハンガリーへ出荷する越境オンライン販売者のほとんどは、そのためEKAERを必要としませんが、大口のB2B卸売輸送には依然として必要です。

EKAER通知の仕組み

トラックへの積み込み前に、荷送人はポータル（またはAPI経由）でEKAER通知を開き、以下を入力します：

• 送り主・受け取り主の税務ID
• 出発地・目的地の住所
• 貨物の説明、VTSZ税関コード、総重量、貨物価値
• 車両登録ナンバープレート＋到着予定時刻の枠

NAVは15桁のEKAER番号を返却します。通知は、出荷が到着する瞬間まで（車両プレートの変更、重量の許容誤差など）修正可能です。EKAERの未取得または不正確な場合の罰則：貨物価値の最大40%。

EKAER＋Online Számla — その相互関係

EKAERとOnline Számlaは、直接的な技術的リンクを持たない独立した制度ですが、データを共有しています。NAVはEKAERの貨物データをOnline Számlaのインボイス明細と照合し、VAT不正（過少申告された物品、幽霊インボイス、輸出の欠落）を検出します。リスクカテゴリーで事業を行う販売者にとって、同一の注文記録からNAVインボイスとEKAER通知を同時に発行する単一のZunaproパネルを持つことは、大きなリスク低減の手段となります。

9. 越境取引 — EUおよび第三国向け販売のIOSS＋OSS

OSS（ワンストップショップ）— 域内遠隔販売閾値を超えるEU B2C

2021年7月1日から、EUは国別の遠隔販売閾値を単一のEU全域10,000ユーロ閾値に置き換えました。他のEU加盟国への越境B2C販売合計が暦年で10,000ユーロを超えるハンガリーの販売者は、購入者の国の税率でVATを徴収する必要があります。26の他国でVAT登録するのではなく、販売者はNAVのKAFTAポータルを通じてOSS（ワンストップショップ）に登録し、すべてのEU加盟国をカバーする単一の四半期OSS申告を提出できます。

IOSS（輸入ワンストップショップ）— 150ユーロ未満の輸入

IOSSは、貨物価値が150ユーロ以下の第三国（EU域外）からの物品の輸入に適用されます。IOSSのもとでは、販売者はチェックアウト時にEU VAT（購入者の国の税率）を徴収し、すべてのEU向け貨物をカバーする単一の月次IOSS申告を提出します。メリットは：通関がほぼ即時になること、配達時の予期しない関税/VAT請求がないこと、そしてハンガリーの購入者にとって注文が国内購入のように感じられることです。

NAVオンラインシャームラとOSS・IOSSとの位置づけ

OSSとIOSSは別個のVAT申告制度です — 集計されたEU VATをNAVに申告しますが、Online Számla義務を代替するものではありません。ハンガリーのインボイスは依然として発行され、Online Számlaに送信される必要があります。両者の関係は次のとおりです：

• 国内HU B2C — 27%（または該当税率）でインボイスを発行 → NAVオンラインシャームラに送信 → 標準的なハンガリーVAT申告に含める
• OSS下のEU越境B2C — 仕向地国のVAT税率でインボイスを発行 → NAVオンラインシャームラに送信（XML内で越境フラグを設定）→ 四半期ごとに集計OSS申告を提出
• IOSS下の第三国B2C — IOSS VAT税率でインボイスを発行 → NAVオンラインシャームラに送信 → 毎月集計IOSS申告を提出
• OSS／IOSS対象外 — 国別のVAT登録が必要；ハンガリーVAT番号でインボイスが発行される場合、ハンガリーOnline Számlaは依然として適用されます

Zunaproの越境ルーティング

Zunaproは、購入者の配送先住所、貨物価値、販売者のVAT登録プロファイルに基づき、各注文を取得時点で正しい制度 — HU国内／OSS／IOSS／非EU — にタグ付けします。インボイスは正しいVAT税率で生成され、越境フラグを設定してNAVオンラインシャームラに送信され、月末に適切なOSS／IOSSエクスポートに集計されます。

10. 未来 — Peppol UBL 2.1 + EU ViDA

Peppolが重要な理由

Peppol（Pan-European Public Procurement Online）は、UBL 2.1規格とPeppol BIS Billing 3.0仕様を使用する、4コーナー式の電子インボイス交換ネットワークです。もともと公共調達向けに開発されたPeppolは、現在ではEUが優先する越境B2B電子インボイス形式であり、今後のEUViDA（デジタル時代のVAT）指令の技術的な基盤となっています。

ハンガリーのPeppolへのコミットメント

ハンガリーはEU理事会レベルで、越境B2Bインボイスの代替送信形式としてPeppol BIS Billing 3.0を受け入れることを約束しました。2026年第1四半期に公表されたNAVのロードマップは以下を目標としています：

• 2026年後半 — NAVがPeppolアクセスポイントを運用し、受信したUBL 2.1を内部処理用にinvoiceData v3.0に変換
• 2027年 — 送信側の変換：NAVのinvoiceData形式で提出されたインボイスを、UBL 2.1形式のPeppol経由で外国の購入者にルーティング可能に
• 2028年 — 完全なViDA整合：すべてのEU加盟国で調和されたリアルタイムのデジタル報告が、Peppolをデフォルトの技術レイヤーとして実現

Peppolがハンガリーの販売者にもたらす変化

国内のみの販売者にとってはほとんど変化はありません — invoiceData v3.0が引き続き主要な形式です。恩恵を受けるのは越境B2B販売者です：単一のUBLインボイスが、国ごとのアダプタロジックなしに、NAV（HU）、KSeF（PL）、FatturaPA（IT）、Chorus Pro（FR）を同時に満たせるようになります。2028年までには、同じ単一のインボイスがすべてのEU加盟国のデジタル報告要件をクリアするはずです。

ZunaproのPeppolロードマップ

ZunaproのUBL出力モジュールは活発に開発が進められています。このアーキテクチャは既存のNAVアダプタを踏襲しています：マーケットプレイス注文から生成されたインボイスは、invoiceData v3.0（NAV向け）とUBL 2.1（非ハンガリー人の購入者へのPeppolアクセスポイント経由の配送向け）で同時に発行されます。販売者は顧客ごとまたはマーケットプレイスごとにPeppolルーティングを有効にするかを選択できます。

2026年ハンガリーの法的枠組み — ルールの参照先

主要な法令

• 2007年付加価値税法（Áfa törvény、第CXXVII法） — 27%／18%／5%の税率、課税取引の範囲、および根底にある請求義務を定義。njt.hu（国家法令データベース）で閲覧可能。
• 2017年租税手続法（第CL法、Art tv.） — 第7条および第220条でOnline Számla報告義務を、罰則構造を含めて定義。
• NAV政令23/2014（VI. 30.）NGM — XMLスキーマ、5分の期限、APIエンドポイント、資格情報形式を定義する技術政令。毎年更新されており、2026年のPeppol統合を前にした最新の改正は2026年第1四半期に公表されました。
• EKAER政令13/2020（XII. 23.）PM — リスク製品カテゴリーおよび2021年の適用範囲改革を定義。

NAV運用ガイダンス

• onlineszamla.nav.gov.hu — 公式納税者ポータル；技術ユーザーの生成、XSDのダウンロード、ダウンタイムステータス、ハンガリー語・英語のFAQ
• nav.gov.hu — NAVのメインサイト；税率、OSS/IOSSガイダンス、外国の販売者向け英語ランディングページ
• ekaer.nav.gov.hu — EKAERポータルおよびリスク製品リスト

消費者保護 — GDPR、14日間のクーリングオフ、2年間の保証

• GDPR — ハンガリーのデータ保護当局はNAIH（Nemzeti Adatvédelmi és Információszabadság Hatóság）です。Online Számlaのデータは独自の法的根拠のもとNAVによって処理されますが、販売者側の顧客データは引き続き販売者のGDPR上の責任です。
• 14日間の撤回権 — ハンガリーの消費者は、理由を問わず、遠隔購入した商品を14日以内に返品できます（EU指令2011/83/EU、政令45/2014（II. 26.）Korm.によって国内法化）。
• 2年間の法定保証（kellékszavatosság） — ハンガリー民法（Ptk. 第6:163条）は、商業保証とは別に、消費財に対する2年間の法定保証を義務付けています。

NAVオンラインシャームラの始め方 — 2026年版ステップバイステップ

1. ハンガリーVATのフットプリントを決める

• ハンガリー居住の中小企業 — NAV ONYA経由での完全なハンガリーVAT登録、Online Számlaは必須
• OSSを利用するEUの販売者 — 自国のVAT登録を維持したまま、OSS経由でハンガリーB2C VATを申告しますが、他の理由でハンガリーVAT番号を保有した時点でOnline Számlaが適用されます
• EU域外の販売者 — ハンガリーの税務代理人を任命；ハンガリーVAT番号が発行された時点で、1件目のインボイスからOnline Számla送信が義務化されます

2. 請求方法を選ぶ

• Számlázz.hu — ハンガリー第1位のクラウド請求；設定の手間が最も少なく、完全にNAV自動化されており、取扱量が非常に少ない場合は無料
• Billingo — モダンなAPIファーストの代替案、Telekomがバックアップ、強力なShopify / WooCommerceエコシステム
• KBOSS Számla Agent — SAP / Dynamics企業向けデスクトップ/サーバーエージェント
• 直接NAV REST — 高取扱量の販売者（1日500件以上）や特殊なERP構成向け；Zunaproがこれをそのまま運用可能

3. NAV技術ユーザーの資格情報を生成する

1. ハンガリーのクライアントゲート（Ügyfélkapu）IDでonlineszamla.nav.gov.huにサインイン
2. 「Felhasználók」→「Új technikai felhasználó」を開く
3. ログイン名とパスワードを設定；システムが署名鍵と交換鍵を生成
4. 4つの資格情報すべてをダウンロードし、パスワードマネージャーに保存（Zunaproは暗号化されたボルト形式で受け付けます）

4. マーケットプレイスとウェブショップを接続する

NAVの資格情報を手にしたら、eMAG.hu、Vatera、Allegro.hu、AliExpress HU、Shoprenter / WooCommerce / Shopifyのショップ、そして任意の卸売ERPをZunaproハンガリーモジュールに接続します。各コネクタにはデフォルトのカテゴリマッピングとÁFA税率の推定機能が付属しており、販売者は数クリックで確認するだけです。

5. テストモードの往復を実行する

Zunaproは、NAVのサンドボックス（api-test.onlineszamla.nav.gov.hu）に対してテストモードのインボイスを発行します。テストが（通常2秒以内に）NAVトランザクションIDを返すと、販売者は本番モードに切り替えます。それ以降、すべてのマーケットプレイス注文は自動的にインボイスを生成し、5分のSLA以内にNAVへ送信し、トランザクションIDを注文記録に保存します。

6. 監視と監査

ZunaproのNAVダッシュボードは、送信レイテンシー、リトライキューの深さ、署名鍵の有効期限、NAVのダウンタイムウィンドウ、90日間の継続的な監査ログを表示します。会計士や外部監査人向けに、NAVとのやり取りの全ログは、税務申告の照合に対応した署名付きPDFまたはCSVとしてエクスポートできます。

NAVオンラインシャームラFAQ 2026