三分一技術士事務所

ペポルの「インボイス応答」プロセス・ルール要約

Views: 38

本稿は Peppol BIS Invoice Response 3.2 の「Invoice Response process rules」と関連セクションを、日本語で実務向けに要約したものです（正式仕様は原典を参照）。

BIS Invoice Response 3.2

BIS Invoice Response

1. 位置づけと範囲

Invoice Response は 買い手→売り手 一方向で、買い手側の承認・支払プロセスにおける 請求書（またはクレジットノート） の ステータス を通知するメッセージです。複数回送ることができ、各メッセージは 単一の請求書に対し、上位ステータスを 1 つだけ運ぶのが原則です（複数ステータスは別メッセージで順次通知）。

2. 概要

  • Invoice Responseは、買い手の承認・支払プロセス上の請求書/クレジットノートのステータスを、買い手→売り手に通知するメッセージ。

  • 目的：処理停滞や不備時に早期アクションを促し、承認/支払開始を売り手に伝えて資金繰りを可視化。

  • 性格：情報提供（informative）で、売り手側の自動処理を想定（ただし一部は手動対応が必要になり得る）。

2.1. メリット（Why）

  • 処理に問題が生じた時点で早期に通知し、売り手の対処を前倒し。

  • 承認済/支払開始の可視化により、売り手がキャッシュフロー管理や入金確認をしやすい。

  • 買い手側の自動通知により、手作業の照会を削減。

2.2. スコープ内（In scope）

  • 買い手の業務ルールに基づく、請求書/クレジットノートの処理ステップと状態の通知。

  • 一方向（Buyer→Seller）のみ。

  • 1つの請求書に対して複数回のレスポンス送信があり得る。

  • プッシュ通知のみ（売り手から自動リクエストは不可）。

  • 受領可能性の通知（受領・処理投入可の確認）を含む。

  • 売り手に手動対応が必要となる内容を含み得る。

2.3. スコープ外（Out of scope）

  • 行レベルの応答。

  • 1メッセージ内に複数ステータス。

  • 売り手側の完全自動化（全てのエラーの機械化は前提としない）。

  • 双方向のやり取り（応答メッセージ上でのディスカッション）。

  • 応答メッセージの照会（売り手からの取得要求）。

  • 伝送レイヤのステータス通知。

  • 添付ファイルのサポート。

2.4. プロセス・ルール（抜粋）

  • OP-BR111-R001：方向は Buyer→Seller のみ（通知目的）。

  • OP-BR111-R002：1メッセージ=1請求書=上位ステータス1つ。複数ステータスはメッセージを分ける。

  • OP-BR111-R003：同一請求書に対し複数の Invoice Response を送ってよい。

  • ステータス表の方針：
    – ステータスコードのリストは固定（相互合意で変更不可）。
    – 事前合意済みの主ステータスは 7種。
    – 初回応答は3営業日以内が目安（最低限 “Message acknowledged”“Rejected”“Approved” をサポート）。

  • ステータスの進行順（どれから開始してもよい／省略可だが、前進はこの順序）
    AB → IP → UQ → CA → RE → AP → PD（UQ は前進前に繰り返し可。PD は部分支払い PPD と併用可）。

Status

3. 例：請求書 INV-2025-0612 に対するステータス遷移

3.1. 前提

  • 売り手：□□物産 / 買い手：〇〇百貨店

  • 請求書ID：INV-2025-0612（2025-06-12 送付）

  • 買い手が自社の承認・支払プロセス進捗を Invoice Response（ApplicationResponse）で通知する運用。
    （BISは Buyer→Seller の一方向通知。行レベル応答や複数ステータス同報は対象外）

3.2. タイムライン（メッセージごとに 4343 を1つ）

  1. AB — Message acknowledgement（受領通知）（2025-06-12）

    • 目的：受領し処理投入可能であることを通知。

    • 設定：/DocumentResponse/Response/ResponseCode = AB

    • 備考：輸送層ACKではなくビジネス層の“受領可”（処理に乗る）を意味。

  2. IP — In process（処理中）（2025-06-13）

    • 目的：社内検証・承認フローを開始したことを通知。

    • 設定：ResponseCode = IP

    • 備考：この時点では追加情報も差戻しも無し（Clarification不要）。

  3. UQ — Under query（照会中）（2025-06-14）

    • 事象：単価が契約と不一致（例：和食器セットが 10,000 だが契約は 12,000）。

    • 目的：承認プロセスを一時停止し、追加情報/訂正提案を求める。

    • 設定：ResponseCode = UQ ＋ Clarification（理由・期待値・アクション）

    • 例：

    • Clarification.Reason = PRICE_MISMATCH

    • Clarification.Data = ExpectedUnitPrice=12000; Currency=JPY

    • Clarification.Action = Please confirm or resend corrected invoice

    • 備考：売り手の対応を待ってから承認を再開。必要に応じ UQ を繰り返すこともある。

  4. CA — Conditionally accepted（条件付承認）（2025-06-17）

    • 事象：買い手は契約条件に従って支払う旨を宣言（例：支払期日・口座の相違を契約側に合わせる）。

    • 目的：条件を明示して先に進める（売り手が異議なければその条件で進行）。

    • 設定：ResponseCode = CA ＋ Clarification（条件を明示）

    • 例：PayAccordingToContract=true; PaymentDueDate=2025-07-10; BankAccount=XXXX

    • 備考：売り手が外部で異議を申し立てることもできるが、異議なければ条件で支払に進む。

  5. RE — Rejected（否認）（2025-06-18）（分岐例）

    • 事象：別の行で納入不足が見つかり、該当請求を処理しない判断。

    • 目的：最終的に不処理であることを通知（必要ならクレジットノートを依頼）。

    • 設定：ResponseCode = RE ＋ Clarification.Reason（例：SHORT_DELIVERY）

    • 備考：最終ステータス。以降は外部での調整（再請求・訂正発行など）。

      *（※本例は分岐を示すために RE を置きました。RE を経ずに AP/PD へ進む“正常系”は次のとおり）*

  6. AP — Accepted（承認）（2025-06-19）（正常系）

    • 事象：必要な照会が解消され、支払に進める状態に。

    • 目的：承認完了を通知。

    • 設定：ResponseCode = AP

    • 備考：支払起動へ。

  7. PD / PPD — Paid / Partially paid（支払済／部分支払）（2025-07-10）

    • 事象：支払実施。一部支払なら PPD を併記。

    • 設定：ResponseCode = PD（必要に応じ PPD 情報を Clarification.Data 等で補足）

    • 備考：最終ステータス（AP 後に到達）。クレジットノートには PD は通常適用しない点に留意。

3.3. 実装ヒント（フィールド例）

  • UBL パス：/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cbc:ResponseCode（= 4343 サブセット）
    Clarification は同 Response 配下で理由・アクション・データを表現。

  • 1メッセージ=1請求書=1ステータス（複数ステータスはメッセージ分割）。行レベル応答は対象外。

  • 買い手→売り手の一方向通知。UQで承認停止→売り手対応→再開というループが可能。

3.4. まとめ

  • ABで受領可、IPで処理開始、差異があればUQで照会、合意の枠内ならCA、不一致が決定的ならRE、問題なければAP → PD。

  • どこから開始してもよく、省略も可だが、前進方向はこの順序がガイドライン。各ステップの使い分けは BIS 63 のプロセス説明に準拠します。

4. 追加説明

Invoice Response（BIS 63）は「内容を変更しない状態通知」 です。
不備を見つけて RE（否認） や AJ/UQ（照会・対応中） を返しても、元インボイスは変わりません。
必要があれば 売り手が別メッセージ（訂正インボイス or クレジットノート）を発行します。[1]

どれを発行するかは状況と法令/運用で決定します。一般には、計上前なら差替え（再発行）、計上済みならクレジットノートが無難です。
Peppol Billing 実装上も、Invoice / Credit Note のタイプコード設定は必須です。[2]

4.1. 実務フロー（シンプル指針）

4.1.1. 不審を検知

Invoice Response の 4343（Response type） を返す。

  • 軽微/処理継続可: CA（条件付承認）

  • 追加情報必須: AJ（Pending） または（運用により）UQ（Under query）

  • 受入不可: RE（否認）

理由は必要に応じ TDED 4465（例: 9=Invoice error, 4=Short delivery）で明示。

ここまででは インボイスは変更されない。Invoice Response は状態通知のみ。[3]

4.1.2. 売り手側の対応（買い手の応答に基づく）

差替え（再発行）: 元インボイスが未計上・未確定で、単純誤記や価格訂正の差し替えが適切な場合。

クレジットノート発行: 既に計上済/税務確定後、または差額清算が必要な場合。

  • Peppol Billing では Credit Note のタイプコードが必須。元インボイスを参照して発行。[4]

4.1.3. 最終通知

問題が解消したら AP（Accepted）、支払完了で PD（Paid / 部分支払は PPD 併記） を通知。
（Invoice Response の役割は 状態通知。）[5]

5. ステータス（UNCL 4343 サブセット）

各ステータスは cac:DocumentResponse/cac:Response/cbc:ResponseCode に設定します。必要に応じて Clarification（理由／アクション） を併記します。

4343 Response type code

4343 Rersponse type code
コード UNECE 名称 BISの使い方（要旨） 応答が必要 理由が必要 必須 最終 Peppol独自拡張

AB

Message acknowledgement

買い手が可読な請求書を受領し処理投入可能であることを通知。

✓

IP

In process

買い手システムで処理開始。

✓

UQ

Under query

追加情報が必要で処理停止中。

✓

✓

✓

CA

Conditionally accepted

条件付き承認（条件は Clarification で明示）。

✓

RE

Rejected

以後処理しないことを通知（理由の明示推奨/場合により必須）。

✓

✓

✓

✓

AP

Accepted

最終承認。次工程は支払。

✓

PD (+PPD)

Paid / Partially paid

支払（または部分支払）。PPD は部分支払の明示。

✓

✓

※ 補足：

UQ/IP/PD(+PPD) は UNCL 4343 には存在しないため、Peppol側のプロファイル独自拡張として扱います。

4343で「照会中／処理中」に近い表現が必要なときは、AJ（Pending）がUNECE側の近似概念です（必要なら運用で併記ルールを定義してください）。

（上表の各セルの意味：BIS 本文の定義に従う）

6. Clarification（理由・アクション）階層

メッセージ構造：

Invoice Status (1..1)
  └─ Clarification (0..n)
       └─ Data (0..n)  ← 期待値や訂正案など（例：PO番号、訂正単価）

例：UQ（照会中）＋ Clarification Reason で「参照情報不備」を示し、Data で「期待PO=PO123」を通知。

7. 実装の最小ガイド

  • 必須フィールド：メッセージID、参照請求書ID、ResponseCode（上位ステータス）。

  • Clarification：UQ/RE/CA などでは Reason（コードまたはテキスト） を付与し、必要なら Action や Data（訂正案） を併記。

  • SLA 目安：初回応答は 3営業日以内（AB など）。以後、進行順に従い必要なタイミングで通知。

8. 注意事項

  • Invoice Response は 法的効力を持たず、請求書の内容を変更しない。商取引上の責任分担も変更しない。

  • 行レベルの応答や複数ステータスの同報は対象外（別メッセージで段階通知）。

  • 送信側は、売り手が自動処理しやすいよう ステータス前進は保守的に運用する。

9. マッピングの要点（参考）

  • UBL パス：/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cbc:ResponseCode。

  • Clarification（理由・アクション・データ）は Response 配下に表現（詳細は原典の 6.4 参照）。

10. サンプルXML

以下の例は、買い手が正しいデータ・是正手順を指示するための Invoice Response（UBL）です。

<cac:DocumentResponse>
  <cac:Response>
    <cbc:ResponseCode>RE</cbc:ResponseCode> <!-- 1 -->
    <cbc:EffectiveDate>2016-10-25</cbc:EffectiveDate>

      <cac:Status>
        <cbc:StatusReasonCode listID="OPStatusReason">LEG</cbc:StatusReasonCode> <!-- 2 -->
        <cbc:StatusReason>VAT Reference not found</cbc:StatusReason> <!-- 3 -->
        <cac:Condition>
          <cbc:AttributeID>BT-48</cbc:AttributeID> <!-- 4 -->
          <cbc:Description>EU123456789</cbc:Description> <!-- 5 -->
        </cac:Condition>
      </cac:Status>

      <cac:Status>
        <cbc:StatusReasonCode listID="OPStatusAction">CNF</cbc:StatusReasonCode> <!-- 6 -->
        <cbc:StatusReason>Credit fully</cbc:StatusReason> <!-- 6 -->
        </cac:Status>

      <cac:Status>
        <cbc:StatusReasonCode listID="OPStatusAction">NIN</cbc:StatusReasonCode> <!-- 7 -->
        <cbc:StatusReason>Issue new invoice</cbc:StatusReason> <!-- 7 -->
      </cac:Status>
  </cac:Response>
</cac:DocumentResponse>

要点を簡潔に：

  • 1. ステータス：RE（Reject＝否認）

  • 2. 否認理由コード：LEG（法令要件不備）

  • 3. 具体的理由（テキスト）：TAX（VAT）参照が見つからない

  • 4. 参照要素：BT-48（買い手のVAT番号）

  • 5. 期待値：EU123456789

  • 買い手の要求（アクション）

  • CNF：6. 当該インボイスを全額クレジットノートで取消

  • NIN：7. 訂正情報で新しいインボイスを再発行

要するに：法的要件（VAT参照）を満たしていないためインボイスを否認。正しいVAT番号（BT-48）で「全額CN → 新規インボイス発行」を求める、という指示です。

原典： Peppol BIS Invoice Response 3.2（Process rules, Status codes, Response セクション）を参照してください。本文の数値・順序・最小サポート条件は原典の規定に基づきます。

Share this…

投稿日

カテゴリー:

,

投稿者:

Nobuyuki

タグ:

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です