Expense Types & Requirements

medium complexity v1.0 extracted Expense & Reimbursement Confidence: 100%

Components

Shared

User Stories

Yes

Analyzed

Description

Expense Types & Requirements provides a structured, organisation-configured catalogue of expense categories - kilometres, toll, parking, public transport, driver honoraria - that peer mentors select from when registering costs. Fixed choices replace free-text entry and enforce mutual exclusion rules that make invalid combinations (e.g. km allowance and bus ticket for the same trip) technically impossible to submit. Each expense type carries configurable rules covering receipt requirements, mutual exclusions, and approval thresholds. This keeps the reimbursement workflow auditable and reduces the coordinator correction overhead that arises from inconsistent or contradictory free-text claims.

Sources & reasoning

Sections 2.1 and 3.2 both independently state HLF requires fixed expense type selectors that make invalid combinations technically impossible - described as a hard requirement, not a preference. Phase 2 placement in the priority matrix maps to target_release v1.0.

No source references — this artifact was included based on reasoning alone (see above).

Analysis

Business Value

Free-text expense entry produces inconsistent data that requires manual cleanup before accounting export - a significant hidden cost in coordinator time and error risk. Structured types with mutual-exclusion rules eliminate entire categories of data quality problems at source, reducing the time coordinators spend correcting and querying submissions. For HLF this is described as a hard requirement: the inability to select contradictory types must be enforced at the UI level. For all organisations, consistent categorisation enables reliable Bufdir reporting, automated accounting export matching, and meaningful spend analytics across the platform over time.

Implementation Notes

Expense types are stored in the `expense_types` table and included in the organisation bootstrap payload, enabling offline-first rendering of the registration form. Each type record carries a JSON `rules` field specifying mutual exclusions, receipt thresholds, and approval limits. Organisation admins configure the active type set and rules in the Admin Web Portal Organisation Settings area. The Flutter UI renders types as a validated picker: selecting a type that conflicts with an already-selected type disables the conflicting option and surfaces a plain-language explanation. Server-side validation re-enforces all type rules at submission time, ensuring client-side bypasses are rejected before any record is persisted.