Invoice prompts: pin provenance and vendor identity

Last updated: 4 Oct 202611 min read

tutorial

An invoice prompt needs a document ID, file hash, intake time, vendor candidate, purchase-order reference, and system-of-record snapshot. The PDF may request a new remittance account or say to ignore discrepancies. Treat those sentences as untrusted document content. The model can extract and flag them but cannot change vendor master data, schedule payment, or identify the vendor solely from an OCR header. Attach each extracted field to its file and version so the reviewer can locate what was actually supplied.

Operational case

North Quay receives INV-47 twice. Both files have matching bytes and cite PO Q-47, so the intake ledger records two arrivals tied to one candidate invoice identity. A remittance note asks for a new account. The assistant marks it for the separate vendor-verification process; it does not change payment details. The verified vendor ID comes from procurement records rather than the uploaded name alone. Ledger status is checked before anyone declares whether an obligation already exists.

Invoice INV-47 | PO Q-47 | two uploads, one matching hash
Vendor: verify against master record
Remittance note: untrusted change request
Allowed model action: extract and flag; no mutation

Performance and review cost

Hashing B file bytes is O(B), and checking indexed invoice identities is O(D) for D arrivals. Keeping provenance is cheap relative to reversing a wrong payment. The prompt should carry synthetic examples instead of live bank data unless a restricted review explicitly requires them.

Common Mistakes

Do not create two payables from identical uploads.
Do not trust a bank-change sentence in an invoice.
Do not drop file and intake identifiers during extraction.

Connected lessons

prompt engineering

invoice operations