Expense Management holds no money of its own. Every event — a claim approved, an advance paid, a card bill settled — posts a balanced journal into the same ledger as every other finance document, dated by the document's date and linked back to its source record. Posted lines are immutable; corrections are reversals. What the module adds on top is the employee subledger: per-employee open items that carry what the company owes each person and what each person owes back, reconciled to control accounts like any receivable or payable.
The posting map
| Event | Debit | Credit |
|---|---|---|
| Claim posted (on final approval) | each line's expense account; input GST for ITC-eligible tax | Employee Payable, net of any advance adjustment |
| Reimbursement (single or batch) | Employee Payable | Bank |
| Claim handed to payroll (run Calculate or Settle via Payroll) | Employee Payable | Payroll Payable |
| Claim paid by the salary payment batch | Payroll Payable | Bank |
| Advance paid | Employee Advance | Bank |
| Advance settled against a claim | Employee Payable | Employee Advance |
| Advance recovered in cash | Bank | Employee Advance |
| Card transaction posted | the transaction's expense account | Card Payable |
| Card statement paid | Card Payable | Bank |
Two details in the claim posting are worth knowing. First, the ITC split: on a line marked ITC-eligible, the tax goes to the input-GST account and only the net amount hits the expense head — the tax is recovered, not expensed; on other lines the gross posts to the expense head. Per-component tax details (CGST, SGST, IGST, cess) are also captured for tax reporting, on a best-effort basis that never blocks the ledger posting. Second, dimensions: cost centers are stamped on the expense lines only — never on the control or bank lines — so cost-center reporting stays a clean P&L view, while branch rides every line it applies to.
Where the accounting inputs live on the claim
The header of an expense claim carries the accounting context: Resource (the employee whose subledger carries the payable), Claim Date (the posting date), Currency Code, Branch, PaymentGL Account (the bank or cash account a finance reimbursement credits) and, on the Reimbursement tab, Reimbursement Mode — FinancePayment (paid by a finance reimbursement, singly or in a batch) or Payroll (pulled into the employee's payroll run at Calculate and paid by its salary payment batch; Payroll Period and Payroll Component are for reference only). Each claim line carries the Expense GL Account it debits, its Cost Center, Tax Amount and Itc Eligible flag, and the recharge fields (Is Billable To Customer, Customer Account, Markup Percent). The header also shows the three statuses the ledger side reads: Approval Status, Posting Status and Payment Status.
The Reimbursement Mode list ships with Finance payment and Payroll. Every value other than Payroll behaves as finance payment; only the stored value Payroll routes the claim to payroll, so keep it unchanged if you edit the list. Each line also needs its Expense GL Account filled in — it is not taken from the expense category, and a line without it does not post.
The posting steps are entity actions on the claim, so they can be driven by automation: Evaluate Policy, Post, Reimburse, Settle via Payroll, Compute Recharge and Link Recharge Invoice. The standard claim header shows only Evaluate Policy and Post; add the others to the claim's view layout for the users who need them.
Employee balances are open items
Posting a claim raises an open payable item against the claimant's employee record; paying an advance raises an open recoverable item the same way. Reimbursements, settlements and recoveries reduce those items until they close. Because balances live as open items rather than as GL detail, the GL stays summarized — the control accounts carry totals, the subledger carries the per-employee story — so the open items and the control account move together unless someone posts to the control account by hand. This is the same open-item machinery behind the AR and AP subledgers.
Automatic posting, and its one failure mode
Final approval posts the claim automatically (stamping Status and Posting Status to Posted), and replaying a decision never double-posts because an already-posted claim is skipped. But the approval decision and the posting are deliberately decoupled: if posting fails — a missing Employee Payable control account is the classic cause; the error names the missing account type — the approval stands and the failure is logged rather than rolling the sign-off back. The tell is a claim whose Approval Status is Approved while Posting Status is not. Fix the cause and run Post Claim on the claim; Troubleshooting decodes each posting error.
Rebilling clients: recharge
Claim lines marked billable-to-customer carry the customer and an optional markup. Compute Recharge on the claim flags those lines as pending billing and returns the per-customer (and per-project) totals — cost, and cost with markup applied. You then raise the customer invoice through your normal sales flow for those totals, and Link Recharge Invoice stamps the lines as Billed against that invoice, closing the loop so nothing is rebilled twice or forgotten.
Reconciliation and period close
xMatix has no screen or close check that compares the employee open items with their control accounts, so tie them out yourself before closing a period. Compare the total still open on posted claims, and the total Outstanding Amount on paid advances, with the Employee Payable and Employee Advance account balances. A difference usually means a manual journal hit a control account directly, or a journal was reversed without its source record. A payroll-mode claim already handed to payroll still shows Payment Status Unpaid, but its balance sits on Payroll Payable, not Employee Payable, until the salary payment batch pays it — leave such claims (their employee-payable open item is already settled) out of the Employee Payable comparison.
Common questions
Which period does a claim post into?
The period containing its claim date — the same rule every document and journal follows. Reimbursements post on their payment date. A claim dated last month posts into last month, provided the period is open.
Why isn't the employee a party on the payable, like a supplier?
Because the employee is identified on the open item, not on the journal line. The control accounts are configured so their lines need no party — the subledger holds the per-employee detail while the GL stays summarized. It also means expenses and payroll share one person key: the employee record.
The claim is approved but never appeared in the ledger — is the approval lost?
No. The approval committed; the posting that follows it failed and was logged. Fix what the error names — almost always a missing control account or a claim with nothing postable — and post the claim manually. The claim's posting status tells you which side you are on.
Can a posted claim be corrected?
Not by editing — posted journal lines are immutable. Correct through the finance reversal pattern: reverse the posting journal, fix the claim, and post again. The original stays in the ledger as the audit record, exactly as with manual journals.