---
name: receipt-pdf
description: 'File-type spec: digital PDF receipts and invoices. Routes to pdfplumber for digital-native; falls back to vision + OCR for scanned PDFs.'
title: Receipt or invoice (PDF)
category: file-types
status: active
author: system
metadata:
  priority: 0
---
## What this skill is

The receipt-pdf entry in the **File-Type Registry**. Distinct from `paper-pdf` because the extraction goal is structured fields (merchant / date / total / line items), not prose summary. Distinct from `receipt-image` because PDFs need text-layer detection FIRST before falling back to vision — a digital invoice extracts cleanly via pdfplumber and shouldn't waste a vision LLM call.

## Why this exists as a skill

Rule 12. Most invoices arrive as digitally generated PDFs (Stripe receipts, AWS bills, vendor invoices) where the text layer is reliable and free to extract. Only fall back to vision when pdfplumber returns no usable text — that's the marker for a scanned/photographed PDF.

## Tier ladder

- **fast** — pdfplumber digital-text extraction → LLM structuring pass. Cheap, fast, deterministic. Falls through (returns nothing) for scanned PDFs with empty text layers.
- **capable** — pdfplumber + page-render → vision LLM. Handles scanned invoices.
- **reasoning** (deferred to Phase 4+) — capable tier + post-extraction reconciliation pass for multi-page invoices with split totals.

## Field extraction expectations

Same target schema as `receipt-image`. The PDF text layer often delivers the line-item table verbatim — the LLM's job there is to map column headings to the schema, not to re-OCR.

## Extending

- Vendor-specific layouts (Amazon Business, Stripe, AWS): extend the YAML's `prompt_focus` with hints. Better long-term: a dedicated skill per vendor with its own pdfplumber extraction template.
- Multi-page invoices with continuation pages: the `chunking_strategy: fixed` keeps page boundaries; the LLM must reconcile a single total across pages. The `transaction-audit` skill catches mismatches downstream.