ClaimSniff FSA Agent

Inspiration

My background in HR operations made me interested in the gap between offering a benefit and making it easy for people to use. An FSA can be valuable, but using it means sorting receipts, checking eligible expenses, and preparing claims alongside everything else in your life.

I built ClaimSniff to reduce that administrative work.

What it does

ClaimSniff watches a local receipts folder, extracts line items, checks them against eligibility rules, and prepares a readable claim summary. Unrecognized items go to human review. Approval records the user’s decision and updates a locally tracked demo balance; users still file through their own administrator.

I tested it with my actual CVS receipt. It prepared a $6.49 request for SPF 30 lip balm and held two abbreviated gum descriptions for review, excluding them from the requested amount.

How I built it

I built ClaimSniff in TypeScript using the Strands Agents SDK and Claude Sonnet 4.5, with support for Amazon Bedrock or the Anthropic API.

The model extracts information and coordinates tools. Deterministic code applies eligibility rules, checks receipt arithmetic, detects duplicates, and calculates amounts in integer cents. An append-only ledger records approved amounts, and approval is bound to the exact packet and amount shown to the user.

I built it solo as a non-engineer founder, using Claude Code to implement and iterate, with additional code auditing and regression testing.

Challenges and lessons

My real receipt exposed a problem the synthetic examples hadn’t: promotional pricing confused extraction. Rather than accepting incorrect amounts, ClaimSniff checks whether the extracted figures reconcile with the printed total. A mismatch triggers one reread; a second failure requires human review.

Auditing also exposed weaknesses in duplicate detection and interrupted approvals. Fixing those taught me that a convincing demo is only part of building an agent: its safeguards must hold when steps fail or repeat.

The project now has 39 passing automated tests, including checks for repeated approvals, interrupted writes, extraction retries, and attempts to override eligibility rules.

What’s next

The current prototype uses a clearly labeled synthetic account. Receipt images are sent to the configured cloud model for extraction; records and summaries are stored locally. It does not connect to an FSA administrator or submit claims.

Next, I want to improve receipt recognition and make reviewing unfamiliar items easier. My HR operations perspective keeps the goal practical: less work between having a benefit and being able to use it.

Built With

• 4.5
• agents
• amazon
• anthropic
• api
• bedrock
• claude
• code
• node.js
• sdk
• sonnet
• strands
• typescript
• vercel