請求書と電子インボイス

Spec Spec: EN 16931-1:2026, BT-24 EN 16931-1:2026 BT-24 Spec Spec: Factur-X 1.08 Factur-X 1.08 Spec Spec: ISO 32000-2:2020, §14.13 ISO 32000-2:2020 §14.13 Evidence ⊕ Mixed evidence Evidence: Mixed evidence

概要

現代の請求書は、1 つのファイルに 2 つの文書を収めたものです。人が読むページと、税務システムが解析する機械可読な XML ペイロードです。このページでは、ハイブリッド請求書のシナリオを義務から出力までたどります。ZUGFeRD と Factur-X が実際に何を要求するのか、NextPDF が構造化ペイロードをどのように添付して検査するのか、そしてどこから準拠がエンジンではなくあなたの責任になるのかを示します。

なぜ重要か

現在、複数の法域では、企業間（B2B）または企業対政府（B2G）の請求に構造化請求書を義務付けています。落とし穴は、ハイブリッド請求書が画面上では完璧に見えても、それでも拒否されることがある点です。拒否はピクセルではなく、埋め込まれた XML に対して発生します。構造化ペイロードに仕様識別子が欠けている、誤ったプロファイルを宣言している、あるいは誤った関係で添付されている場合、受信プラットフォームはそれを不合格とみなします。あなたの側では、その失敗はしばしば何も通知されないまま、数日後の支払い滞留として現れます。

ファイルを生成するレイヤーで一度正しく処理しておくほうが、クリアランス済みの請求書を 1 通ずつ調べて問題を見つけるよりも、はるかに低コストです。

要点

• 準拠したハイブリッド請求書は、適合する XML ペイロードを関連ファイルとして埋め込んだ PDF/A キャリア です。キャリアのメタデータはプロファイルを宣言しなければなりません。
• 受理を最も大きく左右する単一のフィールドは、仕様識別子である BT-24 です。EN 16931 のビジネスルール BR-1 は、すべての請求書がこれを保持することを要求します。その値は、正確なプロファイルを示す URN です。たとえば EN 16931（COMFORT）プロファイルの urn:cen.eu:en16931:2017 です。
• NextPDF の役割は、呼び出し側が提供した XML の 埋め込みと構造検証 です。請求書の内容は作成せず、税務当局のバリデーターでもありません。
• 法的・財務的な正しさについては、発行者が引き続き責任を負います。クリーンな検証結果は、その判断材料の 1 つであり、証明書ではありません。

NextPDF のアプローチ

NextPDF は構造化請求書を、単一の機能ではなく ティア横断の契約 として扱います。コアエンジンがインターフェース（埋め込み器、プロファイル記述子、バリデーター）を定義し、Premium ティアが実装を提供します。この分離は意図的なものです。公開サーフェスはコアで凍結されているため、呼び出し箇所とテストは、背後にあるティアにかかわらず同じ方法でプロファイルと結果を扱えます。

フローには 4 つの段階があり、各段階は直前の段階に依存するため、順序が重要です。

1. Author the invoice XML You (or your ERP) produce a UN/CEFACT CII or Peppol UBL payload. NextPDF never synthesizes invoice content.
2. Produce the PDF/A carrier A PDF/A-3 or PDF/A-4f document is the human-readable face and the conformant container the standard requires.
3. Embed the payload The embedder attaches the XML as an associated file with the correct AFRelationship, and injects the Factur-X XMP profile declaration.
4. Validate, then ship A structural pass checks the root, the required sections, and BT-24 against the declared profile before the file leaves your system.

ハイブリッド電子インボイスのシナリオを端から端まで示します。あなたが XML を作成し、その法的な正しさを所有します。NextPDF がそれを運び、構造的に検査します。受信プラットフォームが最終的な受理判断を下します。

埋め込み器の契約は、バイト列を受け取りバイト列を返すことです。PDF/A キャリアと XML ペイロードを入力すると、ハイブリッド PDF バイト列が出力されます。添付処理に入る前に、XML は堅牢化されたガード処理を通して解析されます。これは DOCTYPE を拒否し、入力サイズに上限を設け、XML 1.0 で禁止された制御文字を拒みます。請求書 XML は信頼境界の外から日常的に入力されるため、これにより XML 外部実体攻撃と Billion-Laughs 攻撃を構造的に排除します。

プロファイル記述子は、下流システムからの 4 つの問いに答えます。正準のプロファイル URN、表明すべき BT-24 の値、ログ用の安定した名前、そしてパリティテストで結果をグループ化できるティア中立の識別子です。記述子は、不足している点を隠しません。ZUGFeRD の MINIMUM プロファイルは BT-24 仕様識別子を持たないため、記述子は値を捏造せずに null を返します。これが、MINIMUM と BASIC WL が EN 16931 適合ではない理由でもあります。エンジンはカーディナリティの実態をエンコードし、 それを隠しません。

Human-factors note: Human-factors note

バリデーターには 2 つのモードがあり、デフォルトは保守的なほうです。 デフォルトモードでは BT-24 の欠落は警告として報告されるため、既存のパイプラインがブール値でゲートしていても、暗黙のうちに退行することはありません。 厳格（STRICT）モードは同じ所見をハードエラーに昇格させ、外部バリデーターのセマンティクスに合わせます。 このモードは、呼び出しごとにあなたが意図的に行う選択です。 エンジンがあなたのリスク姿勢を勝手に選ぶことはなく、どの姿勢が有効かを推測させるのではなく明示的に伝えます。

エビデンスが示すこと

上記の挙動は 3 つの場所で裏付けられており、それぞれ異なる種類のエビデンスを持ちます。

標準 が義務を定めます。 Spec Spec: EN 16931-1:2026, BR-1 EN 16931-1:2026 BR-1 は仕様識別子をすべての請求書で必須にします。Factur-X の技術附属書は、EN 16931 プロファイルの urn:cen.eu:en16931:2017 を含め、プロファイルごとに URN の値を確定します。キャリア自体は PDF 側の関心事です。 Spec Spec: ISO 32000-2:2020, §9 ISO 32000-2:2020 §9 は、すべてのフォントが埋め込まれているときに、最も予測可能で信頼できるレンダリングが得られると述べています。これは直接関係します。なぜなら、 10 年後にも読める必要がある請求書は、読み手のフォント環境に依存できないからです。

コード が契約を保持します。 Evidence { } Code-backed Evidence: Code-backed コアの EmbedderInterface、ProfileInterface、ValidatorInterface は、実装に依存しないティア中立のインターフェースです。ProfileType::isEn16931Conformant() は、MINIMUM/BASIC WL の除外を型システムにエンコードします。ValidationResult は不変の DTO であり、その isValid は「エラー所見なし」と「致命的なルール違反なし」の論理積です。

挙動 は Premium ティアについて、ケイパビリティレベルで文書化されています。 Evidence § Standard-backed Evidence: Standard-backed 埋め込み器は、呼び出し側が提供した ZUGFeRD 2.4/Factur-X 1.08 CII または Peppol UBL XML を、PDF/A-4f または PDF/A-3b キャリアに、正しい関連ファイル関係で添付します。バリデーターは EN 16931 のセマンティックモデルと BT-24 識別子を検査します。Schematron 段階は XSLT にコンパイルされた CEN ルールセットを実行します。これらはいずれも、請求書の内容を生成も修正もしません。

実践例

以下の例は連携点を示すためのものであり、コピー＆ペーストで使える統合ではありません。キャリアの構築と埋め込み器は Premium ティア由来であり、XML はあなたが用意するものです。

<?php

declare(strict_types=1);

use NextPDF\Contracts\EInvoice\ProfileType;
use NextPDF\Contracts\EInvoice\ValidatorContext;
use NextPDF\Contracts\EInvoice\ValidatorInterface;
use NextPDF\Contracts\EInvoice\EmbedderInterface;
use NextPDF\Contracts\EInvoice\EmbedderOptions;
use Psr\Log\LoggerInterface;

/**
 * Validate first, embed second, never ship an invalid payload.
 *
 * @param non-empty-string $carrierPdf  PDF/A-3 or PDF/A-4f carrier bytes
 * @param non-empty-string $ciiXml      Caller-authored UN/CEFACT CII XML
 *
 * @return non-empty-string Hybrid invoice bytes, ready to deliver
 */
function buildHybridInvoice(
    ValidatorInterface $validator,
    EmbedderInterface $embedder,
    LoggerInterface $logger,
    string $carrierPdf,
    string $ciiXml,
): string {
    // STRICT mode: a missing BT-24 is a hard error, not a warning.
    $context = new ValidatorContext(
        profile: ProfileType::EN16931,
        strictMode: true,
    );

    $result = $validator->validate($ciiXml, $context);

    if (!$result->isValid) {
        foreach ($result->getErrors() as $finding) {
            $logger->error('invoice.structural_finding', [
                'message' => $finding->message,
            ]);
        }

        // A failed structural check is your signal to stop, not to ship.
        throw new \RuntimeException('Invoice XML failed structural validation.');
    }

    $options = new EmbedderOptions(profile: ProfileType::EN16931);

    return $embedder->embed($carrierPdf, $ciiXml, $options);
}

順序こそが要点です。検証は、請求書の拒否や支払い遅延に比べれば安価なので、ペイロードを添付する前に実行します。

よくある誤解

最もコストの高い誤解は 「NextPDF が私の請求書を準拠させてくれる」 というものです。そうではなく、エンジンはその境界を明確にしています。エンジンは、あなたが作成した XML を埋め込み、構造的に検査します。構造検証が通るということは、ペイロードが EN 16931 の期待する構造を持ち、あなたが指定したプロファイルを宣言していることを意味します。それは、請求書が法的に十分である、税務当局に承認されている、あるいはいずれかのクリアランスプラットフォームに受理されることが保証されている、という意味では ありません。各国独自の拡張やクリアランス転送は、エンジンレベルでは対象外です。EN 16931-1 自身が位置づけているように、コアモデルは準拠を支えるために必要な情報を保持します。該当する法令を満たす責任は、発行者にあります。

2 つ目の、見落とされやすい落とし穴があります。標準のサポートは、その標準への適合ではありません。適合とは、最終ファイルとバリデーターに関する性質であり、それを生成したライブラリの性質ではありません。

限界と境界

• NextPDF は請求書の内容を作成も修正もしません。 呼び出し側が有効な XML を提供し、請求書の発行者であり続けます。所見リストが空であっても、非適合のペイロードが適合になるわけではありません。
• 構造化埋め込みと Schematron 検証は Premium ティアのケイパビリティです。 コアは契約を定義し、実装には商用パッケージが必要です。以下の境界を参照してください。
• バリデーターは EN 16931 のセマンティックモデルと ZUGFeRD/Factur-X/UBL コンテナのみを検査します。 税務当局のバリデーターではありません。SDI、Chorus Pro、XRechnung の転送は、転送レベルでは対象外です。
• MINIMUM および BASIC WL プロファイルは EN 16931 適合ではなく、BT-24 仕様識別子を持ちません。これは設計上のものであり、エンジンの限界ではなく標準のカーディナリティを反映したものです。
• Schematron エンジンには ext-xsl が必要です。 ルールセットはビルド時にコンパイルされます。ランタイムは、ネットワークとファイルシステムのリソース読み込みを無効化したうえで、事前コンパイル済みの XSLT のみを実行します。
• このページはケイパビリティレベルの挙動を記述しています。特定の当局やプラットフォームによる受理を主張するものではありません。

Structured e-invoice embedding and validation — edition availability

Edition	Availability
Core	○ コアはティア横断の契約（EmbedderInterface、 ProfileInterface、ValidatorInterface）を定義しますが、構造化請求書の実装は同梱しません。 構造化ペイロードを持たない素の PDF キャリアがコア単体での結果です。
Pro	○ Factur-X 1.08 CII の PDF/A キャリアへの埋め込みと、EN 16931 プロファイル記述子が利用できます。
Enterprise	○ Peppol BIS 3.0 UBL の埋め込み、XRechnung B2G CIUS、COMPAT/STRICT XML 検証、そしてインプロセスの Schematron ルールエンジンを追加します。

関連ドキュメント

• アーカイブと PDF/A — なぜ請求書キャリアが PDF/A ファイルなのか、そしてそれが長期的な可読性に何を保証するのか。
• 統合の意思決定ガイド — どのエコシステムパッケージが、請求パイプライン（キュー生成、フレームワークブリッジ、または Connect）に適合するのか。
• 本番環境での NextPDF の運用 — 請求書が大量に流れ始めた後に、検証の所見や失敗をどう観測するのか。

用語集

• ハイブリッド請求書 — 人が読めるページと、機械可読な埋め込み XML 請求書ペイロードの両方を備えた単一の PDF ファイル。
• ZUGFeRD/Factur-X — 同じハイブリッド請求書アプローチを指すドイツ語名とフランス語名。UN/CEFACT Cross Industry Invoice（CII）XML ペイロードを PDF/A キャリアに埋め込んだもの。
• EN 16931 — 電子請求書のコア要素のセマンティックデータモデルを定義する欧州標準。
• BT-24（仕様識別子） — 請求書が適合する正確なプロファイルを名付ける URN を値とする EN 16931 のビジネス用語。 ビジネスルール BR-1 により必須。
• プロファイル — 適合レベル（MINIMUM、BASIC WL、BASIC、EN 16931、EXTENDED、XRECHNUNG）とも呼ばれます。請求書がどのビジネス用語を保持しなければならないかを決定します。
• 関連ファイル — 可視文書とどう関係するかを記述する宣言済みの関係（AFRelationship）とともに PDF 内に添付されたファイル。請求書 XML を運ぶ仕組み。
• Schematron — EN 16931 のビジネスルールを表現するために使用されるルール言語。NextPDF は XSLT にコンパイルされた CEN ルールセットを実行します。