Reports

“Two reports over the same period give different totals. Which is right?” For the claims your payroll pays, the answer is usually both: the cycle’s Payroll Payment tab, the CSV it exports and the Payroll Payment Report read the same claim lines with different filters, at different moments, and none of them knows what your payroll actually paid. This page is for whoever runs payroll — in a bureau, another system or a spreadsheet — and takes the claims into it each month. It says where each people figure in BigLedger comes from, why the ones that should agree do not, and how the claims get tied to the payroll so that nothing is paid twice or not at all.

There is no payroll report in the registered product, and no HR report builder. What there is: a few listings on the employee master, and the claims-to-payroll hand-off in the Claim Cycle Applet.

Meet the example. Take, for example, a retail group that pays small claims with salary. GadgetSphere Sdn Bhd (GS) pays mileage and parking with salary, through a payroll bureau whose cut-off is the 27th. Its March claim cycle’s approval cut-off is 25 March. On the 26th the cycle’s Payroll Payment tab lists 46 lines, among them a GS-KV-01 supervisor’s RM 280 mileage; a second line of hers, RM 64, was approved on 28 March. And a GS-PEN-01 sales executive’s RM 150 parking, run up on a visit to the fulfilment centre, was charged to GadgetSphere Online Sdn Bhd (GSO). The sections below follow all three.

Where each people figure comes from

Nothing here posts, and only one of these stores what it shows. Everything else is worked out from the claim lines or the employee records at the moment you open the screen, so it can change between two looks.

The figure	Made when, from what	So it can move when
*The cycle’s Payroll Payment* tab**	Read when you open the tab: the Salary Payment lines attached to this cycle that are `APPROVED`, `PENDING_DOC_REVIEW` or `ON_HOLD`. It gives no total	A late line joins the cycle — see the Auto-add row below
The salary-payment CSV (the tab’s Export)	Built on the server when you press Export: every Salary Payment line attached to the cycle, whatever its status, one row per line with three columns — the employee code, the claim item’s code and the claim amount including tax. A foreign-currency receipt is exported at its claim amount; the receipt’s own currency amount is held in other columns and is not in the file	The same as the tab. Export after the cut-off you pay from, not before
The employee code in that CSV	Copied onto the claim line from the employee record when the claim was submitted	It does not move. A code changed on the record later is not the code in the file
Which cycle a line is on	Decided at its last approval: the cycle of the company the line is charged to, for the month of the approval — and only if that cycle exists and the approval is on or before its approval cut-off	With Auto-add approved claims to active cycle on, a late approval joins the current month’s open cycle at once, after that cycle’s cut-off. With it off, a late line joins no cycle and stays on none
The Payroll Payment Report (sidebar)	Read when you press Generate: Salary Payment lines in the three statuses above unless you choose others, for the charged-to company you pick, and for one cycle only if you pick one. It shows each line’s submission date, not its approval date or cycle. One request of at most 1,000 lines, with no date filter and no next page; with no sort chosen they come back in the order of an internal identifier, so a list cut at 1,000 drops lines at random, not the oldest	Any approval, in any month
The report’s Export Report	A copy of the grid as it stands, every column, at most the 1,000 lines it loaded	It is a working list, not the file your payroll imports
The Bank Report (for claims finance pays)	Stored when somebody presses Generate: approved Finance Payment lines per employee, with the bank code and account number read from each employee’s Payment Config at that moment	It does not move until somebody generates it again
The employee listing	Read page by page from the employee records, most recently changed first. Its columns hold the record status, but no branch, employment status, joined date or cessation date, and it has no export button	Any edit to a record
Wages in the trial balance	From the general journal a person posts from the payroll result; nothing in this module writes it	See What reaches the ledger

Nothing in BigLedger records that a claim was paid through payroll. A Salary Payment line stays APPROVED after the payslip that paid it; there is no paid status and no payroll reference on the line. So every screen above answers what was approved, never what was paid — and the difference is kept by the person who runs payroll, outside BigLedger.

Which report answers which question

The question	Where	Who asks it
Which claims go into this month’s payroll?	The March cycle’s Payroll Payment tab, then its Export	Whoever runs payroll, after the approval cut-off
Was any approved claim missed?	Payroll Payment Report with Claim Cycle empty and each company in turn	The same person, before the payroll cut-off
Which claims are waiting for finance, and to which account do we pay them?	Bank Report and PV Details Report — Claims › Reports	Finance, for Finance Payment claims
Which employees do we have, and are they set up?	The employee listing, with the record status filtered	HR, at each joiner and leaver
What did the payroll cost, and what do we owe the schemes?	Your payroll system’s summary and the journal you posted	The accountant

Why two figures that should agree do not

The CSV has more rows than the tab. The tab lists three statuses; the CSV takes every Salary Payment line on the cycle. In the ordinary flow every attached Salary Payment line is APPROVED and they agree. When the counts differ, a line on the cycle is in some other status — find it on the cycle’s Claim Lines tab and decide before the file leaves you.
The tab is right and still misses a claim. GadgetSphere’s RM 64 line was approved on 28 March, after the 25 March cut-off. With Auto-add off it is on no cycle and in no CSV; it is only on the Payroll Payment Report run with Claim Cycle empty. With Auto-add on it lands on the March cycle on the 28th — after you exported on the 26th — so March’s tab now shows 47 lines and the CSV you sent showed 46.
A claim of yours is on another company’s cycle. The RM 150 parking was charged to GSO, so it sits on GSO’s March cycle and in GSO’s CSV, not GS’s, although GS employs and pays the person. A cycle follows the company a line is charged to; your payroll follows the employer.
The report and the tab differ for the same cycle. The report also filters by the company you chose and the statuses you chose, and stops at 1,000 lines; the tab does neither.
The Bank Report shows an account the employee has since changed. It is a stored result. Generate it again.
The employee listing and the payroll head count differ. The listing’s status is the record status, and a leaver whose last claim is still unpaid is rightly still ACTIVE. Employment status and the leaving date are on the record, not in the listing.

Tying the claims to the payroll each month

Who, and when. Whoever takes the claims into payroll, between the cycle’s approval cut-off and the payroll cut-off — for GadgetSphere, on the 26th, once per employer company. The date at the top of the Payroll Payment tab is the cycle’s finance cut-off; the one that decides which Salary Payment lines join is the approval cut-off, shown as Supervisor Approval End Date on Main Details.

Export each cycle that holds your employees’ claims — your own company’s, and the cycles of the group companies your people charge claims to. Send each payroll only its own employees’ rows; the file says nothing about the employer, so match on the employee code.
Count and total the file. Neither screen totals the amount, so total the CSV’s amount column in your spreadsheet. The row count equals the tab’s line count (46 for GS in March), and the total is what the payroll adds to pay as claims (RM 9,870.40 for GS, illustrative).
Look for what fell between cycles. Run the Payroll Payment Report with Claim Cycle empty, for each company in turn. Every line on it is in one of three places: on a cycle you exported, on a payslip you can name, or on the list you carry to next month. If the list holds exactly 1,000 lines it was cut short and proves nothing; choose Claim Status APPROVED and run it again.
Keep your own register of claims paid outside a cycle. GadgetSphere pays the RM 64 in April and writes its Claim ID in the payroll file. Because nothing marks it paid, the same line is on the empty-cycle report in May, June and every month after; the register is the only thing that tells you it is done.
Look at last month’s cycle once more after the payroll closes. Anything that arrived after your export (an Auto-add late line) is paid next month and goes on the register.

How you know it held. The payroll’s claims total for the month equals the CSV totals of the cycles you exported plus the register’s additions; and every line on the empty-cycle report is on a cycle you exported or on the register. A difference you cannot name is a claim paid twice or not at all.

Where the claims land in the books. A Salary Payment claim reaches the ledger only through the payroll journal you post. Post it to what the claim was for, not into wages: add Salary Payment to your own Default Payment Processing Option in the Claim Cycle applet, and the cycle’s PV Details Report lists the salary lines with each claim item’s GL code.

The head count nobody has a report for

The employee listing is a search screen, not a head-count report: it pages through records and has no branch, employment status or date column. So the head count belongs to whoever keeps the starters and leavers list — HR, or payroll where there is no HR — and the check runs at each payroll cut-off: every name on the payroll register is in the employee listing, every leaver whose last claim has been paid reads INACTIVE, and nobody on the starters list is missing a Payment Config row if they claim. Core concepts has why record status and employment status are two fields.

What has no report

Stated plainly, with who does the job instead:

No payroll summary, payslip or gross-to-net reconciliation. The payroll backend has report endpoints for one pay run at a time — a summary read from the pay run’s stored totals and payslips, and EPF, SOCSO, EIS and CP39 files — but Payroll Admin has no row in the applet registry, so no applet you can install calls them. Your payroll system’s summary is the report; the accountant checks it against the journal (below).
No statutory filing report (EPF Form A, SOCSO / EIS, CP39). Same status, same owner.
No annual EA form. The backend endpoint named for Form EA returns the one-pay-run summary, and nothing assembles a year.
No overtime, absenteeism or late-arrival report. No registered applet records attendance; hours come from whatever records them, and the rule that turns them into pay is written down once (the hub).
No leave balance. The employee record’s Approved Leave tab saves nothing. The one number payroll needs — unpaid-leave days — is agreed with the line manager before the salary cut-off.
No claims-paid report. Nothing marks a claim paid through payroll; the register in step 4 above is the record.

So the year-end pack is somebody’s job, and the two dates do not move. A Form EA (or EC) goes to every person employed at any point in the year by the last day of February, and the employer’s Form E with its C.P.8D schedule by 31 March. Whoever files builds both from the year’s payslips, wherever those payslips were produced. The check is arithmetic: the twelve months of gross add up to the EA totals, and the twelve monthly PCB remittances add up to the C.P.8D.

And the monthly reconciliation nobody has a report for. Three numbers have to agree every month, per scheme — what the payslips deducted, what the upload file totals, and what left the bank. The filer reconciles them at the moment of remittance and keeps a one-page schedule with the acknowledgement; the check is that the three figures are equal, or that the difference is a named late or early payment.

When a figure looks wrong

Symptom	Cause	Fix
The CSV has more rows than the Payroll Payment tab	A line on the cycle is in a status the tab does not list; the CSV takes every status	Find it on the cycle’s Claim Lines tab and remove its row from the file, or pay it, before sending
An approved Salary Payment claim is in no CSV	Approved after its cycle’s cut-off with Auto-add off, or charged to another group company	Payroll Payment Report, Claim Cycle empty, each company in turn; then that company’s cycle
Payroll rejects an employee code from the file	The line carries the code as it was at submission, or the employee is on another company’s payroll	Correct the row in the file; send the row to the employer’s payroll
The empty-cycle report lists exactly 1,000 lines	One request of at most 1,000, cut in no useful order	Choose the company and Claim Status `APPROVED` until the list is shorter
A claim you paid by hand is still on the empty-cycle report	Nothing marks a line paid	Expected; tick it off against your register
The file from Export Report will not import into payroll	It is a copy of the report’s grid, every column	Use the Export on the cycle’s Payroll Payment tab
A Bank Report row still has no account after you filled Payment Config	The report was stored when it was generated	Generate it again

How you know the reports are telling you the truth

After each export. The CSV’s row count equals the tab’s line count, and its amount total equals the claims the payroll added for that company.
Before the payroll closes. The Payroll Payment Report with Claim Cycle empty, per company, lists nothing that is neither on an exported cycle nor on your register — and it is shorter than 1,000 lines.
After posting the payroll journal. The claims in it, by GL code, equal the CSV totals plus the register’s additions, and wages expense equals the payroll’s gross plus employer contributions.

What these reports depend on, and what depends on them

What must exist first. A Claim Cut-Off Logic row for each company, or no cycle is created and every Salary Payment line sits on no cycle. Claim items marked Salary Payment. An employee code on every claimant before they submit, because the code is copied then. For the Bank Report, a Payment Config row before somebody presses Generate.

What they make possible. The CSV lets you add claims to payslips without a transfer per claim, which is why small regular claims such as mileage are usually set to Salary Payment. The empty-cycle report is the only cross-month view of approved salary claims, and with your register it is the proof that none was dropped.

The siblings, and when to choose which. Use Claims › Reports when finance pays a claim itself, through the Bank and PV Details reports; this page when payroll pays it. Payroll Admin describes the payroll backend’s own reports, which no installable applet reaches today.

What breaks elsewhere when this is wrong. A claim missed here is a person short-paid, and nobody in BigLedger is told. A claim paid twice — once by hand from the empty-cycle report and once when Auto-add brought it onto a later cycle — is found only by the register. A payroll journal that posts the claims into wages leaves the expense in the wrong account for every report downstream.

What they pair with in practice. The cycle’s Export alongside your payroll import file each month; the empty-cycle report with your register; and the payroll journal in Ledger And Journal, which is where any of this reaches the books.