Claim Applet

Employees submit out-of-pocket expense claims here and supervisors approve them; finance review and payment happen afterwards in the Claim Cycle applet. A claimant is matched to an employee record by login e-mail, and without that link the applet refuses to load their claims.

Your job, and the screen for it

Overview

The Claim Applet is where employees submit out-of-pocket expense claims and where their supervisors approve or reject them. A claim is a header (title, claimant, cost-centre branch) with one or more claim lines; each line names a claim item (the expense type), an amount, dates, receipts and — depending on the item — an engagement, an event, a travel destination or a professional body. The applet also owns all the master data that drives the process: claim items and categories, claim accounts and entitlements (annual or monthly allowances per employee), approval settings, cut-off logic, travel-allowance rates and notification e-mail templates.

The applet stops at supervisor approval. Finance review, sampling, on-hold handling and the bank / payment-voucher reports happen in the Claim Cycle Applet, which picks up approved lines month by month. The module was built for an audit, assurance and tax practice, which is why a claim line can be charged to an engagement (a client job) and re-billed.

Where it fits

Module: Claims Management.

Screens and menus

Sidebar:

My Claim → create / edit. Main Details (Claim ID, Claim Title, Claim Status, Employee Name / Code, Branch (Cost Center)) and Claim Lines. A line opens with tabs Main, Approval Sequence and History; the Main tab changes shape with the claim item (engagement fields, event picker, professional-body fields, travel location / mileage / meal deductions, receipt date and number, attachments, OCR-scanned values). Buttons: Save, Submit, Resubmit (after finance on-hold), Export. Split actions divide a line across branches (chargeable and non-chargeable split components). The line editor comes in two builds — single access and multiple access — and the listing opens whichever matches the claimant’s company access; they save the same way.

Settings → System Configuration: Application Settings, Claim Accounts, Claim Entitlements, Claim Entitlement Auto Top-up Template / Events / Run, Claim Item Category, Claim Items, Professional Body, Subscriptions and Memberships, Travel Allowance, Claim Cut-Off Logic, Claim Approval Settings, Claim Approval Delegation Period Settings, Branches (shown as Job Groups when relabelled), Email Template, Upload Employee Entitlement, Printable Format Settings. Shared screens: Webhook, Feature Visibility, Permission Wizard / Set / User / Team / Role, Applet Log (audit trail). A Default Selection screen exists but has no menu entry (see Applet settings).

Personalization: Default Selection (personal), Favourite Claims, Sidebar.

Configuration

Before you can use it

Applet settings

How settings and permissions work in general is explained once at Settings and permissions; this section only says what is particular to this applet.

Settings live in four places, none of them the shared inline settings gear:

1. Application Settings — the applet’s own Field Settings screen, saved tenant-wide.
2. Default Selection — master defaults for branch, location and company (DEFAULT_BRANCH, DEFAULT_LOCATION, DEFAULT_COMPANY); reachable only by URL because the menu entry is switched off. Choosing a branch fills the company and the branch’s main location; read as the initial cost-centre branch on new claims.
3. Personalization → Default Selection — per-user settings, merged over the master settings at runtime.
4. Master-data screens (Claim Items, Accounts, Entitlements, Approval Settings, Cut-Off Logic, …) — this is where almost all real behaviour is configured; see the next sub-section.

Application Settings is eleven slide toggles. Five of them hide something you can see the moment you flip them — the Claim Category picker on the line editor (HIDE_CLAIM_CATEGORY), the grid / list toggle on My Claim and Line Reports (HIDE_TOGGLE_BUTTON), the Employee Ranking tab under Settings → Branches, the billing company / financial item / GL / markup fields on Claim Item create and edit, and the Claim Approval Delegation Period Settings menu entry (HIDE_CLAIM_APPROVAL_DELEGATION_PERIOD — delegations already recorded still apply when approvals are processed; only the screen goes). One replaces the word Company with Entity across the applet (RELABEL_COMPANY_TO_ENTITY). The rows below are the toggles whose effect is not on the screen in front of you:

On the screen and doing nothing

Enable Audit Trail is rendered and saved, and read by nothing in this applet; the Applet Log screen works regardless of the toggle. The same key name is a live control in the claim-cycle, engagement and events applets — each reads its own settings, not this one.

Personalization → Default Selection (per user). DEFAULT_BRANCH / DEFAULT_LOCATION / DEFAULT_COMPANY override the master defaults on claim create. DASHBOARD_DURATION_TYPE (WITHIN_THE_PAST_NUMBER_OF_MONTHS, the default, or NO_DATE_RANGE) and DASHBOARD_DURATION (months, default 3; required unless the type is no-range) set the window of the My Claim and Line Reports dashboards, and the window is on Created Date — the listing has no transaction-date column. DEFAULT_ORIENTATION (HORIZONTAL / VERTICAL) and DEFAULT_TOGGLE_COLUMN (SINGLE / DOUBLE) are layout preferences for the report and settings containers and the edit panels; they change nothing but the layout.

A key read at runtime without a control in this applet: VERTICAL_ORIENTATION (read alongside DEFAULT_ORIENTATION). PRINTABLE has no toggle on the settings screens, and it matters more than it looks: the Export button on the line editor is disabled unless the key is set, and the key is written in one place: ticking a format in the Default Selection column of Settings → Printable Format Settings saves that format as PRINTABLE. Until someone ticks one, Export on a claim line, and on the claim header, is greyed out for every user. The remaining keys in the applet’s settings model (the SST and WHT enable flags, HIDE_UNIT_PRICE_*, custom-status keys, the gen-doc listing switch, …) are copied from the document-applet template and are neither rendered nor read.

Master-data settings that drive behaviour

Claim Items (unique on code + expense company) are where the process is really configured. The form takes name, code, category, the approval workflow and its approval setting, the payment processing option, a claim account (for entitlement items), the expense company / financial item / GL code, and on a Chargeable item (approval workflow ENGAGEMENT_PIC) the billing company / financial item / GL code / markup ratio — Hide Claim Item Billing Fields hides both financial items, the billing GL code and the markup ratio, and leaves the billing company and the expense GL code on the form — a claimable period in days, a threshold and its unit (KM / DAYS), and a row of Required … switches: supporting document (normal attachment or OCR attachment), vendor / receipt date / receipt number, follow-up programme and guests, subscription and membership type, professional body, travel allowance, mileage claim, location tracking, internal employees, and Custom Validity Date By HR. The GL codes and financial items are copied onto every line for reporting; this applet posts no journal. The fields that decide behaviour:

Claim Accounts / Entitlements / Auto Top-up. A claim account (code, name, currency, Display Entitlement Balance) is a pool. Entitlements define the top-up (amount, whether it recurs and on what rule, calculation By Amount / By Quantity, validity periods, No limit, Prorate for new joiners). Employees are linked per entitlement (with balance); Account Conversion lets a main account draw on a convertible account when short. HR Claim Approval on the account lists the HR approvers per level. Auto top-up is a three-step chain: Template (entitlement + company / job-role filters) → Event (code, recurring, start / end) → Run (start / end; Employee Top-up tab with Draft and Top-up sub-tabs) which posts TOPUP transaction lines. The balance a submission is checked against is the available balance minus lines already pending approval, so two claims submitted the same afternoon cannot both pass on one balance; the message is "%s claim amount of RM%s exceeds your claim balance of RM%s." with the net figure.

Claim Approval Settings: Name, Code, Approval Workflow, Default Approver (employee), Branch, Engagement Role, and per level: Approval Level, Approval Type (ANY_TO_APPROVE / ALL_TO_APPROVE), No of Approvers (quorum), Engagement Role to Approve. The number of required levels is validated against what is actually configured.

Which branch approves a non-chargeable line. The approval branch is the line’s cost-centre branch, not the claim header’s — a claim can carry lines charged to different branches and each is routed to its own. The designation looked up in that branch is the claimant’s job title if a branch designation of that name exists there, otherwise the literal Staff, which is why a branch with no Staff designation stops every junior employee’s submission. One override exists in the platform: an overriding rule (keyed by claimant or by expense branch, optionally per company) that routes the line to the claimant’s default branch instead. No screen in this applet, or in any other, creates such a rule; it is API-only.

Claim Cut-Off Logic (one per company): finance cut-off (LAST_DAY_OF_THE_MONTH or SPECIFIC_DAY_OF_THE_MONTH + day), supervisor approval cut-off (HOW_MANY_DAYS_BEFORE_FINANCE_CUTOFF_DATE + count, or a specific day), extension window (HOW_MANY_DAYS_AFTER_FINANCE_CUTOFF_DATE + count, or a specific day), finance last-review date, and — a September 2026 addition — an Immediate Ingest panel with the toggle Auto-add approved claims to active cycle. When it is on, the moment a line gets its last supervisor approval it is attached to the company’s current-month OPEN cycle, in the company’s own timezone, creating the cycle if there is none, and bypassing the approval cut-off date. The toggle only matters for a line that found no cycle at final approval: whether it is on or off, final approval first attaches the line to its company’s cycle for the month of the final approval when that cycle already exists and the approval falls on or before the cycle’s approval cut-off end (or inside the line’s on-hold window). Only a line that finds no such cycle goes to the current month’s OPEN cycle (toggle on) or waits for the scheduled claim-cycle sweep (toggle off) — see Lifecycle. A line that already has a cycle is never moved.

Claim Approval Delegation Period: Main Employee, Delegated Employee, start / end dates. Applied when approvals are processed: the sequence row is marked as a delegated approval with the delegating approver’s name.

Branches: Main Details (Name, Code, Approval Setting, Description) plus Employees, Employee Ranking and Approval Designation tabs (designation → employees with approval level). This is where non-chargeable approvers are resolved.

Travel Allowance: Destination, Claim Item, Breakfast / Lunch / Dinner / Inconvenience, Total Amount. A travel line stores which meals were included and deducts them from the per diem.

Email Template: Name, Type, start / expiry, Line tab (template code, message type / status, body) and Placeholders. The notification jobs look for the template codes CLAIM_PENDING_APPROVAL_NOTIFICATION, CLAIM_PENDING_APPROVAL_DAILY_REMINDER_TO_APPROVER_NOTIFICATION and CLAIM_REVIEW_NOTIFICATION.

Before you write a template, find out whether anything will ever send it. The daily 09:00 clock that sends the approval notification (the CLAIM_EMAIL_NOTIFICATION_FOR_APPROVAL_PROCESSOR job, cron 0 9 * * *) is not installed when you save a template and is not part of the platform’s default tenant schedule. The cut-off job is meant to install it, on every run, whenever it is missing — but the schedule row it builds has no code, the scheduler refuses a row without one, and the failure is discarded, so it tries and fails again on every run. The review notification (CLAIM_EMAIL_NOTIFICATION_FOR_REVIEW_PROCESSOR, daily at 01:00 UTC) has an installer that nothing calls. So every claim clock that exists anywhere was put there by hand.

So unless your tenant’s administrator has created the rows, every template on this screen is inert: correct, saved, and never sent. Ask them to confirm CLAIM_CYCLE_CUTOFF_DATE_PROCESSOR and CLAIM_EMAIL_NOTIFICATION_FOR_APPROVAL_PROCESSOR are on the job schedule (Scheduler Applet), with the code filled in, before you promise anyone an e-mail. The cut-off job also creates the monthly claim cycle header; with Auto-add on, final approval creates its own cycle header, so cycles are not entirely dependent on it, but the notifications are.

Claim Item Category, Professional Body (name, code, country), Subscriptions and Memberships (name, code, type), Upload Employee Entitlement (file import with Checking tab and delimiter), Printable Format Settings (format code / name).

Document behaviour settings

No status-flow, posting or e-Invoice toggles exist: the claim is not a generic financial document. Behaviour is fixed by the claim item (payment processing option, required fields), the approval setting and the cut-off logic described above. Printables are limited to the Printable Format Settings list and the Export action (which needs PRINTABLE, above).

Who can change what

• Client-side permissions: none are defined for this applet, the applet reads none, and the client-side permission screen is switched off.
• Server-side (API) permissions are what the Permission Wizard assigns: API_TNT_DM_ERP_AAT_CLAIM_ITEM_HDR_{OWNER,ADMIN,MEMBER,CREATE,UPDATE,DELETE,READ}, API_TNT_DM_ERP_AAT_CLAIM_ITEM_TRAVEL_ALLOWANCE_*, API_TNT_DM_ERP_AAT_CLAIM_PERSONAL_FILTER_SUBSCRIPTION_EVENT_*, and on the HR side HR_CLAIM_ACCOUNT_ENTITLEMENT_APPROVAL_SETTING_*.
• Role separation is by which side of the service a screen talks to, not by toggle: the claimant screens use the claimant’s own-record services (Submit checks that every line’s claimant is the caller’s own employee record), while supervisor and settings screens use the back-office services. Whether a user sees the Supervisor group is a matter of the shared Feature Visibility screen and the permission sets granted.

Fields

Claim (header) — Main Details

The header is a title, the claimant (resolved from the login e-mail, not chosen), a status, a cost-centre branch and a Claim ID. The Claim ID is assigned by Submit, not by Create, so a draft has none. The Branch (Cost Center) must be chosen before the Add line button enables, and it defaults from Default Selection — but it is not the branch that routes approvals: each line carries its own cost-centre branch, chosen on the line, and that one is read by the approval logic and copied onto the approval sequence. The header’s transaction date is stamped with the moment you pressed Create, has no control, and no screen in this applet shows it — the listings and dashboards work on Created Date.

Save on the header loads the stored claim, overwrites exactly four fields — branch, company, title, claimant — and sends it back without touching any line. Nothing is blanked and nothing else is rewritten.

Claim line — Main

A line takes a claim category and item, a description, cost-incurred start and end dates (both default to today), the approval workflow (copied from the item, but shown as a radio group you can change on the line), a Non-Reimbursable tick, the amount before and after tax with the tax amount, a currency and — when the item asks for them — an engagement with its financial year end and billing branch, an event, a professional body / subscription / membership number and type / validity dates, follow-up programme / nature of guest / external party / internal attendees, travel location / mileage or days / meal deductions, vendor / receipt date / receipt number, attachments and OCR-scanned values, and a foreign-currency block (foreign amounts, rate, forex source). The line editor Save rebuilds the stored line from the form field by field — so clearing a field clears it, and there is no shape here that silently keeps an old value. The fields that carry a consequence:

Claim line — Approval Sequence / History

Read-only: one row per approval level with approver, delegated-approver flag, action (MASS_APPROVE, INDIVIDUAL_APPROVE, MASS_REJECT, INDIVIDUAL_REJECT) and remarks; and the line’s approval history.

Where a line can vanish — TEMP, DRAFT and Submit

Add line does not open an empty form. It first creates a line on the server with status TEMP (toast “A Temporary claim line is created”) and then opens the editor on it. Save in the editor writes the form and sets the line to DRAFT. Closing the editor without pressing Save also writes the form — the editor autosaves on close when the line is still TEMP — but leaves the status at TEMP. The difference is invisible in the line list and decisive on Submit: Submit deletes every TEMP line of the claim before submitting and refuses only when all lines are TEMP (“All claim lines are TEMP. There is no DRAFT claim line for submission.”). A line you filled in and closed is therefore gone the moment the claim is submitted, with a success toast. If nothing is submitted, the CLAIM_SCHEDULER_TO_AUTO_PURGE_TEMPS_PROCESSOR job — where a tenant has scheduled it — deletes TEMP headers and lines created more than 30 days ago.

Submit itself loads the stored claim, patches the four header fields and sends the server’s own copy of the lines — an edit sitting unsaved in an open line panel is not part of what is submitted.

Lifecycle and effects

Statuses. Header: TEMP, DRAFT, SUBMITTED, APPROVED (all lines approved), CLOSED (all lines rejected or withdrawn). Line: TEMP, DRAFT, PENDING_APPROVAL, APPROVED, REJECTED, WITHDREW, RESUBMITTED, PENDING_DOC_REVIEW, REVIEWED, ON_HOLD, plus failure states FAIL_TO_SUBMIT, FAIL_TO_WITHDRAW, FAIL_TO_RESUBMIT, FAIL_TO_PUT_ON_HOLD. Processing states, shown as the line’s processing status: INSERTED_TO_QUEUE, PROCESSOR_SUCCEED, PROCESSOR_FAIL, PROCESSOR_FAIL_CLAIM_APPROVAL_SETTING_NOT_FOUND, PROCESSOR_FAIL_CANNOT_CREATE_APPROVAL_SEQUENCE, PROCESSOR_FAIL_APPROVAL_SEQUENCE_IS_EMPTY, POSTED, FAILED_TO_POST.

Submit is one button, and it does its work inside the request. The claimant’s screen and the back-office screen run the same submission: header → SUBMITTED and a Claim ID is issued; every line → PENDING_APPROVAL, except Non-Reimbursable lines → APPROVED, and one hard-coded job title whose lines go straight to PENDING_DOC_REVIEW. The checks then run — the balance check, the per-line checks (OCR attachment, claimable period, receipt date, membership validity, entitlement, approval setting, designation, approver count) and the general checks (zero amount, attendees by item name); any failure returns the message you see and nothing is written. On success each pending line is processed there and then, before the response comes back: the approval sequence is built with the workflow’s logic, history is recorded, the approval-request and risk-score steps run the same way, and the first approvers’ e-mail is attempted. What you see when the toast appears is already the finished sequence, or a line whose processing status says why not.

The queue behind it is a safety net that nothing sweeps. A line is left waiting only when the in-request run failed. Nothing drains that queue on its own — the helper job that exists “to process stuck events” is never triggered — and the repair a support person actually has is the retry call, which re-queues a line only when its claim status is one of the four FAIL_TO_* values — that is, when the line could not be queued at all — again inside the request. There is no button for it. A line that was queued and whose run then failed (a processing status beginning PROCESSOR_FAIL) keeps the claim status pending approval, so the retry fetches it and skips it; its queue event was consumed when it ran, so the manual queue drain finds nothing either. The way back is the claimant’s: withdraw the line and raise it again.

Approve / reject (one call for a mass approve): each approval advances the level; delegation periods substitute the approver and record the delegation. When the last level approves: SALARY_PAYMENT items → APPROVED; everything else → PENDING_DOC_REVIEW. At the same moment — but only for a line on the claim-account (entitlement) workflow, and only when the claimant’s balance for that claim account has Display Entitlement Balance set — a UTILIZE transaction line (negative amount) is posted to the claimant’s claim account, with a CONVERSION line on the convertible account if the main account is short, and the account balance is updated. On any other line, or with Display Entitlement Balance off, final approval leaves the balance untouched, so an entitlement tracked without that tick is never reduced by an approved claim. The final approval also attaches the line to its company’s cycle for the final-approval month if that cycle already exists and the approval is on or before its approval cut-off end (or inside the line’s on-hold window), whatever the toggle says. A line that finds no such cycle is attached to the current month’s OPEN cycle at once if the company’s cut-off row has Auto-add approved claims to active cycle on; otherwise the scheduled claim-cycle sweep (CLAIM_CYCLE_PROCESSOR), when it runs, picks up PENDING_DOC_REVIEW lines whose final-approval date is on or before the cycle’s approval cut-off end (and that were not withdrawn). Neither the sweep nor the roll-forward when a cycle closes takes an APPROVED line, so a SALARY_PAYMENT line that final approval did not attach is never attached later. Reject → REJECTED with the remarks; the claimant can clone it, and the clone is exempt from the claimable-period check.

Withdraw / resubmit / on-hold: Withdraw → WITHDREW; every approval-sequence row is marked withdrawn and removed, and the line’s pending approval requests are deleted. Finance on-hold in the cycle → ON_HOLD, which deletes the previous submission’s sequence rows. Resubmit acts only on lines that are on hold or carry an on-hold date, sets RESUBMITTED and the resubmission date, re-runs the per-line checks but not the balance check, and counts the resubmission. Finance acceptance → REVIEWED, then APPROVED and ready to pay at the final review level. The header status is recomputed after every line change.

Posting proof block. Not a generic financial document: no journal, no stock. The header carries posting-status and link fields for a sales order, sales invoice, purchase invoice and payment voucher; nothing sets them, and their only use is as listing filters, so they are always empty. Money leaves through the Claim Cycle Applet’s Bank Report, PV Details Report and salary-payment CSV export, not through an automatic payment voucher. What VOID reverses: there is no VOID; withdrawal and rejection leave the UTILIZE line untouched only if approval never completed — an approved-then-on-hold line has already reduced the balance.

The processors this page names

Every claim job either runs inside the action that needs it or is a clock a tenant has to create by hand; none is in the schedule a tenant is given to start with. Whether each is available to schedule, scheduled, and when it runs:

What the table means in practice: the claim module does its work inside the request that triggered it, so nothing waiting in a queue is the normal state rather than a sign nothing has run — and every scheduled behaviour on the list is one somebody has to switch on first.

Related applets

• Claim Cycle Applet — consumes PENDING_DOC_REVIEW lines; finance review, on-hold, sampling, reports. Its Reviewer Setting decides who may accept lines and close a cycle.
• Employee Applet — claimants, approvers, designations, job titles and the e-mail link that the applet keys on.
• Organisation Applet — companies and branches; the Branches settings screen here adds ranking and designation tabs to them.
• Chart of Account Applet — expense / billing GL codes on claim items (carried for reporting only).
• Forex Applet — rate source for foreign-currency lines.
• OCR Cash Bill Applet — a different OCR (membership cash bills); listed to avoid confusion with the claim-receipt OCR, which is Textract-based inside this applet.

Troubleshooting

Related documentation

• Claims Management module
• Claim Cycle Applet
• HR & Payroll module