仕入先の請求書を、信頼できるデータに変える請求書OCR
請求書の打ち直しは不要です。宣言したフィールドに請求先・番号・日付・合計・明細行を読み取り、各値を box・quad 座標と verified 判定、そして確認対象を並べた data.review.flagged とともに返します。
受信箱に届く請求書は、どれも小さな入力作業の税金です。誰かがPDFを開き、請求先・請求書番号・日付・税の行・合計を探し、それをすべて会計システムに打ち直す——明細が必要なら、それも手で写します。時間がかかり、入力ミスの温床になり、合計をひとつ打ち間違えれば支払処理が止まります。
請求書OCRは本来、その手間を肩代わりするものです。請求書を読んで、フィールドを返す、と。ただ問題は、ほとんどのツールが数字を渡して「これを信じてください」と言うだけなこと。space-ocr は宣言されたフィールドに請求書を読み込み、各値を、ページ上のどこから読み取ったかという領域とともに返します——さらに、照合が通らなかった値を並べた確認リストが付きます。支払の承認前に確認するのは、ページ全体ではなくその数件です。
その場で確認できる、実際の請求書
下のフィールドにマウスを合わせてみてください——請求書上のボックスが、その値を読み取った場所です。請求先・発行日・対象期間・支払期限・ご請求金額・合計、そして各明細行はすべて、実際の解析結果から読み込んだもので、モックアップではありません。
Each value with a box carries a verified on-page location — in data.cells[path], that is box + 4-point quad + evidence.match_ratio — on a 0–1000 normalized grid (0,0 top-left → 1000,1000 bottom-right), the same shape the live API returns. Hover a field to trace it back to the pixels it came from.
space-ocrでの請求書OCRの仕組み
アプリに請求書をドロップすると、ひとつの行に読み込まれます——請求先・日付・金額、そして明細行は並べ替え・絞り込み・エクスポートできるサブテーブルに。PDFの請求書はまずページごとに画像化され、それから読み取られます。APIを直接呼ぶ場合は、ページ画像を送ってください（公開APIはラスター画像を受け付けます——JPEG・PNG・GIF・BMP・TIFF・WebP）。返ってくる構造化結果は同じです。
請求書を一から記述する必要も、テンプレートを選ぶ必要もありません。会計側で使っている名称をそのまま fields として送り、請求書に合う検査を添えます。様式が未知なら autoFields を送り、返ってきた名称をそのまま宣言として使えます。明細行は children を持つ array フィールド 1 つです。
1 枚の請求書から返るもの:
data.values— 宣言した形そのままの業務データ。data.cells[path]— その値のboxとquad、およびverified・review・evidence（文字照合の裏付けで、text_match・printed_text・match_ratioを含みます）。data.review.flagged— 確認リスト。各項目はpathとreasonsを持ち、reasonsはランク順で 0 番目が代表です。data.normalized— スカラー型を宣言したフィールドの解析済み数値・ISO 日付。data.image— すべての座標が基準とする幅と高さ。
curl -s https://api.space-ocr.com/ocr/fields \
-H "Authorization: Bearer $SPACE_OCR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"image": "https://example.com/invoice-page-1.png",
"imageType": "url",
"fields": [
{ "name": "supplier", "type": "string", "required": true, "not_near": ["Bill To", "御中"] },
{ "name": "bill_to", "type": "string", "near": ["Bill To", "御中"] },
{ "name": "invoice_no", "type": "string", "required": true, "pattern": "^[A-Za-z0-9-]{4,}$" },
{ "name": "issue_date", "type": "date", "required": true },
{ "name": "due_date", "type": "date" },
{ "name": "subtotal", "type": "number", "min": 0 },
{ "name": "tax", "type": "number", "min": 0 },
{ "name": "total", "type": "number", "required": true, "min": 0 },
{
"name": "items", "type": "array",
"children": [
{ "name": "description", "type": "string" },
{ "name": "quantity", "type": "number" },
{ "name": "unit_price", "type": "number" },
{ "name": "amount", "type": "number" }
]
}
]
}'請求書をOCRする手順
- 請求書を追加アプリに請求書（PDFまたは画像）をドロップすると、各ページが画像にレンダリングされOCR待ち行列に入ります。AP自動化では /upload に投げ、読み取り完了時にWebhookを受け取ります。
- フィールドを宣言する会計側の名称をそのまま fields として送り、請求書に合う検査を添えます——請求書番号に required、日付に type date、金額に type number と min。様式が未知なら autoFields を送り、返ってきた名称を宣言として使います。明細行は children を持つ array フィールド 1 つです。
- 構造化された結果を読む業務データは data.values に入ります。座標と値ごとの判定は data.cells[path]（box・quad・verified・review・evidence）にあり、その座標の基準となる寸法は data.image が示します。
- 計上前に検証閾値ではなく data.review.flagged を回します。各項目が path と reasons を示すので、data.cells[path] に飛び、box か quad をページ上で強調して値を直します。編集は元のOCR値の隣に保存されます。
- エクスポートまたはクエリ会計取込用にCSV（UTF-8 BOM、明細行は展開済み）をダウンロードするか、保存済みシートを GET /view で where・sort・select を使ってクエリします——OCR再実行も追加料金もありません。
シンプルで予測できる料金
1 ページの読み取りが 1 クレジット——¥10（税込）で、アプリでも API でも同じ価格です。どのアカウントにも毎月 100 クレジットの無料枠があり、カード登録は不要、失敗時は課金なしです。定額プランは月間クレジット数・シート数・ストレージを追加します。