1. 催促の前に、日本の請求書を点検したい
着想元は、Anthropicの公開プラグイン集にある小規模事業向けスキル「invoice-chase」（Apache License 2.0、参照日：2026-10-31）です。海外の会計サービスとの接続と英語の督促メールが前提で、日本の登録番号、税率ごとの消費税額、和暦、締め日と支払日の点検は扱っていません。
参考にしたのは、「期日を過ぎた請求を一覧にし、取引先の支払いの履歴で文面を変え、送るかどうかは利用者が決める」という考え方だけです。文章・例・プロンプト・コードは写さず、日本の請求書の点検手順とともに一から作りました。
invoice-check-jaは、送る前の点検から催促の下書きまでを扱います。会計サービスやメールには接続せず、送信もしません。Anthropicとは関係のない非公式のスキルであることを、READMEにも明記しています。
2. 記載漏れ・税額・日付・支払期日を点検する
適格請求書の6項目の空欄を点検します。発行者と登録番号、取引年月日、取引内容と軽減税率の対象の表示、税率ごとの対価の合計と適用税率、税率ごとの消費税額等、受け取る事業者です。計算や日付も含め、次のような点を表示します。
| 点検するところ | 表示・確認の例 |
|---|---|
| 登録番号 | 「T」＋13桁の形と、法人番号のチェックデジットを点検。一致しなくても「要確認」にする |
| 税額 | 10%・8%、税抜・税込に対応し、税率ごとに合計して1回だけ端数処理。明細ごとの税額の合計とのずれも表示する |
| 日付 | 和暦と西暦の混在、曜日の不一致、取引日より前の請求日を表示する |
| 支払期日 | 締め日と支払日の条件から計算。土日の扱いは利用者が指定し、祝日は渡された一覧だけを使う |
点検項目の全体と入力方法は公開READMEにまとめています。PDFからの読み取りはしません。
3. 催促は、履歴に合わせて下書きする
基準日で期日を過ぎた請求を一覧にし、①ご確認のお願い、②お支払いのお願い、③最終のご連絡の3段階の型を使います。履歴がなければ①から始め、法的な手続きをほのめかす文は、利用者が指示したときだけ扱います。
READMEにある架空の材料を使った修正前後の比較です。
| 項目 | 修正前 | 修正後 |
|---|---|---|
| 件名 | 至急のお支払いについて | 請求書番号・金額（1,100円）・期日を入れた件名 |
| 段階 | 履歴を無視した強い要求 | いつも期日どおりの取引先なので、①ご確認のお願い |
| 期限 | 明日までに必ず | 手続きの状況を尋ねる |
| 法的な手続きをほのめかす文 | あり | 削除 |
| 行き違いのお詫び | なし | 冒頭3行に入れた |
振込先は材料になかったので、推測で書きませんでした。請求の内容を示したうえで状況を尋ね、採用する文面と送信は利用者が決める手順です。
4. スクリプトの点検と、人の確認を分ける
補助スクリプト check_invoice.py はPythonの標準ライブラリだけで動き、読み取りと標準出力だけを行います。
公開READMEの記録では、AIが架空の請求書のCSVを10枚作り、同じAIがスクリプトを実行して出力を照合しました。登録番号の桁数、明細ごとの端数処理、和暦・西暦の混在、税率ごとの合計や受取側の名前の欠け、曜日の誤りなど、わざと入れた確認点は14件中14件を表示しました。 問題のない2枚では、「直すべき点」「要確認」とも0件でした。これは架空の素材と実装の照合で、一般の請求書に対する精度の評価ではありません。
登録番号の実在や登録の状況は照会しません。利用者が国税庁の公表サイトで確かめます。法人番号のチェックデジットが合わなくても、個人事業者の番号の可能性があるため、誤りとは断定しません。一致しても登録の証明にはなりません。
税務・法律の判断はスキルの範囲外です。必要に応じて税理士や担当部署に確かめ、催促の文面は取引先との関係や入金状況を踏まえて人が確認します。
5. まだ分からないこと
実際の請求書の様式の多様さや、会計サービスから書き出したCSVの形との違いは確かめていません。個人事業者の登録番号に、チェックデジットの計算が当てはまるかも未確認です。
簡易インボイス・返還インボイス、源泉徴収、2割特例などの特例、遅延損害金は扱いません。催促の文面が取引先との関係に合うか、入金までの実際の運用も未確認で、作業時間や入金の速さは測っていません。