E-Invoicing Service のステータスについて

DocuWare E‑Invoicing Service は、会社などの法人を国別の電子請求書ネットワークおよび税務当局と接続し、法令に準拠した電子請求書の送受信を可能にします。

DocuWare E-Invoicing Service で電子請求書を送受信する際、すべての請求書は定められた一連のステータスを経由します。これらのステータスにより、請求書が作成された時点から最終結果に至るまでの状態を正確に把握できます。

この記事では、電子請求書の各ステータスの意味と、税務報告がステータスを通じてバックグラウンドでどのように動作するかを説明します。次の 2 つの領域を取り扱います。

E-Invoicing - 電子請求書の送受信
E-Reporting / Tax Reporting - 国内電子請求書、B2C 電子請求書、国境を越える取引の税務当局への自動報告

例として用いる国: フランス この記事では、フランスを実例として使用します。フランスの電子請求書改革では、企業は認定プラットフォームを介して電子的に請求書を送受信し、特定の取引をフランス税務当局である DGFiP（Direction Générale des Finances Publiques）に報告することが義務付けられています。DocuWare はこのプロセス全体をバックグラウンドで自動的に処理します。政府が同様の対応を求めている他の国の電子請求書にも、同じステータスロジックが適用されます。

電子請求書ステータスの仕組み

DocuWare は、請求書が電子請求書プロセスを進む中で、ステータスを自動的に更新します。すべての更新を手動でトリガーする必要はありません。電子請求書ネットワークによる請求書処理に伴い、バックグラウンドで実行されます。一部のステータスは、ユーザーまたはプロセスがステータス変更が必要と判断した時点で、DocuWare ワークフローによって設定されます。例: Received → Accepted。

請求書は、送信者と受信者をつなぐ国際的な電子請求書インフラである Peppol ネットワークを介して交換されます。一方の側でのステータス変更は、他方の側にも自動的に反映されます。

顧客が請求書を承認すると、DocuWare はステータスを Accepted に自動更新します。
顧客が請求書を支払い済みとしてマークすると、DocuWare はステータスを Allegedly Paid に更新します。

この自動的なステータス交換により、売掛金および買掛金ワークフローの自動化が可能になります。DocuWare ワークフローを適応させる方法については、記事「DocuWare E-Invoicing Service のワークフローを設定する方法」をご覧ください。

送信済み電子請求書のステータス（送信者側）

以下のステータスは、顧客に送信する請求書に適用されます。請求書は、DocuWare に保存されたデータから作成することも、ERP システムが提供する UBL や Factur-X 形式などの電子請求書ファイルから作成することもできます。注: 電子請求書の作成は、現在フランスの法人でのみ利用可能です。

ステータス	意味	必要なアクション / 説明
Sending	請求書が作成され、送信待ちの状態です。送信前に請求書は自動的に検証されます。次の 2 つの結果が考えられます: Sent または Error。	アクション不要。次のステータスをお待ちください。これは取引が保留中であることを示す自動付与ステータスです。
Sent	請求書が電子請求書ネットワークに正常に配信されました。請求書ドキュメントは受信者側でダウンロードおよびアーカイブできる状態になっています。	アクション不要。請求書は現在処理中です。これは取引が完了したことを示す自動付与ステータスです。
Registered	請求書が現地の税務当局によって正式に承認・記録されました。法的に有効となり、受信者は処理を進めることができます。	アクション不要。税務当局における電子請求書の義務が果たされました。このステータスは、電子報告の義務がある国に関連するものです。これは自動付与ステータスです。
Accepted	電子請求書が受領され、顧客が電子請求書が正しく発行されたことを承認しました。	アクション不要。売掛金の追跡に役立ちます。これは自動付与ステータスです。
Allegedly Paid	顧客が請求書を支払い済みとして申告しました。	注: これは顧客による申告であり、確認済みの銀行振込ではありません。実際に支払いを受領したかどうかを、ご自身の支払い記録と照合してご確認ください。これは自動付与ステータスです。
Refused	顧客が請求書を拒否しました（例: 金額の誤り、注文参照の欠落、サービス内容の異議）。	対応を進め、理由を顧客と協議してください。クレジットノートを発行し、修正した請求書を送信してください。これは現在手動プロセスです。拒否された電子請求書の拒否理由の交換は、今後のリリースで予定されています。
Error	請求書を配信できなかったか、検証または送信中に電子請求書プラットフォームによって拒否されました。	DocuWare でエラーの詳細をご確認ください。請求書を削除し、修正のうえ新しい請求書として再送信する必要があります。

重要: ステータスが Error の請求書は、そのまま再送信することはできません。削除したうえで新しい請求書を作成する必要があります。

フランス: 送信済み請求書のステータス

フランスでは、すべての国内 B2B 請求書が公式政府電子請求書ポータルである PPF（Portail Public de Facturation）を介して送信されます。DocuWare はこの処理を自動的に行います。

Registered ステータスは、特にフランスの状況において重要です。これは請求書が DGFiP によって検証・承認されたことを確認するものです。この時点で初めて、フランスの改革下における電子請求書の義務が果たされたとみなされます。

フランス語ステータス	CDAR コード	対応するステータス	備考
Enregistrée	—	Registered	DGFiP によって承認・記録された状態 — 法的マイルストーン
Approuvée	205	Accepted	買い手が支払いの承認を確認しました
Encaissée	212	Allegedly Paid	買い手が支払いを申告。支払いに関する税務報告（Flux 10）もトリガーされます
Refusée	210	Refused	買い手による商取引上の拒否
Rejetée	213	Error	PPF プラットフォーム自体による技術的拒否 — 買い手による拒否とは異なります

受信済み電子請求書のステータス（受信者側）

サプライヤーから電子請求書ネットワーク経由で電子請求書を受信した場合、DocuWare では社内処理の状況を反映するためにステータスを更新できます。ステータス更新は自動的にサプライヤーへ報告されます。

ステータス	意味
Received	請求書がプラットフォームに到着し、処理可能な状態です。
Accepted	請求書を支払い承認しました。サプライヤーには自動的に通知されます。
Refused	請求書を拒否しました（例: 価格の異議、注文参照の欠落）。サプライヤーには通知され、クレジットノートと修正請求書の発行が必要です。拒否理由は現在ネットワーク経由で交換されません。今後のリリースで予定されています。
Paid	請求書が支払い済みとして申告されました。

受信した請求書のステータス更新は、DocuWare ワークフローを通じて行えます。

フランス: 受信済み請求書のステータス

フランスでは、受信者は請求書のライフサイクルを PPF に報告することが法律で義務付けられています。DocuWare で受信した請求書のステータスを更新すると、対応する CDAR メッセージ（Compte-Rendu d'Application Récepteur）がバックグラウンドで自動的に PPF に送信されます。

下記の表に、すべての CDAR コードを示します。

CDAR コード	フランス語ステータス	DocuWare ステータス	意味
200	Déposée	（自動）	請求書が PPF に登録・保管されました。PPF により自動生成されるため、ユーザー側のアクションは不要です。
202	Reçue	（自動）	請求書がプラットフォームに配信されました。請求書が環境に到着したことを確認するもので、自動生成されます。
205	Approuvée ✅	Accepted	請求書を支払い承認しました。社内の買掛金検証後に支払い準備が整ったことを示します。
210	Refusée ❌	Refused	請求書を拒否しました。サプライヤーはクレジットノートを発行し、修正請求書を再発行する必要があります。
212	Encaissée	Paid	請求書が支払い済みとして申告されました。注: このステータス更新は、現在 DocuWare では利用できません。今後のリリースで実装が予定されています。
213	Rejetée ❌	Error	PPF が請求書を技術的に拒否しました（例: フォーマットエラー、無効なエントリ）。これはプラットフォームレベルの拒否であり、買い手による拒否（コード 210）とは異なります。サプライヤーは修正のうえ再送信する必要があります。

税務報告

税務報告の仕組み

税務報告／電子報告が義務付けられている国では、DocuWare が電子請求書とともに税務レポートを自動的に生成し、関連する税務当局に提出します。

税務レポートの真実の情報源は常に電子請求書です。DocuWare が税務レポートを作成するわけではなく、税務レポートは提供された電子請求書から導出されます。税務レポートは常に電子請求書に含まれるデータから生成されます。電子請求書のデータが誤っていると、税務報告も誤った内容となる可能性があります。

税務レポートの生成に手動の操作は必要ありません。一部のシナリオでは、税務レポートを作成するためにデータから電子請求書を作成する必要があります。DocuWare E-Invoicing Service は、これが法的に義務付けられている国でこれをサポートします。次の請求書シナリオが税務レポートをトリガーします。

受信する請求書:

Peppol ネットワーク経由 → 常に電子フォーマット
Peppol ネットワーク以外 → 電子請求書フォーマット、PDF、またはその他の許容フォーマット

送信する請求書:

Peppol ネットワーク経由 → 請求書が送信された時点で自動的に報告
Peppol ネットワーク以外:
- 一般的な電子請求書フォーマット → 国境を越える請求書として報告
- 簡略化された B2C 請求書として → DocuWare に保存されたデータから報告 （注: このシナリオでは PDF ファイルはサポートされません）

税務レポートのステータス

税務レポートには、請求書の商取引上のステータスとは独立した、独自のステータスセットがあります。

ステータス	意味
New	税務レポートが作成され、送信待ちの状態です。
Sent	税務レポートが税務当局に配信されました。
Acknowledged	税務当局がレポートを受信し、処理を進めています。
Registered	税務当局がレポートを承認・記録しました。税務報告の義務が果たされました。
Refused	税務当局がレポートを拒否しました。DocuWare サポートにご連絡ください。
Error	送信中に技術的なエラーが発生しました。DocuWare サポートにご連絡ください。

重要: 税務レポートの Registered ステータスは、報告義務が果たされたことを確認するものであり、請求書自体の商取引上のステータス（例: 顧客が支払いを行ったかどうか）とは独立しています。

フランス: 税務報告（Flux 1 と Flux 10）

フランスでは 2 種類の税務報告が必要で、いずれも DocuWare が自動的に処理します。

レポート種別	対象	送信
Flux 1	国内 B2B 請求書	即時、請求書ごとに 1 件の税務レポート
Flux 10	B2C 販売および国境を越える B2B	1 日 1 回、CET 02:00 に日次バッチとして送信

Flux 1: 国内 B2B 請求書

PPF Annuaire に登録されたフランスの企業に送信される各 B2B 電子請求書は、それぞれ個別の税務レポートを生成し、請求書作成直後に DGFiP に提出されます。各ステータス変更は、PPF から受信した検証通知によってトリガーされます。

ステータス	意味
New	税務レポートが作成され、即時送信待ちの状態です。
Sent	PPF に配信されました。PPF の検証確認を待機中です。
Acknowledged	PPF がファイルフォーマットを受信・承認しました。DGFiP の業務検証は保留中です。
Registered	DGFiP が請求書を承認・記録しました。税務義務が果たされました。請求書は不変となり、変更できなくなります。
Refused	DGFiP がレポートを拒否しました（例: 無効な会社番号、フォーマット違反）。請求書を削除して再作成する必要があります。
Error	送信中または処理中の技術的障害です。対応する前に DocuWare でエラーの詳細をご確認ください。
Annulled	登録後に請求書が取り消されました。通常は、元の請求書を取り消すクレジットノートが発行された後に発生します。

Flux 10: B2C および国境を越える請求書

個人消費者（B2C）またはフランス国外の企業（国境を越える、EU 域内および EU 域外、送信と受信の両方）に発行された請求書は、日次台帳にまとめられ、1 日 1 回 02:00 に送信されます。同じ日次バッチに含まれるすべての請求書は共通のバッチ ID を共有し、ステータスをまとめて進行します。

ステータス	意味
New	税務レポートが作成され、日次バッチサイクルを待機中です。即時送信は行われません。
Sent	日次台帳が PPF に配信されました。同じ日次バッチに含まれるすべてのレポートが同時にこの状態へ移行します。
Acknowledged	PPF が台帳を受信しました。DGFiP の検証は保留中です。
Registered	DGFiP が台帳を承認しました。バッチ内のすべての取引が正式に申告されました。国境を越える取引および B2C VAT 報告義務が果たされました。
Refused	日次バッチ全体が DGFiP に拒否されました。バッチに含まれるすべての基底取引に影響します。DocuWare サポートにご連絡ください。
Error	台帳の送信で技術的な障害が発生しました。バッチ内のすべてのレポートがブロックされます。DocuWare サポートにご連絡ください。

フランス: Flux 10 台帳の種類

1 日のうちに、取引の種類および方向に応じて複数の台帳が生成されることがあります。各台帳は独立して送信され、それぞれ独自の検証プロセスを経ます。

台帳の種類	方向	内容
取引台帳	送信（販売）	発行した B2B 国境越え請求書および B2C 請求書。フランス国外の取引先またはフランスの B2C 消費者向けに、その日のすべての送信取引をまとめます。
取引台帳	受信（購買）	外国サプライヤーから受信した請求書（EU 域内および EU 域外）。サプライヤーの国がフランス以外の場合にのみ生成されます。
支払台帳	送信（販売）	支払いステータスの更新。請求書が Allegedly Paid に移行した時点でトリガーされます。請求書の送信と支払いライフサイクルを分離します。

フランス: DGFiP プロセスコード

DGFiP に提出される各税務レポートには、取引の税務上の性質を識別するプロセスコードが付与されます。このコードは、請求書の種類と電子請求書設定に基づいて DocuWare が自動的に割り当てます。手動で設定する必要はありません。

コード	種類	説明
S1	サービス	サービスに対する標準的な請求書（例: コンサルティング、IT、トレーニング）。
B1	物品	物品に対する標準的な請求書。
M1	混合	物品とサービスを組み合わせた請求書。
S2 / B2 / M2	サービス／物品／混合	発行時にすでに支払い済みの請求書（例: 現金販売、即時決済）。Flux 10 を介して追加の支払い報告をトリガーします。
S4 / B4 / M4	サービス／物品／混合	前払いまたは手付金を含む請求書。
S7 / B7	サービス／物品	登録済み請求書の修正。注: 登録済みの混合請求書を修正するコードは存在しません（M7 コードはありません） — これは DocuWare の制限ではなく、フランス DGFiP 仕様で明文化されているギャップです。

トラブルシューティング

状況	推奨アクション
送信済み請求書のステータスが Error である	DocuWare でエラーの詳細をご確認ください。請求書を削除し、問題を修正のうえ、新しい請求書を作成してください。
送信済み請求書のステータスが Refused である	顧客が業務上の理由により請求書を拒否しています。クレジットノートを発行し、修正した請求書を送信してください。
税務レポートのステータスが Refused または Error である	DocuWare でエラーの詳細をご確認ください。請求書を削除し、問題を修正のうえ、新しい請求書を作成してください。
受信した請求書を拒否する必要がある	DocuWare ワークフローで請求書のステータスを Refused に更新してください。サプライヤーには自動的に通知されます。

重要な注意事項

ステータスが Error の請求書は再送信できません。削除したうえで新しい請求書を提出する必要があります。
請求書と税務レポートの両方の Registered ステータスは、コンプライアンスにおける 2 つの重要なマイルストーンです。それぞれを個別に追跡してください。
受信した請求書のステータス更新は、必要に応じて自動的にサプライヤーと税務当局に送信されます。

フランス: 重要な注意事項

支払いフィールドは B2B 請求書では必須ですが、B2C 請求書では不要です。すべての B2B 請求書に、振込情報、支払い方法、支払い条件を含めるようにしてください。
企業登録の検証は非同期で行われます: フランスの取引先の PPF Annuaire への登録状況は、作成直後には確認できない場合があります。Flux 1 税務レポートは、取引先が Annuaire に登録されたことが確認された後にのみ生成されます。
Flux 10 税務レポートファイルは個別にダウンロードできません。これらは、所属する日次台帳の一部としてのみ利用できます。
受信した請求書を支払い済みとしてマークする操作（CDAR 212、Encaissée）は、現在 DocuWare では利用できません。これは受信請求書ライフサイクルにおいて現時点で唯一欠けている機能です。今後のリリースで実装が予定されています。
登録済みの混合請求書の修正のための M7 プロセスコードは存在しません。これは DocuWare の制限ではなく、フランス DGFiP 仕様（XP Z12-012）で明文化されているギャップです。

チームへの質問（公開前に削除してください）

送信側の Allegedly Paid は「自動付与ステータス」と表記されていますが、冒頭の説明では、このステータスは顧客が請求書を支払い済みと申告した結果として発生するとされています。これは本当にシステムによって設定されるものですか、それとも「自動付与」のタグはこの行（および同様に付加されている他の送信側の行）にとって正確ではないのでしょうか？
Flux 10 台帳種類の表では、支払台帳の方向が「送信（販売）」とマークされていますが、その内容には Allegedly Paid によってトリガーされる支払いステータスの更新が記載されています。ここで「送信（販売）」は正しいですか、それとも受信請求書の支払い報告では方向を変えるべきですか？
クロスリファレンスのリンク確認: この記事は /help/docs/e-invoicing-service-implementation にリンクしていますが、ワークフロー記事は /help/docs/clone-how-to-set-up-workflows-for-docuware-e-invoicing-service というスラッグでこの記事にリンクしています。「clone」スラッグはドラフトの痕跡のように見えます。両方向の正しい公開スラッグをご確認ください。

Documentation Index