Receive Clear Feedback When Receipt Is Required But Missing
The receipt threshold configuration is org-specific (e.g., 100 NOK). When the peer mentor enters an expense amount that crosses this threshold, the form dynamically indicates that a receipt is required — before the user attempts to submit. This proactive validation reduces cognitive load by surfacing the requirement in context. The indicator uses plain language, high-contrast styling, and is announced by screen readers when the threshold is crossed. The threshold-validation logic is encapsulated server-side in an edge function to allow org administrators to update thresholds without app releases.
User Story
Audience Summaries
Proactive receipt threshold validation is a high-impact feature for volunteer engagement and multi-organization scalability. By surfacing the receipt requirement dynamically as the peer mentor types — rather than blocking at submission — the experience reduces friction for a user group that includes individuals with cognitive accessibility needs, a core demographic explicitly prioritized in NHF's requirements. Org-configurable thresholds via edge functions enable the platform to serve HLF, Blindeforbundet, and future partner organizations with distinct reimbursement policies without requiring app releases, dramatically reducing time-to-value for onboarding new organizations and protecting the platform's competitive position as a multi-tenant solution.
This story spans multiple teams: Flutter developers for the dynamic form validation UI, backend/edge function engineers for threshold configuration storage and serving, and accessibility specialists for live region implementation. The org-configurable threshold requirement introduces a dependency on the admin configuration system and the edge function infrastructure, which must be scoped and scheduled accordingly. Acceptance criteria include both functional validation behavior and accessibility compliance, requiring assistive technology testing on iOS VoiceOver and Android TalkBack. Timeline risk exists around edge function deployment and the configuration admin interface — if those are not ready, threshold validation can be temporarily hardcoded with a feature flag for initial release, then migrated to dynamic config in a follow-up sprint.
The threshold validation logic must be fetched from an org-specific edge function at form initialization and cached locally for the session to avoid per-keystroke network calls. The amount field's onChanged or onBlur handler should compare the entered value against the cached threshold and emit a BLoC event to update a `receiptRequired` flag in form state. The receipt section widget must observe this flag and conditionally render the threshold indicator using high-contrast styling defined in the design system. Accessibility requires a Flutter Semantics live region wrapping the indicator so threshold crossing is announced without focus change.
On submit, validation must re-evaluate the current state and scroll the receipt section into view using a ScrollController if the error condition is met. Threshold updates from the admin side should invalidate the local cache via a versioned config endpoint or cache-busting header.
Acceptance Criteria
- Given I enter an expense amount above the org-configured receipt threshold, When the amount field loses focus, Then a visual indicator appears on the receipt attachment section showing 'Receipt required for amounts over [X] NOK'
- Given the threshold indicator is shown, When a screen reader is active, Then the threshold requirement is announced via an accessibility live region
- Given I have not yet attached a receipt and the amount is above threshold, When I tap the Submit button, Then submission is blocked and the receipt section is scrolled into view with an error state highlighted
- Given the org administrator changes the receipt threshold in configuration, When I next open the expense form, Then the updated threshold value is reflected without requiring an app update
- Given my expense amount drops below the threshold after editing, When the validation is re-evaluated, Then the receipt requirement indicator disappears and the form can be submitted without a receipt
- Given a receipt is attached and the amount is above threshold, When I view the form, Then the receipt section shows a success state indicating the requirement is satisfied
Business Value
Proactive threshold validation prevents submission errors and reduces coordinator workload from incomplete claims. For peer mentors with cognitive accessibility needs — a core user group per NHF's requirements — clear in-context guidance is essential. Org-configurable thresholds via edge functions ensure the feature scales across HLF, Blindeforbundet, and future organizations with different reimbursement policies.
Components
- Receipt Attachment Indicator ui
- Receipt Threshold Validator service
- Expense Form BLoC service
- Expense Validation Service service
- Expense Threshold Configuration infrastructure
- Threshold Validation Supabase Edge Function infrastructure
- Plain Language Error Display ui
- Live Region Announcer ui