Branch payroll for a commercial bank: rules as data, payslips by SMS

The situation

A commercial bank branch pays its staff under a scheme that looks simple to describe and is not simple to compute. Pay depends on grade and post; the structure has sequences and items, each with its own formula. Income tax applies in bands with thresholds. Insurance and fund contributions apply on bases and caps that are set outside the bank. Attendance is deducted. Performance feeds the calculation. On top of that there is a steady supply of one-off adjustments — back pay, corrections, special allowances — each of which has to land on the right person in the right month.

The branch’s HR team ran this in spreadsheets. Not because they were unsophisticated, but because the rules change and spreadsheets change faster than software does. The cost of that was not the arithmetic; it was that the calculation lived in one person’s file, the payslips had to be printed and distributed, and when an employee queried a deduction the answer involved someone opening last month’s workbook and reconstructing the logic from cell references.

The call we made

The salary rules are the product. This is the decision the whole system rests on. A branch payroll changes its parameters constantly: tax bands are set nationally, insurance bases are revised, the bank adjusts its own scheme, and the branch changes how performance converts into pay. If each of those is a code change, the system spends its life one policy cycle behind, and the spreadsheet it was supposed to replace reappears — this time as the source of truth for anything unusual, which is exactly where errors accumulate.

So the arithmetic was built as a calculation engine fed by configuration: pay sequences, item definitions and item formulas, tax rates and bands, insurance bases and caps, and the scoring standards that drive performance pay are maintained as data by HR, in the system. The engine does what an engine should do — evaluate the configured rule against the period’s inputs — and does not contain a single branch-specific constant.

Each payroll run is a frozen snapshot, not a recomputation. A payslip has to be defensible months later. Every run stores the inputs it consumed and the versions of the parameters and formulas it used, so any line on any payslip can be re-derived exactly. This is not a nice-to-have: without it, the answer to “why was my deduction 320 this month” is a person reconstructing a spreadsheet, and the system has failed at the only moment it is being judged.

The payslip delivery was part of the calculation, not a notification feature. The branch had been printing itemised slips and distributing them. Sending the itemised payslip to the employee’s phone at the moment the run closes removes that distribution step, but the more useful effect is timing: the numbers arrive with the query window attached, so questions come in while the run data is still loaded, instead of arriving three weeks later and requiring an archaeology exercise.

One deliberate concession: attendance arrives as Excel from the branch’s attendance system. We imported it rather than insisting on an interface. Demanding a real-time integration would have delayed the first live payroll by months for no benefit to the person being paid, and an import that is versioned and re-runnable is honest about what it is.

What we built

• Department and post maintenance — the branch organisation, its levels, and the position nature mapping that pay rules hang off.
• Tax and scoring standards — tax rates, brackets and thresholds; the scoring standards used for performance-linked items, maintained as data.
• Pay sequences and item formulas — the salary structure defined as items, each with a formula, so a new allowance is a configuration task rather than a release.
• Attendance import and calculation — period data imported, validated and converted into the deductions and inputs the run requires.
• Bulk payroll generation and review — the run is generated for the whole branch, then reviewed and verified before payslips are released; anomalies surface before money moves.
• Payslip SMS delivery — itemised payslips pushed to employees through the SMS gateway, with Excel import and export for the cases that still need a file.
• Query and summary reporting — cost by department, by post, by period; the aggregate views management asks for.

Result

The branch generates and manages payroll inside the system: structure, income tax and insurance are calculated together rather than in three passes, attendance and performance feed the run without re-entry, and employees receive itemised payslips on their phones instead of on paper. Queries that used to need a spreadsheet and a memory now come from a stored run, with the parameters that produced them preserved.

What we would say honestly about the limits: this is a payroll system, not a human resources suite. It does what a branch’s HR and finance offices need each month, and it holds the evidence for what it did. Everything else — recruitment, appraisal cycles, training — stayed where it was.

Technology

What we cannot show

Salary levels, tax parameters, employee data and bank commercial terms are not shown. The four screens are configuration screens with values replaced.

Similar problem?

If this looks like something you are dealing with — a legacy system that must keep running, a workflow no product covers, an integration nobody wants to touch — send a short description. We will tell you honestly whether we are the right team, and what the first two weeks would look like.

Ask about this project