Work / Records and approvals
Turn receipt photos into records you can review.
Receipts pile up, and someone retypes them later. The goal is to capture the paper at the moment of purchase and still keep a human in charge of what gets recorded.
- Input
- A photo of a receipt, printed or handwritten
- Reader
- An AI vision model that returns structured fields
- Control
- A person confirms or corrects before saving or sending
- Status
- Demo (three variants)
The workflow
Receipts reach a business as paper, phone photos, and screenshots. Someone later types the vendor, date, tax and total into accounting software. That step is slow, easy to put off, and easy to get wrong.
I built three demos to test one idea: read the receipt from a photo, but treat the reading as a draft. A bad extraction should be fixable before it pollutes the records.
Three variants, what each does
- Chat intake, WhatsApp. A person sends a photo to a WhatsApp number. The reply lists what was read and asks for 1 to confirm or 2 to retry. The original image is stored first, so it is preserved even if reading fails. It began as a demo for other document types, with receipts added for demonstration.
- Chat intake, Discord. A person posts a photo in a channel. The reply summarizes the receipt and asks for 1 to save or 2 to discard. Nothing is stored until they confirm. Confirmed receipts go to a database with the image, handwritten receipts are accepted, and records are marked deleted rather than erased. This variant stops at the database and does not touch accounting software.
- Web app with accounting handoff. A signed-in user uploads a photo. The app reads it and saves it as pending review, flagging its confidence and which fields it is unsure about. The reviewer edits and then chooses Approve and send, which creates the expense in a QuickBooks sandbox company.
Why I made these choices
- Confirm before save. The Discord variant originally saved immediately. I changed it so a bad reading cannot enter the records without a person seeing it.
- Keep a review step in the middle. In the web app I kept the saved draft rather than sending straight to accounting. A wrong total is fixed there, and the data is easy to query for other uses.
- Say what the reader is unsure about. The model reports a confidence level and names the specific fields it was unsure of, so the reviewer looks at those first.
- Isolate the handoff. If the accounting step fails, the saved receipt is not damaged and the reviewer can retry.
- Match vendors carefully. The QuickBooks handoff normalizes vendor names so small variations in how a name prints don't create duplicate vendors, and maps each expense category to an account.
What stays manual
- A person confirms every receipt. Nothing here approves spending or posts to the books on its own.
- Someone decides which accounts each category should map to for a real company. The demo uses default accounts.
- Connecting to a live QuickBooks company needs Intuit's production approval, which I have not claimed.
- CapturePhoto is uploaded or sent in chat; the image is storedPerson
- ReadAI extracts vendor, date, tax, total, category, and flags uncertain fieldsAutomatic
- ReviewReviewer checks the draft and corrects anything wrongPerson
- ApproveReviewer approves the receiptPerson
- Hand offAn expense is created in a QuickBooks sandbox companyAutomatic
- RetryIf the handoff fails, the receipt stays saved and can be sent againPerson