OCRで請求書をCSV化し、転記作業を大幅削減。

複数の仕入先から届く請求書を、担当者が1枚ずつ会計システムへ手入力している。

仕入先ごとに書式が違い、同じ項目でも記載位置と表記が揃わない。

入力の正確さが担当者個人の慣れに依存している。

負荷の正体は、入力の手数そのものではありませんでした。仕入先ごとの書式の違いを、人が頭の中で吸収していたことが本質です。同じ項目でも位置と表記が違い、その差を埋める判断が担当者の経験の中にしかありませんでした。

そのため「OCRで読み取る」だけでは解けません。仕入先ごとの読み取りルールを、担当者が自分で直せる形で外に出す必要がある、と整理しました。

あわせて、読み取り精度を100%に近づけることを目標に置かない方針を最初に決めました。どこまでを人が確認するかを先に決めておかないと、精度が上がるほど確認をやめてしまい、かえって事故が起きます。

請求書のPDFをアップロードすると、生成AIが項目を読み取ってCSV化する仕組みを構築しました。

仕入先ごとの読み取りルールをコードではなくマスタとして持たせ、担当者が画面から直せるようにしました。

読み取り結果の一覧・修正・再計算・明細の出力までを1つのアプリに収めています。

拠点マスタを登録すると、保存先フォルダが自動で作られる仕組みを追加しました。

操作マニュアルを7本作成し、担当者が自走できる状態にしました。

手入力していた転記作業が、アップロードと確認に置き換わりました。

読み取りルールの調整を、開発側へ依頼せず担当者側で回せるようになりました。

5社分の読み取りテストを経て試験運用を開始し、その後、本運用へ移行しています。

会計システム本体は変更していません。CSVでの受け渡しに留めています。

読み取り精度を100%にする前提を置かず、人が確認する工程を残す設計にしました。

うまくいかなかったことが5つありました。

1つ目は、読み込み中の行が画面から消え、同じ請求書を二重に読み取ってしまう事象です。表示の作り方が原因で、処理自体は正しく動いていました。

2つ目は、不課税分で1円の差異が出たことです。消費税の端数処理の丸め方が箇所ごとに違っており、丸め処理を統一して解消しました。

3つ目は、生成AIの戻り値が、同じ指示でも配列で返るときと返らないときがあったことです。どちらでも受けられるようにして吸収しました。

4つ目は、特定の仕入先向けに読み取り指示を直すと、別の仕入先の読み取りが壊れたことです。仕入先ごとにルールを分離する設計へ変更しました。

5つ目は、「処理中」が画面に出ず、担当者が二重に実行していたことです。先に仮の行を作って状態を見せる方式に変更しました。

請求書の仕入先が固定されていて、書式のパターンが数社に収まること。

読み取り結果を人が確認する工程を残せること。無人化を目標に置かないこと。

仕入先が増えたときのルール追加を、担当者側で回す前提に合意できること。