省略されている確認工程
購買の現場では、注文書・納品書・請求書の 3 つを突き合わせる「三点照合」が基本とされています。発注したとおりに納品され、納品されたとおりに請求されているかを確かめる工程です。
ところが実際には、この確認は時間がかかりすぎるために省略されがちです。納品書の束と請求書を並べて、明細を 1 行ずつ照らし合わせる作業は、月末の忙しい時期に確保できる時間ではありません。結果として「請求書に書かれた金額を信じて支払う」運用になり、過払いが起きても気づけない状態が続きます。
これは担当者の怠慢ではなく、確認のコストが確認から得られる利益を上回っているという合理的な判断の結果です。だからこそ、精神論ではなく仕組みで解く必要があります。
突合で見つかるのは、過払いだけではない
突合を仕組み化すると、次のような差異が拾えるようになります。
- 単価の相違: 合意した単価と違う単価で請求されている
- 数量の相違: 納品されていない数量が請求に含まれている
- 重複請求: 同じ納品に対して 2 回請求が来ている
- 請求漏れ: 納品したのに請求が来ていない（受け取る側では自社の売上漏れ）
- 納品記録のない請求: 納品書が見当たらない請求がある
支払う側にとっては過払いの防止ですが、受け取る側にとっては請求漏れの発見でもあります。片側だけに存在する帳票が並ぶことに価値があります。
突合が始められない理由は、たいてい前提の不備
突合の自動化がうまくいかない現場を見ると、照合ロジックそのものより手前で止まっていることが多くあります。前提として次の 3 つが揃っている必要があります。
1. 帳票の種別が確定していること
その PDF が納品書なのか請求書なのかが確定していないと、そもそもどちらの側に置くかが決まりません。ファイル名が「scan_001.pdf」のまま共有フォルダに並んでいる状態では、種別の判定を人がやることになります。
2. 取引先が確定していること
「株式会社○○」「（株）○○」「○○商事」が同じ会社として扱われていないと、突合の相手が見つかりません。表記の揺れを吸収して同じ取引先へ結びつける仕組みが前段に必要です。
3. 突合に使う値が確定していること
読み取った値が未確認のまま突合すると、読み取りの誤りが「差異」として大量に出ます。本当の差異が誤読のノイズに埋もれて、結局すべて目視することになります。確認が終わっていないセルが残っている状態で照合を始めない、という制御が要ります。
DropOCR では、この 3 つが揃っていない場合、照合を始める前に警告として表示します。前提が崩れたまま出た「一致」を信じてしまう事故を避けるためです。
差異は合計ではなく明細まで降ろす
合計金額が一致しないことが分かっても、それだけでは何もできません。取引先へ問い合わせるには「どの行の何がずれているか」が要ります。
- 数量が違うのか、単価が違うのか
- 片方にしかない行があるのか
- 端数処理や消費税の計算方法の違いによる差なのか
最後の項目は実務でよく出ます。明細ごとに消費税を計算して合計する方式と、合計に対して消費税を計算する方式では、端数が数円ずれます。これを毎回「差異」として人に見せると、本当に見るべき差異への注意が薄れます。許容する差の幅を決めておき、その範囲は差異として扱わない、という運用が必要です。
月締め請求という難所
日本の商習慣では、月内の納品をまとめて 1 通の請求書にする月締め請求が広く使われています。この場合、1 通の請求書に対して複数の納品書が対応するため、1 対 1 の突合ではなく n 対 1 の突合になります。
ここは実装として難しく、対応していない製品を「対応している」と誤認したまま導入すると、運用開始後に破綻します。DropOCR の現時点の照合は 1 対 1 の突合が対象であり、n 対 1 の月締め照合は実際の運用データを確認したうえで対応を検討する段階です。できないことをできると書かないのは、導入後の落胆を避けるためです。
検討時には、自社の請求がどちらの形式かを先に確認してください。都度請求が中心なら 1 対 1 で足ります。
差異が出たときの対応フロー
突合を仕組みにすると、次は「差異が出たあと何をするか」を決める必要があります。ここが決まっていないと、差異のリストが溜まるだけで支払いは従来どおり進みます。
- 分類する: 誤読による差異か、実際の取引上の差異か。元帳票へ戻って確認する
- 金額の閾値で扱いを変える: 数円の端数差と数万円の差を同じ手順で扱うと、確認が回らなくなる
- 問い合わせるか、内部で処理するか決める: 値引き合意など理由が判明しているものは、記録だけ残して処理する
- 支払いを保留するかを決める: 差異があるものだけ保留し、他は通常どおり進める
とくに 2 番目は最初に決めてください。すべての差異を同じ重さで扱う設計にすると、端数の差に時間を取られ、本当に見るべき差異への注意が薄れます。
発注データがあるなら、三点照合まで届く
注文書のデータが社内にある場合、突合は 2 点ではなく 3 点で見られます。
- 注文 対 納品: 発注したものが、発注したとおりに届いたか
- 納品 対 請求: 届いたものが、届いたとおりに請求されているか
- 注文 対 請求: 発注していないものが請求されていないか
3 番目は、購買の統制としてもっとも重要です。発注を経ずに購入された取引（いわゆる事後承認）が請求書として上がってくるのを検知できます。これは金額の誤りではなく、購買プロセスそのものの問題を示す信号です。
自社の注文データが基幹システムにあるなら、そこから出力して突き合わせる形が取れます。注文書も帳票として受け取っている場合は、注文書も同じ仕組みで取り込んでおけば、3 点が揃います。
突合の頻度をどう決めるか
月末にまとめて突合すると、差異が見つかっても支払期日まで時間がありません。取引先へ確認する余裕を作るには、届いた時点で突合する方が有利です。
メール転送での取込と組み合わせると、請求書が届いた時点で自動的に取り込まれ、該当する納品書との突合が可能な状態になります。月末に 80 件の差異を一度に見るのと、届くたびに 1 件ずつ見るのとでは、後者の方が確実に処理できます。
突合を「跡が残る工程」にする
仕組み化のもう 1 つの効果は、確認した事実が記録として残ることです。属人的な「担当者が目で見て問題ないと判断した」から、いつ誰が何を確認したかが残る工程へ移せます。
この記録は、監査や引き継ぎの場面で効きます。担当者が異動しても、その月に何をどう確認したかを示せます。差異があったが確認のうえ問題なしと判断したもの（値引き合意があった、など）も、その旨を記録として残せる形が望ましいです。
導入の進め方
いきなり全取引先を対象にせず、次の順番が現実的です。
- 取引金額の大きい上位数社から始める。効果が大きく、差異が出たときの影響も把握しやすい
- 1 か月分を並行運用する。従来どおりの確認も残したまま、突合結果と突き合わせて信頼できるか確かめる
- 許容する差の幅を決める。端数の扱いを含めて、何を差異として扱うかを合意する
- 対象を広げる
まとめ
納品書と請求書の突合は、価値が高いと分かっていながらコストの都合で省略されてきた工程です。自動化の要点は照合ロジックそのものではなく、帳票種別・取引先・値の確定という前提を先に揃えることにあります。
DropOCR は帳票種別の自動分類と取引先の自動識別を前段に持つため、照合のための準備作業は基本的に発生しません。差異は明細行のレベルまで表示され、そこから元の帳票へ戻れます。