CoolFace
Datasetpublic

Aulvem/japanese-invoice-receipt-extraction-eval

証憑 · Shōhyō — 日本語 証憑(請求書・領収書・支払通知書)構造化抽出ベンチマーク(無料サンプル) 証憑(しょうひょう)=取引の事実を証明する書類(請求書・領収書など)の会計用語。 「文書テキスト → JSON 抽出」パイプラインの精度を測るための 正解付き評価データセット の無料サンプルです。 config 文書タイプ 無料サンプル invoice 請求書 20 件 receipt 領収書 10 件 payment_notice 支払通知書 / 仕入明細書 15 件 いずれもインボイス制度(適格請求書等保存方式)に対応。 既存のHF日本語帳票データはOCR・画像系が中心です。本データは 画像でなくテキスト→JSON を対象にし、和暦・軽減税率・源泉徴収・収入印紙税・相殺控除のロジックを正解側で算術検証してあります。 実在の企業名・個人情報は含みません(すべて合成)。本サンプルは無料・評価/検証用途で配布します。 このサンプルの位置づけ(凍結版)… See the full description on the dataset page: https://huggingface.co/datasets/Aulvem/japanese-invoice-receipt-extraction-eval.

sourceHugging Facecc-by-nc-4.0updated 2mo agoView on Hugging Face
0likes35downloads
Dataset Card

証憑 · Shōhyō — 日本語 証憑(請求書・領収書・支払通知書)構造化抽出ベンチマーク(無料サンプル)

証憑(しょうひょう)=取引の事実を証明する書類(請求書・領収書など)の会計用語。

「文書テキスト → JSON 抽出」パイプラインの精度を測るための 正解付き評価データセット の無料サンプルです。

config文書タイプ無料サンプル
invoice請求書20 件
receipt領収書10 件
payment_notice支払通知書 / 仕入明細書15 件

いずれもインボイス制度(適格請求書等保存方式)に対応。

既存のHF日本語帳票データはOCR・画像系が中心です。本データは 画像でなくテキスト→JSON を対象にし、和暦・軽減税率・源泉徴収・収入印紙税・相殺控除のロジックを正解側で算術検証してあります。

実在の企業名・個人情報は含みません(すべて合成)。本サンプルは無料・評価/検証用途で配布します。

このサンプルの位置づけ(凍結版)

このリポジトリは凍結サンプルです。上記45件で「自分の抽出器が日本語帳票の どの難所で壊れるか」を測るには足りますが、件数を増やす更新はここには入りません。

フル版(販売中)

各文書タイプ 2,000 件・合計 6,000 件。全件が算術検証を通過しています。

プラン価格内容
スナップショット¥6,800購入時点の版のみ。更新なし
**年間ライセンス**¥48,000 / 年期間中に追加される全文書タイプ+改正追従+商用利用可
再配布ライセンス$499 / 年自社製品への同梱・白ラベル・API 化の権利
  • —仕様・収録内容 → [証憑 プロダクトページ](https://aulvem.com/ja/products/japanese-invoice-receipt-extraction-eval/?utm_source=huggingface&utm_medium=dataset_card&utm_campaign=japanese-invoice-receipt-extraction-eval)(日本語) / English
  • —文書タイプの追加はこのカードでも告知します。追いたい場合はこのリポジトリを Watch(右上)してください。 それが唯一の通知手段です(メールリストはありません)。

支払通知書について(2026-08 追加)

支払通知書は買手が発行する文書なので、請求書と構造が反転します。issuer が支払者(買手)、 payee が支払先(売手)で、登録番号は売手側に付きます(仕入明細書として保存する場合に必要)。 「どちらの登録番号か」が本質的な抽出の難所です。

加えてこの文書タイプ固有の難所があります。

  • —複数請求書の合算 — 明細1行が請求書1枚に対応し、invoice_number を持つ
  • —相殺・値引き・振込手数料の控除(deductions)— 支払額は 税込 − 源泉 − 控除合計
  • —締日と支払予定日 — 日付が2つあり、どちらを取るかを間違えやすい

なぜこのデータか

RAG や OCR 後段の「文書→構造化抽出」を作ると、必ず「精度をどう測る?」で詰まります。 本物の請求書は個人情報で評価に使えず、正解を手作業で作るのは高コスト。 このデータは 現実の請求書で抽出器が壊れる難所をわざと仕込み、正解を全件検証済みで提供します。

既存の評価データはほぼ英語。日本語帳票(適格請求書発行事業者登録番号・源泉徴収・和暦)対応はほぼ空白です。

レコード構造

各行(JSONL):

  • —id, document_type, difficulty(easy/medium/hard), features(難所タグ)
  • —document_text: 現実的な請求書本文(表記揺れ・全角・記号混在あり)
  • —expected_output: 正解の構造化JSON(スキーマは下記)

正解スキーマ(要点)

フィールド内容
issuer.registration_number適格請求書発行事業者登録番号(T+13桁)。免税事業者は null
issue_date / due_dateISO 8601。和暦は西暦変換、相対表記(翌月末日等)は解決済み
line_items[]name, quantity, unit_price, amount, tax_rate(0/8/10)
tax_summary[]税率ごとの区分(taxableamount, taxamount)=適格請求書の必須要件
subtotal / tax_total / total_incl_tax税抜・消費税・税込
withholding_tax / total_due源泉徴収税額・源泉後の請求額

仕込んだ難所(features)

和暦変換 / 相対日付解決 / 軽減税率8%・10%の区分 / 源泉徴収(10.21%、100万円超は超過分20.42%)/ 欠損(免税事業者で登録番号なし)/ 全角数字・「¥」「金〜円」の正規化 / 消費税の端数処理(切捨て)

品質保証(正解を先に確定してから本文を描画)

一般的な合成データは「本文を書いてから正解を読み取る」ため読み取り誤りが混入します。 本データは逆向きです。

  1. 1.正解の構成: 金額・税率区分・税額(切捨/四捨五入/切上)・源泉徴収額・印紙税額を先に確定
  2. 2.本文の描画: 確定値から document_text を描画(和暦・全角・¥/円・相対日付の揺れを意図的に振る) → 本文と正解が原理的に食い違わない
  3. 3.機械検証: JSON Schema 適合 + 算術整合(明細=数量×単価/税率区分の合算/小計・税込・源泉後/ 収入印紙税額)を 全件チェック

生成は seed 固定の決定論。フル版の本体 6,000 件(請求書2,000/領収書2,000/支払通知書2,000)は 全件合格しています。このサンプル45件も同じ生成器・同じスキーマから抽出しています。

測れないこと

本文はテンプレートと語彙の組み合わせです。表記揺れは意図的に振ってありますが、 実務で出会う文書の"崩れ"のすべてを再現するものではありません。レイアウト崩れや OCRノイズへの耐性は測れません(入力はテキスト前提)。

使い方

python
import json
data = [json.loads(l) for l in open("invoice_ja.sample.jsonl", encoding="utf-8")]
# 自分の抽出器の出力を data[i]["expected_output"] と突き合わせ、フィールド単位の正答率を算出

ライセンス

  • —無料サンプル: CC BY-NC 4.0(非商用・評価用途)。
  • —商用利用・フル版: Aulvem の商用ライセンスにて提供。

引用 / 連絡

Aulvem — A solo studio for building & writing. aulvem.com