Turn receipt photos into a reviewed expense PDF

Implementation guide · untested

Source-supported actions are attributed evidence. Proposed steps, prompts, synthetic examples and checks are original editorial guidance; the workflow has not been run.

Why this agent / simpler alternative

Agent contribution

An agent can organize a mixed photo batch, make uncertainty visible in extracted fields, track owner corrections and assemble a reviewable packet. The important work is preserving traceability from each claimed expense to its receipt.

Simpler alternative

For a handful of clear receipts, use a scanner app and manually merge the images or PDFs. An employer's approved expense system may already provide extraction and submission with less setup.

Unsuitable when

The employer requires a different original-file format, the batch includes information that cannot be processed in the chosen environment, or the owner expects automatic reimbursement eligibility or tax determination.

Source-supported scope

A file-based recipe describes image cleanup, OCR review, approval-bound fields and A4 packing. It does not establish expense eligibility, reimbursement acceptance or tested Hermes compatibility.

Setup — required, optional and unknown

Required

1. An owner-approved photo folder, separate output folder and a retained original for every image.

2. A reviewer who can resolve merchant/date/amount/currency ambiguity and identify excluded receipts.

3. An approved processing environment with dependencies reviewed before installation; exact runtime compatibility must be tested.

4. The documented dependencies are Python, OpenCV, Pillow, pillow-heif, pytesseract, ReportLab, NumPy and system Tesseract; installation is not authorized here.

Optional

1. An employer-provided packet specification covering page format, cover details, ordering and maximum upload size.

2. A private receipt ledger with duplicate identifiers and permitted redaction requirements.

Unknown

1. Current dependency versions, installation compatibility and employer acceptance are unverified.

2. The required OCR language packs and performance on the actual receipt languages are unknown.

3. Data retention, model exposure and output-sharing requirements must be decided for the selected environment.

Inputs and access

1. Name

   Receipt photos

   Format

   Owner-supplied images with stable filenames; preserve originals

   Source or owner

   Claimant

   Access scope

   Named batch only

   Permission needed

   Authorize processing location; do not upload to another OCR service without approval.

2. Name

   Claim metadata

   Format

   Text: purpose, period, claimant display name and optional notes

   Source or owner

   Claimant

   Access scope

   Only what is needed on the packet

   Permission needed

   Approve any personal information included in the final output.

3. Name

   Packet requirements

   Format

   Employer specification or owner choices for format, grouping, captions and exclusions

   Source or owner

   Employer policy supplied by the claimant

   Access scope

   This claim preparation

   Permission needed

   The specification is a constraint, not authority to submit or contact the employer.

4. Name

   Reviewed field decisions

   Format

   Ledger: receipt ID, date, merchant, amount, currency, include flag, correction and approval state

   Source or owner

   Claimant reviewing the original images

   Access scope

   Exact displayed batch

   Permission needed

   Explicit approval of corrected values and inclusion before packing.

Documented source actions

1. 1

   Run scan.

   Input: Photos; Python image/OCR/PDF dependencies and Tesseract

   Output: manifest.json

   Checkpoint: One entry per image; review flags.

   Source: Prerequisites; Step 1 ↗

2. 2

   Show review table; correct and show it again.

   Input: Manifest

   Output: Reviewed fields

   Checkpoint: User approval required.

   Source: Step 2 ↗

3. 3

   Run confirm, then pack.

   Input: Approved fields

   Output: A4 PDF

   Checkpoint: Digest rejects changed data; verify output/page count.

   Source: Steps 2–3 ↗

Proposed implementation steps — unexecuted

1. 1

   Create an intake ledger with a stable receipt ID, original filename, orientation, apparent image quality and possible duplicate group. Keep originals unchanged. Ask the claimant which output details and privacy redactions are required; do not decide expense eligibility from appearance.

   Input: Original photos and packet requirements

   Output: Batch manifest and packet-design decisions

   Checkpoint: Every supplied image is accounted for, including unclear and potentially duplicated receipts.

2. 2

   For a later authorized trial, process disposable copies and compare each cleaned image with its original. Check all four receipt edges, totals, dates and faint text. Retain the original-to-processed link and mark any item needing recapture rather than hiding it in an attractive layout.

   Input: Intake ledger and approved local processing plan

   Output: Processed-image review set and image-quality exceptions

   Checkpoint: No amount, tax line or merchant header is cropped or made unreadable by cleanup.

3. 3

   Build a review sheet with one row per receipt and visible uncertainty on date, merchant, amount and currency. Resolve decimal separators and ambiguous currency symbols using the image and claimant. Mark duplicates as possible duplicates; let the claimant choose which is included.

   Input: Extracted fields, original images and duplicate groups

   Output: Corrected field ledger with inclusion decisions and unresolved cells

   Checkpoint: The claimant can inspect the relevant image beside each proposed value. Never guess a missing total or convert currencies implicitly.

4. 4

   Prepare a final approval view that includes included/excluded IDs, per-currency totals and intended cover/caption content. Record the exact approved version. If a field changes afterward, produce a fresh review view rather than treating earlier approval as covering the correction.

   Input: Corrected ledger and chosen packet options

   Output: Versioned approval record and packing-ready candidate data

   Checkpoint: No unresolved amount/currency ambiguity on included receipts; the approved totals equal the sum of included rows.

5. 5

   Create the candidate PDF and inspect every page at normal reading size. Reconcile visible receipt count to the inclusion ledger, verify numbering/order and ensure the cover totals agree. Check tall receipts and page boundaries individually rather than relying only on file existence.

   Input: Approved candidate data and later authorized packing step

   Output: Candidate PDF and page-by-page QA checklist

   Checkpoint: All included receipts are readable and identifiable; excluded duplicates are absent; separate currencies remain distinguishable.

6. 6

   Give the claimant the reviewed file and an exceptions summary. Retain original images and the approval ledger under the agreed retention policy. If the claimant wants submission, ask for the exact employer destination and authorize that separately; do not turn packet preparation into an expense claim submission.

   Input: Candidate PDF, QA checklist and claimant decisions

   Output: Reviewed local expense packet and handoff record

   Checkpoint: The claimant accepts the final file. No reimbursement acceptance or successful external submission is implied.

Original starter prompt — proposed

Origin

editorial_proposal

Text

Prepare a draft receipt-compilation plan for {photo_batch} under {packet_requirements}. Keep originals unchanged and use {output_folder} only for derivatives. Inventory every photo and flag possible duplicates, unreadable fields and ambiguous currencies. Show each proposed date, merchant, amount and inclusion decision with an image reference; obtain approval of the corrected table and packet options before any packing step. Show proposed installation/execution actions for separate authorization. Do not infer reimbursement eligibility, convert currency, submit a claim, share files or bypass an approval mismatch. Return a final page-by-page verification checklist.

Placeholders

1. photo_batch

2. packet_requirements

3. output_folder

Limitations

Original draft-first proposal. OCR values and packet layout still require human review; the prompt grants no installation, execution or submission authority.

Synthetic worked example — not an agent run

Status

synthetic

Label

Invented approval ledger and expected totals; no photos were processed and no PDF was generated

Content

Rows

1. Receipt id

   demo-01

   Merchant

   Example Stationery

   Date

   2026-09-02

   Amount

   12.4

   Currency

   CAD

   Include

   Yes

2. Receipt id

   demo-02

   Merchant

   Example Transit

   Date

   2026-09-03

   Amount

   7.6

   Currency

   CAD

   Include

   Yes

3. Receipt id

   demo-03

   Merchant

   Example Cafe

   Date

   2026-09-04

   Amount

   8.25

   Currency

   USD

   Include

   Yes

4. Receipt id

   demo-04

   Merchant

   Example Stationery

   Date

   2026-09-02

   Amount

   12.4

   Currency

   CAD

   Include

   No

   Reason

   Synthetic duplicate of demo-01

Expected totals

Cad

20

Usd

8.25

Expected included count

3

Approval state

pending

Pdf state

not generated

Artifact url

Not specified.

Costs and effort — unmeasured

Verified prices

Setup work

1. Review dependencies and privacy constraints; choose a processing location and record a safe installation plan.

2. Agree employer formatting requirements, image naming and final-review procedure.

Recurring work

1. Inspect image quality, correct fields, resolve duplicates and currencies, approve the exact table and review each final PDF page.

Unknowns

1. OCR accuracy, dependency installation effort, file size and page count for a real batch are unmeasured.

2. Model/API/hosting charges and claimant review time are unverified.

3. No accepted expense claim or reimbursement result is established.

Failure modes

1. Signal

   Cleaned image loses faint text or cuts off a total.

   Consequence

   The packet looks tidy while losing supporting evidence.

2. Signal

   A decimal, date order or currency symbol is ambiguous.

   Consequence

   A wrong amount or reporting period enters the claim.

3. Signal

   Two photos show the same purchase but both are included.

   Consequence

   The packet may duplicate an expense.

4. Signal

   Fields change after the owner approved the displayed version.

   Consequence

   The final file may no longer represent the approved claim data.

Recovery steps

1. Trigger

   Image cleanup harms legibility.

   Action

   Return to the preserved original, request a better image or retain a clearly identified original-format version. Recheck the affected row before packing.

   Stop condition

   Required evidence remains unreadable.

2. Trigger

   A field or duplicate cannot be resolved.

   Action

   Keep the item in the exceptions list and ask the claimant to correct or exclude it; do not silently guess.

   Stop condition

   An unresolved material field remains on an included item.

3. Trigger

   Packing refuses an approval mismatch.

   Action

   Show the changed table and obtain fresh approval through the normal confirmation path. Preserve the earlier version for traceability.

   Stop condition

   Never edit approval flags or bypass the integrity check.

4. Trigger

   Final PDF count or totals differ from the ledger.

   Action

   Withhold the candidate, trace the missing/extra receipt or stale field, and regenerate only after the corrected version is reviewed.

   Stop condition

   The PDF and approved ledger do not reconcile.

Source-observed and proposed approval boundaries

Source observed

User review precedes confirmation; changed reviewed data invalidates packing approval.

Editorial recommendations

1. Authorize processing destination and redact unneeded personal details before external transmission.

2. The claimant approves exact fields, exclusions and cover information.

3. Do not remove originals or alter receipt evidence to make it match an expected claim amount.

4. Submitting to an employer or insurer, sharing files and changing retention settings are separate actions.

Unexecuted validation plan

Fixture

Unexecuted proposal: four fabricated receipt images matching the synthetic ledger, including one duplicate, one tilted tall receipt, one faint amount and two currencies. In a disposable manifest, change a reviewed amount after confirmation for a negative integrity check.

Acceptance checks

1. All four input images appear in the intake record; three are included in the final candidate.

2. Expected totals remain CAD 20.00 and USD 8.25, with no combined currency total.

3. The owner can compare every approved field to the corresponding original image.

4. The post-confirmation change blocks packing until the updated data is reviewed and approved again.

5. Every visible receipt is legible, uncropped and traceable to its ID; final PDF count matches the selected set.

6. No external submission or original-image deletion occurs.

Stop conditions

1. Required dependency installation or execution is not authorized.

2. Unreadable included amount or unresolved currency.

3. Approval integrity failure is ignored or cannot be verified.

4. Final receipt count, totals or image content disagree with the approved record.

Executed

No

Limits

1. No receipt images, OCR, approval gate or PDF rendering were executed or tested.

2. The original describes a Linux-oriented file workflow; exact agent integration compatibility is not established.

3. Source publication date and reproducibility across dependency versions remain unknown.

4. Canadian employer, tax and reimbursement rules are outside this recipe; the owner must supply relevant packet requirements.

Guide source links

https://github.com/moonlight-lupin/agent-skills/blob/main/productivity/receipt-compiler/SKILL.md ↗
documented_steps; approval_boundaries.source_observed