Use Cases

Every one of these is the same module with a different claim item configured. Nothing below is a separate feature — the approval workflow, the required fields and the payment option on the claim item are what make one look nothing like another.

The examples use the wiki’s running example business, GadgetSphere Sdn Bhd, a Malaysian multi-branch consumer-electronics retailer with three companies and 22 branches.

1. Ordinary staff expenses — the ad-hoc route

The shape. A branch supervisor at GS-KV-03 drives to a supplier to collect a warranty replacement, parks, and buys lunch on the way back. Three lines, one claim.

Configure it as:

What happens. The supervisor submits. BigLedger looks up who holds the approval designation in branch GS-KV-03, builds a two-level sequence, and e-mails level 1. Each approver sees the lines in Pending Approvals and can approve individually or in bulk. When level 2 approves, the lines move to PENDING_DOC_REVIEW and wait for the month’s cycle.

What to watch. This route depends entirely on the branch’s Approval Designation tab. Move somebody between branches without updating it and their team’s claims stop submitting, with a message naming the designation and the branch.

2. An annual allowance — the HR benefit route

The shape. Every employee has an annual medical allowance. Claims against it should stop when the allowance is used up, and HR rather than the line manager should approve them.

Configure it as:

What happens. The employee submits a clinic receipt. Before anything is queued, BigLedger totals what they have already spent and what is pending against the Medical account and refuses the line if the new amount will not fit. On HR’s approval, a UTILIZE line reduces the balance and the line goes to finance review.

Two refinements worth knowing:

• Account conversion lets a main account draw on a second, convertible account when it runs short — an optical allowance topping up from a general medical pool, for instance.
• Manual entitlement adjustment (an applet setting, off by default) lets HR hand-adjust an employee’s balance and validity. The adjustment is posted as a transaction line on the account, so it is auditable.

3. A client-chargeable expense — the engagement route

The shape. This is the route the module was originally built for: a professional-services firm whose staff incur expenses on client jobs and re-bill them. It still applies to any business that books cost to a job rather than a branch — an installation team at GadgetSphere Distribution, for instance.

Configure it as:

What happens. The claimant picks the engagement on the line. Approvers come from the roles recorded against that engagement, not from the claimant’s branch. The line carries both an expense side and a billing side, and if the billing branch differs from the expense branch it appears on the cycle’s Cross-Billing Report.

Reporting on it. The Claim Applet’s Engagement Report groups a claimant’s chargeable lines by engagement. The cycle’s Cross-Billing Report is the finance-side view of the same thing.

4. Expenses the company already paid — non-reimbursable

The shape. A corporate card or a direct supplier invoice paid the expense. Nobody is owed anything, but the cost still needs to be attributed to a branch, an engagement or a project.

Configure it as: nothing special on the item. The claimant ticks Non-Reimbursable on the line.

What happens. On submit the line goes straight to APPROVED with the approval date set to now. It is never routed to an approver, never enters a claim cycle, and never appears on a Bank Report. It shows up in the Claim Applet’s Non-Reimbursable Report.

5. Paying through payroll instead of the finance cycle

Any claim item can be set to Salary Payment instead of Finance Payment. Its lines are APPROVED the moment the last supervisor approves and skip finance review: they never appear in a cycle’s Inbox. Final approval attaches a line to its company’s cycle for that month when the cycle already exists and the approval falls on or before the cycle’s approval cut-off end, and the line then shows on that cycle’s Payroll Payment tab. A line approved after the cut-off joins the current month’s open cycle only if Auto-add approved claims to active cycle is on in the Claim Cut-Off Logic; otherwise it joins no cycle at all, because the later sweeps move only lines waiting for finance review. So a mileage claim approved on the 28th, after a cut-off on the 25th, is missing from every cycle’s tab. The Claim Cycle Applet’s Payroll Payment Report, with a CSV export for payroll, finds it only with Claim Cycle left empty, and then lists every Salary Payment line from every month with no approval date or cycle column. If you pay claims through payroll, switch Auto-add on: every approved line then lands in an open cycle, and the cycle’s tab is the list to work from. It also puts late Finance Payment approvals into the current month’s open cycle, so finance reviews them sooner.

Use it where the reimbursement genuinely rides on the payslip. Do not use it as a shortcut around finance review: nothing checks a salary-payment line after the supervisor.

6. Sampling — auditing a sample rather than every line

Where the volume is too high to check everything, the cycle’s Sampling tab draws a sample and records the result of checking each one.

“Flagged” comes from the background risk-score job, which marks a line when its receipt attachment has been used on another claim, or when the receipt date, amount or receipt number was edited away from what OCR read off the image. Each sampled line records a pass or fail, remarks and who checked it, and the Sampling Analysis Report summarises the results across cycles.

What every one of these has in common

Payment is manual. Whichever route a line takes, the module’s output is a report:

    flowchart LR
  L["Approved claim lines"] --> F{"Payment Processing<br/>Option"}
  F -->|Finance payment| C["Claim cycle → finance review"]
  F -->|Salary payment| P["Payroll Payment report"]
  C --> B["Bank Report<br/>one row per employee"]
  C --> V["PV Details Report<br/>one row per line, with GL code"]
  B --> BANK["Bank portal<br/>uploaded by a person"]
  V --> PV["Payment Voucher<br/>raised by a person"]
  P --> PAYROLL["Payroll<br/>CSV handed over"]
  

There is no step in this module that debits an expense account or credits a payable. See Core concepts §7.