Pay a month of claims

Paying a month of claims

By the end of this guide, every employee claim your supervisors approved for the month is paid once, booked on a voucher whose journal you have read, and closed. It is for the finance person who pays claims, at a company whose claim items are set to Finance Payment. Set aside about an hour per company the first time, and less after that.

Where BigLedger stops. A claim posts nothing. The Claim Cycle Applet tells you who to pay and what to code each line to, and stops there. The bank transfer, the voucher that books it, and the check that both happened are yours, and nothing reminds you of them.

Meet GadgetSphere

GadgetSphere Sdn Bhd (GS) closes claims monthly; the March finance cut-off is 25 March. The GS cycle holds 41 approved Finance Payment lines from 16 employees, RM 6,420 before tax. One is a RM 300 hotel bill with RM 18 of service tax. Mileage is paid with salary, so it is not on this page. The figures are illustrative.

Before you start

Each company you pay has an open cycle for this month on the Claim Cycle listing. If one is missing, stop and read Approved claims never reach finance first.
You have a Reviewer Setting row for the company, and one level is ticked Is Final Approval Level (Claim Cycle Applet › Settings › Reviewer Setting). BigLedger reads the final level from the first ticked row of any company, so give every company in the group the same final level number.
Your Default Payment Processing Option (Personalization › Default Selection) is the one the finance team agreed. It is personal, and it changes the review queues’ and the finance reports’ totals.
You can raise and finalise a Payment Voucher (Internal) on the cashbook you pay from.

Step 1: Review the month’s lines

Accept or hold every line, level by level, so that what you pay is what finance checked.

Claim Cycle › the month’s cycle › Checking Reports › Inbox

Open each line with its receipt. Approve it or put it On Hold with a remark the claimant can act on. A line becomes ready to pay when a reviewer at the final level accepts it. A line on hold goes back to the claimant, who resubmits from the Claim Applet. The claimant is e-mailed only if someone created the review-notification clock, so tell them yourself if not.

What to check that the screen will not. That the receipt names your company, not the employee, if the expense needs an e-invoice. And that the receipt was not already claimed: the duplicate-receipt view and the OCR flags catch some reuse, not all of it (Best practices §11).

If it goes wrong: User is yet to be configured to review claim lines under company means you have no Reviewer Setting row for that company.

Step 2: Generate the Bank Report just before you pay

Make the payment list from the lines as they are now, not as they were last week.

The cycle › Bank Report › Generate

The Bank Report adds up, per employee, the cycle’s Finance Payment lines whose last review was at the level in Reviewed By Level, with the bank code and account number from each employee’s payment method. Three things it does not do for you:

It starts at level 1. Set Reviewed By Level to your final level before you press Generate. At level 1, a company with two review levels gets the lines only level 1 has checked, and none the final level accepted.
It ignores the line’s status. A line put on hold by a reviewer at that level is in it. Clear the On Hold tab first, or take those amounts out of the bank file.
It counts every bank row. An employee with two rows in Payment Config appears twice, each at the full amount. Check that every name appears once.

What you see is the cycle as it was when you pressed Generate, and that total is written on the cycle. A line accepted afterwards, or a bank detail corrected afterwards, is missing until you generate it again. Export works the report out again from the cycle as it is then, so generate, export and compare the file’s total with the screen’s in one sitting, and upload that file.

At GadgetSphere the report has 16 rows totalling RM 6,438. One row has no bank code, because that employee was never given Payment Config on their employee record. Fill it there and generate again.

If it goes wrong: There is no claim data. means no approved line matches your payment-processing filter and the Reviewed By Level filter. Check both before you decide the cycle is empty.

Step 3: Pay through your bank

Send the money; BigLedger does not.

Upload the exported file, or key its rows, in your primary bank’s portal. Keep the bank’s confirmation of the batch total. This is the figure the voucher in Step 4 must equal.

Step 4: Book the payment on vouchers

Put the month’s reimbursements in the ledger, tax included.

Payment Voucher (Internal) › Create, working from the cycle › PV Details Report › Generate, with Reviewed By Level set to the same level as in Step 2

Raise one voucher per employee, on that employee’s own record, because the Bank Report pays per employee and a voucher has one payee. Key one expense line per PV Details row of that employee, on the GL code the report shows. The report’s amount includes tax and it has no tax column, so for a receipt that carries tax, read the tax from the receipt image on the cycle’s Claim Lines tab and enter it in that expense line’s tax field; the voucher posts it to the input-tax default. Add one payment line on the bank method behind CASH-PRI-KV01 for the amount the bank paid that employee. When expenses equal the payment the voucher posts no payee line.

One voucher for the whole run is the other way, and it is a choice for your accountant: one journal instead of 16, but the voucher still needs one payee record, and every journal line carries it. Write the cycle’s code in the voucher’s Reference: the cycle screen has no field for the voucher, and the journal takes the voucher’s reference, so this is how anyone gets from a ledger line back to a month of claims. BigLedger does not check what you type, so attach the PV Details Report to the voucher as well.

Date it the day the money left. The journal takes the voucher’s date. A March claim paid on 5 April is an April expense; if it must be a March cost, that is an accrual your accountant posts.

At GadgetSphere the 16 vouchers are dated 5 April and together post Dr expenses RM 6,420, Dr input tax RM 18, Cr bank RM 6,438, where the accountant treats the RM 18 as recoverable (see Decisions below).

If it goes wrong: use the Payment Voucher, not the Reimbursement Payment Voucher, for any line that carries tax. On a taxed line the Reimbursement voucher reads FINAL and posts the bank line, and writes no journal.

Step 5: Check the journal and the bank

Prove the voucher booked what you paid.

The voucher › Trace Document › Journal Txn, then Cashbook Txn

The journal shows the expense debits, a tax line where the receipt carried tax, and the bank credit. Lines with the same GL code, branch and description are merged into one, so compare totals by GL code with the PV Details Report, not the number of lines. The cashbook line is what Bank Reconciliation will match against the statement. An empty Journal Txn grid on a FINAL voucher is a journal that failed after FINAL.

Step 6: Close the cycle

End the month for finance, and send anything unreviewed to next month.

The cycle › Main Details › Status CLOSED › Update, then confirm (final-level reviewer only)

Closing stamps the cycle Ready to Sync and moves every line still waiting for review into next month’s cycle, which it creates if needed. Lines on hold stay on the closed cycle. There is no reopen, so close after Steps 2 to 5, and after the cycle’s Supervisor Approval End Date: a line approved in time still joins a cycle closed early, where nobody reviews it until the next close moves it on.

Decisions only you can make

Is the tax recoverable? The voucher debits any tax amount to the input-tax default. Whether that is right is your accountant’s call; a line keyed gross puts the whole cost on the expense account.
Is it equipment or an expense? A laptop bought on a claim may be a fixed asset. Decide before the voucher line is coded, because the Fixed Asset applet writes its own acquisition journal.
Who does which step. The claimant, the approver, the reviewer and the payer are four people. Three pairs must never be one person: claimant and approver, approver and payer, and whoever sets an entitlement and whoever claims against it (Best practices §8).
Budget. Claims consume no budget register. The budget owner compares the expense accounts with the budget each month.

What success looks like

In five minutes, once per cycle:

Every line your supervisors approved this month is in a cycle: none of them reads PENDING_DOC_REVIEW on the claimant’s Line Reports while missing from the cycle (Approved claims never reach finance). The Inbox is empty, or holds only lines you deliberately left for next month.
The Bank Report you paid from was generated after your last acceptance; its total equals the bank’s batch total.
The vouchers’ total equals that figure, each Reference names the cycle, and no Journal Txn grid is empty.
The cashbook lines are waiting in Bank Reconciliation.
The cycle is in Claim Cycle History, and next month’s cycle exists.

Common mistakes

What people do	What happens	What to do instead
Pay from a Bank Report generated days ago	Lines accepted since are not paid	Generate it again just before you pay
Two reviewers with different payment-processing settings	Their totals never agree	Agree one setting for the team
Close the cycle before the voucher	Nothing breaks, but nothing shows what was booked	Close last
Use the Reimbursement voucher for a taxed line	FINAL, bank line posted, no journal	Use the Payment Voucher
Pay from a level-1 Bank Report in a two-level company	Lines only level 1 checked are paid, stay unready, and move to next month’s cycle at the close, where they are paid again	Set Reviewed By Level to the final level; check a moved line against last month’s bank file