Claims Management Module
An employee pays for something out of their own pocket and wants the money back. This module is the paperwork between those two events: the claim they submit, the supervisor who approves it, the entitlement balance it draws on, the monthly cycle in which finance reviews it, and the reports somebody takes to the bank portal or to payroll.
Applets in this module
Membership is an editorial judgement — the product has no module↔applet relationship in its data, rather than left to the folder each page happens to sit in. Claims owns two applets, and both are documented.
| Applet | What it is for |
|---|---|
| Claim Applet | Where a claim is written and approved. A claim header holds one or more claim lines; each line names a claim item (the expense type), an amount, dates and receipts. The applet also owns nearly all the module’s master data: claim items and categories, claim accounts and entitlements, approval settings, cut-off logic, travel-allowance rates and the notification e-mail templates. It stops at supervisor approval. |
| Claim Cycle Applet | The finance side. A claim cycle is one company, one month. Approved lines land in it; reviewers accept them level by level or put them on hold; auditors draw samples; and the applet generates the Bank Report, PV Details Report, Cross-Billing Report, Pivot Report and Professional Subscription Report. Closing a cycle pushes whatever is still unreviewed into next month’s. |
Both applets store their data in the claims records — AAT, the family’s internal name, is audit, assurance and tax, the practice area the module was originally built for. That is why the professional-body, engagement and sampling features exist and why they read as more audit-firm than retail.
The line is the unit of everything
The claim header is a folder. Every status, every approval, every entitlement deduction and every report row is on the line. Two lines on the same claim can take different approval routes, land in different months and be paid in different ways. The header status is recomputed from its lines after every change.
flowchart TD
D["DRAFT<br/>claimant writes the line"] -->|Submit| P["PENDING_APPROVAL"]
D -->|"Submit, line ticked<br/>Non-Reimbursable"| A2["APPROVED<br/>never routed"]
P -->|"supervisor rejects"| REJ["REJECTED<br/>claimant may clone it"]
P -->|"last approval level approves"| SPLIT{"claim item's<br/>Payment Processing Option"}
SPLIT -->|SALARY_PAYMENT| A1["APPROVED<br/>hand to payroll"]
SPLIT -->|FINANCE_PAYMENT| R["PENDING_DOC_REVIEW<br/>waiting for a claim cycle"]
R -->|"swept into the month's cycle"| INBOX["Checking Reports → Inbox"]
INBOX -->|"reviewer accepts"| REV["REVIEWED<br/>then APPROVED at the final level"]
INBOX -->|"reviewer puts on hold"| HOLD["ON_HOLD<br/>claimant e-mailed"]
HOLD -->|"claimant resubmits"| RES["RESUBMITTED"] --> INBOX
REV --> PAY["Bank Report / PV Details Report<br/>→ paid by hand"]
A1 --> PAY2["Payroll Payment report<br/>→ paid through payroll"]
For an entitlement line, the final supervisor approval is also the moment the entitlement balance
is spent: a UTILIZE line (a negative amount) is posted to the claimant’s claim account, with a
CONVERSION line against a convertible account if the main one is short. That happens only when the
claim account has Display Entitlement Balance ticked — see below.
What actually reaches the ledger
Nothing. This is the single most important fact about the module and the one most often written the other way round.
Claims posts no journal, moves no stock, and creates no payment voucher. A claim is not a generic financial document: it has no amount or quantity signum, no entry in the product’s journal posting handler, and no stock processor. The header carries posting-status fields for a payment voucher and a purchase invoice — nothing in the claim module ever sets them.
Money leaves the business through the Bank Report (one payment per employee, with bank code and account number), the PV Details Report (per line, with GL code and tax — the working paper for a manual Payment Voucher) and the salary-payment CSV export. All three are hand-offs to a human, a bank portal, payroll or an external integration. None of them is an automatic posting.
The GL codes you set on a claim item are carried onto the line for reporting — they appear in the PV Details and Cross-Billing reports so whoever raises the payment voucher knows what to code it to. They do not post anything by themselves.
Approval here is real — and it is not the platform’s approval engine
Claims is the exception to the rule that runs through the rest of this wiki. BigLedger’s generic document-approval engine covers exactly three document types — Purchase Order, Purchase Requisition and Stock Requisition — is off until configured, and never gates a document. Claims has its own, separate, always-on approval engine, built on its own approval settings and per-line approval sequences, and a claim line genuinely cannot proceed without it.
It is also not Workflow Design, which is an inert status-label engine that nothing in claims reads.
The Approval Workflow drop-down on a claim item offers three choices, not five. The backend enum has more values in it, and the difference matters the first time you go looking for one that is not there:
| What the drop-down says | What it stores | Where the approvers come from |
|---|---|---|
| Non-Chargeable — the ordinary case | EMPLOYEE_ORG_CHART | Employees holding an approval designation in the claimant’s branch |
| Non-Chargeable – Entitlement | CLAIM_ACCOUNT | The HR approval levels configured on the claim account |
| Chargeable | ENGAGEMENT_PIC | The roles on the engagement the line is booked to |
EMPLOYEE_ORG_CHART is not retired and it is not legacy — it is the value the screen writes today
for an ordinary staff expense, and the approval processor treats it and EMPLOYEE_AD_HOC as the
same thing, sending both to the ad-hoc logic. If you read EMPLOYEE_AD_HOC in an export or an API
payload, that is the same route under its other name.
Two more values exist in the enum and cannot be chosen on the claim-item screen:
PROJECT_PIC— approvers from a project’s person-in-charge roles. The processor handles it, so a claim item written through the API works.EVENT— the processor has no branch for it. A line on anEVENTclaim item falls through every case, gets no approval sequence, and sits atPENDING_APPROVALfor ever with no error on any screen. Do not create one.
Two things follow that surprise people:
- A line ticked Non-Reimbursable is never routed at all. It goes straight to
APPROVEDon submit. It is for expenses the company has already paid and only wants recorded. - A submission fails outright if the approval setting is incomplete — no level or quorum, no approver for the designation, no default approver. The message names the gap; the claim is not saved in limbo waiting for someone to fix it.
The entitlement balance is enforced by a checkbox called “Display”
Claim accounts and entitlements are the allowance side: a pool, a top-up amount, a validity period,
and a per-employee balance. When a claimant submits an HR-benefit line, BigLedger checks the
submission against the available balance less anything already pending, and refuses it with
CLAIM_DOC_LINES_INSUFFICIENT_BALANCE if it does not fit.
The check also covers only lines whose workflow type is CLAIM_ACCOUNT. Ad-hoc, engagement, project
and event lines have no entitlement and no cap of any kind.
Three things this module is often believed to do, and does not
It does not post expenses to the general ledger or raise an accounts-payable balance. See above. Every sen of it leaves the business through a report and a person, not a posting.
It does not split expenses into tax-deductible and non-deductible portions. There is no deductibility field, rule or percentage anywhere in the claim domain — the word does not appear in the backend at all. Whatever your tax treatment of entertainment is, it is applied by whoever codes the payment voucher, using the GL codes carried on the PV Details Report.
It does not cap claims by job grade. Claims has no concept of a grade. Limits come from two places only: the claim account entitlement balance (per employee, and only when Display Entitlement Balance is on), and the claim item’s Claimable Period (Days), Threshold and UOM — for example RM 0.80 per kilometre with a distance cap. There is no over-limit override path, no secondary approval for exceeding a cap, and no threshold that routes to a different approver.
What this module needs from others
| Module | What it supplies |
|---|---|
| Core | Employee Maintenance — claimants, approvers, reviewers, designations, and the bank details the Bank Report reads. Organization — companies, branches, and the holiday calendar the cut-off dates skip. Chart of Account — the expense and billing GL codes carried on each claim item. Entity Maintenance — the entity records employees sit on. Forex — the rate source for foreign-currency lines. |
| Financial Accounting | Payment Voucher (Internal) — where the reimbursement is actually recorded, by hand, from the PV Details Report; and the Cashbook the money leaves from. |
| CRM & Digital | Engagement — the client job a chargeable claim line is booked against, and the source of its approvers. |
| HR & Payroll | Claim items set to Salary Payment are approved and handed to payroll rather than paid by the finance cycle. Note that the HR & Payroll module owns no applet in the registry — see its page. |