SmartLink
Public sector

Public sector ERP in Pakistan: cost, timelines and audit evidence

Public sector ERP in Pakistan is bought through a procurement process and judged afterwards by an auditor, which makes it a different purchase from the same software in a private group. SmartLink Services works with departments, authorities and public bodies from Karachi, on specification writing before a tender, delivery after one, and the support arrangement that has to outlive the project team. What follows answers the questions a procuring officer needs settled before a summary goes up: what this work costs at market rates, how long a departmental rollout really runs, and what evidence the system has to hold when the audit party arrives. Figures below are published market ranges rather than our quotation.

Discuss your systems
Priority
Auditability
Access
Role based
Procurement
Tender ready
Handover
Documented
Overview

Public systems are judged on evidence

Public sector work has a different centre of gravity. The question is rarely whether a system can do the task, it is whether you can show who did what, under which authority, on which date, and prove it two years later to somebody who was not there.

That shapes the way we build. Approval chains are modelled on the delegation of authority as written rather than as practised. Every consequential action leaves a record that cannot be quietly edited. Reporting is designed so the figures in a public answer reconcile to the transactions behind them.

It also shapes procurement. Requirement documents, evaluation criteria and technical specifications have to stand up in a tender process, so we write them to be defensible rather than flattering to any one product. Where a requirement can only be met by one supplier, we say so plainly instead of dressing it as an open specification.

The work

Where public sector systems break

Drawn from the problems that come up repeatedly in this sector rather than from a generic capability list.

Where it usually hurts

  • Approval chains that exist on paper but are bypassed in the system
  • Records that can be changed without a trace, which fails audit
  • Data held in departmental spreadsheets that nobody reconciles
  • Tender specifications written around one product by accident
  • Systems delivered without documentation, then unsupportable when staff move
  • Citizen facing services that cannot report on their own turnaround times

What the work covers

  • Requirement and specification documents written for tender evaluation
  • Workflow and delegation of authority modelled as approved, with full audit trail
  • Role based access with segregation of duties evidence
  • Integration between departmental systems and central reporting
  • Data migration from legacy records with reconciliation
  • Documented handover and training so the system outlives the project team

Typically involves

ERP REST APIs Document workflow Identity and access
Discuss your systems
01

Where a delegation of authority schedule meets a live approval matrix

A delegation of authority schedule is written as prose. An approval matrix is written as rules. Turning one into the other is where the difficulties surface, and they surface early. Is a limit applied per transaction, per contract, or cumulatively across a financial year. Is it gross or net of taxes. What happens at exactly the limit rather than above it. Departments usually have a settled answer to each of these, but the answers live with two or three experienced officers and have never been written down in one place.

Temporary arrangements cause more trouble than the permanent hierarchy. Officers take leave, hold additional charge, or act in a post above their own. Most systems model a fixed reporting line well and temporary delegation badly. If the system cannot record a delegation with a start date, an end date and the order that granted it, staff will do the practical thing and share a password. Every audit trail produced after that point is fiction, and the fiction is convincing enough that nobody notices until an investigation.

Thresholds also invite splitting. Two purchases just under a limit attract less scrutiny than one above it, and the pattern is sometimes innocent and sometimes not. Blocking it outright tends to fail, because there are genuine reasons to raise separate orders against the same supplier in the same week. Reporting it works better. The system flags related transactions to internal audit and lets a person judge intent, which keeps the control effective without stopping legitimate work at the counter.

  • Financial limits recorded per transaction, per contract and cumulatively over a period
  • Temporary and acting delegations carrying a start date, an end date and the order reference
  • Conflicting duty combinations checked when a role is assigned, not discovered during audit
  • Possible splitting reported to internal audit rather than silently blocked at the counter
  • A printable statement of who currently holds which authority, and who held it on a past date
02

What an audit trail has to record before it is worth producing

Almost every system logs something. Far fewer log what an auditor will ask for. The useful minimum is the actor, the action, the record affected, the value before the change, the value after it, the time, and where the request came from. The value before the change is the field most often missing and the one most often needed, because the question in an audit is rarely what the figure is now. It is what it used to be, who altered it, and on whose instruction.

Identity is the part that quietly decays. A trail saying a change was made by an account shared across a section proves nothing at all. Named accounts, tied to the departmental directory so a leaver loses access on the day the human resources record changes, are the only version worth building. Service accounts used by interfaces should be labelled as such and kept separate from human ones, so an automated posting is never mistaken for an officer's decision, or used to conceal one.

Correction matters as much as prevention. Records should be reversed and reissued rather than edited in place, with a reason recorded against the reversal, because an auditor reading a ledger with no corrections in it becomes suspicious rather than reassured. Retention deserves an equally clear decision. Agree how long records are kept, where the archive sits, and test that the archive can still be read after a version upgrade, since an unreadable archive is the same as no archive when somebody finally asks.

  • Values before and after every change to a financial, entitlement or status field
  • Named accounts tied to the departmental directory, with shared logins removed rather than discouraged
  • Reversal and reissue entries carrying a reason code, instead of edits that overwrite history
  • A stated retention period and a tested method of reading archived records after an upgrade
  • Synchronised clocks and a recorded time zone, so the sequence of events can be relied upon
03

Writing a specification a tender committee can defend afterwards

Specifications go wrong most often by accident. A requirement mentions a module name, a screen layout or a licence metric that only one product uses, and the tender is effectively closed before it opens. The remedy is mechanical. State the outcome the department needs, then state the evidence an evaluator will accept as proof that a bidder meets it. If the evidence cannot be described, the requirement is not yet a requirement and needs another conversation with the officers who will use the system daily.

Weighting is the second common failure. When every line is marked mandatory, evaluation collapses into a price comparison and the department buys the cheapest interpretation of its own words. Separate what is genuinely mandatory from what is desirable, attach a score to the desirable items, and agree the scoring rubric before any bid is opened. A rubric written afterwards, however honestly, is difficult to defend if a losing bidder asks how the marks were arrived at.

Pricing schedules deserve the same discipline. Bidders who are not told to price test, training and disaster recovery environments will price production only, and the difference reappears later as a variation. Name the environments, the licence basis, the number of support years, the migration scope, each interface, and how prices move over the contract term. Where a requirement really can be met by one supplier alone, write that down and justify it, because an unstated single source is far harder to defend than a stated one.

  • Requirements written as an outcome plus the evidence an evaluator will accept as proof
  • A scoring rubric agreed and signed before any bid envelope is opened
  • A pricing schedule naming environments, licence basis, support years and price movement
  • Demonstration scenarios scripted from the department's own cases rather than the bidder's
  • A written justification wherever a requirement can genuinely be met only one way
01

What public sector systems cost in Pakistan

Published market pricing in Pakistan sorts implementation work into three bands. A focused system covering one directorate, with purchase, stores and accounting at a single office, runs PKR 800,000 to 1,500,000 and goes live in two to three months. Five to seven modules with a mobile application sit at PKR 1,500,000 to 3,000,000 across three to four months. Work spanning several offices, with integration into central reporting, starts at PKR 3,000,000 and runs four to six months or longer. Departmental scope almost always lands in the upper two bands, because a department rarely buys for one office.

Module add ons are what an evaluation committee compares first. Market ranges put accounting and finance at PKR 200,000 to 400,000, human resources and payroll at the same, multi location capability at PKR 200,000 to 500,000, and a mobile application at PKR 400,000 to 800,000. A citizen facing service is a custom web application rather than a module, and market pricing for that work runs PKR 200,000 to 1,000,000 and upwards. Subscription platforms are commonly quoted around PKR 2,500 per user per month, which reads well in year one and needs a five year total before anyone signs.

What moves the figure is rarely the module list. Offices come first: each additional location adds a test cycle, another set of key users to train and another cutover, so the second office is the expensive one. Delegation depth follows. A schedule with four financial limits and one acting arrangement is configuration; one with fourteen limits, temporary charge and case by case delegation is a project in its own right. Register condition is the third. We have loaded departmental records where one contractor appeared under three names, and an opening balance that reconciled only after an adjustment nobody could account for. Treat all of the above as market pricing. A real figure follows discovery, once offices, delegation and register condition are agreed.

  • Offices and directorates in scope, which drive testing, training and cutover
  • Delegation of authority depth, counted in limits and acting arrangements
  • Condition of the legacy registers being migrated and reconciled
  • Documentation written to survive tender evaluation
  • A five year total where the platform is sold by subscription
02

How long a departmental rollout takes

Publicly reported timelines put a focused single entity go live at six to twelve weeks, a mid sized rollout at three to six months, and a large programme with several entities and real integration work at nine to twelve months. Departmental work sits at the longer end of whichever band it starts in, and the reason is procedural rather than technical.

Procurement is the part no delivery plan controls. Between the specification being drafted and the letter of award being issued there is an evaluation committee, a clarification round and often a re-tender, and none of that shortens because the department is in a hurry. The financial year boundary then acts as a second gate: work that misses it waits for the next budget release, which can add a quarter to an otherwise sound plan. We build the schedule backwards from that date rather than forwards from the kick off meeting.

Officer transfer is the quiet risk. A project that depends on one deputy secretary who knows how approvals really move will stall the week that officer is posted elsewhere, and we have watched exactly that happen. The counter is dull and it works: decisions recorded in a signed blueprint, support attached to a post rather than a person, and a written record of who approved what. Elapsed time in this sector is mostly decision latency, so we agree named officers and days per week before a plan is baselined.

  • Focused go live reported at six to twelve weeks, larger programmes nine to twelve months
  • Tender evaluation, clarification and award sit outside the delivery plan
  • The financial year boundary gates budget release and cutover dates
  • Officer transfer handled by recording decisions rather than relying on memory
  • Named officers and days per week agreed before the schedule is baselined
03

Audit evidence and reporting in the public sector

An audit trail is only worth producing if it records who acted, what they changed, when, and under which authority. That last field is the one most systems omit and every auditor asks for. We design the trail before configuration begins, hold it where an administrator cannot quietly edit it, and test it by trying to break it during acceptance rather than by describing it in a document.

Segregation of duties has to be evidenced, not asserted. It is not enough that a conflicting combination of roles is prohibited on paper; somebody has to attempt the combination in the test environment and record that the system refused. Access recertification then belongs in the first quarter after go live, because the leaver who kept a login is a finding waiting to be written, and the department, not the supplier, is the one it lands on.

Sales tax reaches public bodies more often than officers expect. Section 3(9A) of the Sales Tax Act requires Tier-1 retailers and other notified persons to integrate their point of sale with the FBR computerised system for real time reporting, and Sales Tax General Order No. 17 of 2022 addressed Tier-1 retailer integration. Where an authority makes taxable supplies through a canteen, a guest house or a commercial arm, the same engineering applies: the invoice is posted, FBR returns an invoice reference number and a QR code, and both print on the document the customer takes away. Non compliance can mean disallowance of a substantial share of input tax adjustment, currently sixty percent, which turns a systems gap into a cash problem inside one return cycle.

Two boundaries stated plainly. Whether a particular activity falls inside that classification is a question for the department's own tax adviser, and we configure to their written instruction rather than interpreting the law on their behalf. Data residency is treated the same way: we build to where your policy says records, backups and logs must live, and we say so in writing if a hosting option would breach it.

  • Audit trail recording actor, action, date and the authority relied on
  • Conflicting role combinations proved to fail during acceptance testing
  • Access and authority recertification scheduled in the first quarter
  • FBR integration where the body makes taxable supplies, tested in the sandbox first
  • Classification confirmed by your tax adviser, then configured to that instruction
How we deliver

Delivering in public sector

Every step is expected to leave a document a tender committee or an auditor can read afterwards. That is the difference between public sector delivery and a project judged on demonstration day.

  1. 01

    Discover

    Officers who actually process the file walk us through it, step by step, and we read the delegation of authority schedule as approved against how approvals move in practice. Existing registers are profiled for quality.

  2. 02

    Blueprint

    The approval matrix, role design and audit trail specification are signed before configuration starts. Where a requirement can genuinely be met by only one product, we write that down rather than dressing it as open.

  3. 03

    Build

    Configuration follows the signed design, with financial limits and approval routes held as parameters an authorised officer can change later. Increments are demonstrated on departmental cases rather than on a vendor's sample data.

  4. 04

    Test

    Acceptance runs on written cases drawn from your own files, with evidence recorded. Privilege and segregation testing sits beside it, because an auditor will want conflicting role combinations proved, not merely prohibited on paper.

  5. 05

    Go live

    A controlled release on an agreed date. Opening balances are reconciled and signed first, the audit trail records everything from the first transaction, and the rollback point is written into the cutover file.

  6. 06

    Run

    Support attaches to a post rather than a person, because individuals transfer. Change requests get costed and decided. Account and authority recertification starts in the first quarter, not when an audit asks for it.

Working together

Built for the officer who arrives three years from now

The measure of a public system is not the day it goes live. It is an ordinary Tuesday two or three years later, when an officer who took no part in the project needs to answer a question about a decision taken before they arrived, and the system answers it without anybody having to remember.

Everything described above serves that moment. The audit trail exists so the answer can be evidenced. The delegation model exists so the answer carries the authority it was made under. The documentation exists so the officer can find it without telephoning a supplier who may no longer hold the contract. None of this is difficult work. It is simply work that has to happen at the beginning, when it is cheap, rather than during an audit, when it is not.

SmartLink Services works with departments, authorities and public bodies on this kind of delivery, from requirement and tender documentation through implementation to a documented handover. Where the sensible answer is that you need a specification and a defensible evaluation process before you need a supplier, we are content to say so, and to do that piece properly.

Credentials

Compliance for public sector clients

Evaluation committees ask what a supplier is accredited to do and how it handles regulated data, so these are worded to go straight into a technical response.

Oracle

Partner

Oracle Database, E-Business Suite and Fusion Cloud work for departments and authorities, including standby, encryption, privilege review and the residency constraints your policy places on backups and logs.

Microsoft

Partner

Dynamics 365, SQL Server, Power BI and Azure, with identity tied to the departmental directory so a leaver loses access the day the human resources record changes.

Google

Partner

Google Cloud and Workspace delivery where residency policy permits it, with analytics on citizen facing services configured so published turnaround figures reconcile to the transactions underneath them.

FBR digital invoicing

Compliant integrations

Departments sit on the receiving side of digital invoicing more often than the issuing side. Where a public body makes taxable supplies, we build the integration; where it does not, we say so.

HIPAA

Compliant practices

Not central to most departmental systems, though occupational health and hospital records deserve the same treatment: role limited access, encryption, audit logging, and a business associate agreement where we genuinely act as one.

Client words

What public sector clients say

Comments from people running public sector systems day to day.

  • They wrote our requirement documentation knowing it had to survive a tender committee, and they were direct when one of our requirements could only be met by a single supplier. We would not have caught that ourselves. The audit trail design has since been through a full review without a finding.
    IT Director Public sector authority
  • What sold us was that they argued with our brief. We asked for a reporting layer and they came back saying the reporting was fine, the batch data underneath it was not, and fixing that first would cost less. That turned out to be right. Our first mock recall after go live took an afternoon instead of the better part of a week.
    Finance Director Food manufacturing group, Karachi
  • We had been through one failed implementation already, so we were sceptical of the whole category. The difference here was the migration work. Two full rehearsal loads before the real one, with a reconciliation pack we could check ourselves. Nobody had ever handed us evidence like that and asked us to sign it.
    Head of IT Wholesale distribution business
Questions

Questions about public sector systems

Market rates run PKR 800,000 to 1,500,000 for a single office covering purchase, stores and accounting, PKR 1,500,000 to 3,000,000 for five to seven modules with a mobile application, and PKR 3,000,000 upwards where several offices and central reporting are in scope. Subscription platforms are quoted around PKR 2,500 per user per month. Those are market ranges. Our figure follows discovery.

Reported timelines put a focused go live at six to twelve weeks and a large multi entity programme at nine to twelve months. Departmental work sits at the longer end because tender evaluation, clarification and award happen outside the delivery plan, and the financial year boundary gates budget release. We build the schedule backwards from that date.

Section 3(9A) of the Sales Tax Act applies to Tier-1 retailers and other notified persons. Where an authority makes taxable supplies through a canteen, guest house or commercial arm, the same integration work applies: invoice posted, invoice reference number and QR code returned and printed. Whether your activity falls inside that classification is a question for your own tax adviser.

We keep advisory work separate from any implementation bid, because a committee cannot defend an award to the firm that wrote the requirement around itself. Where we help draft a specification, we say plainly in the document if a requirement can genuinely be met by only one product, and we expect to be excluded from the resulting tender.

Wherever your policy says it must be. Residency is treated as a design constraint like any other, covering backups and logs as well as the live database, and we coordinate with whoever supplies the hosting. If an option we are asked to price would breach your policy, we put that in writing rather than leaving it for an auditor to find.

The system has to survive it. Decisions live in a signed blueprint rather than in one officer memory, support attaches to a post rather than a named individual, and handover documentation is written for the officer who arrives three years from now. Departments that skip this end up with a system only the supplier understands, which is a risk to the department.

Other sectors

The other sectors we work in.

The same practices, applied to the problems each sector actually has.

01 Food Manufacturing Batch traceability, shelf life and yield, joined up from goods in through to the despatch note. 02 Aluminum Alloy, coil and billet traceability with the costing detail that melting, extrusion and finishing actually need. 03 Retail Tills, stock and online joined to one set of numbers, with FBR digital invoicing where it applies. 04 Professional services Time, utilisation and project profitability made visible while a job can still be steered. 05 Wholesale Distribution Stock accuracy, route delivery and true landed cost across warehouses and vans. 06 Oil & Gas Asset heavy operations where maintenance, permits and contractor control carry real consequence. 07 Construction Project cost control, subcontractor certification and valuations that reconcile to the ledger. 08 Automotive Part traceability, supplier schedules and dealer systems joined to the plant. 09 Mining Production, grade, fleet availability and consumables measured where the cost is incurred. 10 Telecom High volume billing, provisioning and network asset data, joined without breaking the month end. 11 Textile Style, colour and size matrices, plus real costing across spinning, weaving, dyeing and stitching.
All industries

Working with public sector systems?

Tell us what you run today and where it breaks. The first conversation is a consultation, not a pitch.

Book a consultation All industries