# Product Feature: **AI-Powered Smart Receipt Scanner & Expense Categorisation** ### *For a Personal Finance Management Application* --- ## 📋 FEATURE OVERVIEW CARD | Field | Detail | |-------|--------| | **Feature ID** | FIN-2024-047 | | **Feature Name** | AI-Powered Smart Receipt Scanner & Expense Categorisation | | **Product Area** | Expense Management | | **PO Owner** | [Your Name] | | **Created Date** | June 2025 | | **Target Release** | Q3 2025 — Sprint 23–26 | | **Priority** | P1 — High | | **Effort Estimate** | L (Large — 8 sprints) | | **Status** | Ready for Refinement | --- ## 1. 🎯 PROBLEM STATEMENT > *"Users currently spend an average of 47 minutes per week manually logging, categorising, and reconciling receipts and expenses. This friction causes 68% of users to abandon consistent expense tracking within the first 30 days of using the app, directly undermining the core value proposition of the product."* Users photograph receipts but have no automated way to extract data. They must manually: - Type merchant names, amounts, dates - Choose a category from a flat list - Match entries against bank statements - Reconcile discrepancies at month end This creates cognitive load, error rates, and ultimately **churn**. --- ## 2. 📖 FULL FEATURE DESCRIPTION ### What We Are Building A full end-to-end **intelligent receipt capture and processing pipeline** embedded within the mobile app (iOS and Android) that allows users to: 1. **Photograph a receipt** (single shot or multi-page) using the device camera or import from gallery/email/cloud storage 2. **Automatically extract** key data fields via OCR + Large Language Model (LLM) processing: - Merchant name - Date and time of transaction - Line items with individual prices - Subtotal, tax, tip, and total - Currency - Payment method (if printed on receipt) - Store location / address 3. **Intelligently categorise** the expense using a combination of: - Merchant category codes (MCC) - Merchant name lookup against a curated database - LLM contextual classification - User's personal historical categorisation patterns (personalised ML model per user) 4. **Auto-match** scanned receipts against imported bank/card transactions using fuzzy matching on amount + date + merchant proximity 5. **Surface confidence scores** so users know when the system is uncertain and needs human review 6. **Learn from corrections** — every time a user corrects a categorisation or field, the personal model updates 7. **Generate structured expense records** that flow into budgets, reports, and tax summaries ### What We Are NOT Building (Out of Scope v1) - Video receipt scanning - Automated expense report submission to employers (v2) - Integration with accounting software like Xero/QuickBooks (v2) - Physical receipt mailing/scanning service - Real-time in-store scanning via POS integration --- ## 3. 💡 BENEFIT HYPOTHESIS ### Primary Hypothesis > *"If we reduce the manual effort of expense logging to under 10 seconds per receipt, then users who scan at least 3 receipts in their first week will have a 30-day retention rate of 75%+, compared to the current 32% baseline, because the product delivers immediate, tangible time savings that reinforce the habit of financial tracking."* ### Supporting Hypotheses | # | Hypothesis | Metric | Target | Baseline | |---|-----------|--------|--------|----------| | H1 | Automated categorisation reduces time-per-expense-entry | Avg seconds per entry | <10s | 47s | | H2 | Auto-matching reduces reconciliation abandonment | Reconciliation completion rate | >80% | 34% | | H3 | Users trust the AI enough to reduce manual corrections over time | Correction rate | <8% after 60 days | N/A (new) | | H4 | Feature drives upgrade from Free to Premium tier | Free→Premium conversion | +4.5 pp | 11% current | | H5 | Reduced friction increases weekly active usage | WAU on expense module | +55% | | | H6 | Feature becomes a top acquisition driver via word-of-mouth | Referral attribution to feature | 20% of new signups mention it | 3% | ### Business Value | Value Type | Detail | |-----------|--------| | **Revenue** | Estimated $2.1M ARR uplift from tier conversion at scale (500k users) | | **Retention** | 30-day churn reduction from 68% → 40% = $840k saved CAC annually | | **Competitive Moat** | First personal finance app in our tier with personalised ML categorisation | | **Data Asset** | Merchant + category dataset becomes proprietary training asset | | **NPS Driver** | Receipt scanning is #1 requested feature in CSAT surveys (asked by 71% of respondents) | --- ## 4. ✅ ACCEPTANCE CRITERIA ### Epic-Level Acceptance Criteria (Business Outcomes) ``` GIVEN the feature is released to 100% of users WHEN measured at 60 days post-release THEN: - Average time to log an expense via receipt scan ≤ 10 seconds (p50) - Auto-categorisation accuracy ≥ 88% (validated by user correction rate) - Receipt-to-transaction match rate ≥ 75% for users with connected bank accounts - Crash rate for scanner feature < 0.1% of scan sessions - 30-day retention for users who scan 3+ receipts in week 1 ≥ 65% ``` --- ### User Story 1: Camera Capture & OCR Extraction ``` AS A user with a paper receipt I WANT to photograph it with my phone camera SO THAT the app automatically reads all the key data without me having to type anything ACCEPTANCE CRITERIA: Scenario 1 — Successful single-receipt scan GIVEN I am on the Add Expense screen WHEN I tap "Scan Receipt" and photograph a clearly lit, unfolded receipt THEN the app should: - Process the image in ≤ 4 seconds on a standard 4G connection - Extract and display merchant name with ≥ 95% accuracy on standard printed receipts - Extract total amount with ≥ 98% accuracy - Extract date with ≥ 95% accuracy - Show a review screen pre-populated with all extracted fields - Highlight any fields with confidence < 80% in amber for user attention Scenario 2 — Poor image quality GIVEN I photograph a crumpled or poorly lit receipt WHEN OCR confidence is below 60% for the total amount THEN the app should: - Show a "Retake or Enter Manually" prompt - Provide a tip overlay (e.g., "Try better lighting") - NOT silently submit a low-confidence entry - Still save the receipt image regardless Scenario 3 — Multi-page/long receipt GIVEN I have a receipt longer than one phone screen WHEN I am in scan mode THEN I should be able to: - Tap "Add another page" to capture up to 4 pages - See the system stitch pages and extract as single record Scenario 4 — Import from gallery/email GIVEN I have a receipt image saved in my phone gallery OR a receipt forwarded to my registered email WHEN I tap "Import" or open the email deep link THEN the same extraction pipeline should trigger - Email import processes within 30 seconds of receipt arrival - Image import behaves identically to camera scan Scenario 5 — Unsupported receipt type GIVEN I photograph something that is not a receipt (e.g., a random document) WHEN OCR processing completes THEN the app should: - Detect non-receipt content with ≥ 90% accuracy - Show a friendly "This doesn't look like a receipt" message - Offer manual entry as fallback - NOT create a blank or corrupted expense record ``` --- ### User Story 2: Intelligent Auto-Categorisation ``` AS A user who has scanned a receipt I WANT the app to automatically assign the correct spending category SO THAT I don't have to manually select from a category list every time ACCEPTANCE CRITERIA: Scenario 1 — High-confidence categorisation GIVEN a receipt from a known merchant (e.g., "McDonald's") WHEN extraction is complete THEN the system should: - Assign category "Eating Out" with confidence ≥ 95% - Display the category as pre-selected (not requiring user confirmation) - Show a small confidence indicator (e.g., sparkle icon = AI suggested) Scenario 2 — Low-confidence categorisation GIVEN a receipt from an ambiguous merchant (e.g., "The Corner Store") WHEN confidence score is between 60–79% THEN the system should: - Show top 3 suggested categories with confidence percentages visible to the user - Require user to confirm or select before saving - Pre-select the highest confidence option Scenario 3 — Unknown merchant GIVEN a receipt from a merchant not in the database AND not inferable from context WHEN confidence score is < 60% THEN the system should: - Default to "Uncategorised" - Prompt user with: "Help us learn — what type of expense is this?" - Store the merchant → category mapping for future use (subject to privacy rules — only affects that user's personal model) Scenario 4 — User correction and learning GIVEN the system has categorised a receipt as "Groceries" WHEN the user changes it to "Business Expenses" THEN the system should: - Save the correction immediately - Update the user's personal model weighting for that merchant - Apply the learned preference on next scan from same merchant within the same session - Show a "Got it! We'll remember that" micro-toast Scenario 5 — Category not existing GIVEN a user wants to assign a category that doesn't exist in the default taxonomy WHEN they type a new category name THEN the system should: - Allow creation of custom categories (max 20) - Apply custom category to the current expense - Make custom category available in all future expense entry methods ``` --- ### User Story 3: Receipt-to-Transaction Auto-Matching ``` AS A user with a connected bank account I WANT scanned receipts to automatically match to my bank transactions SO THAT I have a complete picture with both the receipt detail AND the bank record without duplication ACCEPTANCE CRITERIA: Scenario 1 — Exact match GIVEN a scanned receipt showing £34.50 at Waitrose on 12 June 2025 AND a bank transaction showing £34.50 at WAITROSE on 12 June 2025 WHEN matching runs (within 60 seconds of scan) THEN the system should: - Link the receipt to the transaction - Show a green "Matched" indicator on both records - Merge into a single unified expense record - NOT create a duplicate entry Scenario 2 — Fuzzy match (slight amount variance) GIVEN a receipt total of £34.50 AND a bank transaction of £34.51 (rounding difference) WHEN matching runs THEN the system should: - Match within ±£0.05 tolerance for amounts ≤ £100 - Match within ±0.1% tolerance for amounts > £100 - Flag as "Likely Match" (amber) requiring one-tap user confirmation Scenario 3 — No match found GIVEN a scanned receipt with no corresponding bank transaction found within 5 days WHEN the matching window expires THEN the system should: - Mark the receipt as "Unmatched — Cash/Pending?" - Offer "Mark as Cash Transaction" or "Waiting for Bank" options - Surface in a weekly "Receipts to Review" digest Scenario 4 — Multiple potential matches GIVEN a receipt from Starbucks for £4.50 AND two bank transactions for £4.50 in the same week from Starbucks WHEN matching runs THEN the system should: - Present both candidates to the user to select - Show date/time context for each candidate - NOT auto-match ambiguous cases Scenario 5 — Offline scan GIVEN a user scans a receipt with no internet connection WHEN connectivity is restored THEN the system should: - Process the image using on-device OCR (degraded mode) - Queue for server-side LLM processing on reconnection - Attempt matching retroactively on next sync - Clearly indicate "Processed offline — some features may be limited" ``` --- ### User Story 4: Review, Edit & Save Flow ``` AS A user reviewing an auto-extracted expense I WANT a clear, fast review screen SO THAT I can confirm, correct, and save in minimal taps ACCEPTANCE CRITERIA: Scenario 1 — Happy path confirmation GIVEN all fields are extracted with high confidence WHEN the review screen loads THEN: - User should be able to save with a SINGLE TAP (no mandatory edits) - Receipt thumbnail should be visible - All extracted fields displayed in editable form - Save completes in < 1 second Scenario 2 — Field editing GIVEN any extracted field is incorrect WHEN user taps the field THEN: - Inline edit activates immediately (no modal) - Keyboard appears pre-focused on that field - Original OCR value shown as greyed placeholder - Edited value clearly differentiated visually Scenario 3 — Receipt image storage GIVEN a receipt is saved WHEN user later opens the expense record THEN: - Original receipt image is viewable full-screen - Stored in compressed format (≤ 200KB per image) - Retained for minimum 7 years (tax compliance) - User can delete image independently of the expense record Scenario 4 — Bulk scanning GIVEN a user has 10 receipts to process WHEN they use "Batch Scan" mode THEN: - Can photograph up to 10 receipts in sequence - Reviews and confirms each in a swipeable card stack - Can skip any for later review - Batch saves all confirmed in one action ``` --- ### User Story 5: Privacy, Security & Compliance ``` AS A user I WANT my receipt data to be handled securely and privately SO THAT I trust the app with sensitive financial information ACCEPTANCE CRITERIA: Scenario 1 — Data transmission GIVEN receipt images are sent to the server for processing THEN: - All transmission over TLS 1.3 minimum - Images encrypted at rest using AES-256 - Images not retained on server after processing > 24 hours (unless user explicitly stores) - Processing occurs in EU data centres for EU users (GDPR compliance) Scenario 2 — User data rights GIVEN GDPR/CCPA requirements WHEN a user requests data export or deletion THEN: - All receipt images exported within 72 hours - All personal model data included in export - Deletion of all receipt data completable in-app within 30 days - Deletion confirmed via email Scenario 3 — Third-party LLM processing GIVEN we use a third-party LLM API for categorisation THEN: - PII (names, addresses on receipts) must be redacted BEFORE sending to third-party API - Data Processing Agreement (DPA) in place with LLM provider - No training of third-party models on user data - This is disclosed in privacy policy Scenario 4 — Permissions GIVEN the app needs camera access WHEN permissions are requested THEN: - Camera permission requested contextually (on first scan attempt, not on app install) - Clear explanation of WHY permission is needed shown - Feature degrades gracefully (import only) if permission denied - No access to microphone, contacts, or location required for this feature ``` --- ## 5. 🏗️ ARCHITECTURAL CONSTRAINTS ### System Architecture Overview ``` ┌─────────────────────────────────────────────────────────────┐ │ MOBILE CLIENT │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ Camera/Image │ │ On-Device OCR│ │ Local ML Model │ │ │ │ Capture │ │ (Fallback) │ │ (Personalisation)│ │ │ └──────┬───────┘ └──────┬───────┘ └────────┬─────────┘ │ └─────────┼─────────────────┼───────────────────┼────────────┘ │ TLS 1.3 │ │ Sync ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────────┐ │ API GATEWAY │ │ (Rate limiting, Auth, PII scrubbing) │ └─────────────────────────────────────────────────────────────┘ │ │ │ ▼ ▼ ▼ ┌──────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ Receipt │ │ LLM Service │ │ ML Training │ │ OCR Service │ │ (Categorisation │ │ Pipeline │ │ (Cloud │ │ + Extraction │ │ (User model │ │ Vision AI) │ │ refinement) │ │ updates) │ └──────┬───────┘ └────────┬─────────┘ └────────┬─────────┘ │ │ │ └───────────────────┴──────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ CORE DATABASE │ │ ┌─────────────┐ ┌─────────────┐ ┌────────────────────┐ │ │ │ Expenses │ │ Receipts │ │ Merchant │ │ │ │ (Postgres) │ │ (Object │ │ Category DB │ │ │ │ │ │ Storage) │ │ (PostgreSQL) │ │ │ └─────────────┘ └─────────────┘ └────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ ``` ### Constraints & Non-Negotiables | Constraint | Detail | Rationale | |-----------|--------|-----------| | **On-device OCR fallback** | Must function with reduced capability offline using on-device ML model | Users scan receipts in restaurants/areas with poor signal | | **Image size limit** | Max 8MB per image upload; compressed to ≤200KB for storage | Storage cost management; $0.004/GB/month target | | **Processing SLA** | Server-side extraction must complete within 4s at p95 | UX requirement; user drops off after 5s | | **LLM API rate limits** | Max 100 requests/second to LLM provider | Provider contract limitation; requires queuing architecture | | **Data residency** | EU user data processed and stored in EU (Frankfurt/Dublin) | GDPR Article 44 compliance | | **No raw PII to LLM** | PII redaction layer mandatory before LLM calls | Contractual and regulatory requirement | | **Mobile SDK size** | Scanner feature must add ≤ 15MB to app bundle | App store download size sensitivity | | **iOS/Android parity** | Feature ships simultaneously on both platforms | Business requirement — no platform favouritism | | **Backwards compatibility** | Must work on iOS 15+ and Android 10+ | Covers 94% of our current user base | | **Existing data model** | Must extend, not replace, current expense schema | Avoid migration risk for 2.3M existing records | | **Bank matching uses existing connector** | Must use Plaid/TrueLayer existing integration, not new connector | Avoid regulatory re-approval for new data sharing | | **Personalised ML storage** | User model vectors stored per-user, max 2MB per user | Scalability constraint at 500k users = 1TB | | **Third-party LLM** | OpenAI GPT-4o or equivalent; not a fine-tuned proprietary model in v1** | Time-to-market; proprietary model planned for v2 | | **Auditability** | Every AI decision must have a logged confidence score and model version | Debugging, bias monitoring, regulatory | --- ## 6. 🎨 UX DETAILS ### Design Principles for This Feature 1. **Zero-typing happy path** — the ideal flow requires 0 keystrokes 2. **Progressive disclosure** — complexity hidden unless needed 3. **Confidence transparency** — users always know when AI is uncertain 4. **Forgiving** — mistakes are easy to correct without losing work 5. **Fast** — scanning feels instant; loading states must be purposeful --- ### User Journey Map ``` TRIGGER: User has a paper receipt after a coffee purchase STEP 1 — ENTRY POINT User opens app → taps "+" (Add Expense) → sees "Scan Receipt" as primary CTA (not buried) [Design note: Scan Receipt must be above the fold on the Add Expense screen — currently it's option #3] STEP 2 — CAMERA EXPERIENCE Full-screen camera view opens Overlay shows: - Rectangular guide frame (auto-detects receipt edges) - Edge detection turns green when receipt detected - "Hold steady" hint text - Auto-captures when confidence is high enough - OR user taps shutter manually [Design note: Auto-capture is optional — some users prefer control. Setting to toggle it off in preferences] STEP 3 — PROCESSING (2–4 seconds) Animated processing screen: - Receipt image shown (user confirms right photo) - Progress indicator (not a spinner — shows stages: "Reading receipt → Finding merchant → Categorising") - If > 3s, show "Almost there..." message [Design note: Skeleton screen approach — fields populate progressively as they're resolved] STEP 4 — REVIEW SCREEN ┌─────────────────────────────────────┐ │ [Receipt thumbnail] ✅ Matched to │ │ bank txn │ │ ─────────────────────────────────── │ │ Merchant: Starbucks [✏️] │ │ Amount: £4.50 [✏️] │ │ Date: Today, 9:14am [✏️] │ │ Category: ☕ Coffee & Cafes [✏️] │ │ ✨ AI suggested │ │ ─────────────────────────────────── │ │ Add note (optional)... │ │ Split expense? │ │ ─────────────────────────────────── │ │ [ SAVE EXPENSE ] │ └─────────────────────────────────────┘ Confidence indicators: ✅ Green checkmark = > 90% confidence ⚠️ Amber warning = 60–89% (tap to review) ❌ Red flag = < 60% (must resolve before save) STEP 5 — SUCCESS STATE - Satisfying haptic + visual confirmation - Shows: "Expense saved! You've logged £4.50 today" - Quick-access to "Scan another" or "Go to expenses" - If budget impact: "You've used 78% of your Coffee budget this month" (contextual insight) STEP 6 — BACKGROUND - Auto-matching runs in background - If match found later: push notification "Receipt matched to your Barclays transaction 👍" ``` --- ### Accessibility Requirements | Requirement | Standard | |------------|---------| | Screen reader support for all review fields | WCAG 2.1 AA | | Camera view accessible via VoiceOver/TalkBack | Must announce edge detection state | | All error states have text alternatives | Not colour-only indicators | | Minimum touch target 44×44pt | Apple HIG / Material compliance | | High contrast mode support | Receipt overlay legible in all contrast modes | | Font scaling support | UI does not break at 200% font scale | --- ### Empty & Error States | State | Message | Action | |-------|---------|--------| | First-time user | "Scan your first receipt — it takes 5 seconds" | Animated demo | | Camera permission denied | "Camera access needed to scan receipts. You can still import images." | Open Settings / Import button | | Network timeout | "Slow connection — we'll finish processing this when you're back online" | Queue + notify | | Receipt not readable | "We couldn't read this receipt clearly. Retake or enter manually?" | Retake / Manual entry | | Duplicate detected | "This looks like a receipt you already scanned on [date]. Add anyway?" | Yes / No | | Storage full | "You've reached your receipt storage limit. Free up space or upgrade." | Manage storage / Upgrade | --- ## 7. 📊 DATA ANALYSIS DETAILS ### Data We Will Collect (New) | Data Point | Storage | Retention | Purpose | Legal Basis | |-----------|---------|-----------|---------|-------------| | Raw receipt image | S3 (encrypted) | User-controlled (min 7yr for tax) | Source of truth | Contract | | Extracted fields (JSON) | PostgreSQL | Same as expense record | Feature function | Contract | | OCR confidence scores (per field) | PostgreSQL | 90 days | Model monitoring | Legitimate interest | | LLM categorisation + confidence | PostgreSQL | 90 days | Model monitoring | Legitimate interest | | User correction events (field, old value, new value) | Event stream + DWH | 2 years | ML training (personal model only) | Legitimate interest | | Match attempt results | PostgreSQL | 90 days | Matching algorithm improvement | Legitimate interest | | Scan session telemetry (duration, steps, exits) | Analytics DWH | 13 months | Product analytics | Legitimate interest | | Device + OS at time of scan | Analytics DWH | 13 months | Performance monitoring | Legitimate interest | ### Key Metrics & Dashboards #### North Star Metric > **Weekly Active Receipt Scanners** (WARS) — number of unique users who successfully scan and save ≥ 1 receipt per week #### Feature Health Metrics (Operational) | Metric | Target | Alert Threshold | |-------|--------|----------------| | OCR extraction latency p50 | ≤ 2s | > 3s | | OCR extraction latency p95 | ≤ 4s | > 6s | | OCR success rate (any field extracted) | ≥ 97% | < 94% | | Total amount extraction accuracy | ≥ 98% | < 95% | | Category auto-assignment accuracy | ≥ 88% | < 82% | | User correction rate | ≤ 12% (month 1) → ≤ 8% (month 3) | > 18% | | Receipt-to-transaction match rate | ≥ 75% | < 60% | | Scan-to-save conversion rate | ≥ 80% | < 65% | | Processing error rate | ≤ 0.5% | > 1% | | False positive duplicate detection | ≤ 2% | > 5% | #### Product Impact Metrics | Metric | Baseline | 30-Day Target | 90-Day Target | |-------|---------|--------------|--------------| | 30-day retention (scan users) | 32% | 55% | 65% | | Expenses logged per user/week | 2.1 | 5.0 | 8.0 | | Free→Premium conversion | 11% | 13% | 15.5% | | CSAT score (expense module) | 3.2/5 | 3.8/5 | 4.2/5 | | Receipt feature NPS | N/A (new) | >30 | >45 | #### Instrumented Analytics Events ```javascript // Key events to instrument scan_initiated // User taps "Scan Receipt" properties: { entry_point, user_tier, has_camera_permission } image_captured // Photo taken or imported properties: { capture_method, image_quality_score } extraction_completed // OCR + LLM returns result properties: { duration_ms, confidence_total, confidence_merchant, confidence_amount, confidence_date, merchant_in_database, category_assigned, category_confidence } field_corrected // User edits an AI-extracted field properties: { field_name, old_value_hash, correction_reason } category_changed // User overrides AI category properties: { ai_category, user_category, confidence_was } expense_saved // Successful save properties: { had_corrections, time_to_save_seconds, matched_to_bank, category_final } scan_abandoned // User exits without saving properties: { exit_step, reason_if_provided } match_result // Bank matching outcome properties: { match_type, confidence, days_to_match } ``` #### A/B Test Plan | Test | Hypothesis | Variant A | Variant B | Success Metric | |------|-----------|-----------|-----------|---------------| | AB-01 | Auto-capture vs manual shutter | Manual only | Auto + manual | Scan completion rate | | AB-02 | Confidence display | Show % scores | Show colour only | Trust score (survey) + correction rate | | AB-03 | Category suggestion UX | Show top 1 | Show top 3 | Category correction rate | | AB-04 | Success screen CTA | "Scan another" primary | "View expenses" primary | WARS metric | | AB-05 | Batch scan | No batch mode | Batch scan (10 at once) | Receipts per session | --- ## 8. 👥 STAKEHOLDER MAP ``` HIGH INFLUENCE │ ┌───────────────┼───────────────┐ │ │ │ [CPO/VP Prod] [CTO/VP Eng] [CFO/Finance] Sponsor & Architecture ROI approval prioritisation sign-off required │ │ │ HIGH ────┼───────────────┼───────────────┼──── HIGH INTEREST │ │ │ INTEREST │ [Head of Data] [Head of Legal] [Head of Data governance, Privacy/GDPR Design] ML pipeline sign-off on UX quality DPA + policies ownership │ │ │ │ LOW ─────┼───────────────┼───────────────┼──── LOW INTEREST │ │ │ INTEREST [Marketing] [Security Lead] [Customer Feature Pen testing + Support Lead] positioning approval Comms + & launch support scripts │ [External] ──────────────────────────────────────── LLM Provider (OpenAI/Anthropic) — Vendor Cloud OCR Provider (Google Vision) — Vendor End Users — Primary beneficiaries App Store (Apple/Google) — Distribution gatekeepers ``` ### Detailed Stakeholder Register | Stakeholder | Role | Interest | Influence | Engagement | Need From PO | |------------|------|----------|-----------|------------|-------------| | **CPO** | Executive Sponsor | Strategic alignment, revenue | High | Fortnightly steering | Business case, OKR alignment | | **CTO** | Architecture owner | Technical feasibility, scalability | High | Weekly | ADR sign-offs, constraint validation | | **CFO** | Budget holder | Cost of AI API calls, ROI | High | Monthly | Cost model, revenue projection | | **Head of Engineering** | Delivery owner | Team capacity, technical debt | High | Weekly scrum | Detailed stories, priority calls | | **Head of Design** | UX ownership | User experience quality | High | Daily (embedded) | Design QA, prototype sign-off | | **Head of Data** | Data platform owner | Pipeline architecture, ML | Medium-High | Bi-weekly | Data schema, event tracking spec | | **Head of Legal/Privacy** | Compliance gate | GDPR, data processing, liability | High | Monthly + ad hoc | Privacy impact assessment | | **Security Lead** | InfoSec gate | Image data security, API security | Medium-High | Sprint-based | Security review sign-off | | **Head of Marketing** | Launch & comms | Feature narrative, positioning | Medium | Pre-launch | Launch brief, messaging | | **Customer Support Lead** | User-facing ops | Support load, FAQ creation | Medium | Pre-launch | Training material, known issues | | **OpenAI/LLM Vendor** | External dependency | Contract compliance, limits | Medium | As needed | DPA, API quota negotiation | | **End Users (Paid)** | Value recipients | Time savings, accuracy | Low (individually) | Usability testing, beta | Research synthesis | | **End Users (Free)** | Acquisition & conversion | Feature access (limited) | Low (individually) | NPS, feedback | Research synthesis | --- ## 9. ⚠️ RISK ANALYSIS ### Risk Register | ID | Risk | Category | Likelihood | Impact | Severity | Owner | Mitigation | Contingency | |----|------|----------|-----------|--------|----------|-------|-----------|------------| | R01 | OCR accuracy significantly lower than 88% on real-world receipts (thermal paper, faded ink, foreign languages) | Technical | Medium | High | 🔴 High | Engineering | Conduct receipt corpus testing with 10,000 diverse receipt samples before launch; benchmark against target | Soft-launch to 5% of users with manual review option; delay full rollout | | R02 | LLM API costs exceed budget at scale (if avg cost per scan > $0.005) | Financial | Medium | High | 🔴 High | PO + CFO | Model cost per scan in financial forecast; set up cost alerts; explore caching for known merchants | Implement merchant lookup cache (covers ~60% of scans for $0); rate-limit free tier users | | R03 | GDPR compliance gap — PII on receipts inadvertently sent to third-party LLM | Legal/Compliance | Low | Critical | 🔴 High | Engineering + Legal | PII redaction layer as hard requirement; legal review of all data flows; DPA signed before dev starts | Feature paused pending remediation; legal has veto | | R04 | Bank matching accuracy too low causing user confusion / duplicate expenses | Technical | Medium | High | 🔴 High | Engineering | Extensive testing with synthetic transaction data; conservative matching thresholds; require user confirmation for fuzzy matches | Disable auto-matching, manual match only; user prompted to review | | R05 | App Store rejection due to camera/privacy concerns or AI disclosure requirements | External | Low | High | 🟠 Medium | PO + Legal | Review Apple/Google AI disclosure policies; pre-submit for App Store review team consultation | Adjust privacy disclosure copy; resubmit; delay launch by est. 2 weeks | | R06 | On-device OCR model adds > 15MB to app bundle size | Technical | Medium | Medium | 🟠 Medium | Engineering | Evaluate ML model quantisation; consider on-demand download of ML asset | Remove on-device fallback from v1; offline mode = manual entry only | | R07 | User trust low — users unwilling to photograph receipts due to privacy concerns | Adoption | Medium | High | 🟠 Medium | PO + Marketing | Clear in-app privacy messaging; transparency about data usage; option for local-only processing | Offer "privacy mode" — on-device only processing with no server upload | | R08 | Personalised ML model doesn't improve fast enough — correction rate stays high | ML/Product | Medium | Medium | 🟠 Medium | Data Science | Set minimum training signal thresholds; evaluate batch vs real-time model update approaches | Fall back to rule-based categorisation; increase prominence of correction prompts | | R09 | Key engineer dependency — only 2 engineers have ML/OCR experience | Resourcing | Medium | High | 🟠 Medium | Engineering Manager | Knowledge sharing sessions; pair programming; document architecture thoroughly | Bring in contractor; adjust timeline | | R10 | Receipt scan latency spikes under load — p95 exceeds 6s at >10k concurrent users | Performance | Low | Medium | 🟡 Low-Medium | Engineering | Load test at 3× projected launch peak; horizontal scaling of OCR service | Auto-scaling rules; queue-based processing; show "processing in background" UX | | R11 | LLM provider outage causes feature unavailability | External dependency | Low | Medium | 🟡 Low-Medium | Engineering | Fallback to rule-based categorisation if LLM unavailable; circuit breaker pattern | "AI categorisation temporarily unavailable — please select manually" graceful degradation | | R12 | Competitor ships similar feature first, reducing differentiation | Market | Medium | Low | 🟡 Low-Medium | PO | Monitor competitor releases; emphasise personalisation angle (unique to us) | Accelerate timeline for unique differentiators (personal ML model) | | R13 | Batch scanning creates server-side processing storms | Technical | Low | Low | 🟢 Low | Engineering | Queue rate-limiting; max batch of 10 enforced; per-user rate limit on bulk operations | Disable batch mode temporarily; reduce batch limit to 5 | ### Risk Heatmap ``` │ CRITICAL│ [R03] │ HIGH │ [R04] [R01][R02] [R09] │ [R07][R08] IMPACT │ [R05][R06] [R12] │ [R10][R11] MEDIUM │ [R13] │ LOW │ └──────────────────────────────────── LOW MEDIUM HIGH LIKELIHOOD ``` --- ## 10. ❓ OPEN QUESTIONS ### Unresolved — Blocking or Near-Blocking | ID | Question | Why It Matters | Owner | Target Resolution | Status | |----|---------|---------------|-------|------------------|--------| | OQ-01 | **Which LLM provider do we use?** OpenAI GPT-4o vs Anthropic Claude vs Google Gemini — each has different cost, accuracy, data handling terms, and DPA implications. Have we completed legal review of all three DPAs? | Architectural decision with compliance implications — cannot start backend dev without this | CTO + Legal | **Sprint 21** | 🔴 Blocking | | OQ-02 | **What is the free tier feature limit?** Do free users get unlimited scanning? Limited scans per month (e.g., 10/month)? Or is this Premium-only? This affects monetisation model and engineering (quota tracking). | Core to pricing strategy — affects feature spec significantly | CPO + CFO | **Sprint 21** | 🔴 Blocking | | OQ-03 | **7-year receipt retention — who is responsible?** Are we a data controller obligated to retain receipts for tax purposes on users' behalf, or do users control their own retention? Legal interpretation needed for UK/EU/US. | Affects storage architecture, cost model, and legal liability | Legal + PO | **Sprint 22** | 🟠 Near-blocking | | OQ-04 | **Email forwarding feature — do we need a dedicated email address per user?** (e.g., `receipts+userid@ourapp.com`) This requires email infrastructure we don't currently have. Is this in scope for v1? | Significant engineering complexity if in scope | PO + Engineering | **Sprint 21** | 🟠 Near-blocking | ### Unresolved — Important But Not Blocking v1 | ID | Question | Why It Matters | Owner | Target Resolution | |----|---------|---------------|-------|------------------| | OQ-05 | **How do we handle receipts in non-Latin scripts?** (Arabic, Chinese, Cyrillic) — OCR and LLM support varies. Do we support or defer? | Internationalisation scope affects OCR vendor choice | Engineering + PO | Sprint 23 | | OQ-06 | **Merchant database — build vs buy?** Options: (a) build from user scan data over time, (b) licence from a data provider (e.g., Refinitiv, Marqeta), (c) hybrid. Cost vs speed vs coverage trade-off. | Affects v1 categorisation accuracy for unknown merchants | Data + PO | Sprint 22 | | OQ-07 | **What is the split expense UX flow?** If a user wants to split a scanned receipt (e.g., half business, half personal), we need a splitting UX. Is this v1 or v2? | Mentioned in AC but not fully designed | Design + PO | Sprint 22 | | OQ-08 | **Do we surface line items?** The extraction pipeline can extract individual line items (e.g., "Latte £3.50, Muffin £2.00"). Do we show these to the user or just the total? Storage and UX implications. | Potential high-value feature but adds complexity | PO + Design | Sprint 23 | | OQ-09 | **How does this interact with existing manual expense entry?** Should scanning and manual entry become a single unified flow, or remain separate entry points? | UX consistency and deduplication logic | Design + Engineering | Sprint 23 | | OQ-10 | **Accessibility for visually impaired users scanning receipts** — how does a user with visual impairment know the photo is framed correctly? Need audio guidance. Is this v1 requirement? | WCAG compliance question; potential legal exposure | Design + Legal | Sprint 23 | | OQ-11 | **Business expense reports** — if a user flags an expense as "Business", should we immediately prompt for additional metadata (project code, description) required for expense reporting? This is a v2 feature but tagging now would unlock v2. | Data capture opportunity now vs UX friction today | PO | Sprint 24 | | OQ-12 | **What happens when a receipt currency differs from the user's home currency?** Exchange rate source? Date of conversion? Who is liable for FX rate accuracy? | Edge case but legally and financially sensitive | Engineering + Legal | Sprint 24 | | OQ-13 | **Beta testing cohort** — who gets early access? How many users? What are the criteria for exiting beta? | Launch planning and risk management | PO + Marketing | Sprint 24 | | OQ-14 | **CS escalation path** — if AI miscategorises an expense that causes a downstream tax error for a user, what is our liability and how does CS handle the complaint? | Liability and CS training gap | Legal + CS Lead | Sprint 25 | --- ## 11. 📅 DELIVERY ROADMAP ``` SPRINT 21 SPRINT 22 SPRINT 23 SPRINT 24 SPRINT 25 SPRINT 26 ───────────────────────────────────────────────────────────────────────── [Foundation] [Core OCR] [ML & Match] [Integration] [Beta] [Launch] - LLM vendor - Camera - Auto-cat - Email - Beta - Full decision capture LLM import (5% users) rollout - DB schema - OCR - Personal - Batch - Bug fix (100%) design extraction ML model scan sprint - Privacy - Review - Bank - Accessibility - Monitor impact screen matching review KPIs assessment - Basic - Split - Category expense - LLM vendor assignment (TBC) DPA signed ``` --- ## 12. 📋 DEFINITION OF DONE (Feature Level) - [ ] All acceptance criteria scenarios passing in QA - [ ] Performance SLAs met under load test (3× projected launch traffic) - [ ] Security review signed off by InfoSec lead - [ ] Privacy Impact Assessment completed and approved by DPO - [ ] LLM provider DPA signed - [ ] WCAG 2.1 AA accessibility audit passed - [ ] All new analytics events instrumented and validated in analytics QA environment - [ ] A/B test framework configured for AB-01 through AB-05 - [ ] Customer support team trained with support runbook - [ ] App store privacy disclosure updated - [ ] Privacy policy updated (legal approved) - [ ] Rollback plan documented and tested - [ ] Error monitoring and alerting configured (Datadog/equivalent) - [ ] Cost monitoring dashboard live (LLM API cost per scan tracked) - [ ] Beta cohort identified and notified - [ ] Launch comms reviewed by marketing --- *Document Version: 1.0 | Last Updated: June 2025 | Next Review: Sprint 22 Kickoff* *Owner: [Product Owner Name] | Reviewers: [CTO], [Head of Design], [Head of Legal], [Head of Data]*

PO BA task