50件のポルトガル請求書を1つのスプレッドシートに:バッチFatura処理

APQCのベンチマークデータによると、手動での請求書処理は1件あたり$8〜$15かかります。ポルトガルの中小企業にとって一般的な月間50件の仕入先請求書では、管理・承認・SAF-T照合が始まる前に、財務チームに$400〜$750の人件費がかかります。この数字だけでも、バッチ処理が重要である理由がわかります。しかし、この数字は本当の問題を隠しています。バッチ処理は処理量だけでなく、ワークフローそのものを変えるのです。そして、ポルトガルの請求書(fatura)には、一般的なバッチツールでは対応できない規制上のレイヤーが追加されています。

手入力はもう終わりに — AIに読ませましょう
画像またはPDFをアップロード — 構造化されたスプレッドシートデータが10秒で完成
今すぐ試す →
ブログ表紙画像:タイトル「50件のポルトガル請求書を1つのスプレッドシートに:バッチFatura処理」、複数仕入先の一貫性、3つのVAT税率、SAF-T対応を示す3つのアイコン

重要なポイント

  1. 手動での請求書入力は1件あたり$8〜$15かかります。月50件のポルトガルfaturaの場合、IVA税率の分割照合、ATCUDコードの確認、SAF-T提出の準備をする前に$400〜$750かかります。
  2. ポルトガルのfaturaには3つのIVA税率、ATCUD検証コードが含まれ、毎月5日までに提出するSAF-T申告に紐づいています。単一の統一レイアウトで機能する位置ベースの抽出は、仕入先2社目がNIFをヘッダーではなくフッターに記載した瞬間に機能しなくなります。
  3. セマンティックな列命名 — データがページ上のどこにあるかではなく、データの意味に基づいて抽出列を定義すること — により、50件のfaturaのバッチ処理が2時間のデータ入力作業から10分のレビューに変わり、各行がATCUDを介して元のドキュメントに遡って追跡できます。

バッチが根本的に異なる理由

単一ドキュメント処理が1枚あたり3分、50枚のバッチが2.5時間かかる見込みを示す比較表。単一にはチェックマーク、バッチには警告マークが付いている

1枚の請求書の処理は数回のキー操作で完了します。PDFを開き、仕入先名、請求書番号、合計金額を入力して次へ進むだけです。これを50回繰り返すと、計算上は約2時間半で完了するはずです。1枚あたり3分というのは、業界調査でベンチマークされた平均的な手入力時間です。しかし、実際に50枚の請求書を一度に処理したことがある人なら、実際の時間はもっとかかると分かっています。

この計算が崩れるのは、バッチ処理には単一ドキュメント処理にはない3つの問題が発生するためです。まず、一貫性です。異なる仕入先が発行した請求書から同じデータ項目を抽出する必要がありますが、各請求書には独自のレイアウト、独自のフィールドラベル、そして「請求書番号」や「課税対象額」の実際の解釈があります。次に、マージです。50件の個別抽出結果を1つのテーブルにまとめ、列ヘッダーがすべての行で揃っている必要があります。1つでも不一致があると、ピボットテーブルやSAF-Tインポートが失敗し、どこが問題かも分かりません。3つ目は、例外です。50枚の請求書があれば、ほぼ確実に、クレジットノート(nota de crédito)が1枚、分割支払い参照が含まれるものが1枚、印刷された合計が明細行の合計と一致しないものが1枚はあります。マージ済みスプレッドシートでどの行が間違っているかを見つけるのは、それを修正するのとは別のスキルであり、はるかに時間がかかります。

結論: 単一ドキュメント処理は、ドキュメントごとの精度を最適化します。バッチ処理は、ドキュメント間の一貫性を最適化する必要があります。そして、一貫性を誤るコストは、バッチ内の請求書が増えるごとに増幅されます。

なぜポルトガルのFaturaにバッチ処理が必須なのか

6つのIVA列にわたる50枚の複数税率faturaの300データポイントを表す大きな数字300と、照合エラーに関する警告アイコン

一般的なバッチ処理ツールは1つの税率しか扱えません。ポルトガルの請求書(fatura)には最大3つの税率が含まれます。標準の23%、中間の13%、軽減の6%で、それぞれが別々の明細行に表示され、それぞれが会計対応スプレッドシートに独自の列を必要とします。マデイラ島(22%/12%/5%)やアゾレス諸島(18%/9%/4%)の仕入先からの請求書を処理する場合、同じ仕入先名が同じバッチ内で異なる地域のVAT制度に基づく請求書を発行することがあり、問題はさらに複雑になります。

この複数税率構造は、ポルトガルのAPチームにとってバッチ処理が任意ではない最初の理由です。単一抽出ツールでも1枚の請求書からIVA合計を取得できます。しかし、declaração periódica do IVA(報告期間の翌々月20日までに提出される定期VAT申告書)では、税率別に課税標準額と税額を明記する必要があります。合計1列では要件を満たせません。複数税率のfaturaではIVAだけでも最低6列が必要です。つまり3つの税率それぞれについてbase tributávelとvalor do IVAが必要です。これを50枚の請求書で手動で抽出する場合、6列にわたって300のデータポイントがあり、それぞれが照合エラーの原因となり得ます。

2つ目の理由は、毎月のSAF-T請求期限です。2024年1月以降、Autoridade Tributária e Aduaneira(AT)は、Billing SAF-T(SAF-T Faturação)の提出について翌月5日を義務付けています。これは、AT認定ソフトウェアが生成するXMLファイルで、すべての請求書明細行、すべての税内訳、すべてのATCUDコードが含まれます。この期限は毎月発生します。毎月50枚の仕入先faturaを処理するポルトガルの中小企業は、実質的に毎月5日間の照合ウィンドウがあります。請求書の受領、データ抽出、e-Faturaポータルでの検証、NIFの照合、SAF-T XMLの生成までを行う必要があります。抽出に1日以上かかる工程があると、このウィンドウが圧迫されます。

3つ目の理由はATCUD(Código Único do Documento)です。CIVA第35-A条に基づき、2023年1月から義務化されています。ポルトガルのすべての請求書には、8桁の英数字による一意の検証コードが付与されます。50枚の請求書を1つのスプレッドシートに統合する場合、ATCUDは各行を元の文書に遡るための唯一の信頼できるキーになります。抽出時にこれを失うと、AT監査中にどの請求書がどの行を生成したかを証明する能力を失います。

個別のfaturaフィールド抽出の詳細な手順(NIFの位置、IVA税率の識別、QRコードの処理)については、ポルトガルのfatura抽出のステップバイステップガイドをご覧ください。この記事の残りでは、その基礎を前提として、バッチ処理時に何が変わるかに焦点を当てます。

複数サプライヤーのバッチ抽出における列アーキテクチャ

バッチ処理用に選択するスプレッドシート構造は、その後のすべてを左右します。SAF-Tインポートが成功するかどうか、e-Faturaの照合に数分かかるか数時間かかるか、同じ構造を毎月再利用できるかどうか。正しく設計するということは、バッチ内のすべてのサプライヤーに対応する列を設計することを意味します。

最低限、バッチ対応のポルトガル語faturaスプレッドシートには、以下の列グループが必要です。

グループ列理由
識別情報サプライヤーNIF、サプライヤー名、請求書番号、請求日、ATCUD行ごとの一意キー。e-FaturaのクロスチェックとSAF-T識別子マッピングに必須
IVA — 標準税率(23%)課税ベース23%、IVA 23%IVA定期申告書の3行目。ポルトガル本土のSAF-TフィールドI7/I8と一致する必要あり
IVA — 中間税率(13%)課税ベース13%、IVA 13%レストランサービス、ワイン、一部の食品に適用。別の申告行が必要
IVA — 軽減税率(6%)課税ベース6%、IVA 6%必需財、医薬品、書籍に適用。数量は少ないが追跡が必須
合計税抜合計、IVA合計、税込合計照合チェックポイント — 各税率列の合計が印刷された合計と一致する必要あり
バッチメタデータバッチ名、処理日月をまたぐ照合用。各行がどの処理実行で生成されたかを追跡
ヘッダーレベルと明細レベルの列アーキテクチャの3列比較。推奨されるハイブリッド方式にチェックマーク付き

重要な設計判断は、faturaごとに1行(ヘッダーレベル)か、明細ごとに1行(詳細レベル)かです。SAF-T課税申告では、ATは明細レベルの詳細を要求しますが、月次の買掛金照合とe-Faturaのクロスチェックには、通常ヘッダーレベルで十分です。私たちが協力しているポルトガルのcontabilistaの多くは、まずヘッダーレベルで抽出し、e-Faturaと照合してから、SAF-T XML生成のために明細レベルで2回目のパスを実行します。両方のパスを同じツールで実行することで、照合ステップを丸ごと省けます。

異なるサプライヤー間でこれを機能させるアプローチは、意味論的な列名です。抽出ツールに「右上隅の数字を見つける」と指示する代わりに、データの意味で列を定義します:「サプライヤーNIF」「IVA込み請求書合計」「ATCUD」。AIが各請求書を読み取り、フィールドの意味を理解し、ページ上の位置やサプライヤーが使用したラベル(「Total」「Valor Total」「Montante」「Total a Pagar」など)に関係なく、値を正しい列に配置します。

JPG/PNG/PDF AI抽出

ファイルは安全に処理され、保存されることはありません。

手入力をやめて、AIにデータを読ませましょう
画像またはPDFをアップロード — 10秒で構造化されたスプレッドシートデータに
今すぐ試す →

月をまたぐ照合に耐える命名規則

バッチ処理はファイルを生成します — 複数のアップロード、複数の抽出実行、複数のエクスポート。3か月後の 四半期IVA照合の際に、スプレッドシートの特定の行がどの仕入先PDFから来たのかを遡って特定する必要があるとします。 命名規則が「Invoice1.pdf、Invoice2.pdf」だった場合、問題が発生します。

バッチ名は最初の整理レバーです。一貫した規則 — 例えば AP-2026-06-Fornecedores や 2506-Faturas-Monthly — により、すべての抽出結果を検索可能なラベルでグループ化できます。元のファイル名を列として保持することと組み合わせることで、 各行は完全な来歴チェーン(バッチ → 元ファイル → 抽出行)を持ちます。ATが特定のIVA控除のソース文書を求めた場合、 50個のPDFを1つずつ開き直すのではなく、数秒で見つけることができます。

抽出列自体については、ルールは次のとおりです:列名は「表示されている場所」ではなく「表す内容」に基づいて付ける。 「Supplier NIF」は、バッチ内のすべてのfaturaで機能します。なぜなら、すべてのfaturaにはNIF(税識別番号、Número de Identificação Fiscal)が あるからです。「右上のVAT番号」は、仕入先がNIFをフッターに配置した瞬間に機能しなくなります(多くの仕入先がそうしています)。 意味に基づく命名こそが、50の異なるレイアウトの50枚の請求書にわたって同じ列定義を有効に保つ方法です。

ポルトガル固有の命名に関する考慮事項:

  • 「VAT番号」ではなく「NIF」を使用してください。 ポルトガルの会計ソフトはフィールド識別子としてNIFを想定しており、e-Faturaポータルでも仕入先・得意先の検索にNIFが参照されます。抽出設定の初回使用時には「仕入先NIF(NIF Fornecedor)」と表記してください。
  • IVA列は仕入先別ではなく税率別に分けてください。 「IVA 23% 課税対象額」「IVA 23% 税額」という列名は、ポルトの文房具仕入先からの請求書でも、リスボンのITコンサルからの請求書でも機能します。特定の仕入先名を付けた列は、仕入先構成が変わるとすぐに使えなくなります。
  • ATCUDは必ず独立した列として抽出してください。 現在のワークフローで使用していなくても、ATCUDは税務当局(AT)の監査システムが照会する唯一の文書識別子です。初日からスプレッドシートに含めておけば、2年後に監査依頼が届いたときにバッチを再抽出する必要がなくなります。

例外処理:バッチ内の1件の請求書が間違っている場合

単一文書処理では、読み取りミスはすぐに画面で確認でき修正できます。しかし50件のバッチでは、同じミスが50行×20列のスプレッドシートに埋もれてしまいます。50件中34番目の請求書のIVA金額が誤っていても、定期申告が合わなくなるまで気づかず、その時点で1,000のデータポイントから1つのエラーを探す羽目になります。

第一の防御策は合計チェックポイントです。バッチ出力を処理する前に、IVA合計列の合計を計算し、元の文書の印刷合計と比較してください。スプレッドシートの合計が€1,247.80なのに仕入先明細が€1,253.45なら、どこかで誤読が発生しています。ATCUD列があれば、どの行がずれているかを特定できます。日付範囲でフィルタリングし、仕入先ごとに並べ替えて、e-Faturaポータル(そのNIFと月に税務当局に報告されたすべての請求書を一覧表示)と1行ずつ照合します。

第二の防御策は、同一バッチ内でのクレジットノート(notas de crédito)と訂正文書の処理です。クレジットノートは請求書のように見えますが、金額はマイナスです。抽出列が標準の請求書と同一に扱うと、マイナス値はバッチ合計を正しく相殺しますが、列レベルのIVA内訳がクレジットを誤った税率に割り当てる可能性があります。最も安全な方法は、「文書タイプ」列(値:Fatura、Nota de Crédito、Fatura-Recibo)でクレジットノートにフラグを付け、クレジットノートのIVA税率が訂正対象の元の請求書の税率と一致することを確認することです。

実践的なルール: バッチ抽出後、最初の5行と最後の5行を元のPDFと照合してください。エラーは端に集中します。レイアウトが特殊な請求書、デジタル原本ではなくスキャンされたもの、または主要フィールドが2ページ目にある複数ページの文書などです。最初の5行でエラーパターンを発見できれば、残り45行に同じ問題が広がるのを防げます。

スプレッドシートからSAF-Tへ:ループを閉じる

バッチ抽出の出力はExcelファイルです。AT認定ソフトウェアが必要とするのは、 Portaria No. 321-A/2007 およびその後の更新で定義されたSAF-T XMLスキーマにマッピングできる構造化データセットです。 その間のステップ(スプレッドシートを会計ソフトにインポートする)で、先ほどの列構成が活きてきます。

ポルトガルの会計プラットフォームごとに、一括インポートの方法は異なります。

  • Cegid Primavera(旧Primavera BSS)は、仕入請求書のCSVインポートとフィールドマッピングをサポートしています。バッチエクスポートの列がPrimaveraのフィールド名(「NIF Fornecedor」「Nº Documento」「Data」「Base Tributável」「Valor IVA」)と一致していれば、インポートは直接マッピングとなり、手動での再入力は最小限で済みます。
  • PHC Software(現在はCegidの一部)は、Excelテンプレートを読み取れるインポートウィザードを提供しています。列とフィールドのマッピングを一度定義すれば、以降のバッチで再利用でき、毎月のインポートが2クリック操作になります。
  • TOConlineは、OCCが提供し、数千人の公認会計士(contabilistas certificados)が利用するプラットフォームで、OCR支援による文書入力機能と仕入請求書の一括CSVインポートをサポートしています。プラットフォームの「Robot」機能は文書を自動分類できますが、その分類精度は、抽出データが Decreto-Lei n.º 158/2009 で定義されたSNC(会計基準化システム)の勘定科目コードにどれだけ正確にマッピングされるかに依存します。
  • Sage 50 PortugalとMoloniはどちらも、仕入書類の構造化CSVインポートに対応しています。Moloniは特に零細・中小企業に人気で、39,000社以上が認定インボイス発行に利用しています。

インポート後、認定ソフトウェアは正しい構造、電子署名、ATCUDリンクを持つSAF-T XMLを生成します。最終確認ステップはe-Faturaポータルです:月でフィルタリングし、NIFで並べ替え、スプレッドシート内のすべてのfaturaがATの記録に存在することを確認します。不足している文書がある場合は、サプライヤーがそれを送信していないことを意味します。これは別の問題ですが、監査中に発見するのではなく、数分で特定できるようになります。

公認会計士協会(OCC)の会長(bastonária)であるPaula Franco氏は、ポルトガルの公認会計士(contabilista)の時間の20%から30%は、クライアントからの書類の追跡に費やされていると公言しています。分析や助言ではなく、単にシステムに取り込むためです。バッチ抽出は「追跡」部分を解決しません。しかし、再入力部分を完全に排除し、2時間かかっていたデータ入力を10分のレビューとインポートに変えます。OCCが積極的に近代化を推進している職業(「Contabilista 3.0」イニシアチブは特に反復作業の自動化を目標としています)にとって、この変化は些細なものではありません。毎月5日をデータ入力に費やす会計士と、検証と助言に費やす会計士との違いです。

よくある質問

バッチ処理は、デジタルPDFだけでなく、スキャンした紙のファトゥーラでも機能しますか?

はい、スキャンが読み取れる状態であれば可能です。最新のAI抽出は、人間が読むのと同じように文書画像を読み取る視覚言語モデルを使用するため、テキストレイヤーは必要ありません。スマートフォンで撮影した紙のファトゥーラの鮮明な写真でも機能します。極端に傾いていたり、解像度が低かったり、一部が切り取られたスキャンでは精度が低下します。混合バッチ(一部はデジタルPDF、一部はスキャン)の場合、文書ごとの抽出品質は入力品質に依存します。そのため、スポットチェックのルール(最初の5行と最後の5行)が、スキャンが多いバッチではより重要になります。

ファトゥーラにIVA免除(isenção de IVA)やリバースチャージがある場合はどうなりますか?

抽出テンプレートに「IVA Regime」列を追加し、「Normal」「Isento (Art. 53)」「Autoliquidação」「Reverse Charge」などの値を設定してください。免税取引の場合、IVA税率列はゼロまたは空白になりますが、正味金額は正しい基準列に表示される必要があります。SAF-Tスキーマは免税コードをサポートしています。有効なXMLを生成するには、認定ソフトウェアにレジーム識別子が必要です。ほとんどのポルトガルの会計プラットフォームは、レジームフィールドが入力されると自動的に処理します。

バッチ抽出で、マデイラ島とアゾレス諸島の供給業者のファトゥーラを同じバッチで処理できますか?

はい、ただし各領土に別々のIVA税率列を設けるか、各行にタグを付けるための「Territory」列が必要です。ポルトガル本土は23/13/6%、マデイラ島は22/12/5%、アゾレス諸島は18/9/4%です。単一の「IVA 23%」列では、本土の23%取引とマデイラ島の22%取引を区別できません。実用的なアプローチとしては、島嶼部の供給業者からの請求書を受け取ることが稀な場合は、必要なときにのみ領土固有の列を追加します。頻繁にある場合は、「Região IVA」列を含め、ソフトウェアインポート時にそれに応じて税率をマッピングします。

1回のバッチで処理できる請求書の数は?

技術的な制限はツールに依存し、概念自体にはありません。ほとんどのAIベースの抽出ツールは、1バッチあたり20~100ファイルを問題なく処理できます。100を超える場合は、管理しやすくするためにサブバッチに分割することをお勧めします。抽出が失敗するからではなく、200行の例外を確認するのが煩雑になるからです。50件のバッチが実用的なバランスです。十分な時間を節約でき、かつ徹底的に確認できる規模です。

会計ソフトに入力する前に、公認会計士(Contabilista Certificado)に抽出データの承認を得る必要がありますか?

法律上、公認会計士(CC)は、法律第68/2023号で規制されるOCCの職業基準に基づき、会計記録の正確性に責任を負います。実際のワークフローは様々で、バッチ出力をインポート前に確認するCCもいれば、クライアントに抽出とインポートを任せ、提出前の最終SAF-Tを確認するCCもいます。いずれにせよ、バッチ出力は確認可能であるべきです。そのため、CCの検証工程では、スプレッドシートにATCUDと元のファイル名を保持することが重要です。

毎月のSAF-T提出期限は変わりません。しかし、最後の仕入先請求書を受け取ってから月次XMLファイルを提出するまでの時間は変わります。バッチ処理は公認会計士の判断を不要にするものではなく、その判断がデータ入力に埋もれてしまう部分を排除するものです。上記の列構成を、実際の仕入先請求書でテストしてみてください。現在、毎月4日と5日を丸々費やしている作業が、半日の作業になるかどうかを確かめてみてください。

自分の請求書で試す
📮 contact email: [email protected]