Invoice prompts: distinguish duplicate ingests from credits

Last updated: 4 Oct 202611 min read

tutorial

Duplicate detection combines vendor ID, invoice number, file hash, amount, and ledger state. The second file may be a retry, correction, or distinct obligation. A credit note has its own identity and relation to the original bill; a model cannot subtract a hypothetical credit to make totals agree. Ask for both file-level and business-level duplicate checks and for the accounting period. Resolve ambiguous identities through the controlled payables workflow before posting.

Operational case

North Quay's second INV-47 file has the same bytes as the first, so it is a duplicate arrival. The payable ledger still must be checked to learn whether INV-47 was already posted. No credit note appears in the current packet. If one arrives later for the two undelivered units, its vendor, reference, amount, and period will need independent verification. The model cannot preemptively create that missing record.

Upload A hash = Upload B hash
Business invoice candidate: INV-47, one identity
Posted ledger state: check separately
Credit in current packet: none
Second upload: not a second payable

Performance and review cost

Hashing B bytes and checking N candidate ledger records costs O(B+N) with indexed identities. A hash match establishes the same file, while changed formatting can still conceal a duplicate business obligation. Keep both checks so document packaging does not decide payment state.

Common Mistakes

Do not count a repeated upload as a second payable.
Do not invent a credit record.
Do not use a file hash as the only invoice identity.

Connected lessons

prompt engineering

invoice operations