ERP integration and interfaces in Pakistan

What ERP integration costs in Pakistan

One integration has a published market range in Pakistan and it is the useful anchor. Adding FBR e-invoicing to a POS or ERP already in production is quoted at PKR 150,000 to 400,000, a spread of nearly three times for what sounds like one job. Everything else is priced against effort, and market hourly rates for full stack development here run PKR 3,500 to 8,000. Where integration is bought inside an implementation it disappears into the programme bands of PKR 800,000 to 1,500,000 and upwards.

What separates a cheap interface from an expensive one is rarely the message. It is the far end. An API with documentation, a sandbox and a support contact is a small job. A partner system with no API, where the exchange is a file dropped on a server at a fixed hour, is larger, and the cost sits in what happens when that file is late, malformed or delivered twice. Bank formats deserve their own line, because each bank has its own layout, layouts change without warning, and testing a payment file involves a bank with no interest in your project plan.

Three items are routinely left out of comparisons and all three are where the money goes later. Error handling with a retry policy and a dead letter path. Monitoring that counts business documents rather than technical messages, so somebody can answer whether all of yesterday's invoices arrived. And a versioned specification, since an interface is a contract between two teams who will never meet. Price those in and a quotation looks higher; leave them out and the first failure at two in the morning costs more than the saving. Our figure follows discovery, once the flow inventory and the far end capability are known.

• Priced per flow, with the far end capability assessed before anything is quoted
• Bank payment and statement formats costed individually, since each bank differs
• Error handling, retry policy and dead letter treatment included rather than added later
• Monitoring that counts business documents, not only technical messages
• A versioned specification per interface, treated as a deliverable in its own right

How long an ERP interface takes to build

Regulatory integration gives the clearest reported figure: FBR digital invoicing is a six to twelve week piece of work when the system underneath it is already stable. That number is a good rule of thumb for any interface of similar shape, because the build is a small share of it. Specification, sandbox access, test data, two rounds of failure handling and a reconciliation take the rest, and none of them can be compressed by writing the code faster.

Dependency on the far end sets the true duration. Your team can be ready in a fortnight and still wait a month for credentials, a test endpoint or an answer about what the response codes mean. Bank interfaces are the classic case, since a test file has to be accepted by a bank operating to its own calendar. We ask for the far end contact by name at the start of the work and record what has been requested and when, because interface delays are almost always a queue somewhere else.

Taking over an interface somebody else built is a different shape of job. The first task is establishing what it actually does, which is regularly not what the documentation says, and adding monitoring before changing behaviour. That sequence is deliberate. Changing an undocumented interface first and observing it afterwards is how a quiet failure becomes a reconciliation across several months of documents.

• FBR digital invoicing reported at six to twelve weeks on a stable system
• Far end dependencies named and tracked from the first week rather than chased later
• Sandbox testing completed before anything is pointed at production
• Monitoring added before behaviour is changed on any inherited interface
• Test evidence per flow retained, including the failure cases rather than only the successes

Point to point interfaces or an integration layer

Point to point means each system talks directly to each other system. It is quick, cheap on the first interface, and what almost every organisation has. The arithmetic is what turns against you. Two systems need one connection. Five systems that all talk to each other need ten, and every one has its own credentials, its own error handling and its own person who understood it. Replace one system and you rebuild every connection it touched.

An integration layer, whether that is a message broker, an integration platform or a modest internal service, puts one hub in the middle. Each system connects once. Message formats are translated in one place, retries and dead letter handling are implemented once rather than five times, and monitoring is a single screen instead of five log files in five formats. The cost is real: a platform to licence or host, a skill your team may not have, and a component that is now on the critical path for everything.

Judge it on flow count, change rate and who runs it afterwards. Under about half a dozen stable flows, point to point built properly, with logging and retries, is usually right and a hub is over engineering. Where flows keep arriving, where the same customer record is pushed to three places, or where a system replacement is already on the roadmap, the hub pays for itself in the second year. The question that settles it is who operates the thing at two in the morning. A layer nobody has been trained to support is worse than the tangle it replaced, because now there is one component whose failure stops everything at once.

Whichever way it goes, the discipline is the same: an interface catalogue with a named owner per flow, a versioned specification, retry and dead letter behaviour agreed in advance, and a dashboard that counts documents. We build both patterns, and we say plainly when a client is being sold a platform for four interfaces.

• Point to point for a small number of stable flows, built with logging and retries from the start
• An integration layer where flow count keeps rising or a system replacement is planned
• Connection count growth counted honestly before the pattern is chosen
• Operational ownership settled before a hub is introduced, including out of hours
• An interface catalogue with a named owner per flow, whichever pattern is used