エストニアのKMD INFのしきい値は
請求書単位ではなく取引先単位です

KMD INFは要約ではなく照合ファイルです

この付属明細書は、ある企業の売上請求書を、その顧客の仕入リストにある同じ請求書と比較できるようにするために存在します。エストニアのKMD INF報告は個々の請求書から構成されており、この一点が以下のほとんどのルールを説明します。Value-Added Tax Actのsection 27(1²)は、VAT return（KMD）への月次付属明細書を義務付けており、他のVAT登録事業者との月間合計が€1,000に達した場合、それらの事業者に発行した請求書および受領した請求書を記載します。returnと付属明細書はいずれも翌月の20日までに提出します。Part Aには発行した請求書を記載します。Part Bには受領して控除した請求書を記載します。だからこそエストニアのVAT請求書報告は識別情報が鍵となり、どの請求書が、どの取引先から、どの期間に、どの番号で、という点が重要になります。

EMTAは不一致を見つけるために企業を監査する必要はありません。必要なのは取引先のファイルです。エストニア納税者協会のMaksuMaksja誌が引用した財務省の説明ノートによると、2023年に税務当局はKMD INF上の請求書データを比較して見つかった差異から€25 millionのVATを課税しました。同じノートは、差異は多くの場合、脱税ではなく、請求書データを手作業で入力する際の申告ミスから生じると述べています。

付属明細書はその点で珍しい存在です。VATを合計額で報告する国では、準備作業は分類が中心になります。スペインのModelo 303は税率・casilla別の合計から構成されるため、スペインの準備ガイドは金額を欄に割り当てる方法を扱っています。

提出する各行は、取引先が確認または否定できる主張です。

付表に記載するもの、記載しないもの

付表に記載するのは、エストニアのVATを24%、13%、または9%で含む国内の企業間請求書のみです。標準税率は2025年7月1日以降、22%から24%に引き上げられました。軽減税率は、宿泊に13%、書籍・定期刊行物・医薬品に9%が適用されます。経過措置として5%の税率が、2026年12月31日まで、2025年1月1日より前に請求・供給され、その後支払われた定期刊行物について、現金主義の事業者に引き続き適用されます。古い請求書に対するクレジットノートは、元の供給の税率を引き継ぐため、手順書には22%や20%も依然として記載されています。

取引の相手方は、法人、自営業者（FIE）、または国・地方自治体・市政府のいずれかでなければなりません。個人への販売は、その個人が自己名義で請求書を求めたとしても、報告の対象外です。エストニアの登録コードを持たない外国の供給者も対象外となり、これによりほとんどのEU内購入が付表から除外されます。Part Bにはもう一つの条件があります。請求書のVATが、KMDのfield 5で全額または一部が控除可能でなければなりません。

0%または非課税供給のみの請求書は、金額がどれほど大きくてもKMD INFの請求書ではありません。

KMD INFのしきい値は請求書単位ではなく取引先単位です

KMD INFのしきい値は、1暦月における同一取引先とのすべての請求書の合計に対する判定であり、請求書1枚ごとの上限ではありません。 文言は「少なくとも€1,000」であるため、€1,000ちょうどは対象となり、€999.99は対象外です。合計がしきい値に達したら、その期間のその取引先とのすべての請求書を申告します。€40の請求書も、credit noteも含まれます。

重要な区別が3つあります。発行した請求書と受領した請求書は別々に判定されるため、同じ取引先がPart Aに記載されてもPart Bには記載されないことがあります。通常の請求書とcredit noteも別々に判定され、これは後述します。また、複数の会社が1つのVAT番号を共有するVATグループでは、グループで1つの申告を行う場合でも、各構成員がそれぞれ自分のしきい値を判定します。さらに、請求書がしきい値に算入されるのは、最初に申告された期間の1回だけです。継続取引のため同じ請求書を後で再度申告しても、2回目は算入されません。EMTAのKMD INFフォームの手順書に、この判定方法と請求書ごとの4行の上限が定められています。

ルールは述べるのは簡単ですが、実務では見落としがちです。同じ雑誌に寄稿した税務実務家は、年に2回、簡易請求書の箱を渡されると述べています。そのほとんどは燃料レシートで、それぞれに会社名とVAT番号がすでに押印されています。1つのガソリンスタンドで月に数回給油するだけで、誰も報告を決めないまま€1,000に達します。

クレジットノートには独自の€1,000基準が適用されます

クレジットノートは、限度額を適用する前に、それが訂正する請求書から差し引かれることはありません。通常の請求書とクレジット請求書は別々に合計されます。通常の合計が€1,000に達した場合、その取引先のすべての請求書が申告され、クレジットノートも含まれます。クレジットの合計だけが€1,000に達した場合も同じです。その引き金となったクレジットノートだけでなく、その取引先の全セットが申告されます。

フォーム上では、クレジットノートと課税価額の減額にはマイナス記号が付きます。3月の€4,000の請求書と4月の€4,000のクレジットノートは、3月に行、4月に行を生じさせます。年間ではゼロに相殺されますが、どちらの月も空にはなりません。

クレジットノートをそれが取り消す請求書と相殺すると、どちらの側も一致させられない取引先合計が生じます。

Part AとPart Bは互いを反映しません

Part AはVAT前の金額を報告し、Part BはVAT後の金額を報告するため、両方のファイルが正しくても金額列で一致しないことがあります。 これはフォームのバグではありません。それぞれの側が異なる問いに答えています。

Part Aは、供給したものと、そのうちどれだけがKMDで課税供給として申告されたかを報告します。Part Bは、受け取ったものと、その期間に実際に控除した仕入VATを報告します。50パーセントの控除がある購入請求書では、column 8には請求書に印字されたVATの半分が入り、exception code 11がその理由を説明します。code 12は国内リバースチャージ購入を示します。VATが請求書の支払時に計上されるキャッシュ会計制度では、支払いがあるまでcolumn 8はゼロです。どちらの数値も、ページに印字されたVATではありません。

これらの差異は正当なものです。購入は完全に有効で全額支払済みであっても、そのVATが控除されていなければPart Bに存在しないことがあります。クレジットノートが、対応する請求書のない月に現れることもあります。取引先の合計が、1回の納品のタイミングによって自社の合計と異なることもあります。いずれも申告エラーではなく、2つのファイルを無理に一致させることでは解決できません。

購入請求書は有効で支払済みであっても、そのVATが控除されていなければPart Bに存在しないことがあります。

期間は請求書の日付ではなく供給から決まる

請求書は、供給が行われた期間または控除が生じた期間に申告され、請求書に印字された期間ではありません。EMTA自身の例がその結果を具体的に示しています。1月に発行された、まだ納品されていない商品に対する€1,000の請求書が、2月に€240、4月に€1,000支払われた場合、Part Aでは2月と4月に申告されます。1月と3月にはその行は一切ありません。

請求書日付の列は、どちらの行でも1月のままです。月ごとに比較する取引先は、1月の請求書が2月と4月にあるのを見て、期間の誤りのように見えますが、誤りではありません。同じ論理が購入側にも当てはまります。請求書が20日以降に届いた場合、仕入VATは請求書を受け取った月に控除されるため、Part Bの行は供給ではなく控除に合わせて移動します。

これが、上限が一度だけカウントされる理由でもあります。2月に初めて申告され、4月に再び申告された€1,000の請求書は、2月にのみ上限に算入されます。4月の行では判定が再実行されません。

日付の列は請求書の日付です。期間は供給の日付です。行は一方を保持し、もう一方で申告されます。

一致するかどうかを決めるフィールド

7つのフィールドが、自社の行が取引先の行と一致するかどうかを決めます。最初の4つは請求書を識別し、最後の3つは金額を担います。行の残りの部分が正しくても、これらのいずれかが誤っていれば一致は失敗します。

静かに失敗するフィールドは registry code です。e-MTA の申告ポータルはコードを入力すると名前を自動入力し、名前を入力すると検証しますが、取引先マスタに存在しなかったコードを生成することはできません。フォームの説明によれば、税務当局が提出データから人物を特定できる場合、コードの欠落は自動的に未申告とはみなされませんが、その行はコードのある行より弱いままです。

請求書番号が、あなたの行と相手の行を結び付けます。金額がすべて正しくても、一致しないことがあります。

請求書から別表を作成する

別表は請求書1件につき1行なので、20日までにPDFのフォルダをその行に変換する作業が必要です。 これは税務の問題である前にデータ入力の問題であり、 ministry's note にある手作業のミスはここから生じます。

ImageToTable.ai はこれを Custom Column Extraction で解決します。必要な列名を入力すると、AIがフィールドの意味を理解して各請求書の値を特定します。固定位置やサプライヤーごとのテンプレートに照合するのではありません。通信費の請求書、燃料の領収書、公共料金の明細を同じバッチに入れても、同じ列に収まります。別表のフィールドはサプライヤーごとにレイアウト上の位置が異なり、3月に請求書を刷新したサプライヤーでも新しい設定が不要であることが重要です。

別表で使える列セット: partner registry code、partner name、invoice number、invoice date、total excluding VAT、total including VAT、VAT rate、taxable value at that rate、VAT amount。さらに Rate Lines Check (sum of rate lines, output the difference from the printed total) のような名前の computed column を追加すると、合計が合わない複数税率の請求書をフォームに入力する前に発見できます。computed column は抽出時にツールが実行する計算で、独自の列としてテーブルに書き込まれるため、後から計算を確認するより速く処理できます。

その月の請求書を1つのバッチとしてアップロードします。Batch processing とは複数のファイルを一度に投入し、1つのテーブルとして出力する処理で、請求書1件につき1行となり、別表に必要な形になります。次に、照合を左右する3つのフィールド(invoice number、invoice date、amount)に Review Mode with Bbox を使います。セルをクリックすると元のページ上でその領域がハイライトされるため、誤った行から読み取られた数値をドキュメント全体を読み直すことなく発見できます。

€1,000 の判定自体は列ではありません。ピボットです。行を registry code でグループ化し、amount excluding VAT を合計し、€1,000 以上のすべての partner にフラグを立てます。同じピボットを credit note のみで再度実行します。この2回のチェックは、抽出ツールよりもスプレッドシートの方が得意な部分であり、締め切りが近いときに最も省略されがちな部分です。

抽出は請求書1件につきクリーンな行を提供します。€1,000 の判定はピボットであり、列ではありません。

抽出が止まる場所

ツールは行を生成しますが、何を附属書に載せるべきかは判断しません。 この境界はほとんどの請求書業務よりも重要です。誤った判断は、乱れたスプレッドシートではなくコンプライアンス上の問題になるからです。

• 申告や送信は行いません。 KMD INF は、XML または CSV のアップロード、あるいは国家のデータ交換レイヤーである X-tee を通じて、会計ソフトから手動で e-MTA に送信します。ツールはこれらのチャネルのいずれにも接続しません。
• 税務上の取扱いを判断しません。 VAT が控除可能か、請求書が附属書の対象範囲内か、その供給がどの期間に属するかは、取引に関する判断であり、ページを読み取ることではありません。
• 照合は行いません。 あなたのファイルを取引先の申告や EMTA 自身のデータと比較することはできません。どちらも入力ではないからです。
• 欠落した registry code を補うことはできません。 コードが請求書にない場合、サプライヤマスタから取得する必要があります。これは毎月の作業ではなく、一度きりのマッピングです。
• 取引先ごとの上限は適用しません。 この判定は請求書をまたいで実行されるもので、前述のピボットに属します。

明細行や税の内訳を含む、請求書の背後にあるより広範なフィールド群については、請求書データ抽出の完全ガイドが、本記事が意図的に省いた部分を扱っています。

2027年4月に変わること

2027年4月から、附属書は様式ではなくデータフィードになりますが、請求書レベルの詳細はなくなりません。 EMTA は KMD 申告をデータベース型の提出に置き換え、事業者が送信する取引データから納税申告書が生成されます。Part A と Part B は、売上、逆課税仕入、調整仕訳、仕入の4つのセクションに置き換わります。

転送方法も変わります。データは会計ソフトから e-MTA へ、会計データ用の構造化フォーマットである XBRL GL でマシン間転送され、移行用の CSV フォーマットが用意され、従来の XML はなくなります。以前は様式 VD だった域内供給データも、同じ提出に統合されます。請求書ごとに必要な詳細は変わりませんが、各レコードには取引タイプと取引先または請求書の識別子を含める必要があります。€1,000 の除外は EMTA の現在のガイダンスでも維持されています。€1,000 未満の請求書と個人宛の請求書は、依然として申告する必要がありません。

実務上の影響は、ファイルが元帳の請求書データを直接反映するものになることです。請求書番号の欠落やコードのない取引先は、様式記入の問題ではなく、ソースシステムにおけるデータの問題になります。エストニアはフランスやドイツと同じ方向に進んでいますが、リアルタイムのクリアリングではなく定期報告を維持しています。

EMTA は、この変更により事業者が年間最大500万労働時間を削減できると推定しています。主な理由は、e-MTA への繰り返しの手動入力がなくなることです。上記の請求書フィールドは、新しいエンベロープでも同じフィールドです。それらをページから正確に取り出す作業は変わりません。

2027年の変更は、同じフィールドを別のエンベロープに移すものです。

FAQ

€999の請求書はKMD INFへの報告が必要ですか？

いいえ、その請求書単体では不要です。上限はその月の同一取引先との合計額（VATを除く）に適用されるため、€999の請求書1件だけでは対象外です。ただし、同じ取引先との他の請求書により合計が€1,000に達する場合は対象となります。上限未満の請求書をsection 27(1³)に基づき任意で申告することも可能で、ファイルの整合性を保つためにそうする企業もありますが、義務ではありません。

上限を適用する前に、credit noteを売上請求書と相殺すべきですか？

いいえ。通常の請求書とcredit invoiceは、€1,000の判定のために別々に集計します。いずれかの合計が上限に達した場合、その期間の同一取引先とのすべての請求書を申告します。マイナス符号が付くcredit noteも含まれます。先に相殺すると、本来記載すべき取引先が隠れてしまう可能性があります。

ドイツの仕入先からの請求書は報告しますか？

仕入先がEstonian register codeを有する場合のみ報告します。その場合、請求書はnon-resident codeの下でPart Bに記載します。VAT 0%およびreverse chargeを伴う通常のintra-EU acquisitionはKMD INFの対象ではなく、KMD return自体のintra-Community acquisition欄およびinput VAT欄で報告します。

請求書にbuyerのregistry codeが記載されていない場合はどうなりますか？

この別表はregistry codeによって取引先を識別するため、取引先を適切に記載することができません。提出データから税務当局がその者を識別できる場合、codeの記載漏れが自動的に申告義務違反とみなされるわけではありませんが、それに依存するのは管理策として不十分です。仕入先または顧客のレコードを一度修正すれば、この問題は再発しなくなります。

請求書ごとではなく取引先ごとに1行で報告できますか？

いいえ。取引先ごとの合計額を要約して提出するオプションは2015年に終了し、2016年以降は請求書ごとに記載します。1件の請求書が税率や特別制度を混在させる場合、最大4行を占めることがあり、それらの行には請求書の識別情報を繰り返し記載する必要があります。

不正確なKMD INFには実際いくらかかるのか？

最初の結果は通常、金銭的というより行政上のものです。EMTAのガイダンスによると、不正確な別表データは税務行動評価（各企業に表示される1〜3のコンプライアンススコア）に差異を生じさせ、VAT returnが管理対象へ回される可能性があります。同じ申告書の提出を強制するために課される延滞金は€3,300が上限ですが、不正確なデータがVATの過少申告につながる場合、罰金は€32,000に達することがあり、1日あたり0.06パーセントの延滞利息がかかります。

ImageToTable.aiはKMD INFを提出できますか？

いいえ。請求書のフィールドを抽出してテーブルを作成するだけです。提出、対象範囲の判断、取引先との照合は、利用者または会計士が行います。

別表は請求書ごとに判定され、必要なフィールドは請求書にしか存在しません。毎月、そのテーブルは比較されることを想定されていないドキュメントから作り直されます。

今月の請求書で試す