Payroll Setup
Payroll is the one system where being nearly right is the same as being wrong. It is proved by parallel running, not by demonstration.
Design and configure payroll rule books for any country: tax slabs, social security, overtime, and allowances, with an audit trail from rule to payslip line.
Payroll projects are judged on a single question: does it produce the same payslip your existing process produces, for every employee, including the awkward ones. Nothing else counts, and no amount of configuration review substitutes for running both systems side by side on the same period and reconciling to the last unit.
The rule book comes from two places, and neither is us. Your employment policy supplies the company-specific rules: allowances, grades, overtime treatment, leave encashment, loans, notice arrangements. Your accountant or payroll adviser supplies the statutory side. We turn both into rules the system executes, and we make the trace from a rule to a payslip line visible so any figure can be explained.
The part that decides whether it lasts is handover. Payroll that only we can change is a dependency you will resent within a year. Your team must be able to add an allowance, adjust a grade and run a period without calling anyone.
What is included
- โ Country-specific tax slabs & social security
- โ Salary structures & grade mapping
- โ Overtime, shift allowance, encashment
- โ Loan, advance, arrears rules
- โ Bank file generation (SAMA, SIF, SEPA)
- โ Auditable rule โ payslip line trace
- โ End-of-service gratuity calculation
- โ Year-end tax slips & Form 16/EPS
How the engagement runs
- 1
Rule capture
Get every rule written down, including the ones that live in somebody's head.
- Work through the employment policy line by line for the company-specific rules
- Take the statutory rules from your accountant or payroll adviser, in writing
- Interview whoever runs payroll today about the exceptions, since those are never documented
- List every allowance, deduction, loan type and one-off that appears across a full year
- Establish the rounding, proration and sequencing rules, which is where most differences originate
You end up with: A written rule book with each rule attributed to its source.
- 2
Structure build
Build the salary structures so a figure can always be explained.
- Salary structures per employee category, with the rule sequence made explicit
- Grades and bands mapped, with the inputs that drive each rule
- Loans, advances and recoveries configured with their schedules
- Leave and attendance inputs connected, since these are the usual source of monthly variance
- A dry run capability so a period can be previewed before anyone is paid
You end up with: Configured structures with a documented rule sequence and a working preview.
- 3
Parallel run
Prove it against payslips you already know are right.
- Run a completed period in the new system and compare to the existing output, employee by employee
- Investigate every difference, including the small ones, because small differences hide rule errors
- Include the awkward cases deliberately: joiners, leavers, unpaid leave, mid-period changes, arrears
- Repeat until two consecutive periods reconcile with no unexplained differences
You end up with: A reconciliation showing two clean consecutive periods.
- 4
Outputs and integration
Make everything downstream of the payslip work.
- Payslip layout approved by the people who will hand it to employees
- Bank output produced in the format your bank accepts, and tested with the bank before go-live
- Accounting posting configured, so payroll lands in the ledger without re-keying
- Access rights checked carefully, since payroll is the most sensitive data in the system
- Employee self-service enabled if you want payslip distribution handled by the system
You end up with: Approved payslips, a bank file the bank has accepted, and posted accounting entries.
- 5
Handover
Leave your team able to run and change it.
- Train the payroll team on the monthly routine including the corrections
- Train someone to add an allowance and adjust a structure without calling us
- Document the rule book as configured, with the source of each rule
- Agree who watches for statutory change and how that reaches the system
You end up with: A trained team, documented rules and a named owner for changes.
What you need to provide
The schedule slips on these more often than on anything technical.
- โ The employment policy, including the parts that exist only as custom and practice
- โ Statutory rules confirmed in writing by your accountant or payroll adviser
- โ Completed payslips for at least two periods, for the parallel run
- โ Employee master data: grades, contracts, bank details, joining dates, entitlements
- โ The bank output format your bank actually accepts, obtained from them
- โ A decision on who may see payroll data, which is stricter than for any other module
Decisions you will be asked to make
How many salary structures
One per employee category keeps rules readable and the reconciliation explainable. One structure with many conditional rules is compact and becomes unmaintainable within a year, usually just after the person who built it moves on.
Where variable inputs come from
Overtime, unpaid leave and attendance adjustments can be entered manually or driven from the attendance and leave records. Driving them from records removes the largest source of monthly error, and it means those records have to be trusted first.
How much history to load
Year-to-date figures matter if you go live mid-year, and loading them is real work. Going live at the start of a cycle avoids it entirely, which is often worth waiting for.
Self-service or manual distribution
Employee self-service removes a monthly task and adds an access-rights question. Both are fine, but it should be a decision rather than a default.
Where this goes wrong
The failure modes we plan around, and what the plan does about each one.
Going live without a parallel run
Payroll errors are personal, visible and remembered. Two consecutive periods reconciling with no unexplained difference is the entry condition for go-live, and there is no substitute for it.
Rules taken from memory
The person who runs payroll today knows exceptions that appear nowhere in the policy, and they surface in month three. The rule capture interview exists specifically to get those out.
Only the standard employee tested
Joiners, leavers, unpaid leave, mid-period grade changes and arrears are where differences live. They go into the parallel run deliberately rather than being met live.
Rounding and sequence ignored
Two systems can apply the same rules and disagree because they round differently or apply rules in a different order. That is captured explicitly, because it is the most common source of small differences that turn out to matter.
Bank output tested only against a specification
Banks reject files for reasons that are not in their own documentation. The file is tested with the bank before go-live, not on the first pay run.
Access rights left loose
Payroll is the fastest way to lose the trust of a workforce. Access is designed at the start and verified before real data is loaded.
Nobody able to change a rule
If every allowance change is a support ticket, the system becomes a bottleneck and workarounds appear in spreadsheets. Handover includes making a change, not watching one.
Not included
Stated up front so the proposal has no soft edges.
- ร Determining statutory rules: those come from your accountant or payroll adviser in writing
- ร Filing, submission or correspondence with any authority
- ร Legal or employment advice, including on contracts and entitlements
- ร Correcting historical payroll errors from the previous system
- ร Bank charges, service fees and any provider costs
- ร Ongoing monthly payroll processing, which is a service arrangement and not a configuration project
How this is priced
Quoted per entity, driven by the number of salary structures and the complexity of the rule book rather than by headcount. The parallel run is part of the scope and not an optional extra, because a payroll build that has not been reconciled has not been finished.
See the published bands โModules that come up on this work
Ready-built modules from our own catalogue. Where one of these covers the requirement, installing it beats writing it.
WT HRMS Payroll
Country-agnostic payroll engine - salary structures, rule engine with safe_eval, batch processing, payslip generation, dry-run preview, and full audit trail.
Why here: The rule engine most of this work is configured in, with the dry-run preview a parallel run depends on.
Human Resources/PayrollWT HRMS Payroll - Accounting Integration
Post confirmed payslips to Odoo accounting. Per-rule debit/credit account config, salary journal selection, batch-post button, auto-reverse on cancel. Closes the gap between WT HRMS Payroll and your books.
Why here: Posting payslips to the ledger without re-keying is what keeps payroll and finance reconciled.
Human Resources/PayrollWT HRMS Payroll - Bank Disbursement Files
One-click salary disbursement files for Pakistani banks. HBL, MCB, UBL, Meezan + generic CSV. Pulls confirmed/paid payslips from a batch, formats per-bank columns, downloads ready to upload.
Why here: Disbursement files are the last mile of every payroll go-live, and the part banks are fussiest about.
Human Resources/PayrollWT HRMS Loans
Employee loan management with amortization schedule, approval workflow, and payroll deduction integration.
Why here: Loan and advance recovery is one of the most common company-specific rules, and it needs a schedule rather than a manual deduction.
Human ResourcesWT HRMS Overtime
Employee overtime requests with policy-based rate multipliers and approval workflow.
Why here: Overtime is the largest source of monthly variance, and driving it from approved requests removes most payroll disputes.
Human ResourcesWT HRMS Attendance
Advanced attendance tracking - late arrivals, early departures, overtime calculation, daily summary, and monthly reports.
Why here: Variable inputs are only as good as the attendance data behind them, which is why that gets settled before the first parallel run.
Human ResourcesSalary Package Configurator and Digital Job Offers
Build salary packages, send tokenised offers candidates can configure themselves, and see net pay and cost to company recompute as they choose.
Why here: Where offers are made against a package rather than a basic figure, building the offer on the same rules avoids a mismatch at the first payslip.
Human Resources/EmployeesWhere we deliver this
Statutory rules differ by market and belong on the country pages, which are sourced and reviewed separately from this one.
Payroll Setup: common questions
How do you know the payroll is correct?
Parallel running. The new system produces a completed period, and it is compared employee by employee against the payslips you already issued. Every difference is investigated, including small ones, because a rounding difference on one employee usually means a rule is wrong for a category. Two consecutive clean periods is the entry condition for go-live.
Where do the statutory rules come from?
Your accountant or payroll adviser, in writing. We configure and prove them in the system, we do not decide them. Statutory detail for each market is on the country pages, which are sourced and maintained separately from this page.
Can our team change salary rules afterwards?
That is the point of the handover phase. Someone on your side should be able to add an allowance and adjust a structure without calling us. Payroll that only the vendor can change becomes a bottleneck within a year, and the workarounds always end up in a spreadsheet.
What about bank payment files?
The file is produced in the format your bank accepts and tested with the bank before go-live. Testing against the written specification alone is not enough, because banks reject files for reasons their documentation does not mention.
When is the best time to go live?
At the start of a cycle. Going live mid-year means loading year-to-date figures for every employee, which is real work and a real source of error. Waiting for the cycle boundary is usually cheaper than the alternative.
Does payroll post to accounting automatically?
Yes, once configured, with each rule mapped to the accounts your finance team specifies. It is worth doing during the same project, because manual re-keying of payroll into the ledger is both slow and the point where reconciliation quietly breaks.
Read next
Odoo Localization
Country-specific compliance out of the box.
Odoo Implementation
End-to-end Odoo deployment, from discovery to go-live.
Odoo Training
Role-based training for users, admins, developers.
Odoo Support & Maintenance
24/7 monitoring, bug fixes, performance tuning.
Odoo Customization
Custom modules built to match your exact workflow.
Tell us what you are trying to fix
A 30-minute call is usually enough to tell you whether this is a small piece of work or a project, and to say so before anyone writes a proposal.