SmartLink
Business applications

HR software in Pakistan: HRM and HCM systems

HR software in Pakistan is usually bought after a bad month rather than after a good plan, and the bad month is normally a payroll nobody could reconcile. SmartLink Services configures HRM and HCM systems from Karachi across SAP SuccessFactors, Oracle HCM, Odoo HR and Zoho People, including attendance devices, shift rules and the record migration that comes first. This page covers what such a system costs at market rates, how long a rollout takes once biometric hardware and several sites are involved, and the decision that shapes everything else: whether plant workers and head office staff belong in the same system.

Modules
Core HR \u00b7 time \u00b7 payroll
Compliance
Local statutory rules
Access
Role-based
Overview

One record per employee, one approval path per event.

HR data spread across spreadsheets turns every payroll into a negotiation. Attendance sits with a supervisor, leave balances sit with an administrator, salary revisions sit in an email thread, and at month end somebody reconciles the three by hand under time pressure. The errors that follow are not carelessness. They are the predictable output of a process where no single record is authoritative and every figure has a second version somewhere in the building. Nobody set out to build that arrangement, and it is remarkably hard to leave once payroll depends on it.

A core HR system fixes that by making the employee master the only place a fact lives. Grade, department, cost centre, reporting line, salary structure and entitlement all sit on one record with a history attached, so a question about last March can be answered without asking who kept the old file. Everything downstream, attendance, leave, appraisal and payroll, reads from that record rather than maintaining a private copy that drifts. Where a module genuinely needs its own copy, it reads on a schedule and reconciles afterwards, rather than being keyed a second time by somebody with a deadline.

Configuration is where written policy meets actual practice. Policy documents usually cover the ordinary case and leave the exceptions to custom and precedent, which works until a system has to encode them. We surface those decisions early, put them in front of somebody with the authority to settle them, and record what was decided and why. That document is worth more than the configuration itself, because in two years it explains why a rule behaves the way it does. That is a question somebody always asks eventually, usually during an audit.

Scope

What HRM & HCM 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

  • Employee master data model and organisational structure
  • Attendance and shift rules, including plant shift patterns
  • Leave policy configuration and approval workflow
  • Appraisal cycles and competency frameworks
  • Payroll setup with statutory deductions and reporting
  • Migration of existing employee records and balances

What you get at handover

  • Configured org structure and position hierarchy
  • Policy configuration document
  • Payroll parallel-run comparison
  • Statutory report set
  • HR team training and manuals

Typically involves

Biometric device APIs
Discuss this service
01

Attendance rules break on the shift

Office attendance is easy. A start time, a grace period, a half day rule and a monthly summary. Plant attendance is not easy, and most HR systems are demonstrated on the easy case. Rotating shifts, night shifts that cross midnight, a fourth shift covering weekly offs, overtime that changes rate above a threshold, and a supervisor who moves people between lines halfway through a shift are all perfectly normal, and every one of them breaks a naive configuration.

Biometric devices bring problems of their own. Clocks drift, so a punch recorded at 05:59 on one device and 06:01 on another is the same event with two different consequences. Devices go offline, buffer, then upload out of order. A worker with worn fingerprints fails to register and a supervisor marks them present by hand, which is legitimate and needs to leave an audit trail rather than being indistinguishable from a genuine punch. The difference matters most in the month when somebody disputes their overtime and asks to see the record.

We configure against the shift patterns actually worked rather than the ones printed in the handbook, and we test with a month of real punch data before anything goes live. Manual corrections remain possible, because they have to be, but each one carries a reason and a person. Exception reports go to supervisors daily instead of accumulating for a payroll clerk to untangle in the last three days of the month. A supervisor can correct yesterday from memory. Nobody corrects three weeks ago from a report.

  • Shift patterns configured from real rosters, including night shifts that cross midnight
  • Device clock synchronisation, with handling for buffered uploads that arrive out of order
  • Manual attendance corrections permitted, recorded with a reason and an approver
  • Overtime thresholds and rate changes encoded as rules rather than calculated by hand
  • Daily exception reports to supervisors instead of a month end reconciliation exercise
02

Leave balances are an accounting problem

Leave looks simple until somebody writes the rules down. Does entitlement accrue monthly or vest annually. What happens to a joiner in August, and to a leaver in March. Does carry forward have a cap, an expiry date, or both. Is encashment allowed, at what rate, and against which balance. Is a public holiday falling inside a leave period counted. Every organisation has answers to these, and most have never had them all written in the same document.

Because a balance is a liability, the system needs to behave like a ledger rather than a counter. Every accrual, deduction, adjustment and carry forward should be a dated transaction with a reason, so a disputed balance can be explained line by line. Systems that hold a single running number are impossible to argue with and therefore impossible to trust, and the disputes end up settled by whoever is most persistent rather than by the record.

Approval routing needs the same care. A request should follow the reporting line held on the employee record, with a defined route for the weeks when the manager is themselves away, because otherwise requests sit unapproved and staff take the leave anyway. Delegation is recorded with a start date and an end date rather than handled by sharing a login, which is the practice that quietly destroys every audit trail built above it. Routing is cheap to get right during configuration and awkward to correct once people have built habits around the gaps.

  • Accrual, carry forward, expiry and encashment rules written down and agreed before configuration
  • Leave held as a transaction ledger, so any balance can be explained line by line
  • Approval routing taken from the reporting line held on the employee master record
  • A defined route and a recorded delegation when an approver is absent
  • Opening balances migrated with a signed reconciliation against the previous records
01

What HR software costs in Pakistan

Published market ranges give a usable frame. HR and payroll configured inside a core systems programme is quoted at PKR 200,000 to 400,000. Multi location capability adds PKR 200,000 to 500,000, which matters because attendance is a per site problem rather than a per employee one. A self service application for staff, whether a mobile app or a portal, is published at PKR 400,000 to 800,000. Where the requirement is built rather than configured it becomes a custom web application, and market pricing for those sits at PKR 200,000 to 1,000,000 and upwards. Subscription platforms in Pakistan are commonly quoted around PKR 2,500 per user per month.

Headcount matters less than most buyers expect. What moves an HR quotation is the number of distinct employment arrangements the system has to model, and Pakistani organisations tend to have more of them than they think: permanent staff, a plant workforce on shifts, contract labour through a third party, field staff paid partly on achievement, and a handful of senior arrangements handled separately for reasons nobody writes down. Each one is a set of rules to configure, test and explain. Two sites with identical policies cost far less than one site with five employment types.

Attendance hardware is the line most often left out. Devices are usually already installed, and usually a mixture of models bought over several years from different suppliers. Each model needs its own integration, and a device that stores punches locally behaves differently from one that streams them. Add the record migration, which on a first HR system means employee masters, opening leave balances, loan positions and a salary history somebody has to certify. Every figure here is market pricing. Ours follows discovery, once the employment types, the site list and the device inventory are agreed.

  • Distinct employment arrangements counted, since each is a separate set of rules to configure
  • Site count priced ahead of headcount, because attendance is a per site problem
  • Biometric device models inventoried, as each supplier and model integrates differently
  • Opening leave balances and loan positions certified by somebody before they are loaded
  • Self service application quoted separately from the core HR configuration
02

How long an HRM rollout takes

Reported timelines put a focused single company go live at six to twelve weeks, an SME rollout at three to six months, and a large multi entity programme at nine to twelve months. HR sits at the longer end of whichever band it falls in, and hardware is the reason. A core HR and leave configuration for one office is genuinely quick. The same configuration with attendance devices at three plants, two of them on a different network, is not.

Policy is the constraint that stops projects, and it is rarely acknowledged in a plan. Half the questions a configuration workshop asks have never been answered in writing: whether unused leave carries forward and how much of it, whether a late arrival is deducted or absorbed, what happens to attendance when a shift crosses midnight, who approves when the approver is on leave. Those answers require a decision from somebody senior, and waiting for that decision is not effort, it is calendar.

Opening balances add a stage nobody enjoys. Leave entitlements have to be agreed employee by employee, and there is usually at least one person whose balance only one member of the HR team can explain. Publish the opening position before go live and give staff a window to query it, because a balance disputed in month one is a conversation and the same balance disputed in month nine is an accusation about the system.

  • Focused single company go live reported at six to twelve weeks
  • SME rollouts at three to six months, large multi entity work at nine to twelve
  • Attendance hardware at each site treated as its own commissioning task
  • Written policy decisions gathered before configuration rather than during it
  • Opening leave balances published for query before the system goes live
03

Bringing plant workers into the same system as head office

Most Pakistani organisations with a factory run two arrangements without ever deciding to. Head office sits in an HR system with leave requests, appraisals and a directory. The plant runs on a gate register, a supervisor's notebook and a wages calculation somebody performs separately each week. The two meet once a month, in a spreadsheet, under time pressure. It works until an auditor asks how many people were on site on a given day, or until a dispute arrives and the evidence is a photocopied register.

Bringing the plant in is not a licensing question, it is a design question. Shift patterns are the first difference: rotating shifts, night allowances, a shift that crosses midnight and therefore belongs to two calendar days depending on which rule you apply. Overtime is the second, and it is where most configurations are wrong, because the rule the policy states and the rule the plant has actually been using since 2019 are frequently different documents. Contract labour is the third and the most awkward, since those workers are on somebody else's payroll while standing on your floor, being counted by your devices and covered by your safety obligations.

A single system earns its place when headcount reporting, absence and cost per line have to be answered for the whole organisation at once. Keeping the plant separate is defensible where the workforce is small, largely stable and paid by a third party, provided somebody owns the monthly reconciliation and it is a written procedure rather than a habit. What is not defensible is the middle position, where the plant is half in the system, the devices are recording, and nobody is quite sure whether the report covers everyone.

Where we do bring both into one system, we model the plant first and the office second. Office HR is the easier half and it will fit around whatever the shift rules demand. Doing it the other way round produces a configuration that handles appraisals beautifully and cannot describe a night shift.

  • Shift patterns, night allowances and midnight crossings modelled before anything is configured
  • The overtime rule the plant actually uses established alongside the one the policy states
  • Contract labour handled explicitly, including who owns the record and the safety obligation
  • A written monthly reconciliation where the plant is deliberately kept separate
  • Plant rules configured first, with office HR fitted around them
How we deliver

Delivering HRM & HCM 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

The policy decisions come before the software

A large part of an HR implementation is not technical at all. It is getting decisions made about rules that have been running on precedent for years, and getting them made by somebody with the authority to settle them. We can facilitate that conversation and we can document what comes out of it. We cannot make the decisions for you, and a project that starts configuration before those answers exist will stall in testing, when the exceptions all arrive at once.

Where an organisation is not ready to settle its policies, the honest advice is to begin with core HR and attendance, get one authoritative employee record in place, and add appraisal and payroll once that foundation is trusted. The sequence looks slower on paper and is faster in practice, because every later module reads from the record built first and inherits its quality rather than repeating its problems.

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.

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 HRM & HCM systems

Market ranges put HR and payroll configured inside a core systems programme at PKR 200,000 to 400,000, multi location capability at PKR 200,000 to 500,000 and a self service application at PKR 400,000 to 800,000. Subscription platforms here are commonly quoted around PKR 2,500 per user per month. What moves the figure is the number of distinct employment arrangements and the site count rather than headcount, because attendance is a per site problem.

Reported timelines put a focused single company go live at six to twelve weeks, an SME rollout at three to six months and a large multi entity programme at nine to twelve months. Attendance hardware at several sites pushes it towards the longer figure. The commonest delay is not technical at all: policy questions that have never been answered in writing.

Below roughly thirty employees in one office, a well kept spreadsheet and a clear leave policy often do the job, and a system adds administration without removing much. The case turns when there are shifts, more than one site, contract labour, or an audit expectation. It also turns the first time a leave balance is disputed and nobody can produce the history.

Yes, and the interface that matters is the payroll journal posting to the general ledger, split by cost centre or department so finance can report labour cost without rekeying. Loan and advance balances usually flow too. We agree which system owns each figure before building anything, because two systems both calculating a deduction is a reconciliation nobody wins.

Yes, through the device APIs, and it is standard work. Inventory the devices first. Most organisations have a mixture of models bought over several years, each integrating differently, and some store punches locally while others stream them. That difference decides what happens to attendance when a site loses its network, which is the case worth designing for rather than discovering.

Broadly a matter of scope and marketing. HRM and HRMS describe systems handling the administrative core: employee records, leave, attendance and usually payroll. HCM describes a wider set that adds recruitment, learning, succession and performance management. The label matters far less than whether the product handles Pakistani statutory payroll, which is where products written abroad most often fall short.

HR data living in spreadsheets?

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