Expense Types & Requirements

HLF stated that making invalid type combinations technically impossible is a hard requirement. When peer mentors can freely combine expense types, coordinators must manually detect and reject invalid claims, adding review overhead and causing frustration on both sides. Fixed mutually exclusive type options eliminate this class of error at source, reducing coordinator workload and improving data quality. A well-structured expense type system also streamlines accounting exports: each type maps cleanly to accounting categories in Xledger (Blindeforbundet) and Dynamics (HLF), reducing manual categorization during export. Centralized type configuration in the Admin Web Portal ensures consistency across all peer mentors in an organization without requiring app updates when policies change.

Expense types are stored in the expense_types table with a mutual-exclusion group field. The mobile app fetches available types and constraint rules from /api/v1/expense-types at session bootstrap and caches them in Drift for offline enforcement. The Flutter expense form renders types as a radio group or segmented control, dynamically disabling incompatible options on selection. Server-side validation re-checks type combinations on submission, returning a structured error if client constraints were bypassed. The Admin Web Portal provides a configuration screen for org admins to enable or disable types and define exclusion rules per organization. Data model must be org-scoped so different organizations can expose different type subsets while sharing the same schema.