架空の設備会社で、経理担当が届いた請求書を表へ写し、発注書と納品記録を探し、責任者に確認しています。転記が速くなっても、何の取引への請求か不明なら正式な処理は止まります。AIが読み取る範囲と、人が取引を確かめる範囲を分けることが入口です。

Microsoftの請求書モデルの公式資料には、請求番号、金額、期日などの抽出と項目ごとの信頼度が載っています。これは入力候補を作る機能の説明で、取引の正当性や支払ってよいことを保証しません。個別の帳票で使えるかは、対応条件と実物の試行で確認します。

仕事を分けるための材料は、帳票の画像だけでは足りません。「どの表へ何を写すか」「写した後に何を探すか」「誰から確認が戻るか」を一件で見せます。AIの作成範囲を入力案までにした場合、販売担当や現場が発注・納品を確かめる流れは残ります。その仕事を経理の対象外に置くなら、引き受ける担当と受領する条件を決めます。転記だけを外注し、探す仕事が経理へ残ったままなのに、経理全体を自動化したと説明しないでください。

この章の根拠：出典1出典2

架空請求書I-01に「請求総額55,000円」「前回未払11,000円」「今回分44,000円」とあるとします。総額を今回の費用として転記すると意味が違います。入力案に原本の欄名を残し、今回分と支払う総額を区別します。数字が一致しても、使う欄が違えば正しい処理になりません。

支払期日の記載がなければ「未記載」と書きます。過去の請求書や一般的な締日から生成AIに埋めさせません。商品名が不鮮明なら原文の読み取り候補と確認待ちを残します。信頼度が高いことを経理の承認と扱わず、どの項目を原本で確認するかを決めます。

もう一つの違いは、数字の型です。原本に「55,000」と書かれた値と、表で計算できる数値55000を区別し、通貨や税込・税抜の欄も原本に沿って残します。桁区切り、マイナス、単位、複数税率などの読み方が違う帳票は試行へ入れます。税区分をAIに決めさせるための欄ではなく、原本の記載と担当者が確認する項目を分けるための表です。金額を自動で型変換する場合も、変換前の記載へ戻れると誤りを見付けやすくなります。

請求書が二枚に分かれているなら、表紙の総額と明細の合計を別の根拠として残します。たとえば二枚目に値引きがあるのに、一枚目の品目だけを抽出すると合計が変わります。試行用の原本は一枚のきれいな帳票だけでなく、複数ページ、読みづらい印、明細の続きがあるものを選びます。必要なページがそろっていない入力案は、原本不足として確認へ戻します。

この章の根拠：出典1出典2

表の計算は44,000円と11,000円を足せば55,000円です。しかし、前回分をすでに支払っているなら、数式が合ってもこのまま支払う理由にはなりません。発注番号、納品日、過去の処理記録と請求番号を照合し、請求先への確認が必要かを経理が判断します。

金額や口座が変わったときも、読み取り結果をそのまま採用せず、会社の確認方法で原本と取引条件を確かめます。訂正を依頼した場合は、元の請求書と修正版の関係を残します。正式な会計処理、税区分、支払いは社内の責任者や必要な専門担当が確認します。

照合結果の完成見本は「I-01は発注O-12へ対応。今回分44,000円は納品記録と照合待ち。前回未払11,000円は既払一覧を確認中。期日は取引条件へ照会中」です。どの数字を確かめたかが読み取れれば、別担当が再びすべてを探す必要は減らせる可能性があります。ただしこの見本は実績ではなく、確認の範囲を示す設計例です。担当者が確認を終えてから、社内で決めた状態へ更新します。

重複候補の完成見本は「取引先A・請求番号I-01・同じ総額の記録が二件。ただし一件は修正前の版」です。番号と金額が同じだけで片方を削らず、受領日、原本、訂正の経緯を照合します。逆に番号が違っていても、同じ納品分を二度請求している可能性は残ります。抽出後の重複判定を自動化するなら、どの組合せで候補を出し、誰が確定するかまでを試行の範囲にします。

この章の根拠：出典1出典2

入力案の完成見本では、I-01の期日を未記載として経理へ戻します。経理が取引条件を確認して期日を追加する際は、AIが抽出した値と、人が確認して追加した値を区別します。誰かが案を見ている間に別の人が正式登録し、二重処理する状態を避けます。

確認済みの印は何を確認したかを示します。「原本の金額を確認」と「取引を確認」と「支払いを承認」は違います。正式処理の担当者が必要な資料へ戻れる形で渡し、権限と社内の手続きを維持します。自動通知を作っても、担当者が受け取っていなければ確認は完了しません。

読めない欄がある原本は、全部をエラーとして捨てるより、読めた欄と読めない欄を分ける設計を検討できます。ただし会社の処理に必要な欄が欠けていれば、正式処理には渡しません。訂正は値だけを上書きする方法と、元案を残して訂正版を作る方法を比べ、履歴と作業の分かりやすさで選びます。誰がどの値を直したかを残す範囲は、自社の監査や保存の要件に合わせます。

この章の根拠：出典2

少量で様式が変わるなら、手入力と表の整備だけで足りる場合があります。OCRや請求書抽出は文字や欄を取り出す候補ですが、誤読と意味の違いの確認が残ります。生成AIで自由な文章を表へ整理する場合も、原本にない情報を補わせない条件と照合が必要です。方法を混ぜるなら、どこで値を作り、どこで直したかを追えるようにします。

料金は、処理枚数、利用契約、連携、設定、例外対応で変わります。速かった一件だけで効果を決めず、原本探しから正式処理へ渡すまで同じ範囲を比べます。電子で受け取った取引データの保存については国税庁の案内を確認し、入力案だけを残して原本を捨てる設計にはしません。保存の要件は取得方法と運用に応じて個別に確認します。

「既存の会計ソフトに読み取り機能があるなら追加のAIは不要か」という疑問には、必要な欄と既存の確認方法を通せるかで答えます。現在の機能で入力案と原本を見られ、担当者の確認が進むなら、まず設定や帳票の整理を試します。追加の仕組みが必要な場合も、原本、出力表、会計への受渡しを一件の完成見本で示します。ソフト名だけで連携できると判断せず、契約、出力形式、権限を確認します。

依頼先へは「I-01の五項目をこの表へ出す。未記載を保持する。原本の該当箇所を確認できる。二枚の明細を一件へまとめる」と渡します。入力案の納品と会計への正式登録を別の完成条件にすれば、見積もりへ含まれる設定と確認の範囲を比べられます。原本の形式が変わった後に誰が直すかも、保守の条件です。

この章の根拠：出典1出典2出典3

I-01の架空例では、今回分と請求総額を分け、期日は未記載にしました。この違いが読み取れる表なら、経理担当は数字の打ち直しだけでなく、必要な取引確認へ進めます。下の試行票で原本一件と照合資料をそろえ、自社の帳票で試してください。

AIの案、経理の照合、責任者の正式処理を一つの確認済み表示へまとめないことが要点です。原本の保存とアクセスも含め、業務を最後まで通す方法を選びます。

この章の根拠：出典1出典2出典3