請求書 データ化 自動化の設計図｜タイ工場で受領からERP転記までを止めない方法

タイ工場の経理担当者が仕入先の請求書をPDF、メール、紙、電子文書で受け取るとき、最初の難所は「文字を読めるか」ではありません。同じ請求書が二つの窓口に届いていないか、仕入先名がERPのどの取引先コードを指すか、税額と合計が整合するか、差異を誰が直すか、そして誰の承認後に買掛金へ転記するか。この一連の判断を設計せずにOCRだけ導入すると、入力欄は埋まっても経理の確認待ちは減りません。

本稿は「請求書 データ化 自動」を検討するタイの製造業向けに、仕入先請求書の受領、抽出、検証、例外キュー、ERP転記ゲートを一つの業務設計として解説します。投資回収の概算や三点照合の全体設計は既存記事請求書処理 自動化2026で扱っています。本稿では、受領した一枚がERPに入る直前までのデータ品質と停止条件に焦点を当てます。発注書そのものを読み取る工程は発注書OCRの設計をご覧ください。

まず決めるべき成果物は「読取結果」ではなく転記可能な請求書レコード

OCRから返るテキストは、そのまま買掛金伝票ではありません。仕入先請求書をERPに渡すには、原本への参照、取引先コード、請求書番号、発行日、通貨、税区分、明細、合計、関連する発注・入荷情報、承認者、検証履歴を紐付ける必要があります。文字列が読めても、仕入先コードが未確定なら請求先を誤る可能性があり、金額が読めても通貨が未確定なら仕訳は作れません。

そこで「データ化完了」を、単に抽出値が揃った状態ではなく、必須項目と照合条件を満たし、例外が閉じ、承認ゲートを通過してERPが受け取れる状態と定義します。ERP側の伝票番号が返って初めて転記成功です。APIへ送信した時点を成功と扱うと、タイムアウトや検証エラーで再送した際に二重登録が起こり得ます。

各レコードには原本ファイルの保存場所、受信チャネル、受信日時、文書ハッシュ、抽出モデルの版、修正前後の値、承認履歴を残します。原本は上書きせず、修正は構造化データの履歴として管理すると、後から「請求書には何と書かれていたか」と「ERPにはなぜ別の値を入れたか」を説明できます。保持期間や法定要件は対象会社の税務・法務担当と確認してください。

受領口を整理し、同じ請求書を一度だけ登録する

仕入先は請求書を共有メール、担当者個人宛てメール、紙、ポータル、EDIなど複数の経路で送ります。まずチャネルごとに到着点と責任者を決めます。個人メールをそのまま正式な受領口にすると、休暇・退職・転送漏れで請求書が見えなくなるため、共有受信箱または統制されたアップロード窓口に集める設計が現実的です。紙はスキャンの時点で受領日時と担当者を記録し、原紙の保管運用と分けて管理します。

メール添付には本文に支払案内があり、請求書PDFと納品書PDFが一つのメールに混ざる場合があります。受領処理は添付単位で文書種別を判定し、「請求書候補」を作る段階までに留めます。まだ買掛金伝票は作りません。暗号化PDF、破損ファイル、ページ欠落、解像度不足は読取キューに入れる前に差し戻します。仕入先が再送した同一ファイルはハッシュで、別形式に変えて再送したものは仕入先・番号・日付・金額の組み合わせで候補を提示します。ハッシュ一致だけで重複判定を終えると、印刷し直した同一請求書を見逃します。

重複の自動排除も強すぎてはいけません。同じ請求書番号を年度ごとに再利用する仕入先や、請求書番号の表記に空白・ハイフンを入れ替える仕入先があります。システムは「確定重複」と「要確認の類似」を分け、後者を人が原本と取引履歴で判断します。二重計上を防ぐ鍵は、受領時の候補検出、ERP転記直前の再照会、転記リクエストの冪等キーの三層です。

抽出する項目は帳票の見た目ではなくERPの入力要件から逆算する

最初にERPの買掛金登録画面または連携仕様から、必須・任意・計算項目を洗い出します。典型的には、仕入先、請求書番号、発行日、期日、通貨、税抜金額、税額、税込合計、明細ごとの品目・数量・単価、発注番号、費用部門です。ただし会社やERPの設定によって必要項目は異なるため、この一覧を導入要件と同一視してはいけません。

抽出エンジンの評価では、文字認識率だけでなくフィールド単位の正解率、明細行の取りこぼし、ページをまたぐ行の扱い、未記入欄の扱いを測ります。例えばAmazon TextractのAnalyzeExpenseは請求書・領収書の標準フィールドや明細行を返し、値の位置情報と信頼度も返します。Google Cloud Document AIのInvoice Parserもヘッダーと明細の項目を抽出します。ただしGoogleの公開プロセッサ一覧に載る言語・バージョンは限定されるため、タイ語や日本語の帳票を当然に処理できると推定せず、候補ごとに公式対応範囲と実帳票で確認します。製品の出力をERP仕様に合わせる正規化層も必要です。

仕入先名の「ABC Co., Ltd.」と「ABC COMPANY LIMITED」は同じ取引先を指すかもしれません。しかし、名称類似だけで自動的にERPコードを決めると、同名の別法人や支店を取り違えます。税登録番号、住所、銀行口座などの照合可能な情報を併用し、既存の取引先マスタと候補を照らします。候補が複数なら例外に回し、一度人が確定した別名は承認付きのエイリアスとして保存します。マスタ更新と請求書処理を同じ権限で行わせないことも大切です。

明細行がある請求書で「合計だけ取れた」を合格にしない

工場の請求書は、部材ごとの品目コード、数量、単価、値引き、運賃、税が同じ紙面に載ります。合計だけが抽出できても、購買部門が発注行へ割り付ける必要があれば業務は止まります。品目説明が長く折り返された行、複数ページにまたがる表、マイナス表記の値引き、数量単位の違いをテストデータに含めます。「読めた明細」と「発注行へ対応付けできた明細」を別の指標で記録してください。

実装では原文、正規化値、候補、信頼度、座標を別フィールドに持ちます。原文の「1,250.00」が数量か金額かは列見出しと周辺の行で変わります。疑わしい箇所を画面で原本にハイライトし、担当者が値だけでなく根拠を確かめられるようにします。後からモデルやルールを更新した場合も、古いレコードを黙って再解釈せず、再処理した版を記録します。

OCRの後に四種類の検証を置く

請求書 OCR 検証のルールは、単一の「信頼度90%以上」では足りません。信頼度はエンジンが読み取り結果に付ける値であり、事業上の正しさを保証しません。数字が鮮明に読めても、請求先が別法人なら転記してはいけません。検証を次の四層に分けると、エラーの説明と担当振り分けが明確になります。

算術検証では税額を一律の率で再計算して「違反」と判断するのは危険です。非課税や免税の取引、複数税区分、請求書全体と行単位の丸め差、値引きの順序などを会社の会計方針と原本表示に合わせて扱います。自動計算と原本に差が出たら、まずは差の理由を可視化する例外として扱い、規則が確定してから自動許容範囲を設定します。

業務検証では、仕入先マスタの状態、発注番号の存在、既登録請求書、入荷済数量、部門・勘定科目、承認限度を確認します。ただし発注のない経費請求や前払金まで同じ三点照合に通すと、正常な取引まで滞留します。取引タイプごとにルートを分け、各ルートで必要な証憑と承認者を定義します。支払口座の変更が含まれる場合は、請求書上の情報だけでマスタを書き換えず、別の確認手順に送ります。

例外キューを「人に返す箱」ではなく解決の作業台にする

請求書 例外処理の成否は、例外の種類・担当・期限・証跡を一画面で扱えるかで決まります。「OCR失敗」という一つの理由コードにまとめると、再スキャンが必要なのか、購買担当へ発注書の修正を頼むのか、経理が税区分を判断するのか分かりません。最低でも文書不備、必須項目欠落、仕入先未確定、重複疑い、算術差異、PO不一致、入荷未完了、承認待ち、ERP拒否を分けます。

例外レコードには、請求書ID、失敗したルール、原本の該当箇所、現在の候補値、担当ロール、期限、コメント、修正履歴、再検証ボタンを持たせます。担当が値を直しただけで全検証を飛ばして転記できる設計は避けます。修正後は少なくとも関係する算術と業務ルールを再実行し、状態が「未解決」から「解決済み」に変わった理由を残します。仕入先への差し戻しも「依頼済み」で放置せず、再送待ちの日数を見える化します。

優先順位は金額の大小だけでは決めません。支払期日、月次締め、止まっている生産材料、取引先の重要度、重複計上リスクを考慮します。一方で、承認待ちの担当者へ毎日同じ通知を送るだけでは解決しません。どのルールで止まったか、何を見れば解決するかを通知に書き、期限超過時のエスカレーション先を事前に定めます。

例外率はモデル精度の点数ではなく業務設計の信号

例外件数が多い原因は、読取モデルの弱さだけではありません。仕入先が複数様式を使う、PO番号の記入規則がない、入荷処理が請求書より遅い、ERPマスタに別名がない、許容差のルールが未承認など、上流の運用にもあります。例外を理由別・仕入先別・発注部門別に集計すれば、どの問題をシステム改修で直し、どれを仕入先との運用調整で直すべきか分かります。

例外を減らすために閾値を無制限に緩めるのは危険です。まず誤検出と真の差異を分け、正常な取引だけに絞った許容条件を文書化します。例外率が下がっても、後から二重計上や誤った税区分が増えれば成功ではありません。件数と同時に転記後訂正件数、支払差戻し件数、未解決日数を見る必要があります。

ERP連携は「送信前」「送信時」「送信後」の三つのゲートに分ける

ERP 請求書連携で最も避けたいのは、画面では成功と見えたのにERPには入っていない状態、またはリトライで二つの買掛金伝票ができる状態です。送信前ゲートでは、原本・必須項目・重複候補・承認・勘定設定・税区分・関連PO/入荷の検証がすべて終了しているかを確認します。さらにERPが受け付けるマスタコード、桁数、日付形式、通貨コードへ変換します。この時点で内部レコードをロックし、同じ版を送信します。

送信時には自社側の一意の請求書IDを冪等キーとして持たせます。ERP側に外部参照番号を保存できるなら、その番号で重複照会します。APIがタイムアウトしても「失敗」と断定してすぐ再送せず、外部参照番号または請求書属性でERPの結果を確かめます。ERP APIに冪等機能がない場合は連携側で送信状態を永続化し、再実行時に人が照合できる状態にします。

送信後ゲートは、ERPが返す伝票番号と状態を受け取り、元の請求書レコードへ保存する工程です。ERPの受理応答だけでなく、非同期処理なら最終的な登録結果まで確認します。拒否された場合はERPエラーを例外キューへ戻し、入力値を修正して再検証します。取り消し・再転記には元伝票との関連を必ず残します。これが「ERPに送った」ではなく「ERPに正しく登録された」を測る条件です。

タイのe-Tax Invoiceと仕入先請求書のデータ化は混同しない

紙やPDFを受け取って社内ERPへ入力する取り組みと、税務当局の要件に沿って電子税務文書を作成・送信する仕組みは、同じ「電子化」という言葉で呼ばれても役割が異なります。ETDAのFAQは、e-Tax Invoice / e-Receiptの文書例として電子ファイルにデジタル署名を付けて買い手へ渡す形を説明し、歳入局へのデータ送信には所定のXML形式が必要だと説明しています。仕入先が送ったPDFをOCRしただけで、正式なe-Tax Invoiceへ変わるわけではありません。

受領する文書がe-Tax Invoiceに該当する場合は、税務・経理担当が文書種別と必要な検証を判断します。ETDAのTEDA Web Validationは、PDF/PDF-A-3やXMLの電子文書について、電子署名・タイムスタンプや構造の信頼性を検証する仕組みを案内しています。画像OCRの正解率と電子署名の有効性は別の検証です。導入時は歳入局のe-Tax関連情報と自社の税務運用を確認し、署名検証や保存ルールをワークフローのどこに置くかを定めてください。この記事は個別の税務判断を代替するものではありません。

国外の親会社とデータを共有する場合も、ERP転記前に原本をどの国・どのシステムで保存し、誰が閲覧でき、修正履歴をどう出力するかを決めます。クラウド製品を選ぶ際は利用可能地域、アクセス制御、ログ、データ削除、再学習への利用条件を契約・技術資料で確認します。製品の一般的な宣伝文句で自社の帳票や規制への適合を判断しないことが重要です。

PoCでは「読取率」だけでなく、転記ゲートを通る率を測る

実証実験に使う請求書は、きれいなサンプルだけでは不十分です。実際に処理する仕入先・チャネル・言語・ページ数・金額帯・税区分を代表するデータを選び、個人情報や機密情報の取り扱いを整理します。PO付き部材、発注なし経費、値引き、運賃、複数明細、再送、クレジットノート、スキャン品質の悪い紙を含めます。評価データの正解値は経理と購買が共同で確定し、判断不能な原本は「不明」と明示します。

指標は少なくとも、受領件数、文書分類の正解率、必須フィールドの正解率、明細行の完全性、仕入先マスタの確定率、例外率、例外解決時間、ERP転記成功率、転記後訂正件数を分けます。OCR精度が高くても、請求書番号の誤読が重複照会を失敗させれば、転記可能率は下がります。逆に一部の文字に誤読があっても、業務上必要な項目が確実に検証されれば処理できる場合があります。単一の総合点にせず、どの段階がボトルネックかを示してください。

例示計算：月1,000件を処理する工場の場合

以下は実績値ではなく、設計の算術を確かめるための仮定です。月1,000件の請求書のうち、初回抽出後に850件が検証を通過し、150件が例外キューへ入るとします。例外150件のうち、担当者が100件を月内に解決し、50件は翌月へ残ります。すると月内に転記ゲートへ進めるのは850＋100＝950件であり、初回の自動通過率は85%、月内の処理到達率は95%、月末の未解決率は5%です。人が介入せずERPに転記された件数は別途数える必要があり、850件と自動的に同じとは限りません。承認やERP拒否で止まる件数があり得るからです。

同じ例で抽出モデルだけを改善し、初回検証通過が900件になったとします。それでもERPマスタ未整備で200件が転記時に止まるなら、月内の実績は良くなりません。PoCの合格条件は「抽出が読める」ではなく、対象の請求書タイプについて、定義した品質・承認・連携条件でERP伝票番号まで追跡できることに置きます。自動化率を報告するときは分母を受領件数とし、例外解決後の転記率や人手なし転記率と混同しないようにします。

さらに試験結果を「なぜ止まったか」まで説明できる形で残します。例えば同じ仕入先の二十枚で請求書番号が毎回誤読されるなら、帳票ごとの読取設定か原本品質の問題かもしれません。一方、番号は正しく読めてもERPの取引先コードが見つからないなら、マスタ整備の問題です。両者を一つの失敗率へ混ぜると投資判断を誤ります。試験表には原本の種類、抽出値、正解値、失敗した検証ルール、担当者が行った修正、ERPの応答を同じ請求書IDで並べます。これにより、製品の設定で直るものと、購買・経理の運用を変えるものを分けて議論できます。

PoC中に例外を人が解決する時間も記録します。読み取りが数秒で終わっても、仕入先へ再送を依頼して三日待つ案件は、月末締めの遅れに影響します。逆に、原本の該当行が画面で即座に見えるようになれば、同じ例外件数でも一件当たりの確認時間は短くなります。少なくとも、初回検証までの時間、例外を割り当てるまでの時間、担当者が実際に作業した時間、外部回答を待った時間、ERPの最終登録までの時間を分けて測ります。これらは同じ「処理時間」でも改善策が異なります。

評価対象から除外した帳票の条件も公開します。例えば多言語の手書き請求書をPoCから外したなら、結果を「全仕入先に適用可能」と表現してはいけません。特定の仕入先や帳票様式だけで高い通過率が出た場合は、その範囲に限定した導入計画を示します。反対に難しい帳票ばかりを集めた試験なら、全体の月間率と混同しないよう、その位置づけを説明します。根拠となる原本と評価表を残しておけば、次のモデルや別のサービスを試すときにも同じ条件で比較できます。

導入順序：全仕入先を一度に載せない

最初の範囲は、月間件数が十分あり、帳票様式と取引ルートが比較的安定し、ERPマスタが整っている仕入先群から選びます。まず受領チャネルを統一し、重複候補検出と原本保存を運用します。次にヘッダー項目の抽出と人手検証を開始し、例外理由を集めます。その後、明細行・PO/入荷照合、承認、ERP転記へ範囲を広げます。段階を分けるのは、検証なしの自動転記を早めるためではなく、各段階で誤登録の原因を特定できるようにするためです。

導入前に合意しておきたいのは、仕入先エイリアスの承認者、金額差異の許容範囲、発注なし請求の扱い、税区分の判断者、ERP側の取消方法、月次締めの例外処理です。これらが未決のまま開発へ進むと、画面やモデルを作った後で業務ルールを追加することになり、例外が個人メールとExcelへ流れます。現場で実際に使われる仕組みは、経理・購買・倉庫・IT・内部統制が同じ状態定義を使える仕組みです。

運用開始後は週次で例外上位を見直します。「どの仕入先のどの項目が止まるか」を確認し、帳票受領ルール、マスタ、抽出設定、照合ルールのどれを直すかを決めます。月次では、転記後訂正と重複候補の見逃しを監査します。モデルを変更するときは、過去の代表帳票で回帰確認し、改善した項目と悪化した項目を記録します。現場からの訂正を無条件に学習データへ入れず、正しい修正かをレビューする運用が必要です。

現場の役割分担を状態ごとに決める

請求書を受け付けた人がすべての誤りを直す設計では、業務が特定の経理担当に集中します。「仕入先の正式名称が不明」は購買、「入荷数量が未登録」は倉庫、「税区分の判断」は経理、「ERP APIの拒否」はITというように、例外理由ごとに一次担当を決めます。ただし最終的な買掛金計上の責任者は別途明示し、担当をたらい回しにしないための管理者を置きます。部署をまたぐ例外では、どちらが次の行動を持っているかを一つの状態値にします。

状態名は現場の言葉で定義します。例えば「受領済み」「抽出済み」「検証中」「仕入先確認待ち」「購買確認待ち」「承認待ち」「転記待ち」「転記済み」「取消済み」です。「処理中」という曖昧な状態が長く続くと、滞留の原因を分析できません。各状態の入口条件、出口条件、操作できるロール、SLA、差戻し先を運用表に書きます。期末だけ例外的に急ぐ業務があるなら、その例外承認を通常承認と区別して記録します。

設計時に準備する最小データセット

PoC前には、対象仕入先の原本サンプル、ERP取引先マスタ、POと入荷のサンプル、過去の重複・差戻し事例、買掛金入力項目一覧を揃えます。原本とERP伝票を後から突合できる共通IDがなければ、成功率を測れません。サンプルは成功例だけでなく、過去に人が電話やメールで解決した例を入れます。現場が「どこで止まるか」を説明できるものほど、ルール設計の材料になります。

実際の文書を外部製品に渡す前には、契約で許された利用目的、保存地域、アクセス権、削除手順を確認します。評価用に個人情報や銀行口座を隠すと、逆に本番で必要な検証ができなくなる場合があります。その場合は匿名化したダミー文書を別に用意して操作性を試し、実帳票でしか判断できない精度評価は権限と保管条件を整えた環境で行います。評価環境と本番環境のデータの流れも図にしておくと、承認が必要な箇所が見えます。

システム選定で確認する質問

「請求書を読めますか」だけでは製品を比較できません。複数ページの明細をどう返すか、項目ごとの信頼度と原本座標を取得できるか、仕入先別の補正ルールを管理できるか、修正履歴を出力できるか、タイ語・英語・日本語が混在した実帳票をどう扱うかを確認します。さらに、ERPへの再送時に重複を防ぐ方法、例外の担当振分と期限通知、APIのエラーを現場向けの理由へ変換する方法を聞きます。デモでは自社の難しい帳票を使い、担当者が原本に戻って根拠を確かめる操作まで試してください。

見積では「一枚あたりの読取料金」以外に、チャネル連携、文書保存、仕入先マスタ整備、例外画面、ERP接続、テスト、保守の費用を分けます。初期の例外率が高いと、人手の解決工数が想定より大きくなります。反対に、仕入先側の送付ルールを揃えるだけで抽出設定の保守が軽くなる場合もあります。価格表だけで判断せず、対象帳票の分布と業務ルールを添えて比較することが重要です。

発注・購買のデータと境界をつなぐ

請求書のデータ化は、仕入先から届く文書の入口を整える仕事です。発注書の作成・承認・OCRや入荷実績の登録は別の仕事ですが、照合キーは共有します。請求書側でPO番号が読めたとしても、ERP側でそのPOが閉じている、別通貨である、納品数量が更新されていない、といった状態なら自動転記は止めるべきです。ここで必要なのは、人が曖昧な一覧を探し回る画面ではなく、どのキーが不一致で、どの部門が元データを直すべきかを示す例外です。

発注書の抽出精度を上げたい場合は発注書OCRの設計を参照してください。請求書処理全体の費用対効果や三点照合の設計を比較する場合は請求書処理 自動化2026に整理しています。このページは両者の間にある「受領した請求書を信頼できるERP入力データへ変える」という範囲を担当します。

よくある導入上の疑問

仕入先からPDFが届くなら、紙のスキャンをやめれば十分ですか

PDFで受け取るだけでも、紛失や再スキャンの手間は減ります。しかしPDFは人が読むための見た目を持つファイルであり、ERPが必要とする取引先コードや勘定科目を必ず含むわけではありません。同じPDFが複数回送られることもあります。したがって、受領チャネルの統制、重複候補の検出、項目抽出、業務検証、承認履歴という工程は残ります。仕入先が構造化データを送れる場合は、OCRを介さずそのデータを使えるかも検討します。ただし、その場合もデータの真正性や取引との整合を確認する必要があります。

信頼度が高い項目だけを自動転記できますか

一部の項目を自動採用することは可能ですが、信頼度の数値をそのまま転記許可と結び付けるべきではありません。例えば「請求書番号99%」でも、似た文字の1桁違いは重複照会に重大な影響を与えます。一方、仕入先住所の一部に誤読があっても、法的名称とマスタコードが別の根拠で確認できれば処理できる場合があります。各項目の誤りが引き起こす業務リスクに応じて、原本照合が必要な条件を決めます。項目単位の信頼度は、どこを先に人が見ればよいかを示す優先順位として使うのが実務的です。

既存ERPにAPIがなければ自動化できませんか

APIがなくても、ERPが受け付けるCSVやインポート機能があれば連携の余地があります。ただしファイル出力を「成功」と扱わず、ERPへの取り込み結果を確認して伝票番号とエラーを元レコードへ返す仕組みが必要です。手動インポートなら、どの版のファイルを誰がいつ取り込んだかを記録します。画面操作を自動化する方法もありますが、画面変更や途中停止に弱いため、二重入力防止と結果照合を先に設計します。どの接続方式でも、送信前後のゲートを省いてはいけません。

仕入先に帳票様式の統一を求めるべきですか

すべての仕入先に一つのレイアウトを強制できるとは限りません。ただし、発注番号を必ず記載する、再送時は件名に再送と付ける、請求書と納品書を別ファイルにする、といった小さな送付ルールは、抽出エンジンを替えるより例外を減らす場合があります。まず主要仕入先の例外理由を集計し、双方に負担の少ないルールから相談します。様式変更を依頼する場合は、旧様式との併用期間とテスト日を決め、切り替え前後の請求書が混在しても取りこぼさないようにします。

経理とITのどちらが運用を持つべきですか

業務ルールと最終的な仕訳の責任は経理が持ち、接続・監視・権限・障害対応はITが支える分担が一般的です。ただし、組織ごとに購買やシェアードサービスの役割は異なります。大切なのは、モデルが誤読したとき、仕入先マスタが古いとき、ERPが拒否したとき、それぞれ誰が原因を判定し、どの担当が直し、誰が再送を許可するかを明記することです。運用開始後の例外会議に経理だけでなく購買・倉庫・ITが参加すると、OCRの調整では直せない上流の問題が見えます。

日次運用では何を監視すればよいですか

日々の監視項目は、受領した件数、分類待ちの件数、検証を通過した件数、理由別の未解決件数、承認待ちの最古日数、ERP転記待ちの件数、転記エラーの件数です。受領したのにどのキューにも表示されない文書が最も危険なので、メールやポータルの受信ログと請求書候補の件数を突き合わせます。月末には受領件数と転記済み・取消済み・未解決件数が説明できるかを確認します。単に処理件数が増えたことだけでなく、取引がどの状態にあるかを一枚ずつ追えることが重要です。

障害時の手順も決めておきます。OCRサービスが停止したら原本を安全に受け付け続け、復旧後に再処理できるか。ERP APIが停止したら転記待ちを保持し、同じレコードを二度送らないか。承認者が不在なら誰へ代理権限を委ねるか。すべてを完全自動で解決する必要はありませんが、手動対応した事実と元の請求書IDを記録しなければ、後日の照合が難しくなります。手動入力した伝票も自動処理の台帳へ紐付けて、二重転記の対象として検査します。

抽出モデルの変更をどう管理しますか

帳票レイアウトが変わると、これまで正しく読めたフィールドが突然別の列を拾うことがあります。モデルやプロンプト、仕入先別ルールを変更する際は、代表的な成功例だけでなく、過去に誤読した原本、値引きのある帳票、複数ページ、類似した請求書番号を含む回帰セットを通します。変更前後で項目正解率だけでなく、例外理由の分布とERP転記ゲートの通過率を比較します。もし改善した仕入先と悪化した仕入先が分かれるなら、全社一斉適用ではなく対象仕入先を限定して公開します。

変更の記録には、適用日時、対象帳票、担当者、承認者、戻し方を残します。抽出値に変更があっても、既に承認・転記済みの伝票を自動で書き換えてはいけません。既存伝票の訂正が必要なら、ERPの訂正手順と監査証跡に沿って別作業として扱います。AIのモデル更新と会計伝票の修正は、権限も影響も違うためです。

最初の相談では何を用意すればよいですか

すべての仕入先の請求書を集める必要はありません。まずは主要な三〜五種類の帳票を匿名化し、各様式について通常例と困った例を一つずつ用意します。月間件数、届く経路、ERPの入力画面、POや入荷との照合方法、よく起きる差戻し理由も分かる範囲で十分です。実数が未集計なら、直近一週間だけ受領件数と処理時間を数えても、PoCの範囲を考える材料になります。大切なのは「OCRが何を読むか」より、「どの状態になれば経理が安心して転記できるか」を関係者と共有することです。

試験に使う帳票は、公開資料へそのまま載せず、仕入先名、銀行口座、担当者名、価格などの機密項目を適切に伏せます。一方で、伏せた結果として明細の配置や請求書番号の形式が変わると、読取評価の意味が薄れます。匿名化の方法を事前に決め、精度の確認に必要なレイアウトを残したサンプルと、権限を絞った実帳票の試験を使い分けてください。

まとめ

「請求書 データ化 自動」の成否は、OCRが何文字を読めるかでは決まりません。受領経路を統一し、原本と構造化値を紐付け、文書・項目・算術・業務の四層で検証し、例外を担当者と期限まで含めて閉じることが必要です。ERPには承認済みの一意なレコードだけを送り、返ってきた伝票番号まで確認します。タイのe-Tax Invoiceに関する文書の信頼性確認は、OCRとは別の検証として扱います。

TOMAS TECHでは、タイ工場の請求書サンプルとERP入力要件を一緒に整理し、どの仕入先・帳票から始めると効果を測れるかを設計します。現行フロー、例外の理由、ERPの転記条件を確認したい場合はお問い合わせからご相談ください。最初の相談では、実際の帳票を匿名化したサンプル、月間件数、主要な例外理由があると具体的に検討できます。

参考情報

• ETDA: e-Tax Invoice & e-Receipt FAQ — 電子税務文書と歳入局向けXMLの説明。
• タイ歳入局: e-Tax Invoice / e-Receipt — 制度・運用の公式入口。
• ETDA: TEDA Web Validation — 電子署名等を含む電子文書検証の案内。
• Amazon Textract: Analyzing Invoices and Receipts — AnalyzeExpenseのフィールド、明細、信頼度の仕様。
• Google Cloud Document AI: Processor list — Invoice Parserの抽出項目と対応言語・版。