ECMもIDCも使わないEpicor AP自動化には
結局ファイルが必要

3つのルートは請求書を異なる役割に分割する

ECMとIDCのみが、ドキュメント・承認・マッチングをEpicor内に保持します。他の2つのルートはこれらのステップを別の場所に置きます。この違いが、キャプチャ後に誰が例外を担当するかを決め、これはベンダーページの機能一覧よりも重要です。

しばしば一緒に販売される3つの役割を分けて考えると理解しやすくなります。キャプチャはドキュメントを読み取り、値を生成します。構造化はそれらの値をEpicorが期待するレコードに格納します。コントロールは請求書が有効で、マッチングされ、承認され、転記準備ができているかを判断します。ECMとIDCはキャプチャ、構造化、承認とマッチングのワークフローを担当します。サードパーティAPプラットフォームはキャプチャと承認作業の大部分を担います。DMTルートはキャプチャを入力として受け取り、構造化ステップのみを担当します。

DMTルートでは、唯一の新しい製品がEpicorの外にあり、その出力はファイルであり、そのファイルが統合そのものです。

ファイルは検査、照合、再実行が可能であり、これはほとんどのAPI統合がAPマネージャーに提供する以上のものです。問題はチームがそれを確実に生成できるかどうかであり、他の2つのルートは製品がその作業を担う場合の姿を示しています。

Epicor ECMとIDCが自動化する範囲と、その限界

ECMとIDCの組み合わせは3つのルートの中で最も多くを自動化し、ドキュメントリポジトリ、承認ルート、マッチングルールがすべてEpicor製品内に収まる唯一のルートです。 Epicor ECM（エンタープライズコンテンツ管理）は、導入済みの多くの顧客が今もDocStarと呼ぶ製品の現行名称です。IDC（Intelligent Data Capture）は、受信ドキュメントを分類し、そこからフィールドを読み取るレイヤーです。

EpicorのIDC製品ページでは、ニューラルネットワークによる分類、フォーマットごとのテンプレートなしで学習するフィールド、手入力データを最大90%削減できるという主張が説明されています。ECM AP Automationページには、そのチェーンの残りの部分が加わります。すなわち、キャプチャとインデックス作成、ルーティングと承認、自動2-wayマッチ（請求書と発注書）および3-wayマッチ（請求書と発注書と入荷）、そしてERPへの2-way APIです。これらを合わせて読むと、メールボックスから承認まで請求書をEpicor製品内で一貫して管理するルートが描かれています。

限界は、抽象的なキャプチャ品質ではありません。請求書がきれいにマッチしないときに何が起きるかです。IDCとECMを運用していたあるメーカーは、明細行のOCRや自動マッチングをまったく行っていないと報告しています。「当社の仕入先請求書はそもそも混沌としていて、明細行の処理はまだ試していません」（Epicor User Help Forum、2019年から2024年）。同じスレッドには、別のユーザーによるより率直な評価もあります。ECM AP Automationは「APワークフローを自動化するように作ることはできる」ものの、「その名付け方と売り込み方からすると、本来あるべき完成度には達していない」というものです。

チームがネイティブルートを見送るもう一つの理由はコストです。EpicorはECMを見積もりベースで販売しており、その金額は導入形態、ユーザー数、IDCの処理量、ワークフローの範囲によって変わります。2022年のフォーラムスレッドで、あるERPユーザーは自社プロジェクトが別の道を選んだ理由をこう説明しています。「当社の経営陣は、主にコストを理由にDOCSTARを使わないことを決定しました」。彼らは請求書を外部のOCR会社に送り、XMLを受け取り、自分たちでDMTファイルを生成していました（Epicor User Help Forum、2022年）。これは抽出優先ルートの自然な姿です。つまり、アーキテクチャ上の好みではなく、コスト判断なのです。

サードパーティ製APプラットフォームが提供するものと、追加されるもの

サードパーティ製APプラットフォームは請求書を囲むワークベンチを提供し、Epicorにどこまで踏み込むかはコネクタ次第です。ワークベンチとは、AP担当者が一日を過ごす場所であり、コーディング、ルーティング、コメント、承認者への催促、仕入先からの問い合わせ対応、場合によっては支払いまでを行います。キャプチャツールがその作業を置き換えることはなく、DMTも同様です。

統合の深さは、マーケティングの訴求以上にばらつきがあります。たとえばStampliは、Epicor統合をファイル連携と説明しており、ベンダーリスト、GL勘定、未処理の発注書、明細行、入荷データを同期し、承認済み請求書と支払情報を返します（Stampli）。ファイルの受け渡しはうまく機能することもあります。ただし、コネクタがさらに踏み込まない限り、承認時点でEpicorのライブ状態を読み取っているわけではないため、その統合で請求書を承認する前に、実行するリリースと同期するフィールドを検証してください。

このトレードオフは、範囲と引き換えに所有権を得るというものです。承認と仕入先コラボレーションを一か所で得られる一方で、請求書ステータスを保持する2つ目のシステム、2つ目の監査証跡、そしてプラットフォームが承認した内容とEpicorが転記した内容の照合を引き受けることになります。承認が複数のERPにまたがる場合や、支払いがEpicorでは十分にカバーできないシステムを必要とする場合には、価値があります。ただし、単なる入力作業の問題に対しては、規模が大きすぎるプロジェクトです。

DMTルートは統合ではなく、データ形状の判断です

DMTはEpicorのビジネスオブジェクトを通じてレコードを書き込む一括データローダーです。請求書を読み取ったり、入荷と照合したり、有効かどうかを判断したりはしません。EpicorはData Management Tool（DMT）を、レガシーERPからKineticへの移行ツールキットの一部として位置づけており、60以上の事前設計されたインポートテンプレート、ExcelおよびCSV入力、ビジネスロジックに対する検証、エラーログを備えています（Epicor）。これは別ライセンスです。Epicorの2025.2リリースノートによると、DMTは無料のPower Tools Clientにバンドルされるようになりましたが、「これらのツールを使用するには、これらの製品のライセンスが依然として必要です」。

Epicor APでは、作業単位は入力グループです。請求書はグループに入力され、Edit List（転記前のレビューレポート）でチェックされ、その後転記されて仕入先とGLレコードが更新されます。DMTはグループとその中のレコードを作成できますが、レビューや転記の判断は行いません。AP Invoice Entryと同じ検証を適用します。それでもAPワークフローではありません。これを日次のAP取り込みチャネルとして使うことは、移行ツールの転用であり、エラー処理はバッチ指向のままです。つまり、拒否された行のログであり、請求書レベルの例外キューではありません。

AP請求書のロードは通常、4つのレコードタイプを中心に構成され、GL配分は明細行と雑費行の背後にある経費レコードとGLコントロールレコードに保存されます。マッピングの会話では必ずこれらの名前が使われるため、知っておく価値があります。

正確な列セットはブログ記事ではなく、お使いのKineticリリースから生成されます。この注意書きは免責のためのものではありません。フィールド名、必須キー、更新動作はリリース間で変わり、他人の環境からコピーしたテンプレートは、一部の行だけでインポートが失敗する、気づきにくい原因の一つです。

Epicor請求書インポートが実際に失敗する箇所

最も多くの時間を費やすDMTの失敗は参照または順序の失敗であり、エラーテキストはしばしばそれをフォーマットの問題に見せかけます。メッセージはテーブルと値を示すため、その行が間違っているように見えます。実際には行は通常問題なく、その周囲のキーが問題です。以下は実務者のスレッドで繰り返し見られるものです。

仕入先の識別：名前ではなくID

DMTは、請求書に印字された名前ではなく、マスターデータのベンダーキーで仕入先を解決します。PDF上の「Acme Manufacturing Inc.」は、Epicorに存在するベンダーIDに変換されなければなりません。変換できなければロードはその行を拒否しますが、危険な対応はインポートを通すために新しい仕入先を作成することです。こうして1つの仕入先が2つのレコードになり、支出が両方に分割され、ERPは請求書番号を仕入先単位でしかチェックしないため、後に重複請求書がすり抜けます。

キーフィールド自体が混乱を招きます。AP Invoice CombinedテンプレートではVendorNumVendorIDです。Epicorサポートはある顧客にベンダー番号が必要だと伝えた一方、同じスレッドの実務担当者はベンダーIDを使用して動作したと報告しています（Epicor User Help Forum, 2021 to 2024）。ご利用のリリースで両方をテストし、列セットがどちらの識別子を持つかを一度だけ決めてください。APが両者を交互に使うことは避けてください。

列の順序とヘッダーの有無

Combined APテンプレートは列の順序に敏感です。あるユーザーは、ファイル内でVendorNumVendorIDをInvoiceNumの前に移動することで、繰り返し発生していた"A valid Invoice Number is required"エラーを解消しました（Epicor User Help Forum, 2020）。請求書番号は何も変わっていません。ローダーの処理順序が変わったのです。

Combinedテンプレートはまた、明細行が処理される前にヘッダーが作成または検出されないと、"APInvHed record not found"を発生させます。あるERPシステムマネージャーは、2017年から2020年まで続いたスレッドで、Combinedロードを「私の経験では非常に予測不能」と述べています（Epicor User Help Forum）。さらに役に立たないエラーもあります。あるスレッドではフィールド名なしで"Index was outside the bounds of the array"が報告されており、デバッグが二分探索になってしまいます（Epicor User Help Forum, 2021 to 2024）。

ヘッダー、明細行、雑費の計算

請求書明細行の金額は、そのGL配分合計と一致している必要があります。一致しない場合、Epicorは入力時に請求書明細行の金額はGL配分合計と異なることはできないというメッセージを返します。DMTファイルでも同じルールが適用されますが、エラーはフィールドレベルのメッセージなしで失敗した行として表面化することがあります。

雑費には独自の慣例があります。明細行0の雑費はヘッダーに属します。また、2つ目の雑費行が「使用禁止」トラップとして設定されたGL勘定にデフォルトで入り込むことがあると報告されており、順序とGL配分は意図的に設定する必要があります（Epicor User Help Forum, 2018）。行はロードされます。雑費は誤ったバケットに入ります。これは拒否よりも悪い状況です。インポートログのどこにも注意を促す表示がないからです。

PO請求書と入荷請求書は別のロード

発注書や入荷に関連する請求書は、統合テンプレートに確実には適合しません。UIのパスでは入荷明細行の選択ダイアログが開きますが、DMTはその操作を再現しません。実務担当者は代わりに分割した手順を説明しています。まずヘッダーを作成し、AP Invoice Receiptプロセスで入荷明細行を取り込み、その後AP明細レコードを請求書金額で更新します（Epicor User Help Forum, 2019年から2020年）。部分入荷、梱包明細書の参照、1つの請求書に対する複数の入荷は、その手順を容易にするどころか難しくします。

ここがDMTが一般的なAP受付ルートではなくなり、請求書タイプ固有のルートになるポイントです。非PO請求書と雑費請求書が自然な適合先です。PO請求書はマッチングが属する領域であり、DMTはマッチングを行いません。同じ参照整合性の問題は他のEpicorインポートでも発生しており、それがファイルが正しく見えてもPOデータがERPインポートを壊し続ける理由です。

読み込まれた行は有効な請求書ではない

DMTは、レコードがローダーの検証を通過したことを証明するだけです。仕入先が正しいこと、請求書が重複していないこと、GL配分が正しいこと、明細の合計がヘッダーと一致することまでは証明しません。あるユーザーは、およそ5回に1回のロードで最初の明細行が受け入れられた後に失敗し、残りはすべての明細行で失敗したと報告しています（Epicor User Help Forum, 2019）。バッチローダーでは部分コミットが普通に起こるため、チームは再試行の前にどの行がコミットされたかを正確に把握する必要があります。

コストがかかる障害は、きれいにインポートされてしまうものです。誤ったGL勘定に入った雑費、同じ仕入先に対する2つ目の仕入先レコード、1文字だけ異なる重複請求書番号などです。

Open Invoice Loadはこれを回避する近道ではありません。新しいシステムに期首残高を取り込むために設計されたもので、実務担当者によれば、明細やGL配分を伴わずに請求書合計のみを保持します（Epicor User Help Forum, 2019）。明細レベルの配分を必要とする運用中のAP担当にとっては、別の問題を解決するものです。

DMT対応の請求書セットとはどのようなものか

DMT対応セットとは、1つのキーを共有する複数の小さなファイルであり、請求書全体を含む1つのスプレッドシートではありません。 レコードタイプごとにロードを分割することで、各障害領域を分離できます。拒否された明細行があっても、すでにコミットされたヘッダーを再ロードする必要はありません。

データ型は列名と同じくらい重要です。日付は日付として、金額は数値として、コードは先頭のゼロが保持されるようテキストとして取り込む必要があります。小計行、結合セル、空白のスペーサー行はファイルをDMTに渡す前に削除してください。空白の意味を定義しましょう。任意フィールドの空白は問題ありませんが、必須フィールドの空白は拒否される行となり、ゼロは値です。

照合ルールは1行に書けるほどシンプルです：ヘッダーの請求書金額 = 明細の拡張原価の合計 + 税（税が別途請求される場合） + 雑費。すべての明細行と費用行は、同じグループ内に存在するヘッダーキーを持つ必要があります。請求書に印刷された合計が自身の明細行から再構築できない場合は、ロード前に停止してください。DMTは差異を説明してくれず、照合できないグループを転記すると問題が元帳に移るだけです。

DMTでは必須ではありませんが、すべての行にソース識別子を付けておきましょう。ファイル名とページ参照があれば、AP担当者はバッチ全体を開き直すことなく、拒否された行を請求書まで追跡できます。

PDFからこれらの行を構築する方法

ここでの抽出レイヤーの役割は1つだけです。各仕入先請求書を、ヘッダーがすでにDMTテンプレートと一致する行に変換することです。 これはAP自動化よりも狭い役割であり、DMTが対応を委ねている部分です。

ImageToTable.aiはカスタム列抽出を使用します。InvoiceNum、VendorNumVendorID、APInvDtl#ScrDocExtCostなど、必要な列名を入力すると、AIがページ上の意味を理解して各値を探し出します。ゾーンを描く必要も、仕入先ごとのテンプレートを維持する必要もありません。これは、仕入先が何も告げずに請求書レイアウトを変更した場合に重要です。入力した列名がそのまま出力ヘッダーになるため、エクスポートしたデータは、すべてのフィールドをリネームすることなく生成済みのDMTテンプレートに投入でき、その後テンプレートに合わせて並べ替えられます。

3つの列セットを構築し、同じバッチを3回実行します。ヘッダーセットは請求書ごとに1行を生成します。明細セットは明細行のフィールドを記述し、各行をヘッダーに紐付けられるよう請求書キーを含み、明細項目が記載されたページの明細行ごとに1行を生成します。雑費セットは運賃やその他の雑費をキャプチャし、割り当てるGL勘定の列を持ちます。バッチ処理とは、1回のアップロードに含まれるすべての仕入先請求書をまとめて1つのテーブルに処理することを意味するため、100件の請求書が100回の手動実行になることはありません。各実行は1つの列セットを使用し、こうして1つのバッチから3つのファイルが生成されます。

計算列は、ドキュメントを読み取る間に照合の一部を実行します。請求書に明細行の合計が印刷されていない場合、Qty × Unit Priceとして計算できます。検証列は、計算した合計が印刷された合計と一致する場合にOKを返し、一致しない場合はその差額を返すようにできます。計算は列名に、またはRule Format（ログインユーザー向けのJSONルールフィールド）に記述し、税率が印刷されていない場合は固定税率をそこに埋め込むこともできます。これらは読み取っているページ上の行レベルのチェックです。複数ページにまたがるヘッダー合計は、計算列がファイルをまたげないため、エクスポート後に比較する必要があります。

Bbox付きレビューモードは、DMTロードをより安全にするステップです。抽出されたセルにカーソルを合わせるかクリックすると、元の画像上でソース領域がハイライトされるため、APはファイルを構築する前にベンダーID、請求書番号、金額をドキュメントと照合して確認できます。サイレントなインポートエラーを引き起こす値こそ、この方法で確認する価値があります。Bbox注釈はファイルごとにトリガーすることも、処理後に自動実行するよう設定することもできます。

マルチページマージは、複数ページや複数の写真で届く請求書を処理します。テンプレート設定で、結果をどのようにグループ化するか（たとえば共通の請求書番号で）を選択すると、ページが1つのヘッダー行にまとめられ、フィールドはそれを含むページから埋められます。1つの請求書が複数ファイルに分割されている場合に使用し、同じ仕入先からの別々の請求書には使用しません。

以下に続く運用ループは、あえて地味なものです。

抽出レイヤーが行わないこと

抽出レイヤーはドキュメントを読み取って行を生成するだけであり、Epicor固有の判断はすべてチーム側に残ります。 この境界は明確にしておく価値があります。統合のように見えるファイルは、ツールが対応できない前提を招きやすいからです。

• ネイティブのEpicorコネクタはありません。出力はExcelまたはCSVファイルで、チームがそれをロードするか、独自の統合に取り込みます。
• DMTの実行、ロードのスケジュール、拒否された行の再試行は行いません。
• ベンダーIDを仕入先マスターと照合しません。ベンダーIDのように見える値が誤っている可能性は残ります。
• 請求書を発注書や入荷とマッチングせず、未請求の数量も把握しません。
• 請求書の承認、グループの転記、仕入先への支払いは行いません。
• GL勘定の選択、税務処理の解決、梱包明細間の原価配賦は行いません。
• ドキュメントリポジトリ、監査証跡、重複請求書のコントロールではありません。

タッチレス処理が要件であれば、このアーキテクチャは適していません。このルートが生成するのはレビュー済みの行であり、請求書が有効で、マッチングされ、承認されているかを判断するのは人です。これは実際の制約であり、同時にこのルートが1週間で試せるほど低コストである理由でもあります。

どのルートがAPデスクに合うか

最も長い機能リストではなく、実際に人手が足りていない業務で選んでください。 各ルートはキャプチャで重なり、その後で分岐するため、キャプチャ精度だけで作った候補リストではどれが合うか判断できません。

パイロットの前に経済性を試算してください。APQCの中央値である請求書1件あたり$6.00では、月1,000件の請求書で約$6,000のAPプロセスコストがかかります。明細行1件あたり$1.36では、30行の請求書で約$41の明細行コストがかかります。これらは入力時間ではなく完全なプロセスコストであるため、そのまま削減額にはなりません。ただし、どこに業務があるかは示しています。ヘッダーだけを取り込み、明細行をAPに残すルートでは、この数字の大部分に手を付けていません。

次に、正直に失敗できるパイロットを構築します。クリーンなPO請求書、一部入荷のあるもの、GLに計上された非PO請求書、運賃またはヘッダーレベルの請求を含む請求書、クレジットノート、多通貨請求書、1文字だけ異なる重複請求書を含めます。テスト会社で実行します。4つの項目を測定します。初回ロードで受け入れられた行数、照合に費やした分数、請求書あたりの例外数、各例外を誰が修正するか。例外がAP担当者に戻ってくるなら、そのルートは作業を移動しただけで、削減していません。

本番稼働前に責任者を割り当てます。ERP管理者はDMTのバージョン、テンプレート、列の順序を担当します。APリードはソース値と照合を担当します。コントローラーは承認と転記の判断を担当します。これら3つの役割が、誰か他の人がファイルを確認していると想定すると、DMTルートは静かに失敗します。

APワークフローにおける抽出の位置づけをより広く見るには、PDFから総勘定元帳までの5つのハンドオフが有用な地図です。ギャップが入力ではなく承認にある場合、承認ワークフローは別の設計課題です。また、ERPテンプレートとセマンティック抽出を比較検討している場合、テンプレート比較で各アプローチがどこで破綻するかを説明しています。

ERPアドオンなしの請求書抽出をより広く見るには、請求書処理ソフトウェアと買掛金自動化ソフトウェアをご覧ください。

FAQ

Epicor DMTは、POと入荷にマッチしたAP請求書をインポートできますか？

1つの統合ファイルとして確実にインポートすることはできません。実務担当者は、まずヘッダーを作成し、次にAP Invoice Receiptプロセスを使用して入荷明細行を取り込み、その後AP明細レコードを請求書金額で更新すると説明しています。一部入荷や1つの請求書に対する複数の入荷は、さらに手順を増やします。1ファイルでのロードを約束する前に、ご自身のリリースでこの手順をテストしてください。

AP請求書にDMTを使うにはECMやIDCが必要ですか？

いいえ。DMTは別ライセンスのツールであり、ECMに依存しません。失うのはドキュメントリポジトリ、承認ワークフロー、マッチングエンジンです。また、それらの製品が担うはずだったファイル準備と照合も自前で行うことになります。

ImageToTable.aiはEpicorに接続できますか？

いいえ。ネイティブのEpicorコネクタはなく、自動転記もできません。このツールは仕入先の請求書を読み取り、定義した列名に沿ったExcelまたはCSVの行を生成します。チームがその行をDMTテンプレートにマッピングし、Epicorでロードを実行します。

APInvGrp、APInvHed、APInvDtl、APInvMscとは何ですか？

それぞれAP請求書のグループ、ヘッダー、明細、雑費のレコードです。1つのグループが1バッチを保持し、各ヘッダーは1件の仕入先請求書、各明細行は1つの請求書明細行、各雑費行は運賃などの費用です。ヘッダーレベルの費用は行0を使用します。

重複請求書番号のロードを防ぐにはどうすればよいですか？

ロード前にベンダーキーと請求書番号を正規化し、同じ仕入先と同じ番号の既存請求書がないか確認します。Epicorは仕入先と請求書番号を比較するため、INV-5521と5521-OPSはどちらも通過してしまいます。仕入先の一致に失敗した場合でも、2つ目の仕入先レコードを作成して修正しないでください。

Open Invoice LoadはAP Invoice Entryと同じですか？

いいえ。Open Invoice Loadは期首残高向けであり、実務担当者によれば明細やGL配分のない請求書合計のみを扱います。明細レベルのコーディングとマッチングが必要な運用中のAP担当には、Open Invoice LoadではなくAP Invoice Entryのレコードが必要です。

DMTルートの隠れたコストは何ですか？

ファイル準備と照合、さらにEpicorやDMTの変更時のテンプレート保守です。ライセンスは目に見えるコストです。継続的にかかるのは、列の順序、キー、テンプレートを正しく保つためのERP管理者の時間と、各バッチをロード前に照合するAPの時間です。

インポートは簡単な部分です

DMTの請求書インポートは数秒で完了します。プロジェクトの本質は行にあります。ベンダーマスターと一致するベンダーキー、GL配分と一致する明細行合計、正しい区分に入る運賃、そしてファイルを構築する前に各値の出所を確認できるレビュアーです。ファイル準備を本当の作業と捉えるチームは、低コストで検証可能なAP受付ルートを手に入れます。単なるフォーマット作業と捉えるチームは、同じエラーをより速くインポートする方法を手に入れるだけです。

自社の仕入先請求書で試してみてください。バッチをアップロードし、DMTのフィールド名を列として定義し、Epicorに届く前に行が照合できるかを確認します。照合できれば、DMTルートは請求書の構成に有効です。できなければ、最初の本番ロードの前にそれが分かったということです。

請求書で試す →