Best Practices

These follow from the mechanics on Core concepts. Where a control you might expect does not exist, that is said plainly rather than worked around.

1. Tick Display Entitlement Balance, on every claim account

It is the switch that turns an entitlement from a number into a limit. With it off, the submission balance check is skipped entirely: the allowance is invisible to the employee and unenforced by the system, and the first anyone knows is when the yearly spend is double what was budgeted.

There is no report that would catch this for you. Audit it directly: open every claim account under Settings → Claim Accounts and confirm the box is ticked.

2. Create the cut-off row for every company on day one

One missing Claim Cut-Off Logic row means one company where no claim cycle is ever created and approved claims silently accumulate at “pending document review” forever. No error is raised anywhere, on any screen, for any user.

When you add a company to the tenant, adding its cut-off row belongs in the same checklist as its fiscal calendar.

3. Reconcile the module by hand, because nothing reconciles it for you

Claims posts no journal, so there is no automatic tie between what was approved and what was paid. Three checks each month close that gap:

Record the payment-voucher reference on the cycle before closing it, even where the system does not insist. It is the only link back from the ledger to the cycle.

4. Use claim items to enforce policy, because nothing else will

There is no over-limit override, no secondary approval for exceeding a cap, and no amount threshold that routes to a more senior approver. The controls that exist all live on the claim item:

• Claimable Period (Days) stops people claiming a receipt from eight months ago — but only on claim items that require an OCR receipt attachment. The backend runs the check exclusively on lines that carry an OCR document and a receipt date, so on an item without that requirement the period is a number nobody enforces. If a stale-receipt rule matters to you, the OCR attachment requirement is what turns it on.
• Threshold and UOM cap a mileage or per-diem rate.
• Required attachment / OCR attachment stops receipt-free claims.
• Required vendor, receipt date and receipt number makes a claim traceable to a document.
• Required internal employees makes an entertainment claim name who was there.

A policy you cannot express as one of those is a policy this module will not enforce. Write it into the approval levels instead — more levels, higher up — and accept that it is a human control.

5. Turn on OCR where receipts are the risk, and then use the flags

Claim items can require the receipt to be scanned through OCR. The value is not the data entry — it is the background risk-score job, which flags a line (the mark Flagged Claims Only filters on) only on items that require OCR, and only when:

• the attachment has already been used on another claim, naming the other claim IDs;
• the receipt date, the amount or the receipt number was edited away from what OCR read off the image (an uploaded statement is never flagged, and nor is an amount change on a split line or a foreign-currency receipt).

On an item without OCR the same job only computes a risk score, so a flagged-only sample never contains it.

Those flags are only worth collecting if somebody looks at them. Draw a monthly sample in the cycle with Flagged Claims Only ticked, and record a pass or fail against each. The Sampling Analysis Report is then a real control rather than a screen nobody opens.

6. Keep the employee record and the login e-mail in step

The whole identity model is the match between a login’s primary e-mail and an employee record. When it breaks, the person cannot open their own claims at all, and the message they get names an applet they have never heard of.

Make “update the employee record” part of the same task as changing anyone’s e-mail address, and check it first whenever one person — and only one person — cannot use the module.

7. Agree the payment-processing filter across the finance team

The filter that decides whether a cycle’s queues and finance reports count finance-payment lines, salary-payment lines or both is per user, and defaults to finance payment only (the Payroll Payment Report and tab ignore it and always show salary-payment lines). Two people reconciling the same cycle with different settings will never agree, and neither will find the discrepancy by looking at the data.

Agree one setting, write it down, and make it part of onboarding a new reviewer.

8. Separate the four people, because the applet is the only thing that separates them

Four jobs run through this module: claiming, approving, reviewing in the cycle, and paying. Three pairs must never be one person — claimant and approver, approver and payer, and whoever sets an entitlement and whoever claims against it.

The product gives you two levers and no third. The Claim Cycle Applet is the reviewer’s applet and the Claim Applet is everybody’s, so withholding the cycle applet is how you separate finance review from claiming. Inside it, Reviewer Setting decides who may review and who may close. Below that there is nothing to configure: every claims permission in the platform is ordinary record access — read, create, update, delete — and not one of them says approver.

Which leads to the trap. Approvers for an ordinary staff claim are everybody linked to the approval designation on the branch, and the claimant is not removed from that list. Link a branch manager to the designation for their own branch and their own claims appear on their own approval sequence. The Default Approver on the approval setting looks like the guard against this and is not — it fires only when the designation has nobody linked to it, never when the only person linked is the claimant.

So: when somebody must approve for a branch they also claim in, link them to a different branch’s designation, not their own.

So the third separation is a human control, and the claim reports will not show it to you: the claimant’s reports return only their own lines, and the supervisor’s return only their team’s. Checking it means exporting a period’s lines and comparing the claimant against the approver recorded on each — once a quarter is enough — and it has worked when the two are never the same person. Whoever owns the expense policy does it; if nobody owns the expense policy, that is the finding, not the empty list.

9. Accrue what nobody has claimed yet, because three dates are not one date

A claim line carries the date the money was spent, the date it was submitted, and the date it joined a cycle. They can be three different months, and nothing in this module moves cost between them. A December dinner submitted in February and paid in March is, as far as BigLedger is concerned, a March event — and it is a December cost.

That accrual is the accounts clerk’s journal at each close, not a claims task. Size it from the cycle’s cut-off dates and last year’s pattern; the check that you got it right is that next month’s reversal lands inside the tolerance your business has set, and if it never does, your claimable period is longer than your close.

10. Do not assume you can reclaim the tax

The tax shown on a claim line is what was on the receipt. Whether your business can recover it is a different question with a different answer, and the condition that usually fails is that the tax document is in the employee’s name rather than the company’s — an ordinary till receipt almost never satisfies it.

Claims holds no deductibility data and makes no such decision; the GL codes and tax fields on the PV Details Report are the only thing carried forward. The decision belongs to whoever codes the payment voucher, at the moment they code it, and it needs a rule they can apply without reading each receipt — usually a claim item per treatment, so the coding follows from the expense type rather than from a judgement made twice a month under time pressure. You will know the rule is working when the tax agent stops asking for the claim file.

11. Find the duplicates yourself, and know what the flag will not find

The background risk score treats a line as a possible duplicate when another line exists with the same claim item, the same approval workflow type and the same amount including tax — drafts and withdrawn lines included. That is all it compares, and it does not flag the line: it only adds to the line’s risk score, so Flagged Claims Only never shows it. It does not look at the claimant, the date, the vendor or the receipt number either, so:

• two different employees claiming the same RM 45 on the same item raise each other’s score, and
• the same receipt claimed twice at two different amounts matches neither line.

A second, separate test does catch one honest case, and this one does flag: re-uploading the same image file on another claim is matched by the file itself. Photographing the receipt again, or keying it on an item without OCR, is not.

The keys that actually identify a duplicate — vendor name, receipt date, receipt number — are on every line and nothing compares them. So the real duplicate check is an export of the cycle’s lines sorted on those three columns, run by the finance reviewer before the cycle is closed, and it has worked when no two rows in the cycle share a vendor, a date and an amount. Ten minutes a month, and it is the only test in this list that would catch the commonest expense fraud there is.

The same processor’s other test — is this amount unusual — is two standard deviations above the mean of every claim ever recorded against that claim item, across the whole tenant, with no date window. It too only raises the score. It is a prompt to look, never a conclusion, and it gets quieter every year as the history grows.

12. Do not describe this module as automated accounts payable

It is not, and a customer who has been told it is will find out on their first month-end. Claims produces the instruction to pay; a person still uploads the bank file, and a person still raises the payment voucher. Say so during implementation, not during the first close.