SmartLink
ERP

ERP that survives the first month-end.

ERP implementation in Pakistan is usually bought twice: once as a licence, and again as the effort that makes the licence useful. SmartLink Services does the second part. We work from Karachi across SAP, Oracle, Microsoft Dynamics 365 and Odoo, on new implementations, stalled recoveries and the support arrangement that follows go live. What follows answers the questions buyers ask before scoping begins: what the work costs, how long it runs, which platform suits which kind of business, what FBR digital invoicing requires of the system, and whether to host it yourself or rent it. Every figure below is a published market range rather than our quotation.

Discuss this practice
Platforms
SAP · Oracle · Dynamics · Odoo
Model
Fixed-scope phases
Team
Functional and technical
Handover
Documented, always
Overview

Most ERP projects do not fail at go-live. They fail earlier.

By the time an ERP programme is visibly in trouble, the cause is usually months old. A blueprint that was never signed. A data migration treated as a task rather than a workstream. An interface that nobody owned. The go-live is simply where those decisions become visible to everyone at once.

We run ERP work to remove those specific failure points. The functional design is signed before anything is configured, so there is a document both sides are held to. Migration gets its own owners, its own mock cycles and a reconciliation that balances at row and value level. Interfaces are catalogued, specified and monitored rather than built point to point and forgotten.

That approach is slower to start and considerably faster to finish. It also means the questions an auditor asks after go-live have written answers, which matters more than most teams expect in the first year.

Scope

What ERP & core systems covers

Scope varies by platform and module, but the shape of the work is consistent across SAP, Oracle and mid-market implementations.

What the work covers

  • Fit-gap analysis against your current process, module by module
  • Functional blueprint signed off before any configuration begins
  • Configuration of finance, materials, sales, production and maintenance
  • Legacy data extraction, cleansing and load with reconciliation reports
  • Authorisation roles designed against segregation of duties rules
  • Integration testing, user acceptance testing and a rehearsed cutover

What you get at handover

  • Signed functional blueprint and configuration document
  • Data migration reconciliation pack
  • Role and authorisation matrix
  • Cutover checklist with a rollback point
  • Trained key users and end-user manuals

Typically involves

Discuss this practice
Services in this practice

Every ERP & core systems service

ERP

SAP implementation

S/4HANA and ECC projects run as blueprint, build, test and cutover, with your finance and plant teams involved throughout.

Open service page → ERP

Oracle ERP & EBS

Oracle E-Business Suite and Fusion Cloud implementation, upgrade and module extension.

Open service page → ERP

ERP consultation & selection

Independent assessment before you commit budget: process fit, licence cost and honest total cost of ownership.

Open service page → ERP

ERP data migration

Master and transactional data moved from legacy systems with reconciliation you can show an auditor.

Open service page → ERP

ERP integration & interfaces

ERP connected to banking, e-invoicing, tax portals, plant systems and third-party applications.

Open service page →
01

Drawing the scope boundary before anyone counts modules

Scope conversations usually open with a module list, because that is how licence quotations are structured. It is the wrong starting point. A module list says nothing about whether an order can be taken, priced, produced, delivered and invoiced without leaving the system, and that end to end path is what determines effort. We scope by process chain instead, then work backwards to the modules the chain implies. The list that emerges is often shorter than the one on the quotation, and occasionally longer in a place nobody expected.

Entity structure is the second dimension and it is routinely underestimated. Two legal entities in one country sharing a warehouse are a different problem to two in different countries with different tax treatment, statutory reporting and languages. Sites add a third dimension. Ask early how many plants, depots and sales offices will transact in the system during phase one, and how many are merely expected to follow later. The answer changes the design of almost everything above it, including the chart of accounts.

What gets excluded matters as much as what is included, so exclusions are written down with the same care. A deferred module, a report that stays in a spreadsheet for another year, an interface waiting on a counterparty who is not ready: each is recorded with a reason and a date to revisit. Teams that skip this spend the second half of the programme arguing about whether something was ever in scope. Written exclusions end that argument in a minute rather than a meeting.

  • Scope defined as end to end process chains rather than a licensed module list
  • Legal entity, country, currency and language count fixed before the chart of accounts is designed
  • Sites transacting in phase one separated from sites merely expected to follow
  • Exclusions written down with a reason and a date to revisit
  • One named person on your side who can approve a change of scope
02

The choices that cannot be undone once transactions exist

Chart of accounts design sits at the top of that list. It determines what can be reported without a spreadsheet for the next decade, and it is fixed before a single document is posted. Getting it wrong is not fatal, it is merely expensive, because changing account structure after two years of postings becomes a conversion project with its own testing and its own reconciliation. We run the design as a workshop with finance, internal audit and whoever prepares the statutory accounts, rather than accepting a copy of the previous structure.

Numbering conventions are the quiet version of the same problem. Material codes, customer and supplier numbers, document ranges, plant and storage location codes all end up printed on paper, quoted in correspondence, keyed into other systems and memorised by people. Once external parties use them they are effectively public. Decide whether codes carry meaning or are simply sequential, and decide it once. Intelligent codes always run out of room, usually about eighteen months after somebody promised the classification would never change.

Costing method and unit of measure belong in the same category. Standard against moving average changes what the plant sees and what appears in the accounts, and switching later is an accounting event rather than a configuration change. Base units cannot be altered once stock and history exist. We lay out the options and their consequences in plain terms, but the decision is signed by your finance leadership and confirmed with your auditors. We implement systems, and we are neither a tax adviser nor an audit firm.

  • Chart of accounts and controlling structure designed with finance and your statutory accounts preparer
  • Numbering conventions decided once, on the assumption that codes become public
  • Costing method and base units of measure settled before any stock is loaded
  • Fiscal calendar, period control and consolidation requirements confirmed with your auditors
  • A written record of each irreversible decision, the options rejected and who approved it
01

What ERP implementation costs in Pakistan

Typical market rates in Pakistan fall into three bands. A focused implementation covering inventory, sales and purchase at a single location runs PKR 800,000 to 1,500,000 and goes live in two to three months. A mid sized programme of five to seven modules with a mobile application sits at PKR 1,500,000 to 3,000,000 across three to four months. Multi location work with manufacturing and external integrations starts at PKR 3,000,000 and runs four to six months or longer. Where the platform is sold by subscription rather than licence, the market figure is around PKR 2,500 per user per month, which changes the shape of the spend without changing its size.

Modules are the line buyers price first. Published add on ranges put accounting and finance at PKR 200,000 to 400,000, HR and payroll at the same, manufacturing at PKR 300,000 to 600,000, multi location capability at PKR 200,000 to 500,000, and a mobile application at PKR 400,000 to 800,000. Adding FBR e-invoicing to a POS or ERP already in production is quoted at PKR 150,000 to 400,000. Users move the licence line. Sites move everything else, because a second plant means another round of testing, another set of key users to train and another cutover weekend, which is why a second site costs far more than a hundredth user.

Integrations and the condition of your data are where estimates come apart. An interface to a bank, a weighbridge or the tax portal is a small piece of code wrapped in a long agreement about what happens when it fails, and that agreement takes time from people who do not write code. Data is worse. We have opened supplier masters carrying three spellings of the same company, stock records that had not been counted against the shelf in two years, and opening balances that only tied out after an adjustment nobody could explain. Cleansing that is chargeable work, and it is work you would pay for eventually in any case. Treat every figure above as market pricing rather than as our quotation. Ours follows discovery, once the process chains, the site count and the true state of the data are on paper and agreed.

  • Licence or subscription, set by user count and edition
  • Configuration effort, set by process chains rather than by the module list
  • Data cleansing and migration, priced after the source systems have been profiled
  • Each integration costed with its failure handling, not only its happy path
  • Training, cutover and hypercare, which rise with site count rather than headcount
02

How long an ERP implementation takes

Publicly reported timelines for Pakistan group into three. A focused single company go live covering accounting, sales, purchasing and inventory is reported at six to twelve weeks. An SME implementation carrying more modules and a second site is reported at three to six months. Large programmes with manufacturing, several legal entities and real integration work are reported at nine to twelve months. FBR integration on its own is a six to twelve week piece of work when the system underneath it is already stable.

Three things stretch those numbers and the software is none of them. Scope that keeps moving is the first: a new report, an extra approval, a warehouse remembered in month two. Each one resets testing rather than adding to it. Dirty data is the second and the most common. If the material master needs a classification decision from a person nobody has appointed, the load cannot run, and every task behind it waits. Availability is the third. Key users are usually the busiest people in the building, and a plan that assumes two days a week from a production manager who has not been released from his day job will slip, predictably, in about week three.

One further effect is worth naming because it never appears on a plan. Elapsed time is mostly decision latency. Programmes rarely lose weeks to configuration; they lose them waiting for an answer about who owns pricing, or which entity the stock in the yard belongs to. We commit to a date in the signed blueprint rather than in the proposal, because a duration quoted before anyone has watched a real order move through your current process is guesswork wearing a suit.

  • Focused single company go live reported at six to twelve weeks
  • SME rollouts reported at three to six months, large enterprise at nine to twelve
  • FBR integration alone typically six to twelve weeks on a stable system
  • Scope changes reset the test cycle rather than extending it
  • Client effort agreed by name, role and days per week before the plan is baselined
03

Which platform fits: SAP, Oracle, Dynamics and Odoo

SAP is really two propositions here. S/4HANA and ECC suit manufacturers and groups with genuine statutory complexity: several legal entities, intercompany trade, costing that has to survive an audit. The functional depth is real and so is the discipline it demands, because SAP expects a process to be defined before it is configured. Where organisations struggle is the cost of change afterwards, and the thinness of the local skills market for some modules. SAP Business One is aimed at smaller companies and should not be judged by what the larger products do.

Oracle earns its place in finance heavy organisations. E-Business Suite is still widely run in Pakistan, particularly in utilities, telecoms and large distribution, and Fusion Cloud is where new Oracle work goes. Financial and procurement functionality is strong, and reporting over an Oracle database is a solved problem for most technical teams. It strains on timeline. Oracle implementations are rarely quick, the technical depth required is high, and organisations that treat the product as a finance package underestimate what the integration work will cost.

Microsoft Dynamics 365 fits the middle of the market. If your organisation already runs Microsoft 365, if finance lives in Excel and leadership wants Power BI, the fit is natural and the learning curve is shorter than the alternatives. Licensing runs per application, which is efficient when you need two modules and expensive when you need seven. The recurring failure is customisation drift. Dynamics makes extension easy, so extensions accumulate quietly, and three years later a routine upgrade turns into a project nobody budgeted for.

Odoo and ERPNext are where a good number of Pakistani SMEs should start, and where some larger ones later regret arriving. Entry cost is low, the module range is broad, and a distributor with straightforward processes can be live quickly. Depth is the limit. Discrete manufacturing, complex costing and multi entity consolidation are where both platforms strain, and heavy customisation makes version upgrades painful in a way that is easy to ignore in year one.

None of that decides anything by itself. Fit is a function of your process chains, your entity structure and how much change the organisation can absorb in a year. Two companies of the same size in the same industry regularly land on different answers, and both can be right. We write the shortlist with the runners up named and the reason each was set aside, and we do not resell licences, so the recommendation carries no margin either way.

  • SAP for statutory complexity, multi entity costing and audited manufacturing
  • Oracle for finance heavy organisations already committed to Oracle databases
  • Dynamics 365 for mid market organisations standardised on Microsoft
  • Odoo and ERPNext for SMEs with straightforward processes and a tight budget
  • A written shortlist naming the rejected options and the reason for each
04

FBR digital invoicing and sales tax compliance

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, so that sales are reported in real time rather than summarised later. Sales Tax General Order No. 17 of 2022 addressed Tier-1 retailer integration. The mechanics matter to whoever builds it: the system posts the invoice, FBR returns an invoice reference number and a QR code, and both have to be printed on the receipt the customer takes away.

Retail is not the only case. Distributors and manufacturers raising sales tax invoices meet the same requirement where they are notified, and the engineering is identical: a document posted to a government endpoint, a response stored against that document, and a printed output carrying what the response returned. Getting it wrong is expensive in a specific way. Non compliance can mean disallowance of a substantial share of input tax adjustment, currently sixty percent, which converts a systems problem into a cash problem inside one return cycle.

Connectivity is the part that gets demonstrated least. A counter in Karachi loses its link mid queue and the queue does not stop, so the integration has to keep selling and reconcile afterwards. We build it to hold documents locally, retry on a backoff, and stamp every one with a status a human can read: sent, acknowledged, failed, requeued. The failed queue needs a named owner and a screen that owner actually opens, because a silent failure found at month end becomes a reconciliation across thousands of receipts. Testing goes through the sandbox before anything touches production, and the receipt layout stays under version control, since the reference number and the QR code are the first things an inspector looks for.

One boundary, stated plainly. SmartLink implements and integrates. Whether your business falls within Tier-1, which supplies are taxable, which rate applies and how an unusual transaction should be treated are questions for your own tax adviser. We configure to their written instruction and record it in the design document, because the alternative is a systems house interpreting tax law on your behalf.

  • Section 3(9A) integration for Tier-1 retailers and other notified persons
  • Invoice reference number and QR code printed on the customer receipt
  • Local queue, retry and a failure screen with a named owner
  • Sandbox testing before production, with the receipt layout version controlled
  • Classification confirmed by your tax adviser, then configured to that instruction
05

Cloud or on premise

Cloud is the default now and for most Pakistani businesses it is the right default. You rent capacity instead of buying it, the vendor patches the platform, and recovery becomes a contractual matter rather than a second room full of hardware. The market subscription figure, around PKR 2,500 per user per month, is predictable and it never stops. Upgrades also arrive whether you are ready or not, which is a real loss of control and is precisely the trade the subscription buys.

On premise still wins in a few situations worth naming. Regulated organisations with a written policy against holding certain records outside their own estate. Plants where production cannot pause for an internet outage and a local server keeps recording through it. Organisations that already employ a capable database team, for whom running the platform is a marginal cost rather than a new department. Everyone else is usually buying control they will not exercise and an upgrade backlog they will not clear.

Connectivity deserves an honest look before the decision is taken. We have worked at a plant on the outskirts of Karachi with one fibre link and a generator sized for the line but not for the server room. Cloud ERP there needs a second circuit from a different provider, and the cost of that circuit belongs in the comparison rather than in a surprise invoice later. Hybrid arrangements, with the core in the cloud and a local node keeping the shop floor recording, are common and they double the number of things somebody has to monitor.

  • Cloud for predictable cost, vendor patching and contractual recovery
  • On premise for written data residency policy or an existing database team
  • A second internet circuit costed into any cloud decision at a plant
  • Upgrade timing surrendered to the vendor on cloud, owned by you on premise
  • Hybrid nodes only where production genuinely cannot pause
How we deliver

Delivering ERP & core systems

The six steps below run on every ERP engagement, whether the platform is SAP, Oracle, Dynamics or Odoo. What changes is depth, and how many legal entities and sites have to be carried through one cutover weekend.

  1. 01

    Discover

    We follow a real order, a real goods receipt and a real payment run from desk to ledger. What the procedure says and what people do rarely match, and that gap is the requirement.

  2. 02

    Blueprint

    The functional design fixes chart of accounts, entity structure, costing method and document numbering. Nothing here is easy to change once postings exist, so finance signs it before a consultant touches configuration.

  3. 03

    Build

    Configuration is done in a development client and travels one way to test. Key users see each process area demonstrated on their own material and customer records rather than on vendor sample data.

  4. 04

    Test

    Integration testing runs order to cash and procure to pay end to end, on migrated data. Then key users work written scripts, and every defect is logged with the screen, the document number and a severity.

  5. 05

    Go live

    A timed cutover sequence with named owners: final legacy postings, opening balance load, stock count, reconciliation, then the go decision at a stated hour. The rollback point is a restore that has been tested.

  6. 06

    Run

    Hypercare covers the first month-end close, which is where ERP problems actually surface. After that, a named key user group answers routine questions and changes are batched into a release cadence.

Working together

What you should own at the end of an ERP engagement

Ownership is the honest measure of whether an implementation went well. At handover you should hold a signed functional design that matches what is actually configured, a record of every irreversible decision and who took it, a reconciliation you can put in front of an auditor, and a support arrangement that does not assume our telephone number is permanently available.

Nothing in that list is exotic. Each item is produced during the work rather than assembled afterwards, which is the only way it stays accurate. The alternative remains common: a live system understood by three people, documented by a slide pack describing the plan rather than the result, and dependent on a supplier relationship that was never designed to end.

We work across SAP, Oracle, Dynamics and mid-market platforms, on new implementations, recoveries and long term support. Where the right answer is that your current system is capable and the real problem is process, data or training, we will say so, because being wrong in the other direction costs you far more than losing the work costs us.

Credentials

Accreditations behind ERP & core systems

ERP buyers ask two things before shortlisting: which platforms we are accredited to deliver on, and how the system will meet Pakistani tax reporting once it is live.

Oracle

Partner

Oracle E-Business Suite and Fusion Cloud implementation, module extension and release upgrades, with the database underneath sized, tuned and backed up by the same team rather than a separate supplier.

Microsoft

Partner

Dynamics 365 Finance and Supply Chain work, with SQL Server behind the mid-market implementations and Power BI reporting built on the same chart of accounts finance signed at blueprint.

Google

Partner

Google Cloud hosting for Odoo and ERPNext deployments where an on-premises server is not wanted, plus Workspace identity so ERP sign in uses the account staff already have.

FBR digital invoicing

Compliant integrations

Sales tax invoices raised in the ERP post to the FBR system as they are issued. The returned invoice reference number goes back onto the billing document and prints as a QR code.

HIPAA

Compliant practices

Where an ERP holds patient identifiers in billing or receivables, access is limited by role, the tables are encrypted, activity is logged, and we sign a business associate agreement.

Client words

What ERP & core systems clients say

Comments from people who run erp & core systems systems day to day.

  • 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
  • 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
Questions

ERP & core systems: the questions we are asked

Typical market rates run PKR 800,000 to 1,500,000 for a focused single site implementation, PKR 1,500,000 to 3,000,000 for five to seven modules with a mobile application, and PKR 3,000,000 upwards for multi location manufacturing with integrations. Subscription platforms are commonly quoted around PKR 2,500 per user per month. Those are market ranges rather than our price. Our figure comes after discovery, when scope and data condition are known.

Publicly 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 enterprise programme at nine to twelve months. FBR integration alone is usually six to twelve weeks. What stretches a plan is rarely the software: moving scope, unclean master data, and key users who were never released from their day jobs.

It depends on how the plant actually runs. Discrete manufacturing with costing that has to survive an audit points towards SAP or Oracle. A single site with straightforward routings is often well served by Dynamics 365 or Odoo at a fraction of the cost. We shortlist against your process chains, your entity structure and your appetite for change, then name the options we set aside and why.

Yes, and it is standard work now. The system posts the invoice to FBR, stores the invoice reference number and QR code that come back, and prints both on the receipt. Adding e-invoicing to a POS or ERP already in production is quoted in the market at PKR 150,000 to 400,000. We test in the sandbox before anything reaches production.

Cloud means renting the platform. The vendor patches it, recovery is contractual, and you pay per user every month for as long as you use it. On premise means owning the hardware, controlling when upgrades happen, and staffing the people who keep it running. Connectivity, written data policy and whether you already employ a database team usually settle the argument.

Yes. SAP S/4HANA, ECC and Business One are all implemented and supported here, and a number of large Pakistani manufacturers and groups run them. Availability is not the constraint. The local skills market for certain modules is thinner than in larger economies, and that affects both project staffing and what support costs in the years after go live.

Most current platforms ship mobile applications for approvals, stock enquiry, delivery confirmation and sales orders. Whether they suit your process is a separate question, and a purpose built application is quoted in the market at PKR 400,000 to 800,000. Warehouse scanning usually needs rugged devices rather than phones, which is a hardware decision we specify but do not supply.

Section 3(9A) of the Sales Tax Act applies to Tier-1 retailers and other notified persons, who must integrate with the FBR computerised system for real time reporting. Whether your business falls inside that classification is a question for your tax adviser rather than for us. Once they confirm it in writing, we build, test and support the integration to that instruction.

Thinking about ERP, or repairing one?

Tell us which platform you run, where the process breaks and when you need to be live. The first conversation is a consultation, not a pitch.

Book a consultation See all practices