Expense & Claims
Reimbursements, advances and expense claims with approval workflows.
Expense & Claims gives money spent on the organisation's behalf a single, auditable path: log the claim, move it through approval, and mark it reimbursed. Every claim records who spent, what it was for, which category it belongs to, how much and on what date — and its status is always exactly one of four states: pending, approved, rejected or reimbursed. There is no grey area between "the manager said yes" and "the money went out"; each is its own recorded step.
The module is more than a claims list. A Categories register holds the expense types your organisation recognises, each with a per-claim limit, a requires-receipt flag and an active or inactive status. An Advances register tracks money issued to employees ahead of spending — reason, amount, issue date and a lifecycle of its own, from pending through approved to settled. Both sit beside the claims queue in the same left-rail workspace.
Policy lives in the module's own Settings page: whether approval is required, whether a receipt is required, whether reimbursement should be handled with payroll, and a monthly limit preference, alongside a free-form list of your organisation's expense categories. These choices are saved to your organisation's shared configuration, so they persist across sessions and administrators.
HR administrators create and action claims on behalf of employees, and access is gated form by form: the Claims, Advances and Settings tabs each map to a named permission in the role matrix, so you decide exactly who can raise, approve and configure. Whenever a claim changes state, the employee concerned is notified automatically.
How Expense & Claims works
Raise a claim in under a minute
New expense opens a short dialog: pick the employee from the organisation's directory, give the claim a title, choose a category — Travel, Food, Office, Medical, Accommodation or Other — and enter the amount, the expense date and an optional description. Title and amount are required; everything else can follow. The claim lands in the queue as pending, stamped with when it was created.
The claims list itself is a clean table — title, employee, category, amount formatted with thousands separators, date and a coloured status badge — with the available action shown right on the row, so an approver never hunts through menus to move a claim along.
An approval order the server enforces
A pending claim offers exactly two actions: approve or reject. An approved claim offers exactly one: reimburse. Rejected and reimbursed claims are terminal, and the row shows no further actions.
This ordering is not just interface polish — the server refuses any transition out of sequence. Try to reimburse a claim that was never approved, or approve one already rejected, and the API answers with a conflict error explaining which states the action is allowed from. The workflow you see is the only workflow that can happen, whatever client is talking to the API.
The employee hears about every step
Each transition — approved, rejected, reimbursed — raises an in-app notification for the user account linked to the claimed employee, naming the claim and what just happened to it. Where outgoing email is configured, the same message is also sent to the employee's email address, on a best-effort basis that never blocks the approval itself.
Because notifications key off the employee on the claim, HR can raise and action claims centrally while the person who spent the money still finds out the moment a decision is made.
Categories with limits and receipt rules
The Categories tab is a register of expense types: each entry records a category name, a per-claim limit shown in money format, a requires-receipt flag and an active or inactive status. Entries can be added, edited and removed as policy evolves, giving finance a single written-down answer to "what can be claimed, up to how much, and does it need a receipt?".
A simpler category list also lives in Settings, kept in the organisation's shared configuration — handy for teams that just want the names without per-category rules.
Advances, from issue to settlement
Money issued before it is spent is tracked in the Advances register. Each advance records the employee, the reason, the amount and the issue date, and carries its own status — pending, approved, settled or rejected — so an advance is never silently forgotten once the cash leaves the drawer. Records can be edited or removed, and the table resolves each employee ID to their name from the directory.
Statuses render as colour-coded badges on the advances register, just as they do on the claims list, so the state of either table is legible at a glance, before you read a single word.
Settings that write your policy down
Expense Settings gathers the module's preferences in two tabs. General Setting covers approval — whether approval is required, whether a receipt is required, and whether reimbursement is to be handled with payroll — plus a monthly limit preference offering No Limit, 10,000, 25,000 or 50,000. The Categories tab manages the organisation's category list. All of it is stored against your organisation's configuration, one shared source of truth for every administrator.
Features
One auditable claims register
Every claim is a titled record with employee, category, amount, expense date, description and status, stamped with creation and update times. The table shows a coloured status badge per row and formats amounts with thousands separators, so scanning a month's claims takes seconds.
A four-state workflow, enforced server-side
Pending, approved, rejected, reimbursed — nothing else. Approve and reject act only on pending claims and reimburse only on approved ones; the server rejects any out-of-order transition with a clear conflict message, so the audit trail can never contradict itself.
Reimbursement as its own step
Approval and payment are recorded separately. A claim stays visibly approved until someone explicitly marks it reimbursed, so finance always knows the difference between money promised and money paid out.
A category catalogue with rules attached
Record each expense type with a per-claim limit, a requires-receipt flag and an active or inactive status. The register is fully editable, giving you one maintained answer to what may be claimed and on what terms.
An advances ledger
Issue advances against future claims with a reason, amount and issue date, then track each one from pending through approved to settled — or rejected. Advances name their employee from the same directory as claims, so the two registers always agree on who is who.
Automatic employee notifications
Approvals, rejections and reimbursements each raise an in-app notification for the affected employee, and an email where outgoing email is configured. Decisions never sit unread in a spreadsheet waiting for someone to pass the news on.
Form-level access control
The module sits behind the shared role and permission matrix: Claims, Advances and Settings are each gated by a named form permission, and the module's tabs only appear to people whose role includes them.
Policy settings in shared configuration
Approval-required, receipt-required, reimburse-with-payroll and monthly-limit preferences are stored in your organisation's configuration alongside the category list, so every administrator works from the same written-down policy.
Used by: HR administrators create and action claims on behalf of employees.
Works with the rest of Nexa People
Claims and advances are keyed to employee records from the Employee Management module. The claim and advance forms pick people from the same organisation-wide directory used everywhere else, and every table resolves the stored employee ID back to the person's current name — there is no second list of staff to keep in step.
State changes flow through the platform's shared notification service: each approval, rejection or reimbursement creates an in-app notification for the user account linked to the employee, and sends an email through the platform's email service where one is configured. Access rides on the same role and permission matrix that Employee Management administers — the Expense module and its forms are entries in that catalogue, so expense permissions are assigned exactly the way every other module's are.
Module settings are saved to the organisation's shared configuration store, the same one other modules read their policies from, and every claim, advance, category and setting is scoped to your organisation by the server on every request.
Frequently asked questions
What does an expense claim record hold?
A title, the employee it belongs to, a category, the amount, the expense date, a free-text description and a status — pending, approved, rejected or reimbursed — plus timestamps for when the record was created and last changed. Title and amount are required when raising a claim; the rest can be added as available.
What stops a claim being reimbursed before it is approved?
The server. Approve and reject are only accepted on pending claims, and reimburse only on approved ones; any attempt out of order is refused with a conflict error stating which states the action is allowed from. The interface mirrors the same rule by only showing the actions a claim's current status permits.
How does the employee find out what happened to their claim?
Automatically. Every approval, rejection and reimbursement raises an in-app notification for the user account linked to that employee, naming the claim and the decision. If your organisation has outgoing email configured, the same message is also emailed to the employee's address — sent best-effort, so a mail hiccup never blocks the approval.
Can we define our own categories and limits?
Yes, in two places. The Categories register records each expense type with a per-claim limit, a requires-receipt flag and an active or inactive status, all editable at any time. Settings additionally keeps a simple category name list and a monthly limit preference — No Limit, 10,000, 25,000 or 50,000 — in your organisation's shared configuration. The claim form itself offers a standard category set: Travel, Food, Office, Medical, Accommodation and Other.
How do advances work, and how are they different from claims?
A claim reimburses money already spent; an advance records money issued before spending. Each advance holds the employee, a reason, an amount and an issue date, with its own status of pending, approved, settled or rejected — so you can see at a glance which advances are still outstanding and which have been settled against later spending. Advances live on their own tab beside the claims queue, and entries can be edited or removed as their circumstances change.
Who can raise and approve claims?
HR administrators create and action claims on behalf of employees. Access is governed by the shared role and permission matrix: the Claims, Advances and Settings tabs are each gated by a named form permission under the Expense module, so a role can be given the queue without the settings, or approvals without configuration, as your policy requires.
Is the module isolated to our organisation?
Yes. Every claim, advance, category record and setting is stored against your organisation, and the server scopes each list, read and update to the requesting organisation on every call. Claims are also indexed by organisation and status, and by organisation and employee, so the queue stays quick as history accumulates.
Related modules
See Expense & Claims in your own setup
We'll walk you through the modules you care about and email you login credentials to try it yourself.