請求書照合を自動化する｜発注・納品・請求の三点照合と、国税庁の公的APIによる登録番号の確認

月末に届く請求書の束を、発注の記録と納品書に突き合わせる。金額が合わない、数量が違う、そもそも発注していない請求が混ざっている。経理担当者がこの確認に使っている時間は、支払件数が月100件を超えるあたりから急に重くなります。

この照合は、条件が明確なぶん機械に渡しやすい作業です。ただし全部を渡すことはできません。差額が出たときに支払ってよいかを決めるのは、最後まで人の仕事です。この記事では、三点照合と登録番号の確認を機械に任せ、人が見るのは差異だけにする仕組みを、設計図から順に説明します。

ムダの現状：合っているものを確認する時間が大半

請求書の照合作業を分解すると、時間の使われ方がはっきりします。

届いた請求書を開き、発注の記録を探し、納品書と数量を見比べ、金額を電卓で確かめ、合っていれば支払の一覧に転記する。この一連が1件あたり3分から5分。月120件なら6時間から10時間です。

そして、このうち実際に差異が見つかるのは、多くの会社で1割前後です。つまり9割の時間は「合っていることを確認するため」に使われています。機械が得意なのは、まさにこの部分です。

差異には3種類ある

残りの1割、差異が出たときの扱いを先に整理しておきます。差異は性質が3つに分かれ、それぞれ判断する人が違います。

照合の自動化でよくある失敗は、差異の一覧を作ったところで終わり、誰が処理するかを決めていないことです。結局その一覧を経理が全部抱えることになり、作業量が変わりません。

機械に渡せる部分と、人に残す部分

ここまでを踏まえて、工程ごとに担当を分けます。ポイントは、突き合わせと登録番号の確認だけでなく、差異を3種類のどれかに振り分けるところまでを機械にやらせることです。分類まで機械が済ませておかないと、人が一覧を上から読んで振り分ける作業が残り、削れる時間が半分になります。

スキームの全体図：三点照合、登録番号、差異の判断

必要なツールと費用（2026年9月22日時点）

アプリケーションIDの取得手順

国税庁は、適格請求書発行事業者公表システムのWeb-API機能を提供しています。このAPIを使うには、利用規約への同意とアプリケーションIDの取得が必要です。

手続きの流れは、メールアドレスの仮登録、基本情報の入力と利用方法の資料の提出による本登録、国税庁による審査、そしてIDの発行です。審査があるため、即日で使えるものではありません。照合の仕組みを作り始めるのと同時に申請しておくと、ちょうど実装が終わるころに使える状態になります。

IDにはインボイス用と法人番号用の2種類があり、インボイス用のIDであれば法人番号システムのWeb-APIも利用できます。発行は無料と明記されています。

導入手順：照合の許容差を決めるところから

Step 1：3つの記録をつなぐ鍵を決める

三点照合の前提は、発注・納品・請求の3つが同じ鍵で結びつくことです。多くの場合、この鍵は発注番号になります。

ここで止まる会社が少なくありません。発注番号を採番していない、あるいは採番しているが請求書に書かれていない、という状態です。この場合、照合の自動化より先に、次のどちらかを決める必要があります。

1つは、発注番号を採番し、取引先に請求書への記載を依頼することです。継続的な取引先であれば、依頼すれば入れてもらえることが多くあります。もう1つは、取引先コードと納品日と金額の3つを組み合わせて仮の鍵にすることです。精度は落ちますが、番号の運用を変えずに始められます。

どちらを選ぶかは、取引先の数で決めてください。20社以下なら依頼したほうが速く、それ以上なら仮の鍵から始めるほうが現実的です。

Step 2：許容差を決める

照合を「完全一致」で組むと、1円の差でも差異として出てきます。端数処理の違いや消費税の計算方法の差で、実務上は問題のない差額が大量に出ることになります。

そこで、許容差を先に決めます。次の3つを、責任者と合意してください。

許容差は、過去3か月の実際の差額を数えてから決めてください。感覚で「100円まで」と決めると、多すぎたり少なすぎたりします。過去のデータを並べると、端数の差と本当の誤りは、金額の分布ではっきり分かれます。

許容差の数え方

やり方は単純です。過去3か月ぶんの請求について、納品の金額と請求の金額の差額を1列に並べます。そして差額の絶対値で昇順に並べ替える。

すると、多くの場合ふたつの塊ができます。0円から数円に集まる塊と、数百円以上に散らばる塊です。前者は端数処理や消費税の計算方法の違いで生じたもの、後者は単価や数量の違いによるものです。この境目より少し小さい値を許容差に設定してください。

境目がはっきりしない場合は、差額が出た請求を10件だけ実際に調べてみてください。原因が端数なのか誤りなのかを10件見れば、どこで線を引くべきかが判断できます。全件を調べる必要はありません。

そして、許容差は固定ではありません。運用を始めて3か月たったら、一度見直してください。取引先の構成が変われば、適切な値も変わります。

Step 3：照合と登録番号の確認を書く

次のApps Scriptは、請求シートを1行ずつ見て、発注・納品と突き合わせ、結果を判定します。登録番号の確認も同じ処理の中で行います。

var AMOUNT_TOLERANCE = 3;
var API_BASE = 'https://api.invoice-kohyo.nta.go.jp/1/num';
function matchInvoices() {
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var orders = indexBy(ss.getSheetByName('発注'), 0);
  var deliveries = indexBy(ss.getSheetByName('納品'), 0);
  var rows = ss.getSheetByName('請求').getDataRange().getValues().slice(1);
  var out = [];
  var cache = {};
  for (var i = 0; i < rows.length; i++) {
    var r = rows[i];
    var key = r[0], amount = Number(r[2] || 0), regno = String(r[3] || '');
    var o = orders[key];
    var d = deliveries[key];
    var status = judge(o, d, amount);
    var reg = checkRegno(regno, cache);
    out.push([key, r[1], amount, status, reg, '', '']);
  }
  write(ss, out);
}
function judge(o, d, amount) {
  if (!o) return '記録の不一致：発注が見つからない';
  if (!d) return '記録の不一致：納品が見つからない';
  var diff = Math.abs(Number(d[2] || 0) - amount);
  if (diff <= AMOUNT_TOLERANCE) return '一致';
  if (Number(o[2] || 0) !== Number(d[2] || 0)) return '条件の相違：発注と納品で金額が違う';
  return '請求側の誤り：納品と請求で金額が違う';
}
function checkRegno(regno, cache) {
  if (!regno) return '登録番号なし';
  if (cache[regno]) return cache[regno];
  var url = API_BASE + '?id=' + encodeURIComponent(appId())
    + '&number=' + encodeURIComponent(regno.replace(/^T/, ''))
    + '&type=21&version=1';
  var res = UrlFetchApp.fetch(url, { muteHttpExceptions: true });
  var text = res.getContentText();
  var ok = text.indexOf('登録年月日') >= 0;
  cache[regno] = ok ? '有効' : '要確認';
  return cache[regno];
}
function appId() {
  return PropertiesService.getScriptProperties().getProperty('NTA_APP_ID');
}
function indexBy(sheet, col) {
  var m = {};
  var v = sheet.getDataRange().getValues().slice(1);
  for (var i = 0; i < v.length; i++) {
    m[v[i][col]] = v[i];
  }
  return m;
}
function write(ss, out) {
  var sh = ss.getSheetByName('照合結果');
  sh.getRange(2, 1, Math.max(sh.getLastRow() - 1, 1), 7).clearContent();
  if (out.length === 0) return;
  sh.getRange(2, 1, out.length, 7).setValues(out);
}

実装で押さえておきたい点が3つあります。

1つ目、アプリケーションIDをコードに直接書かないこと。スクリプトのプロパティに入れて読み出します。規約でも、利用者はIDの管理責任を負うものとされ、譲渡・貸与・開示は禁止されています。

2つ目、同じ登録番号を何度も照会しないこと。上のコードでは1回の実行の中で結果を保持しています。規約は大量アクセスによって本機能の運用に支障を生じさせる行為を禁止しているので、必要以上に呼ばない設計にしてください。

3つ目、判定は3種類に振り分けること。単に「不一致」と出すだけでは、誰が処理すべきかが決まりません。発注が見つからないのか、発注と納品で違うのか、納品と請求で違うのか。この区別が、そのまま担当の振り分けになります。

Step 4：差異の担当を先に決める

照合結果が出たら、種類ごとに担当を割り当てます。ここを決めずに運用を始めると、差異の一覧が経理の机に積み上がります。

記録の不一致は、発注や納品の登録が抜けている状態なので、購買部門または現場が記録を直します。条件の相違は、単価の変更や送料の追加が連絡されていないケースが多いため、購買が取引先に確認します。請求側の誤りは、経理から取引先へ再発行を依頼します。

この割り当てを、照合結果のシートに列として持たせてください。機械が種類を判定した時点で担当者名が入る形にすると、朝に一覧を見た人が自分の行だけを処理できます。

あわせて、未処理の件数を種類別に週1回共有してください。誰の担当が滞っているかが見える状態にしないと、割り当てたはずの差異が結局は経理に戻ってきます。共有するのは件数だけで十分です。個別の案件名まで並べると、追及の場になって協力が得られなくなります。

もうひとつ、差異が解消したときに何をしたかを1行で残す列を用意してください。次に同じ取引先で同じ差異が出たとき、前回の対応がそのまま使えます。記録の不一致が同じ部署で繰り返し出ているなら、それは個人の注意不足ではなく、発注の登録のしかたに無理があるという合図です。

Step 5：月末だけでなく、届いた日に回す

照合を月末にまとめて行うと、差異の確認が支払期日の直前になります。取引先への問い合わせが間に合わず、結局そのまま支払うことになりがちです。

請求書が届いた日、あるいは翌営業日に照合を回してください。差異が見つかってから支払期日まで、2週間以上の余裕がある状態を作ると、確認のやり取りが落ち着いて進みます。

実装としては、請求シートに行が追加されたときに走らせる形と、平日の朝に前日ぶんを処理する形があります。後者のほうが安定します。行の追加を検知する仕組みは、取り込みの方法を変えたときに動かなくなることがあるためです。

朝に走らせるなら、処理が終わった時点で差異の件数だけを担当者に知らせる形にしてください。差異が0件の日は通知しない。毎日必ず届く通知は、2週間で見られなくなります。

現場の合意の取り方：購買部門と経理の役割が動く

この仕組みは、経理だけで完結しません。発注と納品の記録を正しく残すのは購買や現場の仕事なので、そこに新しい負担が見えます。

購買には「減る話」から入る

購買部門にとって、この仕組みは記録の負担が増える話に見えます。しかし実際には、減るものもあります。

月末に経理から「この請求、発注してますか」と個別に聞かれる回数が減ります。差異の問い合わせが月末に集中するのではなく、届いた日に分散します。この2つを先に伝えてください。負担の話から入ると、記録の項目を増やす交渉になり、まとまりません。

経理の1か月並走は、必ず入れる

照合を機械に任せることへの不安は、実際に精度を見るまで消えません。最初の1か月は、機械の判定と人の確認を並走させてください。

数えるのは、機械が一致と判定したもののうち、人が見て差異だった件数です。ここが0件で1か月通れば、翌月から一致分の目視をやめる判断ができます。やめる判断の基準を、並走を始める前に決めておくのが要点です。決めずに始めると、並走が終わりません。

失敗パターンと限界：公的APIの利用規約と、記載事項

公的APIには、守るべき規約がある

国税庁のWeb-API機能は無料で使えますが、利用規約に従う必要があります。実装と運用に直接関わる条項を挙げます。

第6条は、情報の取得元の明示について定めています。このサービスはWeb-API機能を利用して取得した情報をもとに作成しているが、サービスの内容は国税庁によって保証されたものではない、という趣旨の文言を適切な場所に明示することが求められます。社内システムであっても、照合結果の画面や出力にこの但し書きを入れてください。

第9条第1項は禁止事項を定めており、大量アクセスによって運用に支障を生じさせる行為、アプリケーションIDの譲渡・貸与・開示、そして取得した公表情報を運営方針に定める目的以外の目的で第三者に提供する行為が含まれます。取引先の登録状況を取りまとめて外部に共有する、といった使い方は避けてください。

第4条の2は、取得した情報を個人情報保護法等の規定に基づいて管理することを定めています。第12条は、取得した情報について漏えい、滅失、き損または改ざんが生じないよう必要な措置を講ずることを求めています。個人事業主の情報も含まれるため、社内での保存場所とアクセス権限を決めてから運用してください。

第10条第1項は免責について定めており、本機能の利用にあたり利用者または第三者が被った被害について、国税庁の故意または重過失による場合を除き、国税庁は責任を負わないものとされています。APIの結果を唯一の根拠にして支払を止めるような設計にはしないほうが安全です。

照合が通っても、記載事項は別の話

三点照合と登録番号の確認が通っても、それは金額と発行者の確認が済んだというだけです。請求書そのものが要件を満たしているかは、別に見る必要があります。

この点は制度の要件に関わるため、自社が仕入税額控除を受けるうえで何を保存し、何を記載しておくべきかは、国税庁の資料や顧問税理士に確認してください。記事の仕組みは、金額の突き合わせと発行者の確認を自動化するものであって、税務上の判断を代替するものではありません。

この仕組みが向かない場合

請求件数が月50件に満たないなら、仕組みを作る手間のほうが大きくなります。ただし登録番号の確認だけは、件数が少なくても価値があります。新規の取引先が増えたときに調べる運用を作るだけでも足ります。

また、請求書が紙のみで届き、電子データがない場合は、照合の前に読み取りの工程が入ります。読み取りの誤りが照合の誤りとして現れるため、まず主要な取引先に電子での送付を依頼するほうが、全体としては速くなります。

効果の測り方

3つ目が、この仕組みの本当の価値を示します。月末にまとめて照合していた頃は、差異の解消が支払期日ぎりぎりになっていたはずです。届いた日に回す運用に変えると、ここが数日単位で短くなります。

逆に2つ目が0件にならない場合、許容差の設定が広すぎる可能性があります。過去の差額の分布に戻って、設定し直してください。

まとめ

請求書の照合は、時間の9割が「合っていることの確認」に使われています。ここを機械に渡し、人が見るのは差異だけにする。これが基本の形です。

始める前に決めるのは2つ。3つの記録をつなぐ鍵と、金額・数量・日付の許容差です。許容差は感覚で決めず、過去3か月の実際の差額を数えてから設定します。そして差異は3種類に分け、記録の不一致は購買と現場、条件の相違は購買、請求側の誤りは経理、というように担当を先に割り当てます。

登録番号の確認は、国税庁が提供するWeb-API機能で自動化できます。発行は無料ですが、申請と審査があり、取得元を明示する文言、大量アクセスの禁止、目的外の第三者提供の禁止といった規約上の制約があります。APIの結果を唯一の根拠にして支払を止める設計にはせず、承認は人が行う形を保ってください。

よくある質問

発注番号を採番していない場合、どう始めればよいですか

取引先が20社以下なら、採番して請求書への記載を依頼するほうが速く進みます。それ以上なら、取引先コードと納品日と金額を組み合わせた仮の鍵で始めてください。精度は落ちますが、番号の運用を変えずに照合を回せます。1か月動かしてから、本格的な採番に進むか判断します。

アプリケーションIDの申請には、どれくらいかかりますか

メールアドレスの仮登録、基本情報と利用方法の資料を提出する本登録、国税庁の審査という流れで、即日発行ではありません。実装を始めるのと同時に申請しておくと、実装が終わるころに使える状態になります。発行自体は無料です。

登録番号が「要確認」と出た場合、支払を止めるべきですか

止める判断をAPIの結果だけで行わないでください。規約でも、国税庁は利用にあたっての被害について故意または重過失による場合を除き責任を負わないとされています。入力の誤りや、取得のタイミングによる差も起こりえます。まず番号の転記を確認し、それでも解消しなければ取引先に問い合わせてください。

許容差はいくらに設定すべきですか

過去3か月の差額を並べて決めてください。端数処理による差は数円の範囲に固まり、本当の誤りはそれより大きな金額に分布します。その境目が自社の許容差です。他社の数字をそのまま使うと、取引の内容や端数処理の方法が違うため合いません。

差異の担当を決めても、結局経理が処理してしまいます

照合結果のシートに担当者名の列を持たせ、機械が判定した時点で自動で入る形にしてください。そのうえで、未処理の件数を種類別に週1回共有します。誰の担当が滞っているかが見える状態にすると、割り当てが機能し始めます。

AIを使って請求書を読み取らせてもよいですか

読み取りの工程には使えますが、この記事の照合の仕組みとは別の層です。読み取りには誤りが混ざるため、読み取った値をそのまま照合に流すと、判定の誤りとして現れます。まず電子データがある取引先で照合を回し、精度の基準を作ってから読み取りに広げる順番を勧めます。

同じ部門の記事

経理経理の仕訳を自動化する｜摘要辞書とAIと人の三層で、経理担当者と税理士が納得する仕組みにする2026年9月21日