ブラジルの貨物文書
CT-e XMLが未だに手動再入力を必要とする理由

CT-eのパラドックス：デジタルで生まれ、手作業で再入力される

「電子運送状」という言葉は、物流の専門家なら誰でもこう期待する：データが運送会社のシステムから荷受人のシステムへ電子的に流れる、なぜなら電子文書とはそういうものだからだ。しかしCT-eが電子的であるのは特定の意味においてだ——貨物が動く前に州税務当局に提出され承認される電子会計文書である。その主な消費者はSEFAZであり、荷主でも荷受人でも、ましてやサービス価値を原価台帳に反映させる必要のある物流アナリストでもない。

ブラジルのSEFAZシステムは、27の独立した州税務当局にわたって年間3億件以上のCT-e文書を処理している。このシステムは、あらゆる貨物移動が追跡・課税・監査可能であることを保証するために設計されている。荷受人の物流システムに構造化データを届けるようには設計されていない。運送会社は発行フローの一部として承認済みXMLを受け取る。荷受人がそれを受け取れるかどうかは、完全に運送会社の請求・統合能力次第であり——65万社以上の登録運送会社が存在する細分化された業界では、その能力は大きく異なる。

CT-eデータ抽出ガイドでは、DACTEの印刷物を構造化されたスプレッドシートの行に変換する実践的なワークフローを解説している。この記事では、そもそもそのワークフローが必要となる構造的な理由——あらゆる規模のブラジルの物流業務で手作業によるデータ再入力を存続させているCT-eパラドックスの4つの層——を考察する。

レイヤー1: XMLの入手しやすさ — なぜ運送会社は構造化ファイルを送らないのか

手作業での再入力が発生する最も直接的な説明は、最も簡単に修正できるように思えるかもしれません。運送会社はCT-e XMLを保有し、荷受人もそれを望んでおり、運送会社がそれを送るべきです。実際には、運送会社から荷受人へのXMLの流れは、単独の当事者では解決できない3つの構造的要因によって妨げられています。

第一に、XMLは荷受人ではなくSEFAZ宛てであること。運送会社がCT-eを発行すると、XMLは署名され、承認のために州税当局に送信されます。荷受人は文書内のデータフィールドであり、法的・運用上の意味での受信者であって、データフロー上の受信者ではありません。運送会社の義務は、商品を配送し、それに同伴するDACTEの印刷物またはPDFを提供することです。XMLの提供は商業サービスであり、法的要件ではなく、多くの運送会社はこれを請求ポータルのアップセル機能として扱っています。

第二に、運送会社の状況はXMLを標準とするには断片化しすぎていること。ブラジルの道路貨物部門には、約65万社の登録運送会社があります。最大手のJSL（上場企業、売上高約R$80億）やBraspress（ラテンアメリカ最大のLTL運送会社）のような企業は、XMLダウンロード、APIアクセス、自動化された請求書配信を提供する高度な請求ポータルを運営しています。しかし、大多数の運送会社は小規模です。単独トラックの個人事業主（transportador autônomo）または10台未満の車両を保有する地域企業です。彼らのCT-e発行ワークフローは、無料のSEFAZウェブポータルまたは、SEFAZ用のXMLを生成するがその後荷受人に配信する仕組みを持たない基本的なemissor CT-eソフトウェアである可能性があります。これらの運送会社にとって、DACTE PDFをメールで提供することが、彼らのデジタル能力の限界です。

第三に、荷受人自身のシステムがXMLを消費できない可能性があること。運送会社がXMLを提供する場合（多くの大手運送会社はデフォルトで提供します）でも、荷受人の物流システムまたはERPがそれをインポートするように設定されている必要があります。ブラジルのERPエコシステムでは、CT-e XMLインポートは、SAPのTDF（Tax Declaration Framework、コンサルティング費用だけでR$500,000以上かかるSAP S/4HANA実装が必要）およびTOTVS Protheusの財務モジュール（ライセンス料として月額R$2,000〜R$10,000）によってサポートされています。「完全に手作業には大きすぎる」と「ERPモジュール投資には小さすぎる」の間に位置する中規模企業では、XMLは届きますが、DACTE PDFと同じメール受信トレイに置かれ、貨物アナリストはこれまで通りPDFを開きます。

レイヤー2：事実上の情報源としてのDACTE

DACTE（Documento Auxiliar do Conhecimento de Transporte Eletrônico）は規制上の設計によって存在する。Ajuste SINIEF 07/2007の条件に基づき、貨物に物理的に同行しなければならない印刷された要約書である。これは執行目的に役立つ。車両がSEFAZの検問所（blitz fiscal）で停止された場合、運転手はDACTEを提示し、検査官はQRコードをスキャンするか、chave de acessoを入力して、許可されたCT-eに対して貨物を照合する。これは検査用に設計された文書であり、データ転送用ではない。

実際には、DACTEは規制とは無関係の理由で荷受人にとって主要な情報源となっている。それは、貨物とともに一貫して届く唯一の文書だからだ。XMLは届く場合もあれば届かない場合もある。DACTEは常に届く。貨物はそれなしでは移動できないからだ。

DACTEには30〜50のデータポイントが含まれており、完全なCT-e XMLのサブセットである。完全なスキーマには、明細レベルの貨物説明、製品ごとの複数の税区分、参照されるNF-eアクセスキー、および契約上の参照や特別な取扱指示を含む可能性のある自由文の追加情報（informações complementares）が含まれる。このデータの多くはDACTEに印刷されない。したがって、DACTEのみで作業する物流チームは縮小されたデータセットで運用していることになり、その縮小自体がリスクをもたらす。valor a receberは、XMLにのみ記載されている源泉徴収により、valor do serviçoと異なる場合がある。ICMSの基準額計算は税率と控除に依存するが、DACTEは中間ステップを示さずに単一の最終数値として提示する場合がある。

これらの制限にもかかわらず、DACTEは物流チームが持っているものだ。データ入力タスクは、XMLにあるものではなく、印刷されたページにあるものによって定義される。そして、そこでパラドックスの2番目のレイヤーが機能する。最もアクセスしやすい文書（DACTEの印刷物）は、アクセスしにくい文書（XML）よりも少ないデータを運ぶが、チームはアクセスしやすいものに基づいてプロセスを構築するのだ。

レイヤー3：ERPモジュールのコスト — 技術的な修正が高すぎる場合

CT-eデータのパラドックスに対する技術的に正しい解決策は、ブラジルの物流・財務関係者の間ではよく知られています。CT-e XMLを直接インポートし、SEFAZの記録と照合し、運賃コストの仕訳を自動的に転記するERPモジュールを実装することです。SAP TDF、TOTVS Protheus Fiscal、およびOracleのブラジル向けローカライゼーションモジュールはすべてこのフローをサポートしています。技術は存在します。しかし、ほとんどのミッドマーケットの物流事業にとって、そのコストは法外です。

SAP TDFはSAP S/4HANAの上に構築されます。まだS/4HANAを導入していない企業は、CT-eインポートモジュールを検討する前に、複数年にわたる数百万レアル規模のERP変革に直面します。すでにS/4HANAを導入している企業でも、TDFの実装には6〜12ヶ月かかり、コンサルティング費用としてR$200,000〜R$500,000、さらにユーザー数とモジュール構成によって変わる継続的なライセンス費用がかかります。

TOTVS Protheusは、ブラジルのミッドマーケットにとってはより導入しやすいものの、モジュール構成に応じて月額R$2,000〜R$10,000のライセンス費用に加え、実装コンサルティング費用がかかります。会計モジュールを追加する決定はCT-eだけが理由ではありません。これは企業の財務・会計インフラへのより広範な投資です。CT-eインポート機能は、より大きなビジネスケースの中の一項目に過ぎず、NF-e処理がすでにモジュールなしで手動処理されている場合、CT-eのためだけにモジュールを追加してもROIの基準を満たすことはほとんどありません。

その結果、処理の空白が生じます。SAP S/4HANAとTDFを導入している大企業はCT-e XMLを自動処理できます。月20件のCT-eを処理する非常に小規模な事業は、その量では投資を正当化できないため、手動処理を続けます。ミッドマーケットの事業（月200〜500件のCT-e）は苦しい中間層に位置します。手動処理には年間R$30,000〜R$80,000の人件費がかかりますが、ERPモジュールの実装コストは、手動処理の年間コストよりも高くなります。投資判断には複数年にわたる視点が必要ですが、多くの企業はその評価を行う体制を整えていません。

レイヤー4：業界の断片化 — 65万以上の運送事業者

他のすべてのレイヤーを増幅させる構造的要因は、ブラジルの道路貨物業界の規模と断片化です。ANTT登録の運送事業者ベースは約65万事業者であり、業界全体の標準化は、実際のシステムでは達成不可能な理論上の理想です。200社のサプライヤーから輸入貨物を受け取る荷受人（consignee）は、1か月に80〜100社の異なる運送事業者とやり取りする可能性があります。各事業者は独自の請求システム、独自のDACTEレイアウトバリアント、独自のメール配信形式、そして独自の「請求書配信」の定義を使用しています。

運送事業者レベルでのERP統合 — 各運送事業者が自社のCT-e XMLを荷受人のシステムにプッシュする場合 — には、それら80〜100社の各運送事業者がAPI統合をサポートする必要があります。大手運送事業者にとってはこれは実行可能です。中小運送事業者や個人事業主の大半にとっては、それは不可能です。業界の構造上、ERPへの投資額に関係なく、ほとんどの荷受人にとって完全に統合されたデータパイプラインは非現実的な目標となっています。

実際的な意味合い：荷受人のデータ入力問題は、運送事業者がXMLの送信を拒否することではありません。データが100の異なるチャネル、100の異なるDACTEレイアウトで届き、唯一の共通点は商品に同梱される印刷物だけであることです。運送事業者ごとの統合（API設定、XML解析のカスタマイズ、テンプレート設定など）を必要とするソリューションは、運送事業者の数が数社を超えると機能しなくなります。

これが、ビジュアルレイヤーでの抽出 — DACTE印刷物を画像として読み取り、構造化データに変換すること — が統合問題の回避策ではなく、業界の断片化に直接対処する唯一のソリューションである理由です。運送事業者側のアクションは一切不要です。同じバッチで、あらゆる運送事業者のあらゆるDACTEレイアウトを処理します。また、荷受人のERPロードマップにも依存しません。

ビジュアルレイヤーでの抽出が変えるもの

CT-eのパラドックスの4つのレイヤー — XMLの非アクセス性、デフォルトとしてのDACTE、ERPモジュールのコスト、業界の断片化 — は、手動プロセス再設計では逃れられない構造的な罠を形成しています。各レイヤーは一部のケースでは個別に解決可能ですが、その組み合わせは事実上すべての物流業務をカバーしています。規模が十分に大きく、標準化を妨げるほど断片化されており、エンタープライズソリューションへの投資基準をわずかに下回っています。

ビジュアル抽出 — DACTE印刷物をソースドキュメントとして扱い、AI搭載のカスタム列抽出でデータを抽出する方法 — は、異なるポイントで罠を打ち破ります。XMLが運送会社から荷受人に流れる必要はありません（レイヤー1）。すでに利用可能なDACTEで機能します（レイヤー2）。ERPモジュールよりも桁違いに低コストで、数か月ではなく数時間で結果を提供します（レイヤー3）。そして、運送会社ごとの統合なしに、すべての運送会社のレイアウトを単一のバッチで処理します（レイヤー4）。

仕組みは簡単です。DACTEのPDFまたは画像をアップロードし、抽出したい列名を入力すると、AIが印刷ページ上の各値をその意味を理解して特定します — 事前設定されたテンプレートに一致させるのではありません。出力はドキュメントごとのスプレッドシート行で、既存のコスト台帳やERPインポートにそのまま使用できます。CT-e抽出のステップバイステップガイドでは、列定義と処理ワークフローを説明しています。

ドキュメントごとの抽出以上のものを必要とするチーム向け — 1kgあたりの運送コストを計算する計算列、実効ICMS税率の検証、月次バッチ集計など — CT-e運送コスト台帳のバッチ処理ガイドでは、組み込みのコスト分析を備えた複数運送会社のバッチ処理ワークフローを拡張しています。

よくある質問

運送会社にCT-e XMLを直接請求できないのですか？

請求は可能です。確実に受け取れるかは運送会社次第です。大手運送会社（JSL、Braspress、Rodonaves）は通常、請求ポータルからXMLダウンロードを提供します。小規模運送会社や個人事業主は、発行後にXMLを再送信または共有する仕組みを持たない場合があります。その発行ツールが無料のSEFAZウェブフォームであり、XMLは政府にのみ送信されるためです。実際には、大手運送会社との調達契約でXML納品を義務付けることができますが、それ以外の市場では、DACTEのPDFまたは印刷物が入手できるものとなります。

DACTEの印刷物で十分なデータですか、それとも完全なXMLが必要ですか？

DACTEには、コスト追跡と運送会社への支払いに必要なデータ（サービス価値、ICMS額、重量、経路、当事者）が含まれています。完全な明細レベルの貨物詳細、製品ごとの一部の税区分、完全なイベント履歴（CT-e修正、取消イベント）は含まれていません。運送費会計には、DACTEで必須項目をカバーできます。最高レベルの詳細でのSPED EFD ICMS/IPIコンプライアンスには、完全なXMLが望ましいです。実践的な戦略：コスト追跡にはDACTEを抽出し、税務チームが完全な税区分を必要とする場合にはコンプライアンス用にXMLを請求します。

ERPにCT-e XMLインポートを実装する実際のコストはいくらですか？

SAP S/4HANAとTDFの場合、コンサルティング費用としてR$200,000〜R$500,000、実装に6〜12か月、さらにS/4HANAライセンス自体がかかると見積もってください。TOTVS Protheusの場合、ライセンス料として年間R$24,000〜R$120,000（月額R$2,000〜R$10,000）に加え、実装コンサルティングがR$30,000〜R$80,000かかります。OracleやSageの同等モジュールでも、コストは同程度です。これらの数字は、すべてのブラジルの税務文書をカバーするERPモジュール実装のためのものであり、CT-e XMLインポートはより大きなモジュール範囲内の機能です。一部の小規模なERPローカライゼーションパッケージでは、より低コストでCT-eインポートを提供する場合がありますが、通常は企業がすでにそのERPプラットフォームを利用していることが条件です。

運送会社に調達契約でXMLの送付を義務付けることはできますか？

可能です。大手荷主は実際にそうしています。実際の制約は、この強制力が機能するのは、あなたのビジネスを競争している運送会社に対してのみであることです。スポット輸送、緊急貨物、または1〜2社の運送会社しか運行していない路線では、交渉力は弱くなります。また、サプライヤーからの入荷貨物を配送する多くの中小運送会社（契約していない運送会社）とは、契約関係がまったくありません。これらのケース（ほとんどのメーカーにとって入荷貨物のかなりの割合を占める）では、DACTEが輸送データとの間で存在する唯一の文書です。

DACTEからの視覚的抽出は、XML解析と同じ精度を実現しますか？

XML解析はデータがすでに構造化されているため、100%正確です。DACTEの印刷物やPDFからの視覚的抽出には、あらゆるAI文書読み取りの精度上の制限が伴います。きれいなPDFやスキャンでは優れた精度（印刷フィールドで最大99%）、品質の低い写真や手書きの注記ではやや低くなります。違いは、XML解析は常に利用できるとは限らないのに対し、視覚的抽出は常に可能であることです。選択肢はXML精度とDACTE精度の間ではなく、DACTE抽出（わずかな精度のトレードオフを伴う）と、DACTEの手動再入力（1〜4%のエラー率と文書あたり90秒の時間コストを伴う）の間です。

CT-eはブラジルの広範な電子文書エコシステムの中でどこに位置づけられますか？

CT-eは、NF-e（商品請求書）、NFS-e（サービス請求書）、MDF-e（複数のCT-e文書を1台の車両にまとめる貨物マニフェスト）、BP-e（乗車券）と並んで機能します。物流コスト管理において、重要な関係はCT-eとNF-eの間にあります。CT-eは輸送コストを記録し、NF-eは商品価値を記録し、この2つが合わさって総着地コストが算出されます。ブラジル電子文書ハブガイドでは、これらの文書がどのように相互作用し、それぞれが物流ワークフローのどこに位置づけられるかについての完全な概要を提供しています。