請求書のOCR結果は、台帳へ確定する前に、原本と必要項目を照合する候補として扱います。日付や金額がそれらしい形式でも、読み間違いがないとは限りません。
必要な項目と、見つからない場合の扱いを決める
取引先、請求番号、発行日、支払期日、通貨、金額など、台帳に必要な項目を決めます。税や会計上の判断までOCRへ任せず、社内の確認担当へ渡します。個別の税務処理をこのworkflowだけで確定しないようにします。
抽出結果の設計例
file_id：原本の識別ID
invoice_number：読めた請求番号
issue_date：発行日候補
currency：通貨候補
total：合計候補
missing_fields：見つからない項目
review_status：未確認 / 照合済み見つからない値を、AIが推測した値で埋めないようにします。空の項目を残して確認待ちへ送る方が、誤った日付を確定するより修正しやすくなります。
ファイル取得・文字抽出・項目整理を分ける
n8nで原本を取得し、対応するOCRや文書処理サービスへ渡し、その結果を必要な項目へ整理する構成にします。PDFに文字が入っている場合と、画像を読み取る必要がある場合で手段が変わります。
ファイルの扱いはn8nのBinary dataで確認できます。外部サービスへ渡す場合は、入力の保存・利用条件と会社の許可範囲を先に確認します。
原本を開いて、金額と日付を照合する
| 見間違いやすい箇所 | 確認方法 |
|---|---|
| 合計と小計 | 原本のラベルと対応させる |
| 発行日と支払期日 | 項目ごとの意味を照合する |
| 桁・小数・通貨 | 値だけでなく表記と単位を読む |
| 請求番号の文字 | 数字と英字、先頭0を原本で確認 |
合計の検算で不一致を見つけることはできますが、一致していてもすべてが正しく読めた証明にはなりません。原本と候補を同じ画面や確認票へ並べます。
登録後のIDを残し、再処理で二重計上しない
照合された版だけを試験台帳へ登録し、原本IDと登録結果IDを対応させます。請求番号が空、同じ番号が別の取引先にある、同じ原本を再送した場合も試験へ入れます。
最初は架空の少数の請求書で、抽出と確認の流れを点検します。保存済み原本の再処理は、二重実行の防止と組み合わせてください。