Best Practices

Everything below is a consequence of a behaviour documented on an applet page. Where the earlier version of this page advised locking time logs and password-protecting payslips, none of that exists in the registered product and none of it appears here.

1. Set the employee code prefix before the first import

Blank codes are generated from the EMPLOYEE_ID running number plus the tenant’s employee prefix. Records created through Entity Maintenance never carry a code at all, so they are always numbered this way. Decide the prefix once, before anyone creates a record; changing it later leaves two numbering schemes side by side.

2. Put EMPLOYEE_CODE on every CSV row

The import matches a row without an employee code against all entities by ID number, tax number, e-mail and phone. A branch clerk who once bought something as a walk-in customer will be matched to their customer record and flagged as an employee — one record, two roles, which may be what you want but is rarely what you expected. A code on every row makes the import create or update by code and nothing else.

3. Link logins from Employee Maintenance, never from Entity Maintenance

The Claim Applet finds the claimant by matching the login e-mail to an employee record; without the link it refuses to load claims at all. The Login tab in Employee Maintenance does this; the Login tab in Entity Maintenance lists the wrong logins and cannot save a link. Wait for the person to accept the invitation before clicking Invitation Accepted, or the link fails with User has not accepted invitation link in email.

4. Add Payment Config for every claimant before their first claim cycle

The Claim Cycle’s Bank Report reads bank code and account number from the employee’s payment method. A missing payment method does not stop the report — it produces a row with no account, and the person is not paid until someone spots it. Make the Payment Config tab part of onboarding, not part of month-end.

5. Do not record leave on the employee record

The Approved Leave tab has a form and an Add button and saves nothing. Anything typed there is lost. Leave is tracked wherever it is tracked today, and the only thing payroll needs back from that record is the unpaid-leave days for the period, 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 dates — and that nobody is relying on a tab that throws the entry away.

6. If claims are paid with salary, own the hand-off

A SALARY_PAYMENT claim line is APPROVED at the last supervisor approval and then waits on the Claim Cycle’s Payroll Payment Report. BigLedger does not push it anywhere. Decide who pulls that report (or the CSV export), when in the month, and how they confirm the amount reached the payslip — because nothing in the product records that it did.