At its core the module lets an employee turn evidence of spend into a settled claim with minimal friction. A user photographs or uploads a receipt, and the module extracts the merchant, date, gross and tax amounts, and currency, then proposes an expense category. Individual expense lines are grouped into a claim, the unit that moves through approval and reimbursement. The module supports out-of-pocket cash expenses, corporate card transactions, mileage claims computed from distance, and per-diem allowances computed from trip duration and location.

Policy enforcement runs continuously rather than as a final gate. As lines are added, the module tests them against configured rules: category spend caps, receipt-required thresholds, duplicate detection, date-window limits, and restricted merchant types. Violations are surfaced to the claimant before submission, with the option to add justification where a rule permits a soft override. The result is that most claims arrive at an approver already clean, and the exceptions are clearly labelled with the reason they need a human decision.

The central entities are the expense line, the claim, and the policy. An expense line carries a category, a date, an original-currency amount and its reporting-currency equivalent, a tax component, an attached receipt document, and a coding block that says which cost centre, project, or task should bear the cost. A claim is an ordered collection of lines owned by one employee, with a status that tracks its position in the workflow and an audit trail of every state change.

Employees are not mastered here. The module references the employee record held in Human Resource Management for identity, cost centre, manager, and reimbursement bank details, so that a leaver or a reporting-line change is reflected without duplicate maintenance. Policy is modelled as a versioned set of rules scoped by category, grade, country, and currency, which lets one organisation run different mileage rates, per-diem tables, and receipt thresholds across jurisdictions from a single configuration. Mileage and per-diem rate tables are effective-dated, so a claim is always evaluated against the rates that applied on the date of travel rather than the date of submission.

The principal workflow follows the money. Capture creates lines from receipts, card feeds, or manual entry. Submission assembles those lines into a claim, runs the final policy pass, and routes the claim for approval. Approval is a configurable chain: the default is the claimant's line manager drawn from Human Resource Management, with escalation by amount to a second approver and a separate project-owner sign-off where a line is coded to a project. Settlement posts the approved claim and releases reimbursement.

Rejection and query are treated as first-class paths, not dead ends. An approver can send a single line back with a comment while approving the rest, so a whole trip is not held up by one contested taxi fare. Corporate card transactions follow a matching variant of the same flow: the card feed creates unclaimed transactions, the employee attaches receipts and coding, and the reconciliation confirms that every card charge has been accounted for, which keeps card liability and employee reimbursement cleanly separated.

The functional depth that matters here is correctness of money and defensibility of decisions. Mileage is computed from distance and an effective-dated rate that can vary by vehicle class and by cumulative annual distance, so tiered rates that step down after a threshold are handled without manual intervention. Per-diem allowances are derived from trip start and end times against a location-specific day rate, with configurable rules for partial days and for deductions when a meal was otherwise provided.

On the accounting side the module respects the distinction between the expense and its recoverable tax. Where input tax is reclaimable and a valid receipt is present, the tax component is separated from the net cost so that Accounting & Control can post the net to the expense account and the tax to the recoverable tax account. Every claim carries an immutable audit trail: who entered each line, which policy version evaluated it, which rules fired, who approved or overrode, and when. Controls include segregation between claimant and approver, duplicate-receipt detection across claims, and enforced receipt evidence above configured thresholds, which together give internal audit a complete and reproducible account of each reimbursement.

Expense Management is deliberately narrow in what it masters and broad in what it consumes. It relies on Human Resource Management as the source of the employee master: identity, grade, cost centre, manager for approval routing, and the bank details used for reimbursement. It reads the project and task structure from Project Management so that billable and cost-tracked spend can be coded to the right job at the point of capture, which means project profitability reflects travel and expense cost in near real time rather than after a month-end journal.

Its downstream counterpart is Accounting & Control. An approved claim becomes a posting: the expense and recoverable tax to the ledger, and a reimbursement liability to the employee that flows into the payment run. Because the coding, tax treatment, and approval evidence are all settled before the claim leaves this module, the finance team receives fully formed transactions rather than raw receipts to interpret. This keeps the module focused on the expense domain while the suite's shared ledger, people, and project data do the work they are already responsible for.

The suite treats AI Workers as first-class users, and in this module they carry real operational load. On capture, a Worker reads each uploaded receipt, extracting merchant, date, amounts, and tax, and proposes a category and project coding based on the claimant's history and the trip context. Where a receipt is ambiguous or missing, the Worker flags it rather than guessing, so the human sees exactly what needs attention.

On policy, a Worker checks every line against the active rule set and explains its findings in plain language, so a claimant understands why a line breached a cap or needs a receipt before they submit. Workers also run anomaly and exception detection across claims, surfacing duplicate submissions, out-of-pattern amounts, and clusters of spend that merit review. A finance user can query module data conversationally, asking for a person's unreimbursed balance or a project's travel cost to date, and receive an answer drawn from live records.

Most significantly, a Worker can act as an approval or review node in the workflow. For low-value, in-policy, well-evidenced claims it can approve within a delegated authority, passing only genuine exceptions to a human. For higher-value claims it prepares the decision, assembling the receipts, policy results, and coding into a concise recommendation so the human approver decides in seconds rather than minutes. In every case the Worker's action is logged in the same audit trail as a human's, which keeps the AI-native workflow fully accountable.