Document Type Routing

Given one document (usually an OCR'd scan), decide which of a fixed set of types it is, so the calling system can run the matching extractor. The output is a single label read by code — get it wrong and the whole document goes to the wrong parser and every downstream field is garbage.

The label set is closed:

invoice | receipt | bank_statement | remittance_advice | packing_slip | w9 | unknown

unknown is a real answer — return it when no type's fingerprint is present, instead of forcing a guess.

Why a bare guess misroutes

The easy cases (a clearly-titled bank statement) route fine without help. The lift is in the near-misses, where the base model latches onto the dominant surface feature and routes to the wrong extractor:

• A receipt has a Subtotal / Tax / Total block, so it gets called an invoice.
• A packing slip has line items and quantities, so it gets called an invoice.
• A remittance advice lists a column of transactions with amounts, so it gets called a bank statement.
• An invoice stamped PAID gets called a receipt because of the stamp.

Each of these has a decisive fingerprint that overrides the surface. Route on the fingerprint, not the vibe.

Decision order

Check these discriminators first — the first one that fires decides the type. This order matters because the diagnostic feature beats the shared one.

1. Tax form title / TIN box + certification → w9.
2. Opening balance and closing balance for a period → bank_statement.
3. Line items but no monetary amounts at all (quantities only, no prices/total) → packing_slip.
4. References other documents' invoice numbers as being paid (amount paid, check/payment ref) → remittance_advice.
5. A tender line + change given (how it was paid), no amount owed, no due date → receipt.
6. An amount owed with a due date / terms and a Bill To → invoice.
7. None of the above fingerprints present → unknown.

Fingerprint catalog

Each type: what fires it, what it must NOT have, and the specific confusable it gets mistaken for.

invoice — a seller's request for payment (money still owed)

• Fires on: "Invoice No." / "Invoice #"; "Bill To" (often + "Ship To"); payment "Terms" (e.g. Net 30);

a Due Date; line items with unit prices; a Subtotal + Tax + Total / Amount Due / Balance Due.

• Must NOT rely on: the presence of a totals block alone — receipts have that too. The invoice

signature is amount owed forward + due date + Bill To, and no tender line.

• Confusable with receipt: invoice = money is unpaid and due; receipt = money is already paid.

A PAID stamp does not turn an invoice into a receipt — if it still has an Invoice No., Bill To, and Due Date, it is an invoice.

receipt — proof payment already happened

• Fires on: merchant name/terminal at top; itemized purchase; and the deciding pair — a tender /

payment method line ("VISA \\\\1234", "CASH", "Amount Tendered") plus Change Due, an auth/approval code, transaction/terminal ID, "Thank you".

• Must NOT have (as a receipt): "Bill To", a PO number, net terms, or a forward Due Date.
• Confusable with invoice: both show Subtotal / Tax / Total. The receipt is settled here and now —

it records how it was paid and the change given; it never states an amount still owed.

bank_statement — periodic account activity

• Fires on: an Opening / Beginning Balance and a Closing / Ending Balance; a statement period

(date range); a running list of debits/credits with a running balance; a (masked) account number.

• Confusable with remittance advice: both list a column of transactions with amounts. The

opening+closing balance pair is unique to a statement — a remittance advice never carries a running account balance.

remittance_advice — sent by the payer to say which invoices a payment covers

• Fires on: "Remittance" / "Payment Advice"; a list of invoice numbers being settled with their

amounts; Amount Paid (not "amount due"); a Payment / Check reference; often deductions or an early-pay discount taken.

• Direction test: it flows payer → payee and describes money already sent. An invoice flows

payee → payer and describes money to collect.

• Confusable with invoice and statement: vs invoice — it references existing invoice numbers as paid,

not new charges; vs statement — it settles specific invoices and has no running account balance.

packing_slip — a shipment's contents list

• Fires on: "Packing Slip" / "Delivery Note"; line items with quantities (ordered / shipped /

backordered); SKUs and descriptions; "Ship To"; sometimes carrier/tracking.

• Deciding absence: no prices, no subtotal, no tax, no total, no amount due — not one monetary value.
• Confusable with invoice: identical line-item + quantity layout. The total absence of money is the

fingerprint — if there are prices and a total, it is not a packing slip.

w9 — IRS Request for Taxpayer Identification Number and Certification

• Fires on: the title "Request for Taxpayer Identification Number and Certification" or "Form W-9";

federal tax-classification checkboxes (individual/sole proprietor, C corp, S corp, partnership, LLC); a TIN box (SSN or EIN); a certification signature line; "Give Form to the requester".

• Confusable with nothing transactional: it is a form to collect a taxpayer's info — no amounts,

no line items, no transaction. TIN + certification language is unmistakable.

Output

Return the label plus the single fingerprint that decided it — so the routing is auditable:

json
{"type": "receipt", "deciding_fingerprint": "card tender line + change due, no due date"}

Abstention

If a document carries no type's fingerprint — a letter, a memo, a page of prose with no invoice number, no balance pair, no tender, no line items, no TIN — return "type": "unknown". A wrong forced label sends the document to a parser that will fabricate fields from it; unknown routes it to human review instead.