請求書のOCRを入れて一年が経つ。読み取り精度は提案どおり出ている。それでも経理の月末は前と同じ時間まで灯りが点いている。担当者に聞くと、答えはたいてい似ている。読み取った内容を直す作業はたしかに減った。減っていないのは、発注と数量が合わない、単価が違う、検収が入っていない、そういう請求書を一件ずつ調べて関係部署に確認する作業のほうだ。OCRは入力の速度を上げる道具であって、合わないものを合わせる道具ではない。 支払業務の時間はもともと入力ではなく照合と例外に張り付いており、そこには一枚も手が入っていない。
99%は、請求書1枚あたりの精度ではない
導入検討の最初に、この計算を当てる。
読み取り精度が語られるとき、その分母はたいてい項目である。請求日、請求書番号、取引先名、登録番号、税率別の対価の額、消費税額、明細の品名、数量、単価、金額。1枚の請求書から抽出する項目は、明細1行の単純な書類でも10前後になる。
項目ごとの正解率が99%で、各項目が独立に判定されるなら、1枚のすべての項目が正しい確率は0.99の10乗、すなわち90.4%になる。10枚に1枚は、どこか1項目が人の目に戻る。項目が20なら81.8%、明細20行に各5項目で100項目なら36.6%である。
業種によっては、この差が決定的になる。 建設資材や医薬品の卸のように明細行が数十行に及ぶ請求書を扱う会社では、伝票単位の完全一致率は5割を割ることがある。逆に、明細1行・毎月同額の請求書が大半を占める業種なら、90%台が現実的に出る。
したがって、導入の効果見積りは項目精度ではなく自社の請求書1枚あたりの平均項目数から始める。過去3か月の受領請求書を50枚抜き出して項目数を数えるだけで済む作業で、これを飛ばした試算はまず外れる。
もっとも、これはまだ前哨戦にすぎない。仮に伝票精度が100%でも、次の工程は動かない。
詰まるのは読み取りではなく、三面照合の例外である
支払業務の中核は、発注書、入庫記録、請求書の三つを突き合わせる工程にある。金額と数量が三つとも一致すれば、承認も支払も機械的に進む。合わなければ止まる。
SAPのロジスティクス請求書照合では、この止め方が設定として作り込まれている。許容差異キーは会社コード単位にトランザクションOMR6で上限・下限を設定する。数量差異はDQとDW、価格差異はKW・PP・PS、発注価格数量差異はBR・BW、納期差異はST、金額のチェックはANとAP、小額差異の自動許容はBD、包括発注に対する差異はLAとLD、移動平均価格の変動幅はVPが受け持つ。BDとVPを除き、上限を超えて転記された請求書は支払ブロックの状態になり、MRBRで解除するまで支払プログラムには乗らない。
注目すべきは、この一覧に読み取り精度に関するキーが一つもないことだ。 差異は、請求書の内容が正しく読めていても発生する。むしろ正しく読めているからこそ、発注と合っていない事実が可視化される。
例外の型を並べると、発生源が経理の外にあることがはっきりする。
| 例外の型 | 主な発生源 | ERP側の設定で吸収できるか |
|---|---|---|
| 単価が発注と違う | 購買。価格改定が発注に反映されていない | 一定幅までは許容差異で吸収できるが、恒常的なら発注の直しが本筋 |
| 数量が入庫と違う | 現場。検収の未入力または遅れ | 吸収できない。検収の入力タイミングを直す以外にない |
| 単位が違う | マスタ。発注単位と請求単位の換算が未設定 | 品目マスタの単位換算で恒久的に解消できる |
| 分割納品で1請求 | 取引条件。納品と請求のサイクルが揃っていない | 検収基準の請求書照合を使えば吸収できる |
| 送料・手数料の後乗せ | 購買。発注に含めていない付帯費用 | 発注に付帯費用の行を持たせるか、少額として許容幅で吸収 |
| 発注書がない | 購買統制。そもそも発注を起票していない | 吸収できない。三面照合が成立しない |
一番下の行が本丸である。順に見ていく。
照合をERPの外に置くと、鮮度差が差戻しを生む
導入の設計でよくあるのが、OCRツール側で三面照合まで済ませ、通ったものだけをERPへ連携するという構成だ。ERPの伝票入力を減らせるので、一見すると効率がよい。
だがこの構成には、避けられない弱点がある。照合の判定に使う発注残と入庫データが、ERPからのコピーである点だ。
日次でコピーしているなら、判定は最大1日古いデータで行われる。そして購買の現場では、単価改定の発注反映も検収の入力も、後追いになるのが普通である。夕方に検収が入った品目について、翌朝のコピーには入庫が載っていない。外側のツールは「数量が合わない」と判定して差し戻す。差し戻された請求書を経理が調べると、ERPでは合っている。この一往復が、自動化の名のもとに新しく生まれた作業である。
もう一つ、承認の証跡が二か所に割れる問題もある。ブロックと解除の記録が外側のツールにあり、会計伝票はERPにある。監査で「なぜこの請求書は3週間止まっていたのか」と問われたとき、二つのシステムを突き合わせて説明することになる。統制の証跡は、一か所に寄せておくほど説明が短い（SAPの権限設計とSoD（職務分掌）｜内部統制を仕組みで担保する）。
発注書のない請求書が、自動化率の天井を決める
三面照合が成立するのは、発注書が存在する請求書だけである。発注がなければ、突き合わせる相手は請求書と誰かの承認しかない。二面照合であり、その「誰か」の判断は自動化できない。
したがって、支払業務の自動化率の上限は、発注書の発行率とほぼ同じ値になる。 読み取り精度をいくら上げても、この線は越えられない。
発注のない請求書は、費目に偏る。会議費、旅費の立替以外の直接請求、広告・販促の追加発注、修繕の緊急対応、士業への報酬、サブスクリプションの月額。いずれも「その都度の判断で発生し、金額が事前に確定しない」という共通点を持つ。
打ち手は三つある。
第一に、費目ごとに発注必須の線を引く。 全社一律で「すべて発注必須」とすると現場が回らなくなり、抜け道が常態化する。金額と反復性で線を引く。年間の反復購入は金額の大小によらず発注必須、単発は一定金額以上を必須、それ以外は事後承認のワークフローに載せる、といった切り方になる。
第二に、反復する少額請求を包括発注に寄せる。 月額のサービス料や定期配送は、期間と上限金額で発注を1本立てておけば、毎月の請求は残高から引き当てるだけで照合が成立する。SAPの許容差異キーにLA・LDが用意されているのは、この使い方を前提としているためである。
第三に、検収の入力タイミングを直す。 数量差異の多くは、物が届いていないのではなく、届いた記録が入っていないことに起因する。締めの期ズレを起こす原因でもあり、支払だけの問題ではない（決算のカットオフ（期ズレ）を止める：入荷データと請求書のギャップを締めで潰す）。
なお、単位換算や取引先マスタの整備を後回しにすると、例外の一定割合が恒久的に残る。稼働後にマスタが劣化していく構造も含めて、先に手当てしておきたい（SAPのマスタデータを稼働後に劣化させない｜登録権限とオーナーシップの決め方）。
制度側の要請が、原本の置き場所を縛る
配置の議論には、税務の制約も入ってくる。ここを後から知ると、設計をやり直すことになる。
消費税法第30条第7項は、同条第1項の仕入税額控除について、帳簿及び請求書等を保存しない場合には適用しないとしている。仕入税額を証明する手段が法定の帳簿と請求書等に限定されているという点が実務上は重い。ほかの資料で支払対価を合理的に推認できても、それでは要件を満たさない。
そのうえで、経過的な緩和がある。いわゆる少額特例は、基準期間の課税売上高が1億円以下、または特定期間の課税売上高が5,000万円以下の事業者について、税込1万円未満の課税仕入れであれば、帳簿の保存のみで仕入税額控除を認めるものである。適用期間は2023年10月1日から2029年9月30日までとされている。
この期限を、いま設計に織り込む。 少額特例を前提に「1万円未満はインボイスの判定をしない」という運用を組んでいる会社は、2029年10月以降、全件が判定対象に戻る。そのとき件数がどれだけ増えるかを試算しておかないと、期限が来た月に人手で受け止めることになる。日本固有の要件をどこまで作り込むかという判断の一部である（SAPで日本固有の要件をどこまで作り込むか｜インボイス・電子帳簿・消費税区分の落とし所）。
保存の側では電子帳簿保存法が効く。第7条により、電子取引の取引情報は電磁的記録で保存する必要がある。2022年度改正で置かれた宥恕措置は2023年12月31日で終了し、2024年1月からは猶予措置に移っている。猶予措置は、保存要件に従って保存できない相当の理由があると税務署長に認められ、かつ税務調査の際に電磁的記録のダウンロードの求めと出力書面の提示・提出の求めの双方に応じられる場合に適用される。
設計上の含意ははっきりしている。保存義務がかかるのは受領した原本であって、OCRが抽出した項目データではない。 したがって、原本をOCRツール側にだけ置く構成は、会計伝票から原本への到達性を別途担保しなければならない。ERP側の伝票に原本の格納先を紐づけるか、原本そのものをERP側に寄せるか。どちらでもよいが、決めずに稼働すると税務調査で探し回ることになる（電子帳簿保存法スキャナ保存・電子取引の決算実務への落とし込み）。
製品の選択肢は増えたが、判断の軸は変わらない
SAP側の選択肢は、この数年で整理が進んだ。文書からの項目抽出はSAP Document AI（従来のDocument Information Extraction）が担い、供給業者請求書を文書種別として扱う。上流の請求受領と処理の集約についてはSAP Ariba Central Invoice Managementが提供されてきたが、2026年2月にSAP Ariba Invoicingへ名称が変更されている。
製品名は変わるが、判断の軸は変わらない。項目抽出をどこでやるかは選択の問題で、照合と例外処理をどこに置くかは設計の問題である。 前者は入れ替えられる。後者は入れ替えるたびに業務が止まる。
導入の順序としては、抽出の仕組みを選ぶ前に、許容差異キーの上限を実績に当てて見直す作業をやっておきたい。上限が保守的すぎてブロックが多発している会社と、緩すぎて単価誤りが素通りしている会社の両方がある。3か月分のブロック実績と、解除時の判断内容を並べれば、どちらかは1日で分かる。債権債務の残高を意思決定に使える状態に保つ話とも直結する（SAPの債権・債務管理（AR/AP）を回収と支払の意思決定に効かせる）。
決めるのは三つ
請求書処理の自動化を設計するとき、決めるのは三つである。
第一に、自社の請求書1枚あたりの平均項目数を測ってから、効果を試算する。 50枚を抜いて数えれば済む。項目精度をそのまま伝票精度として受け取った試算は、業種によって二倍から三倍ずれる。
第二に、照合と例外処理をERP側に置く。 判定に使う発注残と入庫データを外部にコピーする構成は、鮮度差ぶんの差戻しを構造的に生む。ブロックと解除の証跡も一か所にまとめる。OCRは入力の代替であって、判定の主体ではない。
第三に、発注書の発行率を天井として認識し、そこを上げる打ち手を別立てで持つ。 費目ごとの発注必須の線引き、反復する少額請求の包括発注への集約、検収入力の当日化。この三つは情報システムの案件ではなく、購買と現場の運用案件である。自動化の投資対効果は、システム側でなくこちら側で決まる。
そのうえで、少額特例の期限を工程表に置いておく。2029年9月30日を過ぎれば、いま判定を省いている少額の課税仕入れが全件戻ってくる。件数の試算だけでも先に済ませておけば、その期の予算編成で慌てずに済む。
