受け取った請求書が適格請求書の要件を満たしているかを、支払う前に点検する

処理の起点を決める

受領フォルダにファイルが保存されたことを起点にします。 締め日の直後に集中して届くため、1日1回の定時実行にはしません。 まとめて処理すると、不備が見つかるのが支払の直前になり、再発行を頼む時間が残りません。

入る経路は3つあります。紙をスキャンしたもの、PDFで届いたもの、メール本文をPDFにしたものです。いずれも同じフォルダに入れ、そこから先は区別しません。経路ごとに分けると、どれか1つだけが点検されない期間ができます。

保存のたびに1枚ずつ動かし、処理が終わったファイルは処理済みフォルダへ移します。 移すのは成功したときだけにします。受領フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、いちばん下の2つです。 取引先マスタに登録番号が無ければ、読み取った番号を突き合わせる先がありません。自社名の表記ゆれの一覧が無ければ、「株式会社」が前か後ろか、旧社名かだけで、相手方の名称が書かれていないという判定になります。

過去の不備の履歴は、取引先ごとの傾向を見るために持ちます。 毎月同じ項目を落としている相手なら、1枚ずつ差し戻すより書式そのものを相談したほうが早く終わります。

データの取得方法を決める

読み取りは、ワークフローから請求書モデルを呼ぶだけです。このとき、キーと値のペアの返却をオプションで有効にします。 既定では無効なので、有効にしないと「項目名はあるが値が無い」という状態を見分けられません。

税率ごとの区分は、値ではなくテーブルの構造で見ます。 10％と8％の対価や消費税額が分かれて書かれているかは、金額の数だけでは分かりません。セルが行として分かれているかを pageResults で確かめます。

取引先マスタの照合は、スプレッドシートを読むだけで足ります。照合の順は、登録番号が先、名称が後です。 名称から先に引くと、表記ゆれで引けない取引先が出ます。

AIへ渡す前に整形する

1. 形式の確認 … PDFまたは画像であることを確かめ、それ以外はPDFに変換します
2. ページ数とサイズの確認 … PDFとTIFFは最大2,000ページ、有料（S0）レベルで500MBが上限です。超えるものは分割します
3. 画像の寸法の確認 … 50×50ピクセルから10,000×10,000ピクセルの間である必要があります。範囲外はスキャンし直します
4. 解像度の確認 … 抽出するテキストの最小高さは、1024×768の画像で12ピクセルです。150dpiで約8ポイントのテキストに相当します
5. ロックの解除 … パスワードでロックされたPDFは、提出前にロックを解除する必要があります
6. 複数の請求書がないかの確認 … まとめてスキャンされたものは、ページで分けます
7. 重複の検知 … 同じ取引先・金額・取引年月日のものが直近にあれば、既処理として印を付けます

3番目と4番目を軽く見ないでください。 紙をコピー機の既定の設定でスキャンすると、この下限に近いところに入ります。解像度が足りないだけの請求書は、「書かれていない」と区別がつきません。

AIに処理させる

させるのは、6項目それぞれについて「値が読み取れているか」を判定し、根拠にした文字列を書き出すことだけです。 6項目は、国税庁が示す記載事項をそのまま並べたものです。

右端の列が、この構成でいちばん大事な区別です。 missing は書かれていないということ、unreadable は文字は検出されているが値として確定できないということで、前者は取引先に再発行を頼むもの、後者は自社のスキャンをやり直すものです。

分ける材料は pageResults の信頼度です。 何も検出されていなければ missing、検出はされていて信頼度が低ければ unreadable。根拠を、OCRが返した数値に置きます。

3行目がいちばん起きやすい失敗です。 税率ごとの消費税額が無い請求書を渡すと、合計と税率から計算して埋め、その瞬間、見つけようとしていた不備が消えます。

指示内容を固定する

あなたは経理部門で、受け取った請求書の記載事項を点検する立場です。
OCRが返した読み取り結果だけを見て判定してください。推測で埋めないでください。

【点検する6項目】
1. 相手方（請求を受ける側）の名称
2. 売手の名称と登録番号
3. 取引年月日
4. 取引内容（軽減税率の対象品目である旨の表示を含む）
5. 税率ごとの対価の総額と適用税率
6. 税率ごとの消費税額等

【status の選び方】
- ok ......... 値が読み取れており、その項目として解釈できる
- missing .... 値が無い。項目名だけがあって値が空の場合も missing
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 値の候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 記載がなければ「不明」とし、status を missing にしてください。
  他の項目から補って埋めないでください。
- 「登録番号」といった項目名があっても、値が空なら missing です。
  項目名があることを、値があることとして扱わないでください。
- 登録番号は読み取った文字列をそのまま value に入れてください。
  桁を補う、記号を足す、それらしい番号に直すことをしないでください。
- 金額の計算をしないでください。税率ごとの金額や消費税額が無いときに、
  合計から割り戻して埋めないでください。書かれていなければ missing です。
- 税率ごとの区分は、金額が行として分かれているかで見てください。
  1行にまとまっているものを、分かれているものとして扱わないでください。
- evidence には、判定の根拠にした文字列をそのまま写してください。
- confidence は OCR が返した値をそのまま入れてください。
- 適格請求書に当たるかも、差し戻すべきかも書かないでください。
- 請求書でない書類と判断した場合は、点検をせず document_type に種類を書いてください。

【読み取り結果】{ocr_result}
【この取引先の区分】{rule_set}
【自社の名称と表記ゆれの一覧】{own_names}

「項目名を、値があることとして扱わない」を明記しないと ok になります。 読み取り結果には「登録番号」という文字列が確かに存在し、何も言わなければその存在を根拠に選びます。禁じるのは、項目名を根拠にする判断そのものです。

「合計から割り戻さない」を2か所に書いているのも同じ理由です。 計算を禁じるだけでは「合計から推定した」と書いて埋めます。埋めた値が正しいかではなく、書かれていないという事実が消えることが問題です。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "invoice_id": "",
  "document_type": "invoice",
  "vendor": {
    "name": "",
    "registration_no": "",
    "master_match": "matched | not_found | mismatch"
  },
  "rule_set": "standard | simplified",
  "checks": [
    { "item": "recipient_name", "status": "ok | missing | unreadable | ambiguous",
      "value": "", "confidence": 0, "evidence": "" }
  ],
  "verdict": "pass | needs_resend | needs_human",
  "resend_draft": ""
}

checks にはこの形の要素を6つ並べます。item は recipient_name ／ issuer_and_reg_no ／ transaction_date ／ transaction_detail ／ amount_by_tax_rate ／ tax_by_tax_rate です。

1つ目の理由は、status と verdict を別の層に置けることです。 checks はAIが埋め、verdict はワークフローが規則で決めます。不備の範囲が変わっても、直すのは規則だけです。

2つ目は、rule_set で基準を切り替えられることです。 適格簡易請求書では、宛先は省略してよく、税率又は税額のどちらか一方の記載でよいとされています。マスタの区分から standard か simplified を入れ、同じ checks を別の規則で読みます。

要は、status を基準で書き換えないことです。 簡易インボイスの取引先でも、宛先が無ければ checks には missing と記録し、判断は verdict の側だけで行います。 区分を付け間違えていても、checks を読み直すだけで判定をやり直せます。

3つ目は、evidence と confidence で確認が速くなることです。 画像を開く前に、何を見てどれくらいの信頼度で判定したかを一覧で読めます。

システムへ連携する

会計システムへは書き込みません。 この構成が出すのは点検の結果までで、支払データを作るのは別の仕組みの仕事です。 書き込みを足すと、見落としが誤った支払まで一息に進みます。

取引先マスタも読み取りだけです。登録番号がマスタに無かったときも書き足しません。 書き足すかは、取引先に確認したうえで人が決めます。

人が確認する

人が開くのは needs_resend と needs_human のものだけです。 pass のものは一覧で件数と取引先を流し見ます。全件を開く設計にすると、第10章の12.5時間には収まりません。

1. needs_human を先に見る … unreadable と ambiguous が含まれるもの。多くはスキャンのやり直しで解決します
2. needs_resend の根拠を確かめる … evidence を読み、画像で該当箇所を見ます。missing の項目が本当に空欄かを目で確かめます
3. 差し戻すかを決める … 下書きを直して送ります。送信そのものは人が行います
4. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

2番目を省かないでください。 missing の判定は、取引先に再発行を頼むかどうかに直結します。 頼んで空振りだった1件は、その取引先との次の1年に残ります。

目標は、750枚をならして1枚1分です。 開くのは1割前後という想定で、それより多い月は、unreadable が増えているか、マスタの区分が足りていません。

例外に対処する

上から4行目までが大半を占めます。 どれもAIの問題ではなく、紙の受け取り方とスキャンの設定の問題です。 直すほうが、判定の精度を上げるより効きます。

記録を残す

• 元の請求書ファイルと、受け取った日時・経路（紙／PDF／メール本文）
• OCRが返したJSONの全文（readResults、pageResults、documentResults）
• 判定結果（checks、rule_set、verdict）と、そのとき参照した取引先マスタの内容
• 人が判定を覆した記録 … どの項目を、どちらに変えたか
• 再発行を依頼した日時と、再発行された請求書との対応
• 取引先ごとの unreadable の発生率

3つ目で「そのときのマスタの内容」を残すのは、区分が後から変わるためです。 簡易インボイスの区分を付け直すと過去の判定の意味が変わり、当時の基準が残っていないと、やり直しの範囲が決まりません。

最後の行は、取引先との相談の材料になります。 特定の取引先だけ unreadable が続くなら、紙質か自社のスキャンのしかたに理由があります。