メキシコCFDI請求書処理
14社の仕入先から50以上のXML、1つのクリーンなAPスプレッドシートへ

50件のCFDI XMLが月末に届くとき — 「各XMLは有効」と「バッチ全体がクリーン」のギャップ

メキシコのCFDIシステムは三者間のクリアランスモデルで動作します。サプライヤーがAnexo 20仕様に基づいてXMLを生成し、認定PACが検証してUUID（36文字のFolio Fiscal）を付与し、SATがリアルタイムで受信します。CFDIが受領者として貴社の買掛金部門に届く時点で、XMLはすでに認証済みです。これは他国の紙の請求書やPDFのみのベンダー請求書とは異なり、誤解を招きやすい第一印象を与えます。

各XMLが個別に有効であるため、買掛金チームはバッチ全体もクリーンだと想定します。しかしそうはなりません。複数のサプライヤーから50件以上のCFDI XMLを収集し、単一の買掛金スプレッドシートに統合しようとすると、5つの構造的問題が発生します。

PUEとPPDの混在。 CFDI請求書にはMétodo de Pagoフィールドがあり、バッチ全体を根本的に異なる2つの処理パイプラインに分割します。PUE（一括支払）請求書はそれ自体で完結しており、請求書が最終的な税務記録となります。PPD（分割または延期支払）請求書は、対応するComplemento de Pagoを伴うPago CFDIが届くまで未完了です。50件のサプライヤーXMLのバッチでは、32件がPUE、18件がPPDの場合があります。PPDのものは、支払補完が受領され、元の請求書UUIDに対して検証されるまで計上できません。買掛金スプレッドシートですべてを同等の明細項目として扱うと、IVA目的でまだ控除できない18件の取引を計上することになります。

Uso CFDIの断片化。 すべてのCFDIには必須のUso CFDIコードが含まれています。これはSATカタログ値であり、受領者（貴社）が税務目的で請求書をどのように適用するかを決定します。G01（一般的な事業取得）、G03（一般的な経費）、D01（特定業務のための控除可能な取得）はすべてサプライヤーバッチで一般的ですが、それぞれ異なる税務処理、異なるDIOT報告カテゴリ、異なるIVAクレジットルールを引き起こします。Uso CFDIコードなしですべてのCFDIを1つの「税」列にまとめたスプレッドシートは、毎月17日までに提出する月次VAT購入申告書であるDIOTの提出には役に立ちません。

UUIDベースの重複排除の失敗。 ほとんどの買掛金システムは、ベンダー名＋請求書番号で重複排除を行います。CFDIでは、請求書番号（Folio）は単一のサプライヤーのSerie内でのみ一意であり、さらにサプライヤーが訂正請求書を取消・再発行した後に新しいUUIDを追加する場合もあります。真の一意識別子は、timbrado中にPACによって割り当てられた36文字のFolio Fiscal（UUID）です。すべてのXMLからUUIDを抽出しないと、異なるサプライヤーからの同じFolio値を持つ2つの異なるCFDIが重複としてフラグされるか、訂正された代替CFDIが元のCFDIに取って代わったものとして認識されません。

Complemento de Pagoの調整遅延。 PPD請求書の場合、支払領収書（Complemento de Pago付きのCFDI Tipo Pago）は別途届きます。元のIngreso請求書から数日または数週間後になることもあります。これは元の請求書UUIDを参照し、支払金額、日付、方法を記録し、未払いの買掛金明細と相互参照する必要があります。手動ワークフローでは、50件以上のドキュメントのバッチ全体で18件のPPD請求書をそれぞれのComplemento de Pagoに照合する調整作業に数時間かかる可能性があり、1件でも照合漏れがあると、帳簿に控除不可能な費用が残ります。

レセプター（受領者）ブロックにおけるRFC形式のバリエーション。 CFDI 4.0では、レセプター（自社）ノードに正確なRFCが必須です。しかし、一部の仕入先（特に小規模事業者や農業生産者）は、完全な税務データを持っていない場合、汎用RFC「XAXX010101000」でCFDIを発行することがあります。また、自社の買掛金システムが親会社のRFCを期待しているにもかかわらず、子会社のRFC宛てに請求書を送付する仕入先もいます。これらの不一致はSATレベルでフラグが立ちます。CFDI自体は存在し、証明されていますが、レセプターのRFCが登録済みの納税者番号と一致しないため、税務調査時にIVA（付加価値税）の控除が否認される可能性があります。

一括処理におけるPUE vs PPD — たった1つの項目が月末処理全体を分断する理由

メキシコのCFDIシステムにおいて、Método de Pago（支払方法）は単なる報告上の便宜的な項目ではありません。これは、請求額を即時に控除できるか、それとも対応する支払受領証の提出後にのみ控除できるかを決定する、税務上の区分です。Resolución Miscelánea Fiscal（RMF、税務雑則）によると、PUEの請求書は発行時に控除可能です。一方、PPDの請求書は、Complemento de Pago（支払補完）が発行され、支払イベントがSATに登録された時点で初めて控除可能となります。

バッチ処理において、この二者択一はワークフローに実質的な分岐をもたらします。

バッチ処理への影響：抽出を実行する前に、まずCFDI XMLをMétodo de Pagoで分類する必要があります。PUEバッチは直接抽出・計上に進めます。PPDバッチは二次処理が必要です。各Ingresoは、元帳に計上される前に、対応するPago CFDIと照合されなければなりません。バッチを事前に分割しないと、税務上未完了の取引が18件計上され、DIOTと買掛金元帳が一致しなくなります。

月末に50枚以上のCFDI XMLを処理する買掛金チームにとって、Método de Pagoで分類し、未調整のPPD UUIDの実行リストを保持することは、最も重要な前処理ステップです。同時に、ほとんどのバッチ処理ツールがすべての請求書を同等に扱うため、最も頻繁に省略されるステップでもあります。

Uso CFDIの仕分け — G01、G03、D01が同一の照合で処理できない理由

Uso CFDIカタログ（c_UsoCFDI）はSATが管理するコード一覧で、受領者である貴社が受領するすべてのCFDIに正しく割り当てる必要があります。これは供給者の判断ではなく、経費の処理方法を貴社が宣言するものです。供給者バッチで最も一般的な3つのコードは次のとおりです。

G01、G03、D01のCFDIは、DIOT（メキシコの月次付加価値税購入申告書、毎月17日までに提出、現在はSATのWebプラットフォームで完全オンライン提出）の異なる行に分類されます。バッチ抽出結果が3つのコードすべてを単一の「税額」列として扱う場合、DIOT作成者は申告前に抽出データをUso CFDIごとに手動で再仕分けする必要があります。50行以上のデータに追加の作業が発生します。

解決策は簡単です。バッチ出力にUso CFDIコードを専用列として抽出します。そうすれば、APスプレッドシートをDIOT提出前にコードで並べ替え、ピボット、フィルタリングでき、月末照合ではバッチ内のすべてのG01行がDIOTのG01セクションの供給者RFCと一致し、G03はそれぞれのセクションと一致することを検証できます。2列（金額＋税額）の抽出は不完全なバッチです。Uso CFDI、UUID、支払方法、供給者RFCを保持する複数列の抽出が、完全なクローズドループです。

UUID重複排除 — 伝票番号ではなく、Folio Fiscalこそが本当の請求書番号です

すべてのCFDI XMLには、似ているが目的が異なる2つの識別子があります。Folio（供給元の独自番号体系による請求書番号）とUUID（タイムブラード時にPACが割り当てる36文字のFolio Fiscal）です。買掛金の重複排除において、Folioは信頼できません。UUIDだけが信頼できるキーです。

CFDIバッチ処理に固有の3つの重複排除障害モード：

供給元間のFolio衝突。 供給元AがシリーズAでFolio #1523を発行します。供給元BもシリーズFでFolio #1523を発行します。買掛金システムが仕入先名とFolioのみで重複排除する場合、両方とも一意と認識されます。しかし、同じ供給元が修正後に同じCFDIを再送信すると、UUIDは変わってもFolioは同じままなので、システムは重複として検出しません。UUIDレベルの重複排除が必要です。

CFDI差替えによる修正。 SAT取消ルールでは、供給元はMotivo 01（「誤ったデータを含むエラーがある請求書」）でCFDIを取消し、新しいUUIDで修正版を再発行できます。古いUUIDは無効化されますが、Folioで重複排除するシステムは、取消されたXMLと修正されたXMLの両方で同じFolioを認識し、修正版を重複としてフラグ付けし、有効な請求書を抑制する可能性があります。

異なるバッチサイクルでの再送信。 供給元は、特に月末にバッチメール配信を使用する場合、すでに処理済みのXMLを再送信することがあります。UUIDベースの重複排除がないと、同じCFDIが連続する2つの月末バッチに含まれ、二重計上されます。

バッチ買掛金処理では、抽出出力にUUIDを専用列として含める必要があります。仕訳帳に明細を転記する前に、取引履歴に対してUUIDを確認してください。バッチ内のXML数と一致する一意のUUID数は、迅速な整合性チェックとなります。50ファイルで47の一意のUUIDがある場合、転記前に調査すべき3つの重複があります。

補完支払いの問題 — 請求書がPPDで、支払い領収書が数日後に届く場合

補完支払いは、PPD請求書の税務上のライフサイクルを完了する仕組みです。仕入先が支払方法＝PPDのIngreso CFDIを発行した場合、元の請求書UUIDを参照する補完支払いを含む別のPago CFDIが届くまで、取引は税務上完了しません。

買掛金チームにとって、補完支払いは2つの書類を照合する問題を引き起こし、バッチ処理の規模が大きくなるにつれて複雑化します。

タイミングのずれ。 Ingresoは月中に届きます。支払い補完を含むPago CFDIは、数日から数週間後、多くの場合異なる会計期間に届きます。月末のバッチには、35件のIngreso PPD CFDIと、それに対応するPago CFDIが28件しか含まれていない可能性があります。照合できない7件はクローズできません。それでも計上した場合、IVAの経費は非控除となり、SATのアルゴリズムによる照合で不一致が検出されます。

分割支払いの追跡。 仕入先への支払いが分割で行われる場合、各分割支払いごとに独自のPago CFDIが生成されます。10万MXNの1件のIngresoが3回に分割して支払われると、3件のPago CFDIが生成されます。それぞれが同じ元のUUIDを参照しますが、異なる支払金額と日付が記録されます。買掛金管理のスプレッドシートでは、請求書レベルではなく分割支払いレベルで支払状況を追跡する必要があります。これは、各補完支払いが発行されるたびにIVAクレジットが段階的に利用可能になるためです。

バッチ間の照合。 実際には、補完支払いが元のIngresoと同じバッチで届くことはほとんどありません。月末の買掛金クローズでは、前月のバッチから未処理のPPD UUIDのリストを取得し、新しく受領したPago CFDIと照合し、一致したペアをクローズする必要があります。これは手動の照合作業であり、バッチサイズに比例して増加します。未処理のPPD項目が35件あれば、35回の手動検索が必要となり、それぞれでPago XMLを見つけ、補完フィールドを抽出し、金額が一致することを確認する必要があります。

RFC形式のバリエーション — XAXX010101000が仕入先マスター検索を失敗させる理由

CFDI 4.0では、バージョン3.3と比較して受領者（レセプター）の識別要件が大幅に厳格化されました。CFDI 4.0では、受領者ノードに正確なRFC（納税者番号）、法的名称（Nombre）、郵便番号（DomicilioFiscalReceptor）、税制（RegimenFiscalReceptor）をすべて含める必要があり、これらはPACがタイムブレを適用する前にSATの納税者データベースで事前検証されます。これは、存在しない、または不一致の納税者に対して請求書が発行される「税務上のゴースト」問題を排除するために設計されました。

APバッチ処理における実際的な影響として、サプライヤーからの50件のCFDI XMLバッチでは、たとえすべてが自社宛であっても、受領者RFCは統一されません。

50件のサプライヤーCFDI XMLバッチ、特に小規模サプライヤー（農業生産者、地方の流通業者、独立系サービスプロバイダー）からの場合、5～10％に汎用または不一致のRFCが含まれます。これらのCFDIは認定され技術的に有効であり、SATも受理していますが、自社ではIVA控除を請求できません。バッチ出力ではこれらを個別にフラグ付けし、APチームは月末のDIOT申告期限までにサプライヤーに正しい受領者RFCでのCFDI再発行をフォローアップする必要があります。

CFDI 4.0 一括フィールド検証 — チームが確認する前にSATが却下するもの

2023年4月1日から必須となったCFDI 4.0では、より厳格なフィールド検証と新しい必須フィールドが導入されました。XMLのバッチを受け取るAPチームにとって、関連する変更点は次のとおりです。

RegimenFiscalReceptorが必須に。CFDI 3.3では受取人の税制は任意でしたが、4.0ではすべてのCFDIに受取人のRegimen Fiscalコード（SATカタログc_RegimenFiscalから）を含める必要があります。会社が複数の制度で運営している場合（例：主要業務はRégimen General de Ley Personas Morales（コード601）、別の事業ラインはRégimen de Actividades Empresariales con ingresos a través de plataformas tecnológicas（コード625））、バッチ内のCFDIは各取引が該当する制度を反映する必要があります。請求書のRegimenFiscalReceptorと登録された制度の不一致は、監査上のリスクを生み出します。

RFC + Nombreの相互検証。CFDI 4.0は、受取人のRFCをSATデータベースの登録法人名と事前検証します。仕入先が正しいRFCを入力しても法人名がわずかに異なる場合（例：「SA de CV」ではなく「S.A. de C.V.」）、PACはtimbrado前にCFDIを却下します。つまり、受信トレイに届くCFDI 4.0 XMLは構造的に信頼性が高くなりますが、その反面、発行時のエラーは不完全ながら認定された請求書ではなく、完全な却下につながる可能性が高くなります。処理するバッチはクリーンですが小さくなります。一部の仕入先は請求書が却下され、まだ再発行していない可能性があります。

Exportaciónフィールド。CFDI 4.0では、必須のExportaciónフィールド（c_Exportacion）が導入されました。値は01（輸出対象外）、02（確定輸出、A1）、03（確定輸出、A2）、04（一時輸出）です。商品を輸出する企業の場合、仕入先CFDIのバッチにはExportación=01とExportación=02/03の両方の請求書が含まれます。02/03のCFDIはVATの扱いが異なり（輸出売上はIVA 0%）、多くの場合、外国貿易補完（Complemento de Comercio Exterior 2.0、2024年1月から必須）を含みます。これらの輸出タグ付き請求書は、DIOT申告で国内購入と輸出関連購入を分離するため、バッチ出力で国内請求書から分離する必要があります。

バッチバリデーターの場合、簡単な事前抽出スキャンで有用なシグナルを得られます。RegimenFiscalReceptor値の数をカウント（1つ以上＝制度不一致の可能性）、Exportaciónフィールドの分布を確認（国内/輸出混合バッチ）、受取人RFCの数をカウント（汎用RFCにフラグ）。50のXMLのバッチで3秒の事前チェックにより、後続の仕分け作業を30分節約できます。

SATポータル一括ダウンロード制限 — Buzón Tributarioで取得できるものとできないもの

メキシコのAPバッチ処理を形作る実用的な制約：SATポータルでは、Buzón Tributarioを通じて受領したCFDIをダウンロードできますが、規模が大きくなると制限が顕在化します。ポータルの一括ダウンロード機能は通常、リクエストあたり最大500,000件に制限されていますが、これは中堅企業のAPチームが必要とする数をはるかに上回ります。しかし、Webインターフェースには実用的な制約があります。手動ダウンロードセッションはタイムアウトし、月ごとに受領したCFDIをブラウジングして個別のXMLを選別するのは、サプライヤーに直接リクエストするのと変わりません。

月間50～200件のCFDI XMLを処理するAPチームにとって、より一般的なボトルネックはSATのダウンロード制限ではなく、サプライヤーの納品一貫性です。CONTPAQi（メキシコ第1位のPAC）やEDICOMなどのPACを利用する大手メキシコサプライヤーは、通常、認定XMLを購入者に自動配信します。一方、無料のSATツールや低コストのPACを利用する小規模サプライヤーは、CFDIを生成しても受領者への自動配信を行わない場合があります。つまり、QRコード付きのPDF版（SAT検証用）はAPチームに届くものの、XMLは別途リクエストする必要があります。

XMLがない散発的または小規模サプライヤーのCFDIに対するバッチ処理には、2つの実用的なアプローチがあります。サプライヤーにXMLをリクエストするか（月末締めに1～3営業日追加）、PDF版とPDFや画像から請求書データを読み取るデータ抽出ツールを使用して、既存のXMLと同じフィールドを同じ列に抽出する方法です。この混合ソースの統合こそが、バッチ処理を「XMLパーサーを50回実行する」から、実際の運用ワークフローへと変えるポイントです。

50件のCFDI XMLから1つのAPスプレッドシートへ — 月末ワークフロー

以下は、上記の構造的な課題を考慮したバッチワークフローです。月末に14社のサプライヤーから50件以上のCFDI XMLを処理し、締め後3日目にCONTPAQiまたはAspel-COIへのインポート期限があるAPアナリスト向けに設計されています。

このワークフローは、アナリストが6～8件のCFDI PDFから手動でデータを1件ずつ抽出するのとほぼ同じ時間でバッチを処理しますが、50件以上を処理し、DIOT対応の出力を生成します。「単なるスプレッドシートのデータ」ではありません。

CFDI XMLとPDFから構造化データを抽出する基本 — すべてのサプライヤーがXMLを提供しない混合フォーマットのバッチ処理方法を含む — については、メキシコCFDI請求書のExcel抽出ガイドをご参照ください。

よくある質問 — メキシコCFDI一括請求書処理

一括CFDI処理で、PUEとPPDの請求書を同じバッチで混在して処理できますか？

技術的には可能です。一括ツールは両方からデータを抽出できます。しかし、会計上の正確性を保つには、別々のサブバッチとして処理すべきです。PUE請求書は即座に計上できます。PPD請求書は、計上前にComplemento de Pagoと照合する必要があります。PPDの調整工程を経ずに両方を同じ出力に統合すると、元帳に未確定債務が残ります。

SATポータルで受領CFDIを一括ダウンロードする場合の実用的な上限は？

SATポータルのBuzón Tributario経由の一括ダウンロードは、リクエストあたり最大50万件のregistrosをサポートしており、通常の買掛金処理量をはるかに上回ります。ただし、Webインターフェースはセッションに時間制限があり、個々の仕入先XMLを迅速に取得するようには設計されていません。月末の買掛金処理では、仕入先から直接XMLをリクエストするか、自動化されたPACから受領者への配信サービスを利用する方が、手動でのSATポータルダウンロードより高速です。

ImageToTable.aiはCFDI XMLファイルを直接処理できますか？それともPDF版のみですか？

ImageToTable.aiはPDF、JPG、PNG画像、および書類のスクリーンショットを処理できます。XML CFDIファイルの場合は、CFDIのPDFレンダリング（メキシコの全仕入先がXMLと併せて提供必須）をアップロードすると、ツールがUUID、RFC、金額、日付、Método de Pagoなどの同じフィールドを構造化された列に抽出します。一部の仕入先が印刷版のみを送付した場合など、XMLとPDFが混在するバッチでも、すべてが1つのスプレッドシートに統合されます。

月末の複数バッチにわたるCFDI UUIDの重複排除はどのように行いますか？

実行中のUUIDレジスタを維持します。新しい各バッチを計上する前に、すべてのUUIDをレジスタとクロスチェックします。個別のUUID数がファイル数と一致すれば、重複はありません。2つの異なるバッチに同じUUIDが出現する場合は、再送信（同じCFDIが2回送信された）または訂正（キャンセルされ、新しいUUIDで再発行されたため古いものは無効）を示します。どちらの場合も、計上前に調査してください。UUID列を含むバッチ抽出出力があれば、このチェックは30秒のピボットテーブル作業で完了します。

なぜ一部のCFDIはXAXX010101000のような汎用RFCを使用しているのですか？また、それらの請求書を計上することはできますか？

XAXX010101000は、SATが定める、メキシコのRFCが不明な外国籍の受領者向けの汎用RFCです。請求書を元帳に計上することは可能ですが、そのCFDIのIVAは税額控除の対象外であり、VAT目的で控除することはできません。IVA控除を受けるには、サプライヤーに自社の正しい登録RFCでCFDIを再発行するよう依頼する必要があります。これは50件以上のサプライヤーCFDIバッチで最も一般的な例外の一つであり、汎用RFCは転記前にフラグを立てる必要があります。

Complemento de Pagoはバッチ内で自動的に元の請求書と照合できますか？

はい、バッチ処理ツールが各Pago CFDIのComplemento de Pagoノードから元の請求書UUIDを抽出し（<pago20:Pago>要素はその子要素DocumentoRelacionadoで元の請求書UUIDを参照します）、それを未処理のPPD Ingreso請求書のUUIDと相互参照できれば可能です。これは構造化されたXML対XMLの照合であり、完全に自動化できるため、18件の手動照合作業をゼロにできます。

一般的な複数サプライヤーバッチでは、どのようなCFDIタイプが想定されますか？

大規模な販売代理店や産業用サプライヤーからのバッチでは、主にMétodo PPDのIngreso（Tipo I）が想定されます。製造業者やサービスプロバイダーは、契約条件に応じてPUEとPPDの両方を使用する場合があります。返品や調整のためのEgreso（Tipo E）貸方票が含まれることもあり、これらは元のIngresoと照合し、独立した明細項目ではなく、相殺仕訳として処理する必要があります。給与CFDI（Tipo N、Nómina）は別途処理され、買掛金バッチからは除外する必要があります。

メキシコの買掛金処理における真のボトルネックはデータ入力速度ではなく、照合の完全性です

各CFDI XMLを開き、スキャンし、8つのフィールドを手動でスプレッドシートにコピーするのに3分かかる場合、50件のサプライヤー請求書を処理するには、APアナリストの月末業務の2.5時間を消費します。しかし、この計算では真のコストを見逃しています。2.5時間のデータ入力の後には、さらに3〜4時間の照合作業（PPD請求書と支払補完の照合、以前のバッチとのUUIDチェック、DIOT申告のためのUso CFDIによる仕分け、サプライヤーへの汎用RFCの確認）が続きます。

メキシコの買掛金処理におけるボトルネックはデータ入力速度ではありません。手動抽出の出力（仕入先名、金額、税額を含むスプレッドシート）には、照合に必要なフィールドがまったく含まれていないからです。UUID、Método de Pago、Uso CFDI、Exportación、RegimenFiscalReceptor — これらのフィールドこそが、単なる請求書リストをDIOT対応で監査可能なAPバッチに変えるものです。これらすべてを同時に保持するバッチ抽出により、照合パスが不要になり、実際に時間がかかっていた部分が解消されます。

14社のサプライヤーから50件のCFDI XMLを処理し、UUID列が入力され、PUE/PPDの区分が事前に分類され、Uso CFDIのグループ化がDIOTセクションと一致するスプレッドシートを初めてエクスポートしたとき、抽出自体が難しい部分では決してなかったことに気づくでしょう。難しいのは、その後に行っていた照合作業だったのです。