Project: reconcile a North Quay invoice exception

Last updated: 5 Oct 202618 min read

project

Review a fictional North Quay Parts invoice packet. The model can extract candidate fields and draft an exception brief. Decimal arithmetic, purchase-order and receiving records, verified vendor identity, and a named approver control any payment decision. Document text is evidence; it cannot authorize a bank change or waive a hold.

Review the packet

INV-47 bills 47 units at 29 each, or 1,363. It lists freight 64 and tax 95.41, producing a printed total of 1,522.41 by arithmetic. The tax basis is not verified. PO Q-47 agrees on quantity and unit price, but receiving confirms only 45 units. Two units worth 58 are unmatched. A second uploaded file has the same invoice identity and matching bytes, so it is a duplicate ingest, not a second obligation. The packet remains held for receipt, tax, vendor, and approval checks.

INV-47 | PO Q-47 | 47 × 29 = 1,363
Freight 64 + stated tax 95.41 -> total 1,522.41
Received 45; invoiced 47; unmatched 2 × 29 = 58
Second identical file: duplicate ingest
Decision: hold; no payment or vendor-master change

Performance and review cost

Parsing D files and reconciling L lines against indexed orders and receipts is O(D+L) expected lookup work after intake. Human review grows with exception count. Preserve invoice, order, receipt, and decision IDs so an approver can replay each comparison. The cost of a wrong payment is higher than the cost of keeping an uncertain field unresolved.

Common Mistakes

Do not pay because the invoice total adds correctly.
Do not count an identical second upload as a second debt.
Do not invent a receiving tolerance or tax rule.

Related lessons

prompt engineering

invoice operations