HR & Payroll Module
BigLedger keeps a record of every employee — who they are, which branch and company they belong to, how they log in, which bank account they are paid into, and who they report to — and it runs employee expense claims through to the point where a line is either paid by finance or handed to payroll. Salaries are not calculated here. A Malaysian payroll module is being built and is not yet an installable applet; until it is, the shape this module supports is the one a business in that position already runs — payroll in whatever system computes it, and the monthly result brought into BigLedger as a general journal.
Applets in this module
Membership is an editorial judgement — the product has no module↔applet relationship in its data. Under it, HR & Payroll is primarily a supporting module for the registered people-administration applets below. Payroll Admin is documented separately under Human Resources when it is available on your tenant.
| Applet | Owned by | What it does for HR |
|---|---|---|
| Employee Maintenance | Core | The employee master. One record per employee: identity, employment status and dates, default company / branch / department, the link to their login, bank details (Payment Config), tax rows, spending limits, up to three levels of Report To, employee categories, org charts, and a CSV import. |
| Entity Maintenance | Core | The type-agnostic view of the same entity table. An employee is an entity with the EMPLOYEE flag; this applet is where the Employee Category tree is also maintained, and where you turn an existing customer or supplier into an employee as well. |
| Claim Applet | Claims | Where an employee submits an expense claim and a supervisor approves it. Claim items marked Salary Payment are approved for payroll rather than paid by finance. |
| Claim Cycle Applet | Claims | The finance side of claims. Its Payroll Payment Report and salary-payment CSV export are the list of approved amounts to hand to whoever runs payroll. |
| Payroll Admin | HR & Payroll | When installed: company statutory setup, pay calendars/periods, salary structures, GL mapping, employee roster, pay runs, bank files, Post GL, and statutory TXT reports. |
The employee record is an entity
There is one entity table in BigLedger. Customers, suppliers, employees and merchants are rows in
it with four flags, and the same person can carry more than one. Employee Maintenance shows the
employment fields only while EMPLOYEE is among the record’s types; Entity Maintenance shows every
record regardless of type. Two consequences follow:
- An employee who is also a customer is one record, not two. The CSV import matches on employee code first and, failing that, on ID number, tax number, e-mail and phone against all entities — so a row without an employee code can update an existing customer and flag it as an employee rather than create a new person.
- Employee codes are generated from the
EMPLOYEE_IDrunning number and the tenant’s employee prefix when you leave the field blank. Set the prefix before the first import if you want codes with the prefix you chose.
What reaches the ledger
Employee Maintenance and Entity Maintenance write master data and post no journal. The two claims applets post no journal, move no stock and create no payment voucher — a claim is not a generic financial document and has no entry in the platform’s journal-posting handler for the claim itself. Money for a Salary Payment claim line leaves the business through payroll.
Payroll’s Post GL does not reach the general ledger. It writes three lines into the payroll
module’s own journal tables and nothing anywhere else — no entry reaches the chart of accounts
balances, the trial balance or any financial report, and the pay run still reads POSTED afterwards.
The columns that would link it to a financial journal exist and nothing ever sets them. The detail,
with the source, is on the
Payroll Admin page.
So bringing payroll into the accounts is a person’s job, and it is a manual journal. Whoever keeps the books posts it in the month the work was done — not the month it was paid — debiting wages expense with gross plus the employer’s contributions, crediting net pay to a payable and both halves of the statutory contributions to their liability accounts. You know it worked when the wages expense in the trial balance equals the payroll system’s gross plus employer contributions for that month, and the statutory liability clears to nil when you remit on the 15th.
What this module does not do today
Worth stating plainly:
- No leave record. Employee Maintenance has an Approved Leave tab, and it saves nothing — its add handler is empty and its save call is commented out. Do not use it to record leave. Leave balances stay wherever they are kept today — a spreadsheet, an HR system, a wall chart. What payroll needs from that record is one number a month, the unpaid-leave days, agreed with the line manager before the salary cut-off; the check is that the days keyed into the pay match the approved leave register for the same period.
- No attendance capture. No registered applet writes a clock-in or clock-out event. Hours come from whatever records them, and the conversion to pay is a rule the business writes down once — which divisor turns a monthly salary into an hourly rate, and what multiplier applies to a rest day. The check is that the same salary produces the same hourly rate for two different people in two different months.
- No approval engine of its own outside Claims. Claims has one, always on, with its own approval settings. Who approves leave, overtime and a pay change is therefore a written policy, not a setting. Name one authoritative source for the reporting line — the org chart, the Report To fields or the claims branch designations — and say which; the check is that a manager can list everyone whose time they approve and the list matches the source you chose.
- No salary, no payslip, no statutory calculation you can use today. A Malaysian payroll backend exists and is described at Payroll Admin, and the applet is not registered. This wiki does not publish EPF, SOCSO, EIS or PCB rate tables: take them from KWSP, PERKESO and LHDN, and note that whoever computes your payroll today should be on LHDN’s published list of payroll software whose PCB calculation it has verified — BigLedger is not yet on it.