SmartLink
Business applications

Payroll software and processing systems in Pakistan

Payroll software in Pakistan is judged on one day a month and forgiven for nothing. SmartLink Services configures payroll systems from Karachi across Oracle HCM Payroll, SAP Payroll and Odoo Payroll, covering earnings and deduction rules, statutory contributions, bank transfer files and payslip distribution. This page deals with what the work costs at market rates, why the calendar rather than the effort sets the timeline, and the decision most finance directors face at least once: whether to process payroll in house or hand it to a bureau. We configure to written instruction from your tax adviser. We are not tax advisers ourselves.

Discuss this service
Cycle
Monthly \u00b7 fortnightly
Validation
Parallel run before switch
Output
Bank file \u00b7 payslips
Overview

Payroll is a monthly deadline with legal consequences.

Payroll has no tolerance for iteration. A reporting error can be corrected next week. A payroll error becomes a conversation with an employee about their rent, and then a conversation about trust that lasts considerably longer. It also carries statutory obligations with dates attached, so the deadline is not internal and the penalty for missing it is not internal either. That combination is why payroll deserves more rehearsal than almost any other system we implement. Rehearsal is cheap. Explaining a short payment to several hundred people is not, and the explanation is remembered for years.

The work divides into three parts. Rules configuration covers earnings, deductions, contributions, tax treatment, loans, advances and final settlement. Processing covers the monthly cycle: inputs, calculation, checking, approval, bank file and payslip. Reconciliation covers proving the run is correct before money moves and proving it again to the general ledger afterwards. Most of the payroll problems we are asked to fix are failures of the third part rather than the first. Calculation is usually close to correct. What is missing is a report that proves it before the file leaves the building.

We do not switch a payroll on a promise. A parallel run against the existing payroll, covering at least one full cycle and preferably more, with every variance investigated and explained rather than tolerated, is the condition for going live. A variance nobody can explain is either a defect in the new system or an error in the old one, and both of those are worth knowing about before the switch rather than after it. Nobody has ever regretted running one more parallel cycle.

Scope

What Payroll processing systems covers

Everything below is agreed in writing before any crm & hrm work starts, so both sides know what is in and what is not.

What the work covers

  • Earnings, deduction and contribution rule configuration
  • Tax slab and statutory contribution setup
  • Loan, advance and final settlement handling
  • Bank transfer file generation per bank format
  • Payslip generation and secure distribution
  • Parallel run against existing payroll for sign-off

What you get at handover

  • Rule configuration document
  • Parallel run variance report
  • Bank file templates per bank
  • Payroll calendar and cut-off procedure
  • Month-end reconciliation checklist

Typically involves

SQL reporting Bank file formats
Discuss this service
01

Why the parallel run is the whole argument

A payroll that produces plausible numbers is not the same as a payroll that produces correct ones. Plausible is easy. Everybody gets roughly what they got last month, and nobody notices the allowance that quietly stopped, the tax slab applied at the wrong threshold, or the contribution calculated on the wrong base until a year end statement arrives and several people ask the same question on the same morning. By then the correction has to run backwards through a closed tax year, which is a different order of work entirely.

The parallel run compares the new system against the current one, employee by employee and component by component, across a full cycle. Every difference gets traced to a cause. Some of them will be the new system being wrong. A meaningful number, in our experience, turn out to be the old system being wrong in a way nobody had noticed, which is uncomfortable and very much better discovered during a parallel run than during an audit.

One cycle is the minimum and two is better, particularly where pay varies month to month. A single quiet month will not exercise overtime, arrears, mid month joiners, leavers with a final settlement, or the loan instalment that reaches its last deduction. We plan the parallel run across months that contain those events rather than across the calmest period in the calendar, because the calm month proves almost nothing. Where the business has a bonus cycle or a seasonal shift pattern, that is the month worth testing against.

  • A full cycle compared employee by employee and component by component
  • Every variance traced to a cause rather than tolerated as rounding
  • Parallel months chosen to contain joiners, leavers, arrears and variable pay
  • Sign off by the payroll owner as the condition for switching, ahead of any announced date
  • Findings against the existing payroll reported honestly, including where it was the one at fault
02

Statutory deductions and the cases that create arrears

Tax and contribution rules are usually stated simply and applied with conditions. Slabs change during a financial year. Contributions carry ceilings, and some carry floors. A benefit may be taxable in one form and exempt in another. Employees who join part way through a year need their earlier earnings taken into account or their annual position will be wrong, and employees on unpaid leave create months where a fixed deduction has no salary to come from.

Arrears are where all of this interacts badly. A backdated increment paid in month six changes the tax position of the months before it, and whether that is spread or taken in the month of payment is a decision with real consequences for the employee. Loan and advance recovery needs a rule for the month where net pay would otherwise go below zero. Final settlement needs encashment, notice, gratuity where applicable and recovery of anything outstanding, in one calculation that people check very carefully.

We encode the rules and their exceptions, then test them with constructed cases rather than average ones. The test set deliberately includes the mid year joiner, the leaver with an outstanding loan, the employee with unpaid leave, and the backdated revision, because those are the cases that generate complaints. Interpretation of the statute stays with your tax adviser. We implement what they confirm and record which rule came from where. That record matters later, when a rule changes and somebody has to work out what else it touches.

  • Slab, ceiling and exemption rules held as dated configuration, so a mid year change is supported
  • Arrears treatment decided explicitly, including the effect on tax in earlier months
  • Loan and advance recovery rules covering the month where net pay would fall below zero
  • Final settlement calculated in one place: encashment, notice, dues and outstanding recoveries
  • A test set built from awkward cases rather than from average employees
01

What payroll software costs in Pakistan

Market ranges put HR and payroll configured inside a core systems programme at PKR 200,000 to 400,000, and multi location capability at a further PKR 200,000 to 500,000. Subscription platforms in Pakistan are commonly quoted around PKR 2,500 per user per month. Where the requirement is genuinely unusual and gets built rather than configured, market pricing for a custom application runs PKR 200,000 to 1,000,000 and upwards, though building a payroll engine from nothing should be argued hard before it is taken.

Pay elements are the real unit of cost, not employees. Count them honestly before asking anyone for a price: basic, house rent, utilities, conveyance, a medical allowance, shift and night premiums, overtime at more than one rate, production or attendance incentives, loan and advance recoveries, leave encashment, gratuity and final settlement. Twenty five elements is a normal payroll and each one needs a rule, a test case and somebody to confirm the rule is right. An organisation with two hundred employees and eight elements is cheaper to configure than one with sixty employees and thirty.

Three further items belong in any comparison. Statutory tracks, since income tax withholding, EOBI and provincial social security each carry their own calculation, their own remittance and their own report. Bank formats, because each bank has its own transfer file layout, the layouts change, and testing one involves a bank that has no interest in your timetable. And retrospection, which is the ability to recalculate a closed period when a salary revision is backdated, a feature that is quietly the difference between a payroll system and a calculator. Every figure above is market pricing. Ours follows discovery, once the element list, the statutory scope and the bank list are agreed.

  • Pay element count priced ahead of headcount, since each element is a rule and a test case
  • Statutory tracks configured separately for withholding, EOBI and provincial social security
  • A bank transfer file template per bank, each tested with that bank rather than assumed
  • Retrospection and backdated revision handling confirmed as present before you buy
  • Loan, advance, gratuity and final settlement rules scoped rather than left to month one
02

How long a payroll implementation takes

Configuration is quick and the project is not, and the gap between those two facts is where most payroll proposals go wrong. Reported timelines put a focused single company go live at six to twelve weeks. Payroll fits inside that only when the element list is short and the parallel runs go cleanly, because validation happens against real pay periods and each period costs a calendar month whatever effort is applied.

Two clean parallel cycles is the usual bar before an old process is retired, and clean means every variance explained rather than every variance small. First cycle almost never passes. What it produces is a list of differences: an allowance the old spreadsheet prorated differently, an overtime rate rounded by hand for years, a deduction somebody had been suspending informally for one employee. Each difference is traced to a rule and the rule corrected, then the second cycle proves the correction. That arithmetic cannot be compressed.

Tax year boundaries are worth planning around. Rates, thresholds and slabs change with the Finance Act, and going live in the weeks around a change means configuring two versions of the rules while validating both. Where the choice exists, start the parallel runs early in a tax year. We re-check the configuration at the start of each tax year rather than assuming last year's table still holds.

  • Two clean parallel cycles, each costing a calendar month that effort cannot shorten
  • Every variance in a parallel run explained and traced to a rule before sign off
  • Go live planned away from a Finance Act change where the choice exists
  • Configuration re-checked at the start of each tax year rather than assumed forward
  • Bank file testing booked with the bank early, since their calendar is not yours
03

Processing payroll in house or through a bureau

A bureau takes the monthly run off your desk. You send the changes, they calculate, and you receive the results, the bank file and the statutory reports. For a company of forty people with one location and no shift complexity, that is often the sensible answer, because payroll is a specialised task performed once a month and keeping the knowledge in house means keeping one person who cannot go on holiday in the first week.

In house wins on control and on speed of change. A backdated revision approved on the twenty eighth can be processed on the twenty eighth. Data stays inside the building, which matters to boards in family owned groups where senior pay is closely held. Reporting is available without asking for it, and the payroll journal posts straight to the ledger rather than arriving as a file somebody imports. The cost is that you employ the knowledge: somebody has to understand the rules, keep up with the Finance Act and own the run.

Three questions separate the two more cleanly than a cost comparison does. How often does something unusual happen, because a bureau is efficient at routine and slow at exceptions. How sensitive is the salary data, and would the board accept it leaving the building. And who is the single point of failure today, since organisations that answer with one name have already found their strongest argument for a system, whichever route they take.

Where a bureau is used, the systems work does not disappear, it changes shape. Somebody still has to hold the employee master, produce the monthly change file in the agreed format, check what comes back before the money moves, and post the journal. Write the responsibility split down before any data moves, including who is accountable for a late statutory remittance. We build the interface and the controls around a bureau arrangement as readily as we configure a payroll engine, and we hold none of your payroll data ourselves.

  • A bureau for small, stable payrolls with few exceptions and no shift complexity
  • In house where backdated revisions are frequent or salary data must stay in the building
  • The single point of failure named honestly before the route is chosen
  • A written responsibility split covering the change file, the checks and the remittance
  • Journal posting to the ledger designed either way, so finance is never rekeying
How we deliver

Delivering Payroll processing systems

Customer and people systems fail on adoption rather than on features. So the weight in these six steps sits on the pilot and the first real cycle, not on the build.

  1. 01

    Discover

    Sit with two reps through a week of their pipeline updates and with payroll through one close. The stages people describe in a meeting and the stages deals actually pass through are different things.

  2. 02

    Blueprint

    A register names which system owns customers, prices and credit terms, and where a prospect becomes an account. Employee numbering, effective dating and the leave accrual rules are settled in the same document.

  3. 03

    Build

    Pipeline stages, qualification criteria, approval routes and payslip layouts get configured against that register. Fields nobody named an owner for are left out, because every extra field is one more reason not to update the record.

  4. 04

    Test

    Payroll is proved by parallel run, two cycles, every variance explained by a rule rather than dismissed as small. CRM testing follows the deal from lead through quotation to the invoice raised in the ERP.

  5. 05

    Go live

    One pilot team first, with a sceptic in it, then waves. Payroll switches at a tax year boundary where the local framework gives one, so year to date figures stay clean.

  6. 06

    Run

    Adoption is measured at thirty days: records updated within a day of the activity, mandatory fields left at default, time a manager spends assembling the weekly review. Unused fields are then removed.

Working together

What we do not decide for you

We are software implementers, not tax advisers. Where a statutory rule is open to interpretation, and several usually are, that interpretation stays with your tax consultant or your finance leadership. What we do is encode the rule they confirm, record where it came from, hold it as dated configuration so a mid year change does not need a code release, and test it against the cases that would otherwise surface as complaints in month three.

The other boundary is the go live date. We will not switch a payroll because a date has been announced if the parallel run still contains variances nobody can explain. Payroll is the one system where a delayed go live is a small problem and a wrong first run is a large one. That position is worth agreeing at the start of a project rather than during the week when it suddenly matters to everybody.

Credentials

Accreditations behind CRM & HRM

These systems hold salary data and customer records at the same time, so the questions we are asked are about access control as much as about platform accreditation.

Oracle

Partner

Oracle HCM Cloud for employee master data, absence and payroll, sitting on an Oracle database we also administer. Customer records held in EBS stay the source for credit terms and pricing.

Microsoft

Partner

Dynamics 365 Sales and Customer Service configuration, Power Automate for leave and expense approvals, and Entra ID sign in so a leaver loses CRM access when human resources ends the record.

Google

Partner

Workspace calendars and mail threaded onto the account record, so a rep's meeting history sits on the opportunity instead of in a personal inbox. Google Cloud where the CRM is self hosted.

FBR digital invoicing

Compliant integrations

Quotations approved in the CRM become sales orders and then tax invoices in the ERP, which is where FBR submission happens. The invoice reference number is visible back on the opportunity.

HIPAA

Compliant practices

A hospital service desk using a CRM sees patient contact details, so views are cut to the minimum necessary, exports are restricted and logged, and a business associate agreement is signed first.

Client words

What CRM & HRM clients say

Comments from people who run crm & hrm systems day to day.

  • Timesheets were the thing everybody hated, so that is where they started. Entry now takes seconds on a phone and the utilisation numbers are current rather than a week old. I can see an engagement drifting while there is still something I can do about it.
    Managing Partner Professional services practice
  • Our cost reports used to show what we had paid, never what we had committed. Once the subcontract orders and approved variations started registering as commitment, the forecast stopped flattering us. It was uncomfortable reading for a month and then it became the most useful number we have.
    Chief Financial Officer Construction and contracting firm
  • The team spent two days on the floor before they proposed anything, which I did not expect. They noticed that our scrap was being written off as a variance instead of recorded as returning metal, and that one change altered how we look at recovery on every press.
    Plant Manager Aluminium extrusion operation
Questions

Questions about Payroll processing systems

Market ranges put HR and payroll configured inside a core systems programme at PKR 200,000 to 400,000, with multi location capability adding PKR 200,000 to 500,000. Subscription platforms here are commonly quoted around PKR 2,500 per user per month. The figure is driven by the number of pay elements and statutory tracks rather than by headcount, so an organisation of sixty people with thirty elements costs more to configure than one of two hundred with eight. Ours follows discovery.

Configuration is quick and validation is not. Reported timelines put a focused single company go live at six to twelve weeks, and payroll fits inside that only when the element list is short. Plan two clean parallel cycles against real pay periods, each costing a calendar month. Effort cannot shorten that, and any supplier offering to is not describing a validated payroll.

As separate statutory tracks, each with its own calculation, remittance and report, alongside monthly income tax withholding. Provincial social security applies through the institution for the province the employee works in, which for a Karachi employer means Sindh. We configure to what your tax adviser confirms in writing and re-check it at the start of each tax year.

A bureau suits small, stable payrolls with few exceptions. In house suits organisations with frequent backdated revisions, shift complexity, or a board that will not let salary data leave the building. Either way somebody still owns the employee master, the monthly change file and the journal posting, so write the responsibility split down before any data moves.

Yes, and it needs a template per bank, because each bank has its own layout and those layouts change without much warning. We build the template, test it with the bank rather than against a specification, and keep it under version control. When a format changes, the fix is a configuration change rather than a night spent editing a file by hand.

Rates, thresholds and slabs change with the Finance Act, and the configuration is updated to what your tax adviser confirms in writing rather than to a reading of the gazette by us. We re-check the tables at the start of each tax year and retain the written instruction against the configuration, so an auditor asking why a rate was applied has a document rather than a recollection.

More in CRM & HRM

More CRM & HRM services

Business applications

CRM implementation

Pipeline, quoting, service and reporting configured around how your sales team really sells.

Open service page → Business applications

HRM & HCM systems

Employee master data, attendance, leave, appraisal and payroll in one system of record.

Open service page → Business applications

Employee & customer portals

Self-service portals over ERP and HRM so requests stop arriving as email.

Open service page →

Payroll taking the last week of every month?

Tell us what you run today and where payroll processing systems is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All crm & hrm