SmartLink
Retail and commerce

Retail POS software in Pakistan: cost, timelines and FBR integration

Retail POS software in Pakistan is judged on two things the demonstration never shows: whether the tills keep selling when the line drops, and whether the day reconciles without somebody rekeying it. SmartLink Services works from Karachi on point of sale integration, stock, ecommerce and FBR digital invoicing for retailers running anything from a single shop to a branch estate across several cities. What follows is the commercial detail buyers ask for first: market rates in PKR, how long an estate rollout really takes, and exactly what section 3(9A) requires of the system before an inspector asks. Prices quoted here are published market ranges, not our quotation.

Channels
Store and online
Stock
One version
Compliance
FBR integration
Reporting
Daily, reconciled
Overview

One stock figure, one sales figure, whichever channel it came from

Most retail system problems are reconciliation problems wearing a different hat. The till says one thing, the stock system says another, the online store has sold something the warehouse has already picked, and finance spends the first week of the month deciding which source to believe.

The fix is unglamorous. Decide which system owns each number, make every other system read it rather than keep its own copy, and reconcile daily instead of monthly so a discrepancy is one day old when you find it.

For Tier-1 retailers in Pakistan there is a compliance layer on top. Point of sale must integrate with the Federal Board of Revenue computerised system so sales report in real time, with the FBR invoice number and verification QR code printed on the receipt. We build that integration to keep trading through connectivity drops, and to reconcile what was reported against what was taken.

The work

Where retail systems break

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

Where it usually hurts

  • Till, stock and online each holding a different version of the truth
  • Online orders sold against stock that has already been picked
  • Shrinkage discovered at stock count rather than tracked through the month
  • Promotions and discounts that cannot be reported on afterwards
  • Manual FBR reporting, or an integration that stops the tills when the line drops
  • Daily takings reconciled to the ledger by hand

What the work covers

  • Point of sale integration with stock, pricing and the ledger
  • FBR digital invoicing integration with offline queueing and retry
  • Online and store stock served from one inventory position
  • Promotion, discount and loyalty handling that stays reportable
  • Daily takings, banking and stock reconciliation
  • Store performance reporting by branch, hour and category

Typically involves

ERP POS systems Ecommerce integration
Discuss your systems
01

Where the daily reconciliation actually breaks

Reconciliation rarely fails on the sales figure. It fails on tender. Cash counted at the till, card settlements that reach the bank a day or two later, vouchers redeemed against a liability nobody has posted, cash collected by a delivery driver, and refunds issued in a tender that was never taken in the first place. Each of those has a different timing and a different owner. When the daily routine treats them as one lump, the gap between the till total and the bank statement becomes a monthly investigation rather than a five minute check.

The design that works is unremarkable. Every tender type gets its own control account and its own expected settlement date, so the system knows what should have arrived and when. Store banking is declared at the till rather than reconstructed later from the safe. Card settlement files are imported and matched automatically, with unmatched lines queued for a named person instead of being absorbed into suspense. Anything that cannot be matched is visible the next morning, attached to a store and a shift, while the people involved still remember the day.

Refunds and exchanges deserve separate attention, because that is where both error and loss concentrate. A refund with no link to an original transaction is an open door. So is an exchange processed as a zero value sale. Requiring the original receipt reference where it exists, capturing a reason code where it does not, and reporting refund activity by operator gives management something concrete to look at. Most of what surfaces is honest mistake. The point is that both kinds of problem appear in the same report.

  • One control account per tender type, with an expected settlement date
  • Card settlement files imported and matched overnight
  • Unmatched lines queued to a named person, never to suspense
  • Refunds tied to an original transaction reference or a reason code
  • Banking declared at the till rather than reconstructed from the safe
02

One stock pool

Sharing stock between store and website is easy to say and awkward to build, because the two channels disagree about the moment a unit stops being available. A shopper in store lifts it off the shelf and it is gone. An online order reserves it at basket, at payment capture, or at picking, depending on how the platform happened to be configured. Reserve too late and the same unit sells twice. Reserve too early and the site shows nothing available while stock sits on a shelf. The rule has to be chosen deliberately.

Once reservation is settled, the rest is arithmetic that should be exposed rather than hidden. Available to promise is physical stock less reservations less a channel buffer, and that buffer is a commercial decision about how much oversell risk the business will accept on each line. Fast moving lines with frequent replenishment can run thin. Long tail lines held in a single branch cannot. Making the buffer a maintained field rather than a constant buried in code is what lets a merchandising team tune it without raising a change request.

Click and collect breaks a lot of implementations, because it turns a store into a fulfilment point and a selling floor at the same time. The unit must be reserved against a specific branch, picked by staff who are also serving customers, and released back to sale automatically when the customer never arrives. That release timer is the detail everyone forgets. The symptom is a slowly growing pile of phantom reservations that quietly suppress online availability right across the estate.

  • Choose one reservation point and apply it to every channel
  • Available to promise calculated openly rather than inside the platform
  • Channel buffers maintained by merchandising, per line or category
  • Branch level reservation for collection orders, with an automatic release
  • Phantom reservation reporting so the pool cannot silently shrink
03

Shrinkage is a process problem before it is a theft problem

Shrinkage gets discussed as theft because theft is the interesting part. Across most estates the larger share is process. Goods received against a delivery note that nobody checked line by line. Units sold under the wrong barcode because two variants share a shelf edge label. Wastage put in the bin without being booked out. Returns taken over the counter and placed back on the shelf without ever re-entering stock. None of that is dishonest, and all of it produces exactly the same result at the count.

Separating the two starts with booking every movement, including the unattractive ones. A wastage transaction with a reason code. A goods receipt that records what was counted rather than what was ordered. A returns process that puts the unit into a quarantine location until somebody decides whether it goes back to sale. Once those exist, the residual difference at a count is far smaller and far more interesting, because it can no longer be waved away as paperwork that will catch up later.

Counting then becomes a management tool instead of an annual event. A handful of high value or high movement lines counted every week, on a rota nobody can predict, finds a problem within days of it starting. An annual count finds the same problem many months late, aggregated with everything else, and by then nobody can say which branch, which week or which line began it. The counting itself is cheap. The delay is the expensive part.

  • Every movement booked, including wastage, damage and staff purchase
  • Reason codes on write offs, short enough that they get used honestly
  • Returns held in quarantine until a decision is recorded
  • Rolling counts weighted by value and movement rather than an annual shutdown
  • Variance reported by branch, line and week, not as one estate figure
01

What retail systems cost in Pakistan

Retail spans the widest price range of any sector we work in, because a single shop and a fifty branch estate are different problems wearing the same word. Market pricing puts a focused implementation covering till, stock and purchasing at one location at PKR 800,000 to 1,500,000, live in two to three months. Five to seven modules with a mobile application sit at PKR 1,500,000 to 3,000,000 over three to four months, which is where most growing chains land. Multi location work with warehouse, ecommerce and integrations starts at PKR 3,000,000 and runs four to six months or longer.

Adding FBR e-invoicing to a point of sale or ERP already in production is quoted separately in the market at PKR 150,000 to 400,000, and that figure is worth isolating because a good number of retailers need only that piece. Module ranges elsewhere: accounting and finance PKR 200,000 to 400,000, human resources and payroll the same, multi location capability PKR 200,000 to 500,000, a mobile application PKR 400,000 to 800,000. Subscription platforms are commonly quoted around PKR 2,500 per user per month, and in retail the user count is a shift pattern rather than a headcount.

Branches move the number more than anything else. Every store adds hardware to commission, staff to train on their own busiest day, a stock take to run and a cutover to survive without closing the door. Trading hours make it worse: a shop open thirteen hours has a change window measured in minutes, not evenings. Then there is the price file, in most chains the dirtiest master data in the business, carrying promotions that ended two seasons ago and branch overrides nobody can explain. Cleansing it is chargeable work you would eventually pay for regardless. All of these are market figures. A real figure follows discovery, once branch count, till count and price file condition are known.

  • FBR e-invoicing added to an existing system, quoted at PKR 150,000 to 400,000
  • Branch count driving hardware commissioning, training, counts and cutover
  • Till positions counted by shift rather than by headcount for subscription
  • Price file and promotion history cleansed before go live
  • Ecommerce and stock integration priced with its failure behaviour
02

How long a retail rollout takes

Reported timelines give six to twelve weeks for a focused single site go live and three to six months for a chain taking more modules and a second location. FBR integration on its own is reported at six to twelve weeks where the system underneath it is already stable, which is the case for most retailers who come to us for that piece alone.

Trading peaks decide the rest of the calendar. No retailer in Pakistan will accept a systems change in the weeks before Eid, and the sensible planning assumption is that Ramadan and the fortnight either side of both Eids are closed to change. That leaves a smaller set of usable windows than a project plan usually assumes, and a slipped date does not move by a week, it moves by a season.

Estates go store by store for a reason. One branch runs first, long enough to see a full trading week including the Sunday rush and a delivery day, and only then does the pattern repeat. Each subsequent store is faster, but none of them is free, because the till staff learning the new screens are the same people serving a queue. We have never seen an estate benefit from going in one weekend, and we have twice been called in after somebody tried.

  • Focused single site go live reported at six to twelve weeks
  • FBR integration alone reported at six to twelve weeks on a stable system
  • Ramadan and both Eids treated as closed windows for change
  • First store run through a full trading week before the pattern repeats
  • Till training scheduled around queues rather than around the project plan
03

FBR digital invoicing for Tier-1 retailers

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 report in real time rather than being summarised afterwards. Sales Tax General Order No. 17 of 2022 addressed Tier-1 retailer integration. The mechanics are settled and every retailer should understand them before buying anything: the till posts the invoice, FBR returns an invoice reference number and a QR code, and both have to be printed on the receipt the customer walks out with.

Consequences are the reason this gets attention. 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 a single return cycle. That is a bigger number than the integration costs, and it is why retailers who have been running a manual workaround usually stop arguing about scope once it is explained.

Connectivity is where implementations fail and where demonstrations never go. 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 hold documents locally, retry on a backoff, and stamp every one with a status a supervisor can read: sent, acknowledged, failed, requeued. The failed queue needs a named owner and a screen that owner actually opens, because a silent failure discovered 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 is a Tier-1 retailer, which supplies are taxable and which rate applies 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 a client's 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, receipt layout under version control
  • Tier-1 classification confirmed by your tax adviser before configuration
How we deliver

Delivering in retail

Nothing in a retail rollout is allowed to close a till, so the sequence is built around trading hours and a pilot branch that is genuinely busy. Product and barcode cleansing comes first, and it is the least popular part.

  1. 01

    Discover

    Two or three days behind the tills, in the stockroom and with whoever counts the safe. We follow a sale from the drawer to the ledger, and watch how yesterday's takings are actually reconciled.

  2. 02

    Blueprint

    Ownership of each number is settled: which system holds stock, which holds price, where a unit is reserved for an online order. Tender control accounts, buffers and the FBR receipt layout are specified here.

  3. 03

    Build

    Till integration, pricing, stock and ledger posting are built into a service layer the point of sale calls, so replacing a till later does not become a compliance project. FBR sandbox scenarios are worked through.

  4. 04

    Test

    Cashiers test on a real lane at peak, not in a training room. We pull the network cable to prove queued sales keep the drawer opening, then reconcile a full trading day against what reached FBR.

  5. 05

    Go live

    Stores switch overnight, in waves, and no till stops trading. One branch pilots first through a count, a promotion and a month end; pilot staff then stand beside the next wave on their opening morning.

  6. 06

    Run

    Queue depth on the FBR feed is monitored with an alert rather than checked by eye. Daily reconciliation is meant to take minutes. Where old reporting still runs, we agree the date it is switched off.

Working together

What the software will not do for you

A system will not stop shrinkage. It will show you where the difference arises, how quickly it grew, and which branch and which lines are involved, and then a person has to go and look. The same applies to promotions, refunds and price overrides. Every one of those reports is a prompt for a conversation, and the value is created in the conversation rather than in the report. Retailers who treat the reporting as the outcome tend to end up with well presented numbers and unchanged results.

Nor will it survive a daily routine that is skipped. Reconciliation, counts and exception queues are small tasks that stay small only when done every day, and the first sign of trouble is always a queue that has been left for a week. We build the routine to take minutes and to be obvious when it has not been done, because a control nobody performs is worse than no control at all: it creates confidence without producing evidence.

What we hand over is a set of numbers with a stated owner, an integration that keeps trading when the line drops, and reporting your own team can extend. The parts we cannot hand over are the discipline at the shelf edge and the willingness to act on what the reports say. Those stay with the business, and the businesses that keep them are the ones for which any of this becomes worth the money.

Credentials

Compliance for retail clients

Two questions come up in every retail conversation: what we are accredited to deliver, and how the till talks to the Federal Board of Revenue.

Client words

What retail clients say

Comments from people running retail systems day to day.

  • Our first concern with FBR integration was simple: what happens to the tills when the line drops. They built the queueing and retry before anything else and demonstrated it by pulling the connection in front of us. Trading carried on, and the invoices went up when the link came back.
    Operations Manager Retail chain, Pakistan
  • 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
  • Every vendor we spoke to said they could handle style, colour and size. This team asked to see our order book first, then told us which of the shortlisted platforms would need thousands of item codes to do it. That one piece of advice probably saved us a year.
    General Manager Textile exporter
Questions

Questions about retail systems

Market rates run PKR 800,000 to 1,500,000 for a single location covering till, stock and purchasing, PKR 1,500,000 to 3,000,000 for a growing chain with five to seven modules, and PKR 3,000,000 upwards for multi location work with ecommerce. Adding FBR e-invoicing to an existing system is quoted at PKR 150,000 to 400,000. Those are market ranges rather than our price, and our figure follows discovery.

Reported timelines put a focused single site go live at six to twelve weeks and a chain at three to six months, with FBR integration alone at six to twelve weeks. Trading peaks compress the calendar: Ramadan and the fortnight around both Eids are closed to change, so a slipped date moves by a season rather than a week.

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

Selling continues. Documents queue locally, retry on a backoff and carry a status a supervisor can read, then reconcile when the link returns. What matters afterwards is that the failed queue has a named owner and a screen that owner opens daily, because a silent failure found at month end becomes a reconciliation across thousands of receipts.

Usually yes, and it is often the cheaper answer. If the till software exposes a workable interface, we integrate it to stock, pricing and the ledger and add the FBR piece around it. Replacement becomes the better option when the product is unsupported, or when every small change needs a vendor who no longer answers the phone.

Non compliance can mean disallowance of a substantial share of input tax adjustment, currently sixty percent, which lands as cash rather than as correspondence and does so within one return cycle. How that applies to your specific position is a question for your tax adviser. We build the integration so the question does not arise.

Working with retail systems?

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