Expense Types & Requirements

HLF explicitly identified the inability to enforce mutually exclusive expense types as a root cause of reimbursement errors. When peer mentors can simultaneously select km-based and public transport reimbursement for the same trip, coordinators spend time correcting invalid submissions rather than approving valid ones, increasing per-claim cost and delaying payment. Enforcing valid combinations at the UI layer eliminates this error class before records ever enter the approval queue. The per-organization configuration model supports the multi-tenant architecture: each organization defines its own expense type taxonomy and rates through the admin portal without code changes, allowing organizations with materially different reimbursement policies to coexist on the platform. New organizations onboard by configuring types rather than requiring a deployment, reducing maintenance overhead as the platform scales to additional tenants.

Expense type rules are stored in the expense_types table with a JSON exclusion_groups field encoding sets of mutually exclusive type IDs. The mobile app fetches the active configuration as part of the module bootstrap response and caches it in Drift for offline availability. ExpenseTypeSelectorWidget reads the Riverpod-provided type configuration and applies reactive disabling: any selection updates the enabled state of conflicting types in the same exclusion group immediately. Admin portal management of expense types lives in the admin-expense-approval area. The backend validates submitted expense items against the active type configuration before persisting and returns a structured validation error if an invalid combination is detected, providing defense in depth against client bypass. Reimbursement rate values (e.g., kr-per-km) are stored as type-level configuration and returned with the type list in the bootstrap payload for client-side calculation previews.