Most ERP selections in Pakistan go wrong in the same way. A long feature comparison is built, three vendors demo against it, the one with the most ticks wins, and eighteen months later the business is running half the system and a parallel set of spreadsheets.

The feature list is not where the risk lives. Every serious ERP does general ledger, stock and sales. What separates them is how they handle the things specific to operating here, and whether the people selling it will still be answering the phone in year three.

Start with the close, not the feature list

The most useful question in an ERP evaluation is not "can it do X". It is "show me a month-end close". Ask the vendor to walk through a full period close on their demo data: posting, reconciliation, stock valuation, and out to a trial balance and financial statements.

This exposes more in twenty minutes than a feature matrix does in a month. You will see whether stock and finance genuinely share a ledger or are reconciled by a nightly job. You will see how many manual steps a close takes. And you will see whether the person demoing has ever actually closed a period.

What has to work locally

International ERPs handle Pakistani requirements with varying grace. These are the areas where "we can customise that" usually means a long and expensive project.

Sales tax and FBR digital invoicing
Built into the sales module, not a separate integration bought later. Ask to see an invoice submitted and verified during the demo.
Withholding tax
Applied at the right rates on the right transactions, with the certificates and statements that follow from it.
Multi-company groups
Common here, and often handled badly. Separate chart of accounts, stock and permissions, with the ability to switch companies without logging out.
Import landed cost
Duty, freight and clearing spread across a shipment so goods are valued correctly. Businesses that import and then cost at invoice value are mispricing everything downstream.
Multi-currency
With revaluation that finance can explain, not just a conversion at entry.

What implementation actually costs

The licence is rarely the expensive part. Budget for implementation at somewhere between one and three times the first year of licensing, depending on how clean your data is and how much process change is involved.

The costs people forget: cleaning master data before migration, which is almost always worse than expected; opening balances and stock positions; training, including the second round three months later when the first cohort has moved on; and the integrations to whatever you are keeping.

A vendor who quotes implementation without having seen your data is guessing, and the number will move.

Cloud, on-premise, or either

This matters less than it used to, but it still matters here. Connectivity at plants and remote sites is not always reliable, and some organisations have policy or contractual reasons to keep data in-house.

The practical answer is to choose software that genuinely runs both ways, rather than one that is cloud-only with an on-premise story bolted on. Ask directly whether any customers run it on their own servers today, and what the support arrangement looks like for them.

The questions that separate vendors

By this point most of the shortlist can do the job. These questions sort them.

Who will actually implement this?
The team in the room is frequently not the team on the project. Ask for names and whether they are employed or contracted.
What happens to our data if we leave?
A straight answer about export formats and database access. Evasion here is informative.
Show me a customer at our scale in our industry.
Not a logo slide — a reference call with someone who went live more than a year ago.
What does support cost and what does it cover?
Response windows in writing, and clarity on what counts as support versus billable work.
What was your last failed implementation?
Every vendor with real history has one. The ones who claim otherwise are either new or not being straight with you.

A sensible sequence

Go live in phases, with finance and stock first. They are the backbone, the data is the hardest to migrate, and everything else attaches to them. Manufacturing, projects, CRM and HR can follow once the core is stable.

Resist the big-bang cutover unless there is a compelling reason. The phased route takes longer on paper and is considerably faster in practice, because each phase teaches you something about the next.

Common questions

How long does an ERP implementation take in Pakistan?

A single-company rollout with clean opening data typically runs six to ten weeks for finance and stock. Multi-company groups and manufacturing take considerably longer. Any quote given before someone has looked at your data should be treated as provisional.

Should we pick an international ERP or a local one?

It depends on how much of your complexity is local. If FBR invoicing, withholding tax and import landed cost are central to how you operate, a system that handles them natively will cost far less than customising one that does not.

Can we run an ERP on our own servers?

Some vendors support it properly and some do not. Ask whether any existing customers do so today and what their support arrangement is — the answer separates real on-premise support from a brochure claim.

What is the most common reason ERP projects fail here?

Master data. Projects are planned around configuration and training, then lose months to item codes, customer records and opening balances that nobody had looked at closely. Audit your data before you sign anything.