Consumer Receipt Management
A free consumer receipt wallet in apps/native — scan via LLM vision or enter manually. Merchant-funded via aggregated spend insights; consumers are never charged.
Status: Accepted (direction); implementation deferred
Date: June 2026
Decision: Add a receipt wallet to apps/native where users store every purchase (befday merchant or not), via photo scan (LLM-vision auto-fill) or manual entry. Scanning is free for consumers. Cost and upside are merchant-funded (aggregated spend insights + targeting), never by charging consumers.
TL;DR
A free receipt wallet in apps/native. Manual entry is primary; LLM-vision scan is the accelerator. It captures a user’s total spend (incl. non-befday merchants), which powers personalization and a merchant insights pitch. Consumers are never charged; monetization is merchant-side.
Context
Today befday only sees spend at befday merchant POS stores. The consumer app (apps/native) is a birthday-perks / loyalty app — discover shops, bookmark, claim vouchers, track stamps. It has no record of spend outside the befday network.
Receipt management was proposed for three reasons:
- Data loop — capture a user’s total spend (incl. non-befday merchants) to power perks and personalization.
- Retention — a durable reason to keep the app installed (“my purchases live here”).
- Merchant sales wedge — “befday users near you spend RM X/month on coffee” is a strong acquisition pitch.
Open question: is scanning too expensive, and should consumers pay for it?
Decision
Build a free consumer receipt wallet in apps/native. Manual entry is the primary, always-available path; LLM-vision scan is the accelerator. Monetization is merchant-funded (aggregated, anonymized spend insights + birthday-perk targeting). Consumers are never charged.
Why not charge consumers
- Scanning is cheap (see below) — a consumer paywall loses more in adoption than it recovers.
- A paywalled receipt wallet churns; bank/expense apps already scan receipts for free.
- The data is the product, monetized merchant-side. Charging users to contribute it is backwards.
Why it works (with the right framing)
A standalone “receipt vault” is a low-engagement utility. It works because it feeds the perks engine:
Free consumer scanning → total spend data (incl. non-befday merchants)
│ │
Retention (wallet) Merchant insights & targeting
│ │
Perks personalization → "befday users spend RM X/mo on coffee
near you — run a birthday campaign"Cost Analysis (receipt OCR / auto-fill)
Two approaches; prices approximate, 2026, USD.
Option A — Dedicated receipt OCR APIs
Purpose-built; return structured merchant / date / total / tax / line items.
| Provider | Rough price | Notes |
|---|---|---|
| Veryfi | ~$0.08–0.16/receipt | Best accuracy, full line-item extract |
| Taggun | ~$0.07–0.10/receipt | Cheaper, decent |
| Mindee | ~$0.10/receipt | Good DX, small free tier |
| Google Document AI (Expense) | ~$0.10/page | Scales with GCP |
| AWS Textract (AnalyzeExpense) | ~$0.10/page | AWS ecosystem |
Option B — Multimodal LLM vision (chosen direction)
Send the photo to a vision model; prompt for structured JSON; validate; fall back to manual edit on low confidence.
| Model | Rough cost/receipt | Notes |
|---|---|---|
| Gemini Flash-class | ~$0.001–0.005 | Cheapest, capable for receipts |
| GPT mini/vision | ~$0.003–0.01 | Good, structured output |
LLM vision is 10–100× cheaper than dedicated OCR and “good enough” for receipts. Trade-off: build your own validation / retry / merchant normalization, and slightly lower accuracy on crumpled thermal receipts (mitigated by manual-edit fallback).
Projected spend (Gemini Flash-class @ ~$0.003/receipt)
| Scale | Monthly scans | Est. cost/month |
|---|---|---|
| 1,000 users × 5 receipts/mo | 5,000 | ~$15 |
| 10,000 users × 8 receipts/mo | 80,000 | ~$240 |
Manual entry costs ~nothing (storage only). Cost is negligible until serious scale.
Cost-control measures (no consumer charge)
- Use LLM vision, not dedicated OCR — ~30× cheaper per receipt.
- Manual entry is primary, scan is the accelerator — data keeps flowing even when a scan fails.
- Soft per-user monthly scan cap (e.g. 30–50) purely as abuse protection, not monetization; ~99% of users never hit it.
- Cache / dedupe — store extracted JSON, never re-OCR the same image.
Privacy & Compliance (must-do)
Aggregating consumer spend has real legal + trust implications (Malaysia PDPA; app-store rules):
- Opt-in with clear consent (“help us send you better birthday perks”).
- Sell merchants aggregated / anonymized insights only — never individual receipts.
- Be transparent in-app; trust is the entire reason a user keeps the app.
Data Model Impact (sketch)
New consumer-side tables, keyed by user.id, optionally linked to a befday shops.id when the merchant is recognized.
receipts
| Column | Type | Notes |
|---|---|---|
id |
uuid | PK |
user_id |
text | FK → user.id |
shop_id |
uuid | nullable FK → shops.id (set when merchant recognized) |
merchant_name |
text | as captured / normalized |
merchant_category |
text | nullable (e.g. café, grocery) |
total_cents |
integer | receipt total |
tax_cents |
integer | nullable |
currency |
text | ISO 4217, default MYR |
purchased_at |
timestamp | date on the receipt |
source |
enum | scan | manual |
image_url |
text | nullable — stored photo |
ocr_confidence |
integer | nullable — basis points; drives manual-review prompt |
created_at |
timestamp |
receipt_items
| Column | Type | Notes |
|---|---|---|
id |
uuid | PK |
receipt_id |
uuid | FK → receipts.id |
name |
text | line-item description |
qty |
integer | default 1 |
price_cents |
integer | line total |
Note: this is consumer-owned data, distinct from merchant POS
orders. A receipt may be linked to ashop_idbut is never a substitute for a server-verifiedordersrecord.
Scan Flow (sketch)
1. User taps "Add receipt" → choose Scan or Manual
2. Scan: expo-camera capture → upload image
3. Server sends image to LLM vision → structured JSON
(merchant, date, total, tax, line items, confidence)
4. Low confidence → prefilled manual-edit screen for correction
5. Save → receipts (+ receipt_items); link shop_id if merchant recognized
6. Feed totals into perks/personalization (opt-in)Consequences
| Type | Consequence |
|---|---|
| Pro | Closes the data loop beyond befday merchants; powers personalization and a strong merchant pitch. |
| Pro | Retention utility that complements (not replaces) the perks core. |
| Pro | Cheap to run (~$15–240/mo at realistic scale); no billing complexity for consumers. |
| Con | Receipt OCR is commoditized — only valuable because it feeds the perks engine; must not ship as a standalone vault. |
| Con | Requires explicit privacy/consent work (PDPA) and anonymized aggregation before any merchant-facing insight. |
| Con | LLM-vision accuracy on poor receipts needs a solid manual-edit fallback. |
Resolved Decisions
| Question | Decision |
|---|---|
| Build it? | Yes — as a perks-integrated wallet, not a standalone vault |
| Where? | apps/native (consumer) |
| Scan tech | LLM vision (Gemini Flash-class), structured JSON + validation |
| Charge consumers? | No — free scanning; manual entry always available |
| Monetization | Merchant-funded — aggregated/anonymized spend insights + perk targeting |
| Cost control | LLM vision, manual-primary, soft per-user scan cap, dedupe/cache |
| Privacy | Opt-in consent; merchants see aggregates only (PDPA) |
Open Questions
- Merchant normalization: how to map free-text merchant names to canonical merchants / categories (and to befday
shops)? - Perk linkage: what spend signals trigger which perks (category thresholds, share-of-wallet)?
- Insight productization: what exactly do merchants buy, and at what aggregation floor (min cohort size) to stay anonymized?
- Image retention: keep receipt photos long-term, or extract-then-discard for privacy/storage?
- Phasing: ship manual-only first (zero variable cost) and add scan once perk linkage proves retention?