電子請求書の受領・検証

受領した各証憑に何が起きるか

1. 1 · セキュリティチェックファイルサイズ、フォーマット、XXE／DTD防御 — 改ざんされたファイルは、何かが処理される前に拒否されます。
2. 2 · 検証売上と同じエンジンによる完全なEN 16931検証。有効な証憑→アーカイブ、不備のある証憑→具体的なエラーコードとともに隔離。
3. 3 · 重複検知同じ仕入先、同じ請求書番号？ 二度目のアップロードは拒否されます（409） — 二重計上も二重支払いもありません。
4. 4 · 予備仕訳CoolHanXが税区分とSKR勘定科目を提案します — お客様の過去の判断から学習します。適用されるのはお客様が承認したものだけです。
5. 5 · 異常チェック主要取引先からの異常に高額な請求？ 通常と異なる通貨？ マイナスの合計？ こうした証憑は確認のためにマークされます — あくまで助言であり、判断はお客様が行います。
6. 6 · 処理ステータス各証憑は「未処理／処理済み」を保持します — 見落としがなく、コックピットが未処理案件を一目で表示します。

受領から支払いまで — 推奨される流れ

1. コックピットを確認：「未処理」に新しい有効な証憑が表示されます。2. 証憑を開く：可視ビューと予備仕訳の提案を確認し、異常マーカーに注意します。3. 区分を承認（ワンクリック、学習します）。4. 支払いを指示：バンキングで — IBANと金額は検証済みで証憑に記載されています。5. 処理済みとしてマーク。月末には、すべてをまとめてEXTFで税理士事務所へ送ります — 一連のサイクルは証憑1件あたり1分未満です。

隠れたエラーではなく隔離を

不備のある受領請求書は消えたり「なんとなく」計上されたりすることはありません。ファイル名とEN 16931のエラーコードとともに隔離されます。これにより、仕入先に正確に訂正を依頼でき、なぜその証憑が処理されなかったかの証跡も残ります。

導入事例

ある商社は2025年1月から大口仕入先の最初のXRechnungを受け取りました。以前は、誰も開けないXML添付ファイルでした。CoolHanXでは、アップロード、自動検証、予備仕訳の提案、税理士への月次引き渡し — そして二重支払いされる前にソフトウェアが捕捉した2件の重複がありました。

よくある質問

なぜ受領が仕入税額控除の問題なのか

受領は単なる形式ではありません。適正な受領請求書から、お客様は仕入税額控除を導きます（§15 UStG）。必須記載事項が欠けていたり請求書が形式的に不備であったりすると、仕入税額控除が危うくなる可能性があります — 最悪の場合、数年後の税務調査で初めて判明します。だからこそCoolHanXは、すべての受領証憑をEN 16931およびBR-DEルールに照らして検証し、検証レポートを監査対応の形で保存します。証憑が仕入税額控除に適格かどうかを、期待するのではなく、直ちに確認できます。

受領証憑の保存 — GoBDは双方向に適用される

原本フォーマットでの8年間・変更不可の保存（§147 AO、GoBD）は、受領請求書にも明確に適用されます。メールフォルダや印刷物では不十分です。基準となるのは原本の構造化XMLです。CoolHanXは、すべての有効な受領証憑をチェックサムとタイムスタンプとともにWORMアーカイブに格納します — 隔離も、なぜ証憑が処理されなかったかの証跡として保持されます。

ZUGFeRDの受領：XMLが基準となる

ZUGFeRD請求書（XMLを埋め込んだPDF）を受領した場合、CoolHanXはXMLを抽出し、あらゆるXRechnungと同様に検証します — 法的にも会計的にも、意味を持つのは構造化されたデータセットであり、見栄えのするPDF表示ではないからです。PDFとXMLが食い違う場合はXMLが基準となります。PDFは参考資料として表示されたまま残ります。

推奨される月次リズム

実務では、多くの事業者が受領を週次でまとめています。コックピットの「未処理」を開き、予備仕訳の提案と異常マーカーを確認し、区分を承認し（システムが学習します）、処理済みとしてマークします。月末には、すべてをまとめてDATEVBuchungsstapelで税理士事務所へ送ります — 証憑を失うことのない、閉じた追跡可能なサイクルです。

関連トピック