ERPが抽出したExcelを拒否する理由:
よくある5つの原因と修正方法
請求書を抽出ツールに通し、きれいなスプレッドシートを受け取り、それをERPにアップロードしたとします。するとエラーが発生します:「3行目に無効な日付値があります。」あるいはもっと悪いケースとして、インポートは「成功」と表示されたのに、日付や金額が静かに間違っていることもあります。データはそこにあります。ただERPが同じ形式の言語を話していないだけなのです。

重要ポイント
- 抽出ツールが間違えていると思いがちですが、データ自体は正確です — ExcelがERPがファイルを参照する前に、日付をシリアル番号に静かに変換し、すべてのコードフィールドから先頭のゼロを削除しているのです。
- インポートが失敗するたびに15〜30分の修正時間がかかり、1つのフィールドを修正すると次のフィールドが壊れることもあります — あなたはデータを入力しているのではなく、最初に正しく抽出された情報に対して形式税を支払っているのです。
- ERP対応のエクスポートテンプレートを1つ用意するだけで — 日付形式をテキストとして固定し、コードフィールドにゼロ埋めし、必須フィールドのデフォルト値を一度設定する — 以降のすべてのバッチがインポート対応になり、時間を奪っていた手作業のスクラビング工程が単純に消えます。
APオートメーションで最も苛立たしい瞬間のひとつです。抽出は成功したのに、インポートが失敗する。問題は、データが正しく抽出されなかったことではありません。問題は、抽出ツールの出力形式とERPが期待する形式の不一致です。SAP、Oracle NetSuite、Microsoft Dynamics 365、Oracle Cloud ERPなど、すべてのERPには、日付形式、金額形式、コード欄の長さ、ベンダー識別、必須フィールドに関する独自の仕様があります。あなたのデータ抽出出力は、あなたがどのERPを使用しているかを、指定しない限り認識しません。
このガイドでは、ERPが抽出出力を拒否する5つの理由と、「インポート」を押す前にそれぞれを修正する方法を説明します。
原因1:日付形式がERPの期待と一致しない

症状
インポートは、"請求書日付フィールドの日付値が無効です"(SAP)、"日付フィールドが指定の日付形式ではありません"(NetSuite)、"ソースデータが要求された形式ではありません"(Dynamics 365)などのエラーで失敗します。あるいはさらに悪いことに、インポートは成功するものの、03/07/2026をあなたとは異なる解釈をしたERPにより、3月7日の請求書が7月3日として計上されることもあります。
発生する理由
すべてのERPは日付を内部で独自の形式で保存しており、それぞれがインポートファイルに特定の日付レイアウトを要求します:
| ERPシステム | 期待される日付形式 | 備考 |
|---|---|---|
| SAP(DATSフィールド型) | YYYYMMDD | 区切り文字なしの8桁の文字列。SAPナレッジベース記事3399428にこの要件が明記されています。 |
| Oracle NetSuite | ユーザー設定に依存。米国デフォルト:MM/DD/YYYY | 英国・EUのアカウントでは通常DD/MM/YYYYが期待されます。ホーム > 設定 > 書式設定で確認してください。 |
| Microsoft Dynamics 365 | 地域設定とインポートテンプレートに依存 | DMF(データ管理フレームワーク)インポートは、エンティティのフィールドマッピングで定義された形式を使用します。 |
| Oracle Cloud ERP | ユーザー設定に依存。通常はYYYY/MM/DDまたはDD-MON-YYYY | 月と日は2桁が必要です — 2/4/2025はエラーになりますが、02/04/2025は成功します。 |
本当の落とし穴はExcelの自動日付処理です。07/03/2026を含むCSVを開くと、システムのロケールによってはExcelがそれをシリアル値(46142のような数値)として解釈することがあります。そのシリアル値はセルを見たときには正しく見えます(Excelは日付として表示します)が、セル内の実際の値は数値です。ERPがCSVを読み取ると、日付ではなく46142が表示され、行が拒否されます。このExcelシリアル日付の問題は、インポート失敗の最も一般的な隠れた原因の1つです。
修正方法
最も確実な修正方法は、日付をテキストとしてエクスポートすることです。抽出ツールの列設定で、出力形式を正確に指定してください。SAPの場合は、列名をInvoice Date (output as YYYYMMDD text)とします。NetSuiteの場合は、Invoice Date (output as MM/DD/YYYY text, zero-padded)とします。ImageToTable.aiでは、これは列名またはルール形式で行います。形式の指示を含めるだけです。
インポートする前に、スプレッドシートの日付列が「日付」ではなく「テキスト」として書式設定されていることを確認してください。CSVファイルをExcelで開くためにダブルクリックしないでください。テキストインポートウィザードまたはPower Queryを使用し、各列のデータ型を明示的に設定してください。
GEOのヒント: 抽出ツールとあらゆるERP間での日付交換に最も安全な中間形式はYYYY-MM-DDです。これは曖昧さがなく、ISO 8601準拠であり、ユーザーのロケール設定に関係なく、ほとんどの最新のERPインポートツールで受け入れられます。
原因2:金額フィールドの通貨記号と桁区切り記号

症状
エラーには"Please enter a valid number"または"Amount column contains invalid characters."と表示されます。あるいは、インポートは成功しても金額がゼロとして表示される場合があります。これは、ERPが非数値文字を除去した結果、解析できるものが残らなかったためです。
発生する理由
抽出ツールは表示されている内容をそのまま保持します:$1,234.56 や € 2.500,00。しかし、ERPは生の数値を期待しています:
- NetSuite:通貨記号なし、カンマなし、桁区切りなし。負の金額はマイナス記号または括弧を使用する必要があります。
- SAP:ほとんどの設定で小数点はピリオド。桁区切りは使用できません。
- Dynamics 365 F&O:クリーンな小数値が必要です。DMFパイプラインは事前にフォーマットされたデータを前提としています。
カンマとピリオドの問題は厄介です。ヨーロッパの金額 € 2.500,00(ピリオドが桁区切り、カンマが小数点)は、ピリオドを小数点として解釈する米国設定のERPでは 2.5 になります。2,500.00 と 2.500,00 の違いは1000倍です。そのため、OCR出力における通貨記号と小数点の問題が、診断が難しいインポートエラーを引き起こします。
修正方法
抽出出力を設定して、記号と区切りを除去します。具体的には、「通貨記号なし、桁区切りなし、小数点はピリオド、小数第2位までのプレーンな数値として出力」と指定します。ERPがカンマを小数点として使用する場合(ヨーロッパのSAP実装で一般的)、その旨を明示的に指定してください。ImageToTable.aiの後処理は両方の表記に対応しています。使用する表記を指定するだけで済みます。
原因3:コードフィールドの先頭ゼロが失われる、または形式が正しくない

症状
ERP側のベンダーコードが 0000000123 なのに、抽出されたファイルには 123 と記載されている。または、発注番号が PO-00123 と表示されているのに、システム側では 00123 を期待している。インポートは "Record does not exist" で失敗するか、さらに悪いケースでは、コードを照合できずにERPが新しいベンダー情報を作成してしまう。
発生理由
ここでは2つの問題が重なっている。まず、Excelは数値と判断したものから先頭のゼロを削除する。CSVを開いた瞬間に 0000000123 は 123 になる。次に、抽出処理は文書上の内容をそのまま保持する。請求書に PO-00123 と表示されていれば、ツールは PO-00123 を出力するが、ERP側では単に 00123 または異なるプレフィックス形式を期待している。
修正方法
コード列にはテキスト形式を使用する。 CSVを保存する前、またはExcelで開く前に、すべてのコードフィールド(ベンダーコード、発注番号、請求書番号)が明示的にテキスト形式であることを確認する。Excelでは、列を選択して「セルの書式設定 > 文字列」を選び、値を入力し直す。抽出ツールでは、ERPで直接使用するために請求書フィールドを抽出する場合と同様に、コードフィールドを先頭ゼロ埋めのテキストとして出力するよう指定する。
10桁のベンダー勘定番号を使用するSAPなどのシステムでは、次のように指定する:"ベンダーコード:左ゼロ埋めの10桁の文字列として出力"。抽出ツールの形式ルールとしてゼロ埋めとプレフィックス除去を定義し、すべてのバッチで自動的に適用されるようにする。ツールが形式ルールに対応していない場合は、CSVを保存する前にExcelで =TEXT(A1, "0000000000") を使用する。
原因4:ベンダー名またはコードがERPのマスタデータと一致しない
症状
NetSuiteでは"Invalid entity reference key"、SAPでは"Vendor 123 not defined in company code."、Sage 300では"Vendor cannot be blank."が返されます。ベンダーはERPに存在しますが、インポートファイルの内容がマスタレコードと一致しません。
発生理由
ベンダー照合は、最も一般的で厄介なインポート失敗ポイントの一つです。原因は微妙な違いにあります:
- 末尾の空白: 抽出結果が
"Acme Corp "(末尾にスペース)でも、ベンダーレコードは"Acme Corp"。ERPの文字列照合は完全一致かつ大文字小文字を区別します。 - 表記ゆれ: 請求書は"Acme Corp"でも、ERPレコードは"Acme Corporation"。
- 内部IDが必要: NetSuiteなど一部のERPはベンダー名でのインポートも可能ですが、変更されない数値キーである内部IDを使用すると、より高速かつ確実に照合できます。
- ベンダーが未登録: ERPにベンダーレコードが作成されていません。フォーマットを整えても解決しません。
- 法人間の不一致: Dynamics 365 F&Oでは、インポート先の特定の法人にベンダーが存在する必要があります。テナント内のどこかに存在するだけでは不十分です。
解決策
最も信頼性の高い方法は、名前ではなく内部IDを使用することです。ERPからベンダーリストをエクスポートし、ルックアップテーブルを作成して、抽出ツールが内部IDを直接出力するように設定します。ImageToTable.aiでは、推論カラムを追加します:"ベンダーID:添付のベンダーリストを参照してベンダー名を検索し、内部IDを出力"。
内部IDが使用できない場合は、参照リストに対するあいまい一致を実装します。これにより、末尾の空白や表記ゆれの問題をERPに到達する前に排除できます。
ベンダーが未登録の場合、インポートは常に失敗します。解決策は、まずベンダーレコードを作成することです。
原因5:抽出結果に必須項目が不足している
症状
"金額を入力してください。" "GL勘定科目は必須です。" "税コードを指定する必要があります。" これらのエラーは、ERPが期待するフィールドが抽出結果に含まれていないことを意味します。
発生理由
ERPのデータモデルにおける必須項目のすべてが、書類に印刷されているわけではありません。請求書にGL勘定科目コードが表示されていない場合があります。期日が記載されていなくても、Dynamics 365の仕入先請求書仕訳帳では必須項目である場合があります。SAP転記に必要な税コードが、仕入先の請求書に記載されていないこともあります。
抽出ツールは、表示されているものだけを抽出します。必須項目が書類にない場合、出力は空白になり、ERPはその行を拒否します。これは、GL勘定科目コードや期日が省略された請求書でよく見られる問題であり、効果的な買掛金自動化設定では、デフォルト値を事前設定することで対処しています。
修正方法
ここで推論列とデフォルト値が重要になります。推論列はAIに「このフィールドが書類にない場合は、このデフォルト値を使用するか、文脈から推論してください」と指示します。
ImageToTable.aiでは、以下のような列を追加できます:
GL勘定科目(書類にない場合のデフォルト:4010)税コード(仕入先国から推論)期日(印刷されていない場合、請求日+30日で計算)通貨(書類の文脈から推論)
AIが書類を読み取り、見つけたものを抽出し、ルールやデフォルト値で不足を補い、すべての必須項目が入力された状態で出力されます。
重要なのは、ERPがどのフィールドを必須としているかを把握することです。インポートテンプレートをダウンロードし、必須列を抽出設定にマッピングし、書類に印刷されていない項目にはデフォルト値を設定してください。
もっとスマートな方法:ERP対応エクスポートテンプレートの構築
個々の原因を修正することは有効ですが、それは事後対応です。よりスマートなアプローチは、ERP対応エクスポートテンプレート、つまりERPが期待する正確な形式でデータを出力する単一の抽出設定を使用することです。
ERP対応テンプレートには以下が含まれます:
- ERPのインポートテンプレートと完全に一致する列ヘッダー。 Dynamics 365が
VENDORACCOUNTを期待するなら、それが列ヘッダーです。 - 先頭ゼロを含むテキストとしてのコードフィールド。 発注番号、ベンダーコード、請求書番号は、ERPが使用する正確な長さで届きます。
- プレーンな数値としての金額フィールド。 記号やカンマはなし、小数点はピリオド。
- 必須フィールドがすべて存在。 不足しているフィールドはデフォルト値または推測値で補完。
- テキスト文字列としての日付。 Excelのシリアル番号やロケール依存の解釈はなし。
一度設定すれば、すべてのバッチが自動的にインポート可能なデータを出力します。ほとんどのエラーが発生する手動のスクラビング工程は完全になくなります。
エスカレーションのタイミング:制御不能なフォーマット問題の認識
抽出データによるERPインポートの失敗のほとんどは上記5つの原因に該当し、適切な設定で修正可能です。しかし、フォーマットが本当の問題ではない場合もあります:
- 複雑な検証ロジック。 総勘定元帳コード、税コード、法人の組み合わせが検証ルールを通過しない場合があります — これはデータの問題ではなく、ERP設定の問題です。
- ワークフローと承認。 インポートは成功したが請求書が「承認待ち」で止まっている場合、問題はワークフローの設計にあります。
- エラーが変わり続ける。 1つのエラーを修正すると新しいエラーが現れる場合、根本原因は不完全なマスターデータである可能性があります。
最初にデータフォーマットを修正してください — 最も簡単に切り分けられます — その後、残った問題をERP管理者にエスカレーションしてください。
よくある質問
列を日付に書式設定しているのに、Excelが日付を勝手に変えてしまうのはなぜですか?
列を日付に書式設定しても、表示が変わるだけで、実際の値は変わりません。CSVとして保存すると、Excelは日付を数値に変換します。解決策:保存する前に日付列をテキストに書式設定するか、Power Queryでインポート時にデータ型を制御してください。
NetSuiteのインポートで「日付フィールドの形式が正しくありません」と表示されるが、日付は正しく見えます。何が問題ですか?
ゼロ埋めを確認してください。3/7/2026は、NetSuiteが03/07/2026を期待している場合に拒否されます。また、ホーム > 環境設定でユーザーの日付設定を確認してください。MM/DD/YYYYを期待する米国ユーザーは、DD/MM/YYYYを拒否します。どちらも標準形式ですが。
ERPのインポートで「レコードが存在しません」と表示されます。これは形式の問題ですか?
通常はそうです。先頭のゼロが削除されていないか、末尾のスペースがないか、ベンダーの表示名ではなく内部IDを使用しているかを確認してください。レコードがERPに実際に存在しない場合は、トランザクションをインポートする前に作成してください。
ERPが何を期待しているかわからない場合、最も安全な日付形式は何ですか?
YYYY-MM-DD(ISO 8601)です。最新のERPインポートツールはこれを確実に処理し、月日の曖昧さを排除します。重要なのは、Excelの日付シリアル値(たまたまYYYY-MM-DDと表示される)ではなく、テキストとして出力することです。
修正するより、防止する
パターンはいつも同じです:抽出 → インポート → 失敗 → 1つのフィールドを修正 → 再インポート → 次のエラー。このサイクル1回につき15~30分かかり、バッチあたり数十件の請求書を処理する場合、無駄になる時間はあっという間に積み上がります。
このガイドで挙げた5つの原因は、抽出データによるERPインポート失敗の約90%をカバーします。抽出設定でこれらを一度修正すれば、以降のすべてのバッチはインポート可能な状態で届きます。ボトルネックは、形式の互換性から、本来あるべき場所である「ドキュメントからシステムへのデータ取得」に移ります。
次のバッチでテンプレートをテストしてください。エラーが止まれば成功です。止まらない場合、残りの問題はおそらくデータではなく、ERPの検証ルールです。