Travel and Expenses

Travel and Expenses records planned work travel, calculates policy-based per diem, captures actual expenses, recognises an approved employee claim in the general ledger, and links its settlement to a completed shared Payments transaction. Policy configuration lives under HR → Setup → Travel Expense Policies; requests and claims live under HR → Operations → Travel And Expenses.

This guide describes the current product flow. A configured policy is not a request, an approved claim is not a payment, and a payment reference is not proof that the settlement journal reconciled.

Current source-to-route mismatch

The reviewed backend develop router does not currently declare the Travel Request and Travel Claim endpoints called by the frontend. The SQL procedures contain the business rules described below, but the HTTP workflow cannot be treated as available or end-to-end verified until the router is wired. See Current implementation boundaries.

Access and prerequisites

The active company-service must have HR Travel and Expenses enabled. Users also need the relevant view/create/update permissions; the capability does not grant user permissions. Per-diem setup has separate view/manage permissions. See Capabilities and Access.

Before processing requests or claims:

1. Configure and approve the service-scoped per-diem policy that covers the travel dates.
2. Confirm the employee is approved, active, and in the same HR service.
3. Confirm that the HR travel expense and employee payable tags resolve to approved chart-of-account records.
4. Confirm the approved travel-claim accrual rule and the cash and bank settlement rules are available.
5. If a travel advance is involved, create it through the shared Loans workflow and retain the correct employee, currency, and service linkage.

An empty lookup usually means a scope, approval, active-state, effective-date, or upstream-setup issue. Do not enter an internal database ID as a substitute for a missing lookup.

Per-diem policy

Per diem is a policy-defined allowance for eligible days or assignments. It can be used for qualifying travel and other approved assignments; the policy is configuration, not a payment transaction or expense claim.

The setup form captures a policy name, domestic/international scope, country, currency, daily rate, meals-reduction percentage, lodging daily limit, and effective dates. The system generates the policy code. Approval and active/effective status determine whether a request can use the policy.

For a travel request, the selected policy must be approved, active, service-scoped, and cover the entire departure-to-return window. The request snapshots the policy terms used, so a later policy edit does not silently rewrite the request calculation. Current request calculation is:

travel days = return date - departure date + 1
per diem = travel days × daily rate × (1 - meals reduction percentage / 100)
estimated total = per diem + estimated lodging + estimated transport + estimated other

The current calculation is an inclusive day count. The configured lodging limit is retained as a snapshot; users should still review actual lodging evidence and claim-line policy limits before approval.

Travel request workflow

The Requests tab lists generated reference, employee, destination, dates, per diem, estimated total, and request status. Create a request with the employee, approved policy, purpose, destination, departure and return dates, and estimated non-per-diem amounts. Requests cannot be created for a past departure date or with a return date before departure.

The current request actions are:

Current state	Action	Result
Draft	Submit	Moves the request to Submitted for review.
Submitted	Approve	Approves the request. The creator cannot approve their own request.
Submitted	Reject	Rejects the request; a reason is required.
Draft or Submitted	Cancel	Cancels the request.

Only an approved or completed request can be used for a claim. A claim can be created only once for a given travel request. Request approval authorises the planned travel; it does not recognise a payable or move money.

Create and review an expense claim

The Claims tab displays the generated claim reference, employee, claim date, claimed and approved totals, amount due to the employee, advance reconciliation, settlement GL state, and claim status.

Create a claim against the approved/completed travel request. The employee and currency must match the request. The form captures the claim date, currency, optional advance amount and shared Loans account, notes, and an expense line with type, date, positive amount, description, tax treatment, receipt state, and optional policy limit. The present form exposes one expense line per claim submission; the database model stores lines and the approval routine can validate every line.

If an advance is recorded, select the actual shared Loans account belonging to the same employee and HR service. The advance amount must be positive, the account must be eligible and in the claim currency, and the claim must later reconcile the advance. Do not create a parallel HR loan record for a loan that already exists in Loans.

Current state	Action	Result
Draft	Submit	Moves the claim to Submitted for review.
Submitted	Approve	Validates expense lines, calculates approved totals and the amount due/advance return, then posts the claim accrual.
Submitted	Reject	Rejects the claim; a reason is required.
Draft or Submitted	Cancel	Cancels the claim.

Approval requires each line to have an explicit taxable or non-taxable treatment. Missing/rejected receipts must be resolved, and amounts above a policy limit need an approved exception. Approved lines are totalled separately for taxable and non-taxable values. The balance is calculated as:

amount due to employee = max(approved claim - travel advance, 0)
advance return due = max(travel advance - approved claim, 0)

If the employee owes back an advance, reconcile the return through a posted repayment in the shared Loans module. The claim transition checks that repayment belongs to the linked travel advance and matches the expected amount, currency, and HR service. The claim cannot be paid out while that return remains unreconciled.

General-ledger and payment treatment

There are two distinct accounting events. They must not be collapsed into one journal:

Event	Debit	Credit	When it occurs
Claim approval/accrual	HR travel expense	HR travel-claim payable	When a non-zero approved claim is approved. Uses HR.TRAVEL.CLAIM.ACCRUAL.
Cash settlement	HR travel-claim payable	CASH_AT_HAND account	When a cash/teller payment is linked and its settlement is posted. Uses the cash settlement rule.
Bank settlement	HR travel-claim payable	CASH_BANK account	When a bank payment is linked and its settlement is posted. Uses the bank settlement rule.

The chart-of-account targets resolve through approved HR and cash/bank tags. Cash and bank are separate settlement methods and separate account mappings. The settlement rule must not debit the expense a second time or credit the payable again.

The HR form does not initiate the money movement. It requires the already completed shared Payments transaction for the exact amount due: the payment must be SETTLED, OUTBOUND, in the same HR business unit and currency, and within the amount tolerance. The form then links that payment to the claim and invokes the settlement GL rule. If posting does not return a posted GL batch, the claim is not marked settled. A separate Reconcile settlement GL action is exposed for a settled claim whose settlement posting is pending reconciliation.

The travel procedures do not require an open business-day session. This does not bypass central accounting controls: the settlement journal uses the payment value date, so the general-ledger posting path can still enforce its applicable posting-date and fiscal-period rules.

Payroll interaction

An approved taxable claim may become a payroll input when the payroll input policy enables the relevant travel-claim source and the claim is eligible. The claim's taxable and non-taxable totals are tracked separately. Payroll consumption is a separate workflow from claim approval and GL accrual.

The procedure prevents paying through shared Payments after the claim has already been consumed by payroll. This avoids paying the same employee amount twice. Teams should decide which payment path applies before settlement and reconcile the payroll input, claim status, payment, and GL batch together.

Audit and troubleshooting

Claim and request actions are logged with the actor, service business unit, action, and record reference. For an error, check in this order:

• Policy unavailable: approval, active status, service scope, country/currency, and policy effective dates.
• Request cannot be claimed: request state must be Approved or Completed; verify employee and currency match and that a claim does not already exist.
• Claim approval blocked: tax treatment, receipt evidence, policy-limit exception, and the approved accrual posting rule.
• Advance cannot reconcile: shared Loans account ownership/scope/currency and the posted repayment transaction amount/status.
• Settlement rejected: exact settled outbound payment, employee/business-unit scope, currency, amount due, and unresolved advance return.
• GL settlement pending: inspect the payment's GL batch, the corresponding settlement rule, the resolved payable/cash/bank tags, and the posting date/period.
• No open-business-day record: that is not by itself a blocker for these HR travel procedures; investigate the actual payment and GL posting response instead.

Current implementation boundaries

• Travel Requests and Travel Claims are distinct tabs and have separate lifecycle actions.
• Route wiring must be confirmed before treating the request/claim UI as operational. In the currently reviewed backend develop source, the app mounts business/hr/operations/travel_expense/routes.ts at /api/travel-expense. That router declares expense categories and legacy expense reports, but not the /travel-requests, /travel-claims, or transition paths called by the current frontend. The corresponding controller/service methods and SQL procedures exist, but the mounted HTTP routes are absent from that route list. Treat request/claim UI/API end-to-end operation as unverified until those endpoints are wired with their permissions and the HR_TRAVEL_EXPENSES capability guard.
• A claim uses shared Payments for the actual outbound payment; selecting a payment only records settlement evidence and triggers the claim settlement accounting link.
• Shared Loans owns travel advances and their repayments.
• The current claim form captures one expense line per submission even though the stored claim has line records.
• Provider/employee payment completion is not inferred from request approval or claim approval. Verify the settled payment and posted GL batch independently.

Related guides

• HR Overview
• Capabilities and Access
• HR Setup
• Payroll
• Benefits and Total Rewards