Expense Types & Requirements

Unstructured free-text expense entries are a primary source of reimbursement errors and audit failures. HLF explicitly identified that allowing peer mentors to combine mileage and public transport on the same claim was causing finance rejections and requiring manual correction. A structured, rule-enforced type system eliminates this class of error at the point of entry rather than during auditor review, saving hours of coordinator and finance team time per reporting period. For organizations with Bufdir reporting obligations, having clean and categorized expense data also simplifies the generation of statutory reports and reduces the risk of funding clawback due to documentation errors.

Expense type definitions are stored in the module_configurations table as JSON configuration per organization, loaded at app startup and cached offline via Drift. The Expense Validation Service exposes a REST endpoint returning the active type list with their mutual exclusivity rules and threshold values for the authenticated user's organization. The Flutter expense form widget reads this configuration to build the type selector dynamically and enforces exclusivity at the UI layer with immediate visual feedback. Server-side validation re-checks the same rules on submission to prevent bypass via API. The admin portal provides a configuration UI under Organization Management where admins can adjust type definitions, thresholds, and receipt requirements without a code deployment. Adding a new expense type requires only a configuration change, not a client release.