SharePointリストからZUGFeRD電子請求書を作成する:PDF4meを使用してPower AutomateでJSONをEN 16931 XMLとPDF/A-3に変換する

PDF4meでZUGFeRD請求書を作成 これは、請求書データをPDFとA3サイズの電子請求書のハイブリッド形式に変換するPower Automateアクションです。SharePointリストを対象とすると、Composeアクションが各行から構築したJSONを取得し、EN 16931 XMLを書き込み、読みやすい請求書をベースとなるPDFに描画し、結果をファイルに保存して購入者にメールで送信します。
ZUGFeRDを検索すると、次の3つのいずれかにたどり着きます。フォーマットの説明、既にあるファイルが正しいかどうかを判定するバリデーター、または請求書作成ソフトウェアを開発する開発者向けのPHP、Java、C#ライブラリです。これら3つはすべて、請求書が既にどこかに存在することを前提としています。しかし、これらのどれもが答えていないのは、財務チームが実際に抱えている疑問です。請求書データはリスト、スプレッドシート、あるいは販売内容を記録するシステムなど、どこかに保存されていますが、それを準拠した電子請求書として出力する必要があるのです。このフローは、7つのステップで構成され、コードを使わずに、その欠けていた中間部分を実現します。
SharePointリストに、販売者、購入者、明細項目、日付を含む行が登録されます。4秒後には、ドキュメントライブラリにPDF/A-3サイズの請求書が作成されます。これは、購入者のソフトウェアで処理するためのEN 16931 XMLが埋め込まれた、閲覧可能なページです。このXMLを直接記述する必要はありません。請求書を短いJSONオブジェクトとして記述するだけで、PDF4meがスキーマを生成します。行にはステータスとリンクが付与され、購入者はメールでファイルを受け取ります。
なぜ?という問いに対する質疑応答
なぜ請求書データをSharePointリストに保存するのですか? なぜなら、ほとんどの小規模な財務チームでは、データが既にその形式になっているからです。つまり、請求書ごとに1行、担当者が入力する形式です。列は標準規格で要求されるフィールドに1対1で対応付けられているため、リストを開いた人は誰でもその対応関係を確認できます。また、新しい請求書は監視対象フォルダ内の新しいファイルではなく、新しい行として扱われます。
請求書をXMLではなくJSONで記述する理由は? クロスインダストリー請求書の構文は冗長で厳格です。ネストされた名前空間、誰も覚えていない要素名、正確な位置に配置しなければならないコードなど、多くの制約があります。一方、JSONオブジェクトは同じ内容をはるかに少ない行数で表現でき、キーはそれが表すビジネス用語のように読みやすいものになっています。PDF4meはそれをスキーマに変換するため、間違いやすい部分はメンテナンスする必要がありません。
なぜ請求書を基本となるPDFファイルにレンダリングするのですか? ZUGFeRDファイルは2つの部分から構成されており、両者が一致している必要があります。XMLは購入者のソフトウェア用、印刷されたページはそれを開くユーザー用です。Render Invoice on PDFは、XMLを生成したのと同じデータから請求書をベースページに描画するため、レイアウトを別々に管理する場合のように両者が乖離することはありません。
なぜ通常のPDFではなく、PDF/A-3なのか? PDF/A-3は添付ファイルを格納できるアーカイブ用コンテナであり、埋め込まれたXMLはその添付ファイルです。また、このXMLは請求書を何年も経ってからでも読みやすくする役割も果たします。フォントやカラープロファイルがファイル内に保持されるため、多くの企業が10年間保管を義務付けられている文書にとって重要なのです。
得られるもの
入力: 請求書番号、日付、通貨、販売者ブロック、購入者ブロック、および1つの明細項目を含む行。 出力: ZUGFeRD PDF/A-3 請求書 ZUGFeRD Invoices ライブラリでは、行がステータスとリンクとともに更新され、購入者には請求書が添付されたメールが送信されます。

請求書ごとに1行が表示されます。このペインの各列は、フローが構築するJSONのキーになります。

請求書番号ごとに1つのファイルが作成され、フローアカウントによって書き込まれます。

購入者から見た、同じファイルの読み取り可能な半分。
必要なもの
- パワーオートマタ。 Power Automateを開く標準コネクタによる自動化されたクラウドフロー。SharePoint、Office 365 Outlook、PDF4meはプレミアムプランを必要としません。
- PDF4me APIキー。 APIキーを取得してくださいこのフローでは、PDF4me PDF という 1 つの PDF4me 接続を使用します。
- リクエスト用のSharePointリストキャプチャされたリストは ZUGFeRD Requests と呼ばれ、InvoiceNumber、InvoiceDate、DueDate、Currency、Seller ブロック (名前、住所、郵便番号、都市、国、VAT ID)、Buyer ブロック、ItemDescription、Quantity、UnitPrice、VATRate、Email 列、Status 選択列、およびフローが書き込む OutputLink 列が含まれます。
- 基本請求書のPDF捕捉されたフローは
BaseInvoice.pdfZUGFeRD Templatesというライブラリにあります。これは請求書を作成するページなので、ここにレターヘッドを配置してください。 - 完成した請求書を保管するライブラリキャプチャされたフローはZUGFeRD請求書に書き込まれます。
- 出品者情報VAT IDを含む。これらはリスト列に格納されるため、同じワークフローで複数の法人に対して請求書を発行できる。
フローの概要
- アイテムが作成されると (SharePoint) は、次のリストを監視します。
ZUGFeRD Requests。 - 作曲する 行から請求書のJSONを構築します。
- パスを使用してファイルコンテンツを取得します 読む
/ZUGFeRD Templates/BaseInvoice.pdf。 - ZUGFeRD請求書を作成する (PDF4me PDF) は JSON を EN 16931 XML に変換し、ハイブリッド PDF を返します。
- ファイルを作成する (SharePoint) はそれを次のように保存します
ZUGFeRD_<invoice number>.pdf。 - アイテムを更新 (SharePoint) ステータスを
GeneratedそしてOutputLinkを埋めます。 - メール送信(V2) (Office 365 Outlook) は、購入者に請求書を送信します。
フローの概要全体

処理全体は4秒強で、電子請求書自体の生成には約1秒かかります。最も時間がかかるのは、SharePointがファイルを書き込む工程です。
ステップ1:リクエストが届いたときに、電子請求書をどのように発行しますか?
これまでの流れ: まだ何も起きていない。これが引き金だ。
行を追加すると請求書が発行されるので、それがシグナルになります。
- 作成する 自動化されたクラウドフロー そして選ぶ SharePoint > アイテムが作成されると。
- 設定する:
- サイトアドレス:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - リスト名:
ZUGFeRD Requests
- サイトアドレス:
アイテムが作成されたときの構成

新しい行の各列は、次の6つのアクションで使用できるトークンになります。
ステップ2:リスト列から請求書のJSONをどのように構築しますか?
これまでの流れ: SharePointのトリガー。
1つの「作成」アクションで請求書全体を記述できます。ここでは、列名が標準規格で想定されている名前と一致し、1つの画面で読みやすい長さになっています。
- 追加 データ操作 > 作曲する。
- 以下のオブジェクトを貼り付けてください 入力 そして、それぞれの値を対応するトークンに置き換えます。
{
"InvoiceId": "@{triggerBody()?['InvoiceNumber']}",
"TypeCode": "380",
"InvoiceType": "RECHNUNG",
"IssueDate": "@{triggerBody()?['InvoiceDate']}T00:00:00",
"DeliveryDate": "@{triggerBody()?['InvoiceDate']}T00:00:00",
"IsTest": false,
"Seller": {
"Name": "@{triggerBody()?['SellerName']}",
"VatId": "@{triggerBody()?['SellerVATID']}",
"Address": {
"Street": "@{triggerBody()?['SellerStreet']}",
"PostalCode": "@{triggerBody()?['SellerPostalCode']}",
"City": "@{triggerBody()?['SellerCity']}",
"Country": "@{triggerBody()?['SellerCountry']}"
}
},
"Buyer": {
"Name": "@{triggerBody()?['BuyerName']}",
"Address": {
"Street": "@{triggerBody()?['BuyerStreet']}",
"PostalCode": "@{triggerBody()?['BuyerPostalCode']}",
"City": "@{triggerBody()?['BuyerCity']}",
"Country": "@{triggerBody()?['BuyerCountry']}"
}
},
"LineItems": [
{
"ProductName": "@{triggerBody()?['ItemDescription']}",
"Quantity": @{triggerBody()?['Quantity']},
"UnitCode": "C62",
"UnitPrice": @{triggerBody()?['UnitPrice']},
"LineTotal": @{float(...)}
}
],
"Totals": {
"Currency": "@{triggerBody()?['Currency']?['Value']}",
"LineTotal": @{float(...)},
"TaxBasisTotal": @{float(...)},
"TaxPercent": @{triggerBody()?['VATRate']},
"TaxTotal": @{float(...)},
"GrandTotal": @{float(...)},
"ChargeTotal": 0,
"AllowanceTotal": 0
},
"Payment": {
"Currency": "@{triggerBody()?['Currency']?['Value']}",
"PaymentReference": "@{triggerBody()?['InvoiceNumber']}",
"DueDate": "@{triggerBody()?['DueDate']}T00:00:00"
}
}
構成設定

テキスト値は引用符で囲まれたトークンです。金額と数量は数値そのものなので、浮動小数点演算を経由します。
請求書の各部分がどこから来たのか
| JSONキー | 何を運ぶか | ソース |
|---|---|---|
InvoiceId、 TypeCode、 InvoiceType | 請求書番号、文書種別コード 380 商業送り状の場合、ページに印刷されたラベル | 請求書番号、次に固定値 |
IssueDate、 DeliveryDate | 請求書が発行された日時とサービスが提供された日時 | 請求書日付に接尾辞を付けたもの T00:00:00 |
Seller | 氏名、VAT番号、および住所(フルアドレス) | 販売者名、販売者VATID、販売者住所(番地を含む)、販売者郵便番号、販売者都市、販売者国 |
Buyer | 顧客の氏名と住所 | 購入者名、購入者住所、購入者郵便番号、購入者都市、購入者国 |
LineItems | 説明、数量(単位コード付き) C62単価と行合計 | 商品名、数量、単価 |
Totals | 通貨、正味合計、課税基準、VAT率と金額、総計 | 通貨、VAT率、および計算された金額 |
Payment | 通貨、購入者が支払い時に提示する参照番号、および支払期日 | 通貨、請求書番号、支払期日 |
ヒント。 マネーキーは算術が必要な唯一の部分であり、引用符付き文字列ではなく、生の数値にする必要があります。 フロート 表現は~のためにあります。 LineTotal 数量×単価、 TaxBasisTotal は行の合計の合計です。 TaxTotal 税額基準額に税率を掛け、それを100で割った値です。 GrandTotal 2つを足し合わせたもの。キャプチャされた行は1005、1005、190.95、1195.95です。引用 "1005" 平文の場合拒否されます 1005 受け入れられます。
ステップ3:元のPDFはどこから入手したのか?
これまでの流れ: トリガーとComposeを組み合わせる。
ZUGFeRDファイルには読み取り可能なページがあり、ここから始まります。
- 追加 SharePoint > パスを使用してファイルコンテンツを取得します。
- 設定する:
- サイトアドレス:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - ファイルパス:
/ZUGFeRD Templates/BaseInvoice.pdf - コンテンツタイプを推測する (高度な):
Yes
- サイトアドレス:
パス構成を使用してファイルコンテンツを取得する

レターヘッドはこのファイルに保管してください。印刷のたびに新しいレターヘッドが読み込まれるため、変更すると次回の請求書の内容も変わります。
ステップ4:JSONをZUGFeRD PDF/A-3に変換するにはどうすればよいですか?
これまでの流れ: トリガー、パスを使用したファイルコンテンツの作成と取得。
これは電子請求書を作成する処理です。JSONを読み込み、EN 16931 XMLを書き込み、両方のデータを含む1つのファイルを返します。
- 追加 ZUGFeRD請求書を作成する から PDF4me PDF 繋がり。
- 設定する:
- ZUGFeRDのバージョンと入力フォーマット:
2.0-JSON - 出力モード:
XmlWithPdf - 請求書JSONデータ:表現
base64(outputs('Compose')) - 適合レベル:
EN16931 - 請求書をPDF形式でレンダリングする:
Yes - ファイルの内容: a
base64()内容に対する表現 パスを使用してファイルコンテンツを取得します - ファイル名:
BaseInvoice.pdf
- ZUGFeRDのバージョンと入力フォーマット:
ZUGFeRD請求書構成を作成する

入力形式によって、表示されるデータフィールドが決まります。2.0-JSONを選択すると、請求書XMLデータではなく、請求書JSONデータが要求されます。
各設定が決定する内容
| 分野 | ここで価値 | それが制御するもの |
|---|---|---|
| ZUGFeRDのバージョンと入力フォーマット | 2.0-JSON | 出力がどのZUGFeRD世代に従うか、そしてデータがJSON形式で届くかを指定します。この選択によって「請求書JSONデータ」フィールドが表示されます。 |
| 出力モード | XmlWithPdf | XML単体ではなく、XMLが埋め込まれたPDFというハイブリッドファイルを1つ返します。 |
| 請求書JSONデータ | base64(outputs('Compose')) | 請求書オブジェクトは、入力時にbase64エンコードされます。 |
| 適合レベル | EN16931 | 請求書が満たすべきプロファイル、したがってJSONで提供する必要のあるキー |
| 請求書をPDF形式でレンダリングする | Yes | ページをそのままにしておくのではなく、読みやすい請求書をベースとなるPDFに描画してください。 |
| ファイルの内容、ファイル名 | ベースとなるPDF | 請求書が作成されたページと、アクションが報告する名前 |
ヒント。 アクションは 請求書XMLデータ、 請求書JSONデータ または 請求書のCSVデータ ドロップダウンリストの半分はフォーマットによって異なります。選択した内容に一致するもののみを入力してください。この操作で検証エラーが発生する最も一般的な原因は、同じ実行で2つのデータフィールドに入力することです。
ステップ5:請求書はどこに保管されますか?
これまでの流れ: Create ZUGFeRD Invoice を通じてすべてを実行します。
請求書番号がファイル名の由来となり、ライブラリの検索性を維持する。
- 追加 SharePoint > ファイルを作成する。
- 設定する:
- サイトアドレス:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - フォルダパス:
/ZUGFeRD Invoices - ファイル名:
ZUGFeRD_続いて 請求書番号 トークンと.pdf - ファイルの内容: その 体 トークンから ZUGFeRD請求書を作成する
- サイトアドレス:
ファイル構成を作成する

RE-2026-0007の場合、ZUGFeRD_RE-2026-0007.pdfというファイルが作成されます。
ステップ6:リクエストに結果をどのように記録しますか?
これまでの流れ: ファイル作成を通してすべてを行います。
請求書を要求した行には、請求書がどうなったかも記載すべきです。
- 追加 SharePoint > アイテムを更新。
- 設定する:
- サイトアドレス:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - リスト名:
ZUGFeRD Requests - ID: その ID トリガーからのトークン
- タイトル: その タイトル トリガーからのトークン
- ステータス値 (高度な):
Generated - 出力リンク (上級者向け):ライブラリのURLに続いて
ZUGFeRD_、 請求書番号 トークンと.pdf
- サイトアドレス:
アイテム設定を更新する

リンクはライブラリの URL と、使用されているファイル名と同じ名前パターンから組み立てられ、ライブラリ名内のスペースはすでに %20 としてエンコードされています。
ステップ7:購入者に請求書を送るにはどうすればよいですか?
これまでの流れ: すべてはアイテムの更新を通じて行われます。
図書館に保管されている電子請求書は発行されていないため、最後のアクションでそれを配信します。
- 追加 Office 365 Outlook > メール送信(V2)。
- 設定する:
- に: その メール トリガーからのトークン
- 主題:
Your ZUGFeRD e-invoice続いて 請求書番号 トークン - 体購入者と請求書の名前を記載し、ファイルがEN 16931 XMLが埋め込まれたPDF/A-3であることを示す行
- 開ける 詳細パラメータ そして添付ファイルを追加します。
- 添付ファイル名 - 1:
ZUGFeRD_プラス 請求書番号 トークンプラス.pdf - 添付ファイルの内容 - 1: その ファイルの内容 トークンから ZUGFeRD請求書を作成する
- 重要性:
Normal
- 添付ファイル名 - 1:
メール送信(V2)設定

添付ファイルは、それを生成したアクションからバイトデータを取得するため、SharePointから読み戻されることはありません。
フローを実行して検証する
- 保存 流れ。
- 行を追加 ZUGFeRDからのリクエスト 購入者、1つの明細項目、日付、そして確認可能な住所が記載されています。
- 実行履歴を開いてください。7つのアクションすべてが緑色で表示され、実行全体は数秒で完了するはずです。
- 開く ツークフェルト請求書 ライブラリを開いて、請求書番号の下にファイルが存在するか確認してください。
- 該当の行に戻ってください。ステータスは「生成済み」と表示され、出力リンクをクリックすると請求書が開くようになっているはずです。
- メールに添付されているファイルを開き、両方の部分を確認してください。ページには正しい金額が表示され、ファイルにはXMLデータが含まれているはずです。
キャプチャされた処理は合計で約4秒かかり、そのうちの1秒で電子請求書自体が生成されました。結果として、 ZUGFeRD_RE-2026-0007.pdf、約 331 KB で、ドイツの請求書として表示されます。販売者はベルリンの Muster GmbH (VAT ID DE123456789)、顧客はミュンヘンの Test Kunde AG、文書タイプ 380、コンサルティング 1 行 (VAT 19%)、正味 1,005.00 EUR、VAT 190.95 EUR、合計 1,195.95 EUR。
実際に何を作ったのですか? 自社の記録から始まる電子請求書発行パイプライン。データは財務部門が保管している場所にそのまま残り、標準規格はXMLで満たされるため、自分で記述する必要はありません。購入者は、自社のソフトウェアで自動的に読み取れるファイルを受け取り、担当者は画面上で内容を確認できます。また、リクエスト行には請求書が送信されたことが記録されます。
再構築せずに追加できる一般的なバリエーション
これは、ZUGFeRDの請求書を作成する他の方法と比べてどうなのか
各行は代替案を表しています。最後の行はこのフローを示しています。
| 比較 | 誰が運営しているのか | データの出所 | あなたが維持するもの |
|---|---|---|---|
| ZUGFeRDエクスポート機能を備えた請求書作成ソフトウェアとこのフローとの比較 | その製品の中にいる人なら誰でも | 製品自身の記録 | サブスクリプション、および製品がサポートするものすべて |
| 電子請求書プラットフォームとこのフローの比較 | ポータルを通じて金融 | アップロードまたは統合 | 文書ごとの契約とそれとの関連性 |
| 開発者ライブラリとこのフローの比較 | アプリケーション内の開発者 | コードを通してデータベースを | コード、スキーマの更新、リリース |
| この流れ | リスト行を追加できる人 | チームが管理するSharePointリスト | JSONオブジェクト1つとベースとなるPDFファイル |
よくある質問
ZUGFeRDの請求書とは何ですか?
ZUGFeRDの請求書は、2つの機能を持つ1つのファイルです。これは、人が開いて読むことができる通常のPDFファイルであり、その中に構造化データとして同じ請求書情報を含むXML添付ファイルが含まれています。購入者の会計システムはXMLを読み取り、誰も入力することなく請求書を登録しますが、買掛金担当者は引き続きページを確認できます。
フォーマットは フェルドドイツの電子請求書フォーラムであるFactur-Xは、同じコンセプトを別の名前で提供しているフランス版である。
ZUGFeRDフォーマットとは何ですか?
技術的には、これはクロスインダストリーインボイス構文の埋め込みXMLファイルと、データの完全性を示すプロファイルを含むPDF/A-3コンテナです。ここで使用されているプロファイルはEN16931で、これは電子請求書の欧州セマンティック標準にマッピングされます。 16931年 請求書の核心として定義される。
自動化における実際的な結果として、出力はページではなくXMLに基づいて評価されることになる。プロファイルが要求するデータを提供すればファイルは合格となり、ページをより見栄え良くしても何も変わらない。
ZUGFeRDの請求書を作成する方法は?
必要なものは3つです。構造化された請求書データ、人間が入力するページ、そしてXMLをPDF/A-3サイズの添付ファイルとしてPDFに書き込むツールです。
このフローでは、データはJSONに変換されたSharePoint行であり、ページは BaseInvoice.pdf、 そして ZUGFeRD請求書を作成する 出力モードで3番目の部分を実行します XmlWithPdfデータが既にクロスインダストリー請求書XMLまたはCSV行として存在する場合は、入力形式を切り替えて、そのデータを入力してください。それ以外の処理フローは変更されません。
ZUGFeRDとXRechnungの違いは何ですか?
どちらも同じ欧州規格を満たしており、違いはパッケージング方法にあります。ZUGFeRDはハイブリッド形式で、XMLが内部に含まれた読みやすいPDFファイルであり、顧客が手作業で開封する可能性のある請求書に適しています。一方、XRechnungはXMLのみで構成されており、ドイツの公共部門の購買担当者が求める形式です。
企業宛てに送付する場合は、ハイブリッドファイルの方が通常は安全です。なぜなら、ファイルを開く人が誰でも読み取れるからです。公的機関に請求書を送付する場合は、送付前にその機関がどのファイル形式を要求しているかを確認してください。
トラブルシューティング
実行履歴からComposeの出力を開き、まずJSONとして読み込んでください。空の列があるとキーが空になり、引用符付きの金額が数値が期待される場所にテキストとして表示されます。どちらの場合も、見た目は問題ないオブジェクトが生成されますが、変換は失敗します。
適合レベルは、プロファイルに必要なフィールドを決定します。JSONファイルにプロファイルが期待するキーが欠落している状態でEN16931を主張すると、ファイルが正常に開いたとしても検証に失敗します。欠落しているキーを指定するか、より低いプロファイルに切り替えてください。
PDFへの請求書レンダリングが「いいえ」に設定されているため、XMLは何も描画されずに埋め込まれました。ファイルは有効な電子請求書ですが、人間が読み取る部分は元のPDFの内容のままです。
メールステップの添付ファイルの内容と、ファイルの作成のファイルの内容を確認してください。どちらも以下から取得する必要があります。 ZUGFeRD請求書を作成する代わりにベースとなるPDFファイルを添付すると、見た目は正しいページが送信されますが、相手のソフトウェアが読み取るための情報は何も含まれていません。
次のステップ
最終的に顧客が必要とするフォーマットが何であれ、すべての電子請求書義務化が本当に求めているのは、同じ7つのステップ(行が到着し、請求書がデータとして記述され、ファイルが作成、ファイリング、記録され、送信される)です。