SmartLink
ERP

Oracle ERP implementation in Pakistan: E-Business Suite and Fusion Cloud

Oracle ERP implementation in Pakistan usually means one of three jobs: a fresh Fusion Cloud rollout, an E-Business Suite estate extended for a decade, or a programme that reached financials and then stopped. SmartLink Services takes on all three from Karachi, across General Ledger, Payables, Receivables, Inventory, Purchasing, Order Management and HRMS. What follows is the commercial detail that normally arrives late: market rates for the effort, how long an implementation or an upgrade actually runs here, and how to weigh staying on E-Business Suite against moving to Fusion Cloud. We resell no Oracle licences, so the assessment carries no margin.

Scope
Implement \u00b7 upgrade \u00b7 extend
Modules
GL, AP, AR, INV, PO, OM, HRMS
Environments
Dev \u00b7 test \u00b7 production
Overview

Oracle work, including the implementations nobody finished.

A large share of Oracle ERP work is not greenfield. It is picking up an E-Business Suite estate that has been extended for a decade, or a Fusion Cloud rollout that covered finance and then stopped before supply chain.

We work across both. That means module implementation, version upgrades, cloud migration assessment, and the less glamorous task of cataloguing every custom form, report and workflow so you know what will break when you move. Customisations are where upgrade budgets disappear, and an accurate inventory is the difference between a planned upgrade and a discovered one.

Where the problem is period close rather than functionality, the work looks different again: reconciliation clean-up, concurrent manager review and performance tuning aimed at the specific steps that make close take longer than it should.

Scope

What Oracle ERP & EBS covers

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

What the work covers

  • Module implementation across financials, supply chain and HR
  • EBS version upgrades and Fusion Cloud migration assessment
  • Custom reports, forms and workflow extensions
  • Chart of accounts and flexfield design
  • Period-close acceleration and reconciliation clean-up
  • Concurrent manager and performance review

What you get at handover

  • Setup documents per module
  • Upgrade or migration runbook
  • Custom object inventory with source
  • Period-close calendar and checklist
  • Support handover to your finance IT team

Typically involves

PL/SQL BI Publisher
Discuss this service
01

A chart of accounts designed for a company that no longer exists

Most established E-Business Suite estates carry an accounting flexfield designed a decade or more ago, for an organisation that has since bought, sold or restructured most of what the segments describe. There is a segment for a division that was disposed of, a segment reserved for future use that never found one, and a natural account range that ran out and got extended into whatever values were free. Reporting still works, because three people know all of the exceptions.

Two routes exist and they cost very different amounts. The cheaper route leaves the structure alone and fixes the reporting: hierarchies and parent values that give the group the view it needs, cross validation rules that stop new bad combinations being created, and security rules that keep users inside their own part of the tree. The expensive route restructures, which means remapping history, revisiting every report, allocation, interface and custom form, and agreeing a comparative basis with the auditors before anything moves.

Deciding between them should follow evidence rather than preference. Count the manual reclassification journals raised each month, ask how many reports are built by exporting to a spreadsheet and rearranging columns, and check whether the problem is presentation or control. Presentation problems are usually cheaper to solve in a reporting layer. Control problems, where wrong combinations keep being posted, need the rules tightened at source. Restructuring the flexfield itself is a project in its own right and should never be a workstream inside something else.

  • Cross validation rules added so new invalid combinations cannot be created, whatever history holds
  • Reporting hierarchies and parent values used before any structural change is considered
  • Manual reclassification journals counted monthly as evidence of how bad the problem really is
  • Value set maintenance given a named owner and a request route, rather than open access
  • Any flexfield restructure scoped as a separate project with its own auditor agreement
02

Telling an extension apart from a liability

Customisations are not equivalent to one another and treating them as one category makes upgrade planning useless. Form personalisations are light and usually survive. Custom schemas that read standard tables are manageable. Custom concurrent programmes are fine when they use supported interfaces. Direct data manipulation into standard tables is the liability, because it bypasses validation and the accounting logic that sits behind the screens, and an upgrade will break it in ways that are not obvious for weeks.

Inventory work has to record more than a name. Source, owner, purpose, and the date it last actually executed. That final column is the useful one. Estates routinely contain custom programmes that have not run in years, kept because nobody was willing to be the person who deleted something. Where a custom object writes data, check whether a public interface exists for the same job, keep custom objects in their own schema under a registered application, and stop anything being created inside the standard product schema.

There is a category that never appears in any inventory: the script an administrator runs by hand every month, saved on a laptop, known to two people. Those get found by asking what happens at close rather than by reading code. Promote them into supported objects or retire the need for them. One honest limit belongs here. Some customisations cannot be reproduced in standard functionality at any sensible cost, and pretending otherwise is how upgrades fail late, at the point where reversing course is most expensive.

  • Custom objects classified by risk, with direct table manipulation treated as the highest
  • Last execution date recorded for every custom object, so dead code can be retired with confidence
  • Custom code held in its own schema under a registered application, never inside the product schema
  • Manual scripts run by administrators discovered by interview and brought under control
  • Objects with no standard equivalent identified early, and costed, rather than assumed replaceable
01

What Oracle ERP work costs in Pakistan

Market ranges for ERP implementation in Pakistan sit in three bands: PKR 800,000 to 1,500,000 for a focused single site scope, 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 work with manufacturing and integrations. Oracle programmes land in the top band with some regularity, because organisations that choose Oracle usually have the entity structure and volume that put them there. Module add ons are published separately: accounting and finance at PKR 200,000 to 400,000, multi location capability at PKR 200,000 to 500,000, a mobile application at PKR 400,000 to 800,000.

Customisation is the line that separates an Oracle estimate from a generic ERP estimate. Every custom form, report, workflow and concurrent programme has to be inventoried and either carried forward, rebuilt or retired. Until that inventory exists, a number for an upgrade is arithmetic performed on hope. Chart of accounts and flexfield design is the second cost driver, particularly where the structure was built for a group that has since bought or sold something. Environment count is the third and it is routinely forgotten. Development, test and production each need refreshing, patching and space, and a training environment is a decision with an invoice attached.

Upgrades and extensions price differently. Where the work is module extension, period close clean up or report development, market hourly rates for full stack development in Pakistan run PKR 3,500 to 8,000, with senior specialist work at the top of that range. Junior work is published at PKR 500 to 1,000 an hour, a reminder that an hourly rate alone tells you little. None of these figures is our quotation. A real number follows discovery, once the module list, the custom object inventory and the environment plan are written down.

  • Module scope across financials, supply chain and HRMS, counted per module rather than per suite
  • A custom form, report, workflow and concurrent programme inventory built before anything is priced
  • Chart of accounts and flexfield redesign treated as its own piece of work
  • Environment count, refresh frequency and patching effort included in the estimate
  • Extension and clean up work quoted against hourly market rates rather than as a programme
02

How long an Oracle ERP project takes

Reported timelines for Pakistan put an SME rollout at three to six months and a large enterprise programme at nine to twelve. Oracle work sits in the second group more often than the first, and the reason is structural rather than technical. Organisations running Oracle tend to have several ledgers, statutory reporting in more than one form and a period close that already takes longer than anyone admits. A module extension onto a healthy estate is a different size of job and can finish inside a quarter.

Upgrades follow their own rhythm. The remediation of custom objects usually takes longer than the technical upgrade itself, and it cannot be compressed by adding people, because each object needs a decision from somebody who knows why it was written. Testing then has to cover the concurrent programme schedule, which is where a surprising number of upgrade defects surface, since nothing exercises a nightly job like a nightly run against real volume.

Period close sets the true end date. An Oracle implementation is not finished at go live, it is finished after a close that completed inside the agreed calendar without manual journals raised purely to force a reconciliation. Plan for two of those. We set hypercare exit as evidence rather than as an elapsed number of weeks, and we say plainly when a date is not achievable rather than renegotiating in month eight.

  • SME rollouts reported at three to six months, large enterprise programmes at nine to twelve
  • Custom object remediation as the long pole in any E-Business Suite upgrade
  • Concurrent programme testing run against production like volume rather than sample data
  • Two period closes planned before the project is treated as complete
  • Hypercare exit stated as measurable criteria rather than a fixed number of weeks
03

Staying on E-Business Suite or moving to Fusion Cloud

This is the decision every Oracle customer in Pakistan is being asked to take, usually by somebody with an interest in the answer. Start from a plain fact: E-Business Suite still runs a great deal of serious work here, in utilities, telecoms and large distribution, and a healthy R12 estate that closes on time is not an emergency. The pressure to move is real, but it is a planning horizon rather than a fire, and treating it as a fire produces the worst version of the project.

Fusion Cloud is a re-implementation rather than an upgrade, and the sooner that is said out loud the better the plan gets. Configuration does not lift across, customisations largely do not survive, and the operating model changes: quarterly updates arrive on Oracle's schedule, regression testing becomes a routine rather than an event, and the internal team stops patching servers and starts managing releases. Some organisations gain from that trade and some lose control they genuinely need. Financial and procurement functionality in Fusion is strong. Where local extensions carry statutory or industry logic, the rebuild cost belongs in the comparison rather than in a later change request.

What tips the balance in practice is usually the custom estate and the internal team. Where hundreds of forms, reports and workflows encode two decades of undocumented process, a phased path makes more sense: retire what nothing calls, rebuild what earns its place, and move in tranches with finance leading. Where the estate is thin and the technical team is already stretched, the argument for cloud is much stronger, because the running cost is being paid in people either way. We write the recommendation with a five year cost model behind it, and we name what we rejected.

  • A healthy E-Business Suite estate that closes on time is not by itself a reason to move
  • Fusion Cloud treated as a re-implementation, with the rebuild of extensions costed
  • Quarterly update testing accepted as a permanent routine rather than a project task
  • Custom objects retired, rebuilt or carried, decided object by object before committing
  • A five year cost model covering licence, infrastructure, people and regression testing
How we deliver

Delivering Oracle ERP & EBS

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

Oracle estates reward accurate inventories

Nearly every difficult Oracle conversation traces back to the same shortage, which is not skill or budget but an accurate picture of what is actually installed and what it does. Upgrades overrun because customisations were discovered rather than catalogued. Closes drag because a monthly manual step was never written down. Migration business cases prove wrong because internal effort was left out. None of these is a technology problem, and all of them are cheaper to fix before the decision than after it.

SmartLink Services works with E-Business Suite and Fusion Cloud estates in whatever state they are in, including the ones nobody wants to describe out loud. We start by writing down what exists, then we recommend on the evidence, and where the honest recommendation is to stay where you are for another two years and fix the close instead, that is what we will tell you.

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.

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

Questions about Oracle ERP & EBS

Market ranges for ERP implementation run PKR 800,000 to 1,500,000 for a focused scope, PKR 1,500,000 to 3,000,000 for five to seven modules and PKR 3,000,000 upwards for multi location work with integrations. Oracle programmes usually sit in the top band, because the organisations that run Oracle tend to have the entity structure that puts them there. Extension and clean up work is quoted against hourly market rates of PKR 3,500 to 8,000. Our figure follows discovery.

Reported timelines put an SME rollout at three to six months and a large enterprise programme at nine to twelve months. A module extension onto a healthy estate can finish inside a quarter. On upgrades the custom object remediation, not the technical upgrade, is the long pole, and testing the concurrent programme schedule against real volume adds time nobody plans for.

E-Business Suite is the older on premise suite, run on infrastructure you own and extended over many years with custom forms, reports and workflows. Fusion Cloud is the current Oracle cloud product, updated on a quarterly vendor schedule and configured rather than customised. A well maintained R12 estate that closes on time is not an emergency, but the support horizon deserves a written plan.

Treat the move as a re-implementation rather than an upgrade, because configuration does not lift across and most customisations do not survive. Run the custom object analysis first: how many exist, how many touch core posting logic, how many were executed even once last year. A thin custom estate argues for cloud. Hundreds of encoded process rules argue for a phased path.

Yes. The requirement is the same as anywhere else: post the invoice to the FBR endpoint, store the invoice reference number and QR code that come back, and print both. Market pricing for adding e-invoicing to an existing system runs PKR 150,000 to 400,000. Whether your business is notified is a matter for your tax adviser.

On E-Business Suite, yes, and organisations that quietly stop funding the role usually find out during a patch or a restore. Backups, cloning, patching and performance work do not disappear. On Fusion Cloud the role changes rather than vanishing, moving towards release testing, security administration and integration monitoring. Either way somebody has to own it by name.

Running Oracle EBS or Fusion?

Tell us what you run today and where oracle erp & ebs is causing you trouble. The first conversation is a consultation rather than a pitch.