Verified against ChatGPT · 2026-07-27
Reconcile a stack of receipt photos against an expense policy in one pass
Uses Vision to extract structured line-item data from multiple receipt photos at once and checks each one against a stated expense policy, flagging exactly which line and rule triggered a compliance issue instead of a flat pass/fail per receipt.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are extracting structured data from the uploaded receipt photos and checking each one against the expense policy below. Treat OCR uncertainty as a real risk to flag, not something to resolve by silently picking the most plausible reading. RECEIPT IMAGES Six photos from a two-day client trip — two restaurant receipts, one taxi receipt, two hotel folios, one printed conference registration receipt. EXPENSE POLICY Meals capped at $40/person for solo meals, $75/person for client-attended meals; ground transport uncapped but requires a business purpose note; hotel must be pre-approved rate or below. TRIP OR PURPOSE CONTEXT Client visit to close a renewal — the two restaurant receipts were client dinners with two attendees each, not solo meals. CURRENCY OR CONVERSION NOTES All receipts are in USD except the taxi receipt, which is in CAD — convert using the rate on the date of travel. EXTRACTION AND CHECK RULES For each receipt image, extract: merchant name, date, total amount, currency, and a line-item breakdown if the receipt shows one — do not collapse a receipt with multiple distinct items into a single total if the policy has per-category rules, since a policy that caps meal spend but allows unlimited ground transportation needs the two line items on one combined taxi-plus-lunch receipt distinguished, not summed. For any field where the photo is blurry, at an angle, or the text is genuinely ambiguous, say so explicitly next to that field rather than picking the more common-looking number and presenting it with the same confidence as a clearly legible one; an expense report built on a silently-guessed number is worse than one with an honest gap, since the guess looks verified when it isn't. Check each extracted receipt against every applicable policy rule individually and name which specific rule triggered any flag — "exceeds policy" is not useful on its own; the specific section and the specific dollar amount by which it was exceeded is what someone approving the report can actually act on. If the trip context indicates a legitimately higher-cost exception the policy itself allows for, apply the correct applicable rule, not the default one, and state which rule applies and why. If currency conversion is relevant, show the conversion rate and date used, since a rate that's a few days stale changes whether a receipt is actually within a dollar-denominated cap or not. OUTPUT FORMAT A table: Receipt (image reference) | Merchant | Date | Amount (as extracted, with currency) | Extraction confidence flag if any | Policy check result | Specific rule cited if flagged. After the table, a one-line total and a separate list of every receipt where extraction confidence was flagged, since those need a human to verify against the physical receipt before the report is submitted, not just before it's approved.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Vision-based extraction from a photo is fundamentally a probabilistic read of pixels, not a database lookup, so a blurry or angled total genuinely has more than one plausible reading, and a model under no instruction to flag that ambiguity will resolve it silently by picking whichever reading looks most typical for a receipt of that kind — which means the extracted number can be confidently wrong in a way that's indistinguishable, in the output, from a number that was clearly legible and correctly read; only an explicit confidence flag on a per-field basis preserves that distinction for whoever reviews the report. Requiring the specific policy rule cited alongside every flag, rather than a bare "exceeds policy," matters because expense report review is usually done by someone who cannot instantly recall which of several dollar caps applies to which expense category — a citation to the specific section and the specific dollar amount exceeded is the difference between a flag resolved in one glance and one that sends the approver back to reread the whole policy document. Distinguishing a group client meal from a solo meal, and applying the correspondingly different cap, addresses a real failure mode of naive expense-checking: a flat cap read without context flags every client dinner as over policy, generating false positives that then have to be manually reviewed and dismissed one by one, defeating the purpose of an automated first pass if every legitimate exception still requires a human to catch the mistake. Showing the specific conversion rate and date used for any non-native-currency receipt makes the currency conversion itself auditable — a stale or wrong rate silently shifts whether a receipt reads as within or outside a dollar-denominated cap, and a reviewer with no visibility into which rate was applied has no way to catch that kind of error even if something feels off.
Verified against
ChatGPT GPT-5.1 (Vision) · 2026-07-27
Changelog
- 2026-07-27 — Initial publish, verified against ChatGPT GPT-5.1 Vision.
Building this for real?
This is a free starting point. If you'd rather have what Scult builds built and running for your business, that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
