メキシコのCFDI請求書処理が、
多くのチームの想定より難しい理由
メキシコのサプライヤーが御社の買掛管理(AP)受信トレイにPDFとXMLの2つのファイルを送信します。PDFは請求書のように見えます。XMLは開発者だけが扱えるように見えます。その請求書の処理(データをERPに抽出し、支払いを照合し、監査用に保管すること)には、キュー内の他のどの外国請求書よりも3倍以上の時間がかかります。フォーマット自体がボトルネックであり、その理由のほとんどは印刷されたページには表示されません。
CFDIに不慣れですか? この記事では、CFDIとは何かをご存知であることを前提に、その処理がなぜ難しいかに焦点を当てています。メキシコの電子請求書システムの初心者向け入門(CFDIとは何か、PAC検証の仕組み、各フィールドの意味)については、CFDIとは何か?初心者向けガイドから始めてください。難しさを理解するためではなく、抽出ワークフローを構築するためにここにいる場合は、完全版CFDI抽出ガイドで全手法を網羅的に解説しています。

重要なポイント
- メキシコのCFDI請求書は、他のどの外国請求書よりも御社のAPチームの処理に3倍以上の時間がかかります。その理由のほとんどは印刷されたページには表示されません。
- このシステムは、御社の業務効率ではなく、SATのリアルタイム税務執行のために構築されました。PPD条件の1件の取引で4つの別々のXMLが生成されることがあり、御社のAPワークフローにはそれらを関連付けるネイティブな方法がありません。
- ImageToTable.aiは、ページ座標ではなく意味的な意味によってCFDIコンテンツを読み取り、規制フィールド、二重ドキュメントのPPD追跡、マルチフォーマット入力を1回のパスで処理します。どのサプライヤーの請求書ソフトウェアがPDFを生成したかに関係なく機能します。
単なる長い請求書ではない:表面的な問題
CFF第29-A条に準拠したCFDI(Comprobante Fiscal Digital por Internet、インターネット経由のデジタル税務領収書)は、単なる長い請求書ではありません。これは政府が義務付けたXML文書であり、その構造はAnexo 20技術標準によって定義されています。この仕様は、現在のCFDI 4.0バージョンでは、100以上のXML要素と複数の条件付き検証チェーンを定義しています。しかし、問題をフィールド数の多さに求めるのは、処理が遅くなる真の原因を見逃しています。困難なのはフィールドが多いことではなく、フィールド同士が相互に関連し、異なる文書、異なるシステム、異なる時点にまたがる追跡義務を生み出すことです。
症状は簡単に見つかります。仕入先のPAC(Proveedor Autorizado de Certificación、認定認証プロバイダ)が請求書を拒否するのは、受取人のRFC(Registro Federal de Contribuyentes — メキシコの納税者番号)がSATの納税者登録簿と完全に一致しないためです。アクセント記号が一つ欠けているだけの小さな不一致でも起こります。先週銀行で決済された支払いが、元帳のどの未処理請求書にも表示されないのは、その支払いが元の文書の明細行として表示されるのではなく、元の請求書のUUID(Universally Unique Identifier)を参照する別のCFDIタイプPagoとして発行されたためです。3週間前にチームが処理した請求書が、実は仕入先によって取消されていたことが判明する場合もあります。しかし、72時間以内に貴社で取消リクエストを受け入れも拒否もしなかったため、自動的に承認されてしまいました。APエントリは無効化された文書を参照することになります。
これらは例外的なケースではありません。月に数件を超える規模でメキシコの仕入先請求書を処理する場合、これらは通常の運用条件です。そして、これらは仕入先の不適切な慣行や不十分なAPツールに起因するのではなく、CFDIシステム自体のアーキテクチャに起因しています。このシステムの設計目標は規制上の可視性と税務執行であり、取引の受取側の運用効率ではありませんでした。
核心的な主張: CFDI処理の複雑さには、規制、文書、運用という3つの独立した構造的レイヤーがあり、各レイヤーが下のレイヤーを増幅させます。各レイヤーが存在する理由を理解することが、3つすべてを処理できるワークフローを構築するための第一歩です。
レイヤー1:すべてのCFDIをミニ確定申告にする規制アーキテクチャ
多くの国では、請求書は商業文書です。何が、誰に、いくらで売られたかを記録します。税務報告は後日行われます。売り手が付加価値税申告書を提出するとき、買い手が経費を計上するときです。メキシコでは、請求書そのものが税務申告です。この違いは学術的なものではありません。作成時にどの情報が存在しなければならないか、法的効力を持つ前に誰がそれを検証しなければならないかを変えます。
メキシコは、税制研究者がリアルタイムクリアランスモデルと呼ぶものを採用しています。CFF第29条第IV項に基づき、すべてのCFDIは受取人に発行される前に、SAT(メキシコ連邦税務当局)に送信されなければなりません。送信はPAC(SAT認定仲介業者)を通じて行われ、PACはXML構造をAnexo 20ルールに照らして検証し、発行者と受取人のRFCがSATの有効な納税者登録簿に存在することを確認し、発行者のCSD(デジタルシール証明書)が有効で失効していないことを確認し、税額計算が内部的に整合していることをチェックし、その後初めてデジタル税印を適用し、検証済みのCFDIを割り当てられたUUIDとともに返します。
これは、あなたの買掛金チームにとって、受け取るすべてのCFDIがすでに政府の検証チェックポイントを通過していることを意味します。そのデータはサプライヤーの主張ではなく、SATが確認した主張です。これにより、データは通常の請求書よりも信頼性が高くなります。また、データの誤り(RFCの誤り、誤った税制コードなど)は、サプライヤーが簡単にPDFを更新して修正できるものではないことも意味します。誤ったCFDIは正式な取消手続きを通じて取り消され、新しいものが最初から発行されなければなりません。
必要なデータは単なる「名前、日付、金額」ではありません。CFF第29-A条は、すべてのIngresoタイプ(収入請求書)のCFDIに以下を含めることを義務付けています:発行者のRFC、法的名称、税制コード;受取人のRFC、法的名称、税務上の住所の郵便番号、および受取人が税務目的で請求書をどのように使用するかを宣言するUso CFDIコード;発行場所と日付;一意の連番;発行者のデジタルシール;数量、単位、SATの製品・サービス分類コード、単価、合計を含む明細行;IVA(付加価値税)の移転と源泉徴収を含む完全な税額内訳;支払い形式と支払い方法(一括払いはPUE、分割払いはPPD);UUIDと認証タイムスタンプ。
これらの各フィールドは、あなたの記録のためだけでなく、SATのクロスリファレンスエンジンにとっても重要です。受取人のRFCと名前はSATの納税者登録簿と照合されます。税制コード(法人は601、事業活動を行う個人は612、給与所得者は605などの数字識別子)は、取引の両側に適用される税務処理を決定します。発行者の申告された制度と報告された収入の種類が一致しない場合、自動監査フラグがトリガーされる可能性があります。これが、メキシコのサプライヤーが請求書を発行する前にあなたの正しいRFCと税制コードを入手することに非常にこだわる理由です。彼らは官僚的なわけではありません。SATの記録と一致しないデータを含む請求書を拒否するシステムに準拠しているのです。
2026年の税制改正により、この層に新たな側面が加わりました。連邦税法第29条A(CFF Article 29-A)に第IX項(Fracción IX)が新設され、2026年1月1日より、CFDIが真実かつ正確な取引を反映することが義務付けられました。実際の法的行為や取引を表していないCFDIは虚偽とみなされ、発行者・受領者・仲介者に対する刑事責任を含む結果が生じます。これは御社が受け取るすべてのCFDIの重要性を高めます。実際には提供されていないサービスに対して請求書を発行した仕入先は、単なる報告ミスを犯しているのではありません。SATが虚偽と推定する可能性のある文書を作成していることになり、御社の社名とRFCが虚偽CFDIの受領者として公表され、税務申告を修正する猶予は30日間のみとなります。
レイヤー1の複雑さを要約すると、処理対象の文書は御社のために作られたものではありません。SATのリアルタイム監視インフラのために作られたものです。御社の買掛金ワークフローは、SATが要求するすべてのフィールドと検証を継承します。たとえそれらのフィールドが御社の会計に関係がなくてもです。
レイヤー2:文書構造 — 1つの取引が2つ(またはそれ以上)のXMLを生む理由

規制レイヤーが必須フィールドを追加する一方、文書構造レイヤーは取引自体を複数のファイルに分割します。ここが、米国や欧州の請求書形式に慣れた買掛金チームがCFDI処理で最も大きく戸惑う点です。
分割は支払条件(Método de Pago)と呼ばれるフィールドから始まります。値がPUE(一括払い)の場合、収入CFDI(Ingreso)自体が完全な取引を記録します。商品・サービス、金額、税金、そして発行時点で支払いが全額完了している事実です。1つの文書、1つの取引。これがCFDIの中で通常の請求書に最も近いものです。
値がPPD(分割・後払い)の場合、収入CFDI(Ingreso)は義務のみを記録します。実際の支払い(いつ、いくら、どの方法で)は、支払受領補足情報(Complemento de Recepción de Pagos、Complemento de Pagoとも呼ばれる)を伴う支払CFDI(Pago)という別のCFDIに記録されます。この補足情報は元の収入CFDIのUUIDを参照し、支払日、支払額、支払方法(振込、小切手、現金、電子ウォレット)、該当する場合は通貨と為替レート、この支払い後の残高を記録します。
1つの取引が、一緒に追跡しなければならない2つのXMLを生成します。支払いが3回に分けて行われる場合、4つのXML(1つの収入CFDIと3つの支払CFDI)が生成され、それぞれが独自のUUIDを持ち、補足情報構造を介して元のCFDIを参照します。これらを照合するには、各支払補足情報のUUIDを元の収入CFDIのUUIDと照合し、分割支払いを合計し、残高がゼロになることを確認する必要があります。受信箱で1つの支払CFDIを見逃すと、銀行口座では引き落としが確認できるにもかかわらず、元帳では収入CFDIが未払いのまま無期限に表示され続けます。
実際の意味: 仕入先が3月1日にPPD(分割・後払い)の収入CFDI(Ingreso)をMXN 150,000で送信したとします。御社はこれを受領し処理します。3月15日、仕入先からMXN 75,000の支払CFDI(Pago)が送信されますが、メールの件名は「complemento de pago」で、添付ファイルは別のXMLです。APチームがこのXMLを開いて支払受領補足情報(Complemento de Recepción de Pagos)ノードを読み、参照されているUUIDを見つける必要があることを知らなければ、このMXN 75,000の支払いはシステム上で元の請求書にリンクされません。請求書は未処理のまま残ります。仕入先から「まだ支払われていないのか」と電話がかかってきます。御社はすでに支払い済みです。両者の記録は正しいのです。ただ、APワークフローで結び付けられることのない2つの別々の文書に存在しているだけです。
この二重文書構造は、取引量が増えるにつれて下流で複合的な問題を引き起こします。月末締めの際、PPD(分割・後払い)条件を使用するメキシコの仕入先請求書50件を処理するAPチームは、照合すべきXMLが100件以上になる可能性があります。各XMLで、収入CFDI(Ingreso)とその支払補足情報(Pago complement)の間のUUIDクロスリファレンスが必要です。手動照合では、各支払XMLを開き、参照されているUUIDノードを見つけ、処理済みの収入CFDIデータベースで一致するものを検索し、金額が一致することを確認し、両方を照合済みとしてマークする必要があります。照合1件あたり3分かかる場合、PPD(分割・後払い)ペア50件でAPスタッフの時間を2時間半消費します。これを毎月、一国の仕入先分だけ行うのです。
文書分割にはもう一つの側面があります。XMLとPDF表現の関係です。メキシコ法では、デジタル署名されPAC(認定認証プロバイダー)のスタンプが押されたXMLファイルが法的に権威のある文書です。PDFはSAT(メキシコ税務当局)によって規制された視覚的表現であり(SATの検証ポータルへのリンクをエンコードした二次元バーコードを含める必要があります)、独立した法的効力はありません。PDFのデータが対応するXMLのデータと異なる場合(仕入先のERPシステムがフィールドを切り詰めたり再フォーマットしたりするテンプレートからPDFをレンダリングする場合に発生し得ます)、SATが正しいとみなすのはXMLです。XMLを確認せずにPDFからデータを入力するAPチームは、コンプライアンスの観点から、装飾的な印刷物を処理していることになります。
XMLとPDFの両方からCFDIデータをExcelに抽出するワークフローの詳細については、CFDI抽出ハウツーガイドをご覧ください。CFDI請求書をバッチ規模で処理する場合(特にPago補足情報全体でのUUIDクロスリファレンス)は、バッチCFDI処理ガイドをご覧ください。
レイヤー3:取消の罠 — エラー修正に72時間と2つの署名が必要な理由

ほとんどの請求書処理環境では、エラーを修正する場合、サプライヤーがクレジットノートや修正版PDFを送信し、買い手が調整を計上します。CFDIシステムでは、発行・電子署名済みの請求書は編集できません。取消のみが可能であり、取消自体も規制されたプロセスで、両当事者、政府システム、そして期限が関与します。
現在の規則では、CFDIを取消するには、発行者がSAT税務メールボックス(Buzón Tributario)を通じて取消申請を提出し、4つの標準化された理由コードのいずれかを指定する必要があります:01 — 関連誤記のある証票(取消されるCFDIが関連文書に置き換えられることを意味します);02 — 無関連誤記のある証票;03 — 取引が実行されなかった;04 — 一括請求書内の関連名義取引。コード01は事業上の修正で最も一般的であり、発行者は取消されるCFDIを代替する新しいCFDIのUUIDを指定する必要があります。
取消申請が提出されると、受領者には承認または拒否のための72時間(3営業日)が与えられます。受領者が何もしない場合、取消はタイムアウトにより自動承認されます。受領者が拒否した場合、CFDIは法的に有効なままとなり、発行者は受領者と再交渉するか、SATの紛争解決チャネルを通じてエスカレーションする必要があります。
受領者の承認が不要な限定的な例外があります:給与CFDI(Nómina)、MXN 1,000未満の請求書、一般向け取引(汎用RFC XAXX010101000を使用)、および元の発行から72時間以内に行われる取消。その他すべて — MXN 1,000を超えるすべての商業用収入CFDI(Ingreso)— には、受領者の72時間の承認期間が適用されます。
受領側の買掛金チームにとって、これは2つの運用上の危険をもたらします。1つ目は無効文書リスクです:3週間前に処理・計上したCFDIがサプライヤーによって取消されている可能性があり、組織内の誰もSAT税務メールボックスにログインして申請を承認または拒否しなかったため、黙って承認されてしまった場合があります。帳簿には無効な税務文書に裏付けられた仕訳が残ることになり、SATはこれを無効なCFDIに裏付けられた経費として扱い、控除を否認し、追徴課税や罰則が発生する可能性があります。
2つ目は代替文書追跡のギャップです:サプライヤーが理由コード01でCFDIを取消した場合、新しいUUIDを持つ代替CFDIを発行します。買掛金チームは元の仕訳を特定し、無効化し、代替文書を再入力する必要があります — 新しいUUIDを古いUUIDに照合します。代替文書が別のメールスレッドで、少し異なる件名で、別のチームメンバーによって処理された場合、元の文書と代替文書の関連付けは失われ、両方のバージョンがシステム内に同時に存在することになります。
構造上の影響: 取消メカニズムにより、請求書処理は一度きりのデータ入力作業から、状態を監視し続ける義務へと変わります。CFDIを一度処理したら終わり、というわけにはいきません。その取消ステータスを把握し続ける必要があります。場合によっては、CFDIが最初に発行された会計年度の年次ISR(所得税)申告が提出される月まで取消が可能なため、会計年度全体にわたって監視が必要になる可能性があります。
レイヤー4: 複数RFCとクロスボーダーの課題
上記の3つのレイヤーは、メキシコのCFDI請求書を受け取るあらゆる組織に当てはまります。多国籍企業にとっては、RFC制度がクロスボーダー業務とどのように相互作用するかに固有の、4つ目の複雑さがあります。
メキシコに複数の法人(製造子会社、販売子会社、サービス事業体)を持つ企業は、それぞれに個別のRFCを持ちます。誤ったRFC宛てに送信されたCFDI請求書は、法的に誤った納税者宛てとなります。サプライヤーが製造子会社のRFC宛てに請求書を発行したものの、商品が配送・消費されたのは販売事業体だった場合、製造事業体はその取引が自社の税務登録の下で発生していないため、法的に経費を控除できません。また、販売事業体には売上原価を裏付けるCFDIがありません。これを修正するには、上記で説明した72時間の受信者承認の影響を伴う取消・再発行サイクルが必要です。
メキシコのサプライヤーからCFDI請求書を受け取るものの、自社のRFCを持たない外国企業の場合、汎用の外国事業者用RFCであるXEXX010101000を使用できます。このRFCには重要な制限があります。受信者はIVA控除を請求したり、メキシコの税務目的で経費を控除したりすることはできません(メキシコでの納税申告義務がない外国企業にとっては、通常、問題になりません)。より業務上重要なのは、XEXX010101000は無関係な多数の事業体が使用する汎用識別子であるため、特定の法人へのトレーサビリティが提供されないことです。御社に3つの地域オフィスがあり、それぞれが異なるメキシコのサプライヤーからCFDI請求書を受け取り、すべてがXEXX010101000を使用している場合、処理中に請求書を正しい事業体にルーティングするRFCレベルの方法はありません。ルーティングロジックは、サプライヤー名、説明フィールド、またはメール受信者に依存してAPワークフローに組み込む必要がありますが、いずれも税務IDのような構造的信頼性はありません。
受信側には、税制区分(régimen fiscal)の不一致という問題もあります。メキシコのサプライヤーがCFDIを発行する際、受信者の税制区分コードを記録する必要があります。御社がメキシコの事業体のRFCを取得している場合、その事業体は特定の区分(例えば、601(法人の一般制度))で登録されています。オンボーディング中に誰かが誤ったコードを提供したために、サプライヤーが誤って612(事業活動を行う個人)を入力した場合、CFDIはPAC検証を通過する可能性がありますが(612は有効な区分コードであるため)、将来の監査でSATがフラグを立てる可能性のある構造的データエラーが含まれることになります。CFDIは有効ですが誤っている — 問題になる前に発見するのが最も難しいタイプのエラーです。
スペイン語圏市場におけるドキュメント処理の広範な課題の分析については、スペイン市場におけるドキュメント抽出の概要をご参照ください。
テンプレートベースのアプローチがCFDIで機能しない理由
請求書処理の複雑さへの一般的な対応は、テンプレートベースのOCRです。各仕入先のレイアウトごとにテンプレートを定義し、フィールドを座標にマッピングして、座標に基づいてデータを抽出します。このアプローチは、1つのサンプルでトレーニングしたテンプレートが次の100件でも機能するほど、ドキュメント形式が一貫していることを前提としています。CFDIは、この前提を2つの点で覆します。
第一に、PDFの表現は仕入先によって異なります。すべてのCFDIにAnexo 20(技術標準)で定義された同じ必須フィールドが含まれているにもかかわらず、各仕入先のERPまたは請求システムはPDFを異なる方法でレンダリングします。ある仕入先はUUIDを右上隅に36文字の文字列として配置します。別の仕入先は、それを下部のQRコードバーコードにのみ埋め込みます。3番目の仕入先は、フッターに凝縮されたフォントで印刷します。仕入先Aのレイアウト用に構築されたテンプレートは、仕入先Bの請求書では完全に機能しません。
第二に、PDFとXMLは異なるデータを保持できます。仕入先のERPは、XMLフィールドのサブセットからPDFをレンダリングする場合があります。明細項目の合計は表示するがIVA(付加価値税)の内訳は表示しない、登録済みの正式名称(razón social)の代わりに仕入先の通称を表示する、などです。抽出ツールがPDFを読み取る場合、簡略化された印刷データを取得します。コンプライアンス義務がXMLの完全な税務詳細を要求する場合、PDFでは不十分です。PDFに照合するAPチームは、SAT(メキシコ税務当局)が公式記録とみなすデータよりも少ないデータに照合していることになります。
この構造的な変動性を処理するアプローチは、ドキュメントのコンテンツ、つまりUUID、RFC、IVA 16%、税制区分(régimen fiscal)などのフィールドの意味論的な意味を、ページ上のどこに表示されるか、またソースがPDFかXMLかに関係なく読み取るものです。意味論的抽出は、RFCが座標(200, 450)にあるからではなく、周囲のテキストで「RFC」とラベル付けされた12桁または13桁の英数字識別子のパターンに一致するから、RFCを識別します。これが、視覚的な位置をマッピングすることとドキュメントのコンテンツを理解することの違いであり、CFDI処理を仕入先ごとのテンプレート保守の負担ではなく、大規模に実行可能にする違いです。
メキシコの買掛金ワークフローへの影響

これら4つのレイヤーをまとめると、すべてに対応するCFDI処理ワークフローには、標準的なAPシステム(請求書を単一・自己完結・ステートレスなドキュメントと想定して構築されている)がネイティブに備えていない機能が必要です。
マルチフォーマット取込。 サプライヤーがXMLとPDFの両方で納品するため、ワークフローは両方を入力として受け付ける必要があります。正規データはXMLに存在します。XMLのみから抽出すると、視覚的な検証ステップ(印刷されたドキュメントが構造化データと一致するか)が失われます。PDFのみから抽出すると、法的記録が失われます。両方のフォーマットを同じ抽出パイプラインに取り込み、CFDIごとに統合された出力行を生成する必要があります。
UUID対応照合。 UUID(すべてのCFDIに埋め込まれた36文字の識別子)は、Ingreso請求書をPago補足情報にリンクし、取消を追跡し、各ドキュメントをSATの検証ポータルに接続する恒久的なキーです。UUIDをバッチ間で取得・保存・相互参照しないCFDIワークフローは、手動検索なしではPPD支払照合を実行できません。バッチ照合ワークフローについては、バッチCFDI処理ガイドをご覧ください。
取込時の税制区分・RFC検証。 CFDIが会計システムに入る前に、受領者のRFCと税制区分(régimen fiscal)コードを御社の登録データと照合する必要があります。取込時に不一致を検出すれば、連鎖的な問題を防げます。誤った事業体に経費が計上され、税務チームが監査準備中にエラーを発見し、対応としてサプライヤーとの取消・再発行サイクルが必要になる(しかもサプライヤーが応答しない可能性がある)という事態を回避できます。
取消ステータス把握。 一度処理されたCFDIが恒久的に確定したわけではありません。SATの検証ポータルに対する定期的なUUIDステータスチェックを含むワークフロー、またはサプライヤーが定義されたチャネルを通じて取消リクエストを御社チームに通知することを要求するワークフローは、無効化されたドキュメントを台帳に保持するリスクを軽減します。
これにはエンタープライズ規模のPAC統合や専用のメキシコ税務コンプライアンスプラットフォームは必要ありません。必要なのは、CFDIが何であるか(複数ドキュメント・ステートフル・政府検証済みの記録)を理解し、それに応じてデータを抽出する処理ステップです。単なる数字が追加された長いPDFとして扱うのではありません。
よくある質問
メキシコのサプライヤーはなぜ通常のPDFインボイスを発行できないのですか?
メキシコの法律では、PDFは有効な税務書類として認められていません。2014年以降、メキシコのすべての納税者(企業、個人事業主、営利活動を行う個人)は、PACによって検証され、SATにリアルタイムで登録されたCFDI XMLインボイスを発行することが義務付けられています。PDFのみを発行するサプライヤーは、メキシコの税法上、法的に有効なインボイスを作成しておらず、そのような書類をメキシコでの税額控除の根拠として使用することはできません。
実際の運用におけるPUEとPPDの違いは何ですか?
PUE(一括支払い)は、発行時にインボイスが全額決済されることを意味し、1つのCFDIが取引全体をカバーします。PPD(分割/後払い)は、インボイスが債務を記録し、その後の各支払いごとに、独自のUUIDと元のインボイスを参照するComplemento de Pagoを持つ、タイプPagoの個別のCFDIが生成されます。PPDでは取引ごとに少なくとも2つのXMLを追跡する必要がありますが、PUEでは1つで済みます。支払方法コード(PUEまたはPPD)は、Ingreso CFDIのMétodo de Pagoフィールドに表示されます。
記録としてPDFだけで十分ですか、それともXMLを保管する必要がありますか?
XMLが必要です。CFF第30条に基づき、発行者と受領者の両方は、CFDI XMLファイルを少なくとも5年間保管する義務があります。PDFは規制された視覚的表現であり、SATの検証ポータルにリンクするQRコードを含める必要がありますが、独立した法的効力はありません。税務調査では、SATはPDFではなくXMLを要求します。
サプライヤーからの取消リクエストを無視するとどうなりますか?
72時間(3営業日)以内に応答しない場合、取消はタイムアウトにより自動的に承認されます。CFDIは無効となり、そのCFDIに基づく税額控除や経費計上は、有効な税務書類によって裏付けられなくなります。貴社がメキシコで納税申告を行う場合、これはコンプライアンス上のリスクを生み出します。メキシコで納税申告を行わない場合でも、無効化されたインボイスに気付かずに支払いを行うという運用上のリスクが生じます。
すべてのメキシコ仕入先請求書に汎用RFCのXEXX010101000を使用できますか?
はい、御社にメキシコの税務登録がなく、独自のメキシコRFCもない場合に限ります。ただし、XEXX010101000(外国事業者用汎用RFC)はすべての外国受取人が共有する汎用識別子であり、法人単位の追跡可能性は提供されません。御社に複数のオフィス、部門、またはCFDIを受け取る事業体がある場合は、各請求書を正しい処理キューに振り分けるための内部ルーティング仕組み(仕入先名、説明、またはメールに基づく)が必要になります。
CFDIの複雑さは他国の電子請求書システムより深刻ですか?
メキシコのシステムは、ブラジルのNF-e(ブラジル電子請求書)と並んで、世界で最も厳格に管理されているものの一つです。両方ともリアルタイムの政府承認を必要とし、両方ともデジタル署名付きの構造化XMLを要求し、両方とも元の請求書とその後の支払いまたは輸送文書との間の照合義務を生じさせます。メキシコのシステム特有の複雑さは、二重文書のPPD(分割・後払い)/Pago構造と、受取人の承認を伴う取消メカニズムにあります。これらの機能は、ほとんどの欧州の電子請求書義務付けには直接の同等物がありません。
CFDI請求書を大規模に処理するには、文書の背後にある構造を理解するワークフローが必要です。追加フィールドを持つ単なるPDFとして扱うものではありません。その違いは月末締めのタイムラインに現れます。PPD条件付きのCFDI請求書50件を、UUID対応の照合で処理すれば数分で完了します。それなしで処理すると、同じ50件の請求書に毎月数時間の手動照合作業がかかります。