What Happens When AI Reads Your Receipt but Doesn’t Know Your Return Policy?

You buy something, put the receipt somewhere safe, and tell yourself you’ll remember the return window.

A few weeks later, you find the receipt. The deadline? Already gone. Or maybe you can’t even remember when it was supposed to be.

That everyday problem inspired ReturnRadar, a receipt-powered purchase tracker I built for the DEV Challenge.

The initial idea was straightforward: upload a receipt, extract the important details, and track return deadlines. But while building it, I realized that reading a receipt wasn't the hardest part.

The real challenge was deciding what the application should do when the receipt was blurry, the purchase date was missing, or the return policy wasn't clear.

I didn't want an AI-generated date to look trustworthy just because it appeared in a polished interface.

So I built ReturnRadar around one principle: when the evidence isn't clear, the application should say so instead of guessing.

What is ReturnRadar?

ReturnRadar helps people organize purchases and keep track of return deadlines without relying on memory.

Try the live app: https://return-radar-ruby.vercel.app/

Explore the code: https://github.com/shrutikotgire0129/ReturnRadar

Alternative deployment: https://returnradar-0ftg.onrender.com/

Users can upload receipt images or PDFs, extract purchase information with AI, review and edit the extracted details, manage purchase records, and track upcoming or expired return windows.

The application also supports Google Calendar export for return deadlines—but only after the user has reviewed and explicitly verified the deadline.

Here's what the dashboard looks like:

The dashboard brings purchase records and return statuses together so users can keep track of their deadlines.

The problem I wanted to solve: AI can be confidently wrong

Imagine uploading a receipt that clearly shows the merchant and total price but contains no return policy.

Or imagine a receipt with a blurry purchase date. Perhaps the policy mentions a return period, but the available information doesn't establish exactly when the deadline falls.

An AI model might still return a plausible date. The result could look complete, even when the underlying evidence doesn't support it.

For a return-deadline tracker, that isn't a harmless mistake. Someone could rely on an invented date, miss the actual return window, and lose the opportunity to get a refund.

I wanted the application to distinguish between information it could extract and information that still needed human review.

That led to a simple rule:

Extract what the evidence supports. Flag what it doesn't. Never treat a guess as a verified deadline.

How I used an open-weight vision model

For receipt extraction, ReturnRadar uses Qwen3.8-27B through the Groq API.

The model processes the uploaded receipt and returns structured information, including:

• Merchant and item name
• Purchase date and total price
• Return window and return-by date, when supported by the available information
• Warranty information, when available
• Receipt or policy evidence
• Confidence information, warnings, and review requirements

The flow is straightforward: the user uploads a receipt, a Next.js API route sends it for processing through Groq, and the application handles the model's response before presenting the extracted information in the interface.

I chose a vision-capable model because receipts aren't neatly structured database records. They're documents with different layouts, small text, inconsistent formatting, and sometimes poor image quality.

Using an open-weight model also gives the project flexibility to explore different model and deployment options as it evolves.

There is an important distinction, though: ReturnRadar currently uses hosted inference through Groq. Qwen does not run locally in this version of the application.

The model's open weights make different deployment arrangements possible to explore, but using an open-weight model doesn't automatically mean the application runs privately on the user's device.

Here's the receipt upload interface:

Users upload a receipt to extract purchase details that they can review before relying on them.

Turning AI output into a safer user experience

Getting structured output from a model is only one part of the problem. The application also needs rules for deciding what users can do with that output.

I focused on four areas.

1. Keep evidence visible

ReturnRadar keeps receipt evidence, return-policy evidence, and extraction warnings alongside purchase details.

This gives users context for reviewing the result instead of asking them to trust a date without knowing where it came from.

2. Flag incomplete or uncertain records

When important information is missing, a return policy cannot be established, or an extraction needs further review, the purchase can be marked Needs review.

The interface doesn't have to pretend every receipt was processed successfully. Sometimes the most useful result is an honest warning that the available information isn't enough.

3. Separate extraction from verification

An extracted date is not automatically treated as a verified deadline.

The user must confirm that they checked the retailer's actual return policy. This confirmation records the user's action; it does not mean the application independently contacted the retailer or verified the policy itself.

That distinction matters because extracting a date and establishing that the date is correct are two different tasks.

4. Prevent calendar export for unsupported deadlines

ReturnRadar requires the relevant receipt evidence and a deadline marked as verified before allowing Google Calendar export.

If those requirements aren't met, the application blocks the action and explains why.

A reminder based on an unsupported date could be worse than no reminder at all. It might give someone false confidence that they still have time to return a product.

Here's the purchase details view:

The purchase details view gives users a place to inspect extracted information and its review status.

What else I built

ReturnRadar is built with Next.js, React, and TypeScript. Purchase records are persisted in the browser using local storage.

The current version includes:

• A dashboard for purchase records and return statuses
• Receipt uploads for supported image and PDF formats
• AI-assisted extraction with editable fields
• Search and filtering for purchases
• Persistent purchase records across page refreshes
• Purchase status management
• Evidence, warnings, and review states
• Google Calendar export for eligible, verified deadlines

I also tested scenarios beyond a clean, readable receipt: blurry images, missing purchase dates, unclear amounts, and ambiguous return policies.

I checked that uncertain information could be flagged for review, that corrections persisted after refreshing, and that calendar export remained blocked when the deadline wasn't sufficiently supported or verified.

The goal wasn't to make every receipt appear successful. It was to make the application behave responsibly when the available information was incomplete.

What I learned about building with open AI

This project reinforced a lesson I'll carry into future AI applications:

A model's answer should not automatically become the application's truth.

A model can extract information, but the surrounding software still needs to decide what actions are appropriate based on that information.

For ReturnRadar, that meant separating extraction from verification, keeping evidence attached to results, and preventing calendar export when a deadline hadn't been confirmed.

Open-weight models make it possible to experiment with model selection and explore different deployment strategies. But openness alone doesn't guarantee privacy, accuracy, or safety. Those properties also depend on the inference provider, data handling, validation, and the decisions made in the application itself.

There is also a privacy consideration in the current implementation: because ReturnRadar uses Groq-hosted inference, uploaded receipt content is sent to that external service for processing. Purchase records are stored in the browser, but receipt processing does not happen entirely on the user's device.

A future version with local inference would be worth exploring for users who want receipt processing to remain on their own hardware.

Try it and share feedback

If you have a few minutes, try the live application or explore the repository.

I'd especially appreciate feedback on the receipt-review experience, the way uncertainty is communicated, and what would make you comfortable relying on an AI-assisted tool for something as practical as a return deadline.