Core Concepts

Five concepts cover everything the registered product does with people. None of them is a payroll concept; the module page explains why.

1. An employee is an entity with a flag

Every customer, supplier, employee and merchant is one entity record with four flags — customer, supplier, employee, merchant. The Entity Type field on the record is multi-select, so one person can be an employee and a customer at once, and they are one record, not two.

Employee Maintenance is the employee lens on that table: it sets the employee flag and shows the employment fields only while EMPLOYEE is among the selected types. Entity Maintenance is the lens with no type: it lists every record and lets you add a flag to an existing one. When you create a record there with EMPLOYEE ticked, the only legal form offered is INDIVIDUAL; the edit screen does not apply that limit, so ticking EMPLOYEE on an existing corporate record is accepted. Check the legal form before you add the employee flag to a record that already exists.

The employee code is generated when left blank — the EMPLOYEE_ID running number plus the tenant’s employee prefix — and must be unique among non-deleted entities. Supplying a code on a record that is not flagged EMPLOYEE is rejected outright.

2. Employment status is not record status

There are two lifecycles on the same record, and they do not touch each other:

Field	Values	What it means
Status (the entity record)	`ACTIVE`, `TEMP`, `INACTIVE`	Whether the record is live. There is no `DRAFT`. An `INACTIVE` employee disappears from pickers.
Employment Status	`ACTIVE` … `VOLUNTARY SEPARATION`	Where the person is in their employment. Changing it does not change the record’s status.

So a person who has left can still be ACTIVE as a record — which is what you want while claims are still being settled — and you set the record INACTIVE deliberately, later. Joined Date and Cessation Date sit beside Employment Status on the Main tab; Employment Status and Branch are mandatory on create.

3. Reporting lines and designations are two different things

Employee Maintenance holds who reports to whom in two places, and the claims process reads a third:

Report To — up to three levels of manager per employee, each chosen from the employee list.
Org Chart — a separate structure per company with DEPARTMENT and EMPLOYEE nodes, each with a rank and a designation. The employee’s edit form shows, read-only, which org charts they sit in.
Designations per branch — maintained not here but under Settings → Branches in the Claim Applet, as the Approval Designation tab. This is what the ordinary (EMPLOYEE_AD_HOC) claim workflow uses to find approvers. A claimant whose designation is not configured for their branch cannot submit: Your designation … is yet to be configured for branch ….

Nothing in the registered product reads Report To or the org chart to route an approval. They are reference data.

4. Bank details live on the employee, and one report reads them

The Payment Config tab on the employee record holds payee residential status and country (mandatory) and bank, SWIFT code, account number, account holder name, IBN number and account expiry (optional).

Exactly one thing in the registered product reads them: the Bank Report in the Claim Cycle Applet, which joins each employee’s payment method to produce one payment row per employee with bank code and account number. An employee without a payment method appears on that report with no bank details, and is not paid until someone notices.

5. A claim is paid one of two ways, and the claim item decides which

Every claim item carries a Payment Processing Option:

Option	What happens at the last supervisor approval	Who pays
`FINANCE_PAYMENT`	Line goes to `PENDING_DOC_REVIEW` and waits for the month’s claim cycle	Finance, from the Bank Report or a manual payment voucher
`SALARY_PAYMENT`	Line goes straight to `APPROVED`	Payroll — the line appears on the Claim Cycle’s Payroll Payment Report and its CSV export

That second row is the whole of the module’s link to payroll today. The report is a hand-off: the approved amounts are listed for a person or a payroll system outside BigLedger, and nothing in the registered product computes a salary, deducts anything, or posts a journal from it.

What is not a concept here

Leave. The Approved Leave tab on the employee record has a form and an Add button, and no save path — the handler is empty and the save call is commented out. There is no leave balance in the registered product.
Attendance. No registered applet records a clock-in.
Pay run, payslip, statutory contribution. These exist as backend tables and endpoints (a pyrll package) and no registered applet reaches them. What that backend does is described at Payroll Admin.

All three absences hand the same job to the same person, so it is worth saying once. Whoever computes your payroll — a payroll bureau, an HR system, a spreadsheet — owns leave balances, attendance and the gross-to-net calculation, and BigLedger’s part begins when their monthly result becomes a journal. The seam to agree with them is: what they send, when they send it, and at what level of detail. The check that the seam works is that the wages expense in your trial balance equals their gross plus employer contributions for the month, every month, without anybody investigating. See Use cases.