As of the FBR's own integration figures published on 31 July 2026, 13,586 businesses are integrated with the point of sale system across 37,378 branches. Tier-1 retailers account for 11,900 of them, spread over 24,871 branches. Textile and leather adds 560 businesses across 10,747 branches, restaurants 1,126 across 1,760. Put those numbers next to the number of retail businesses operating in Pakistan and the picture is clear enough. Integration is still the exception, and most owners are working out what it means for them somewhere between a rumour from another shopkeeper and a message from their accountant. This is the software side of that question, written by someone who runs a retail counter as well as an agency. Where it touches your tax position, take it to your tax advisor rather than to me. What follows is about the systems.
What is FBR POS integration in plain terms?
It is a live link between your billing software and the FBR, so every invoice you print is reported as it happens and carries an FBR invoice number and a verifiable QR code. The customer's receipt changes. Instead of a slip from your own till, they get an invoice they can scan and check against the FBR's records. On your side, the sale leaves your system twice at the moment it is rung up: once to your own database, once to the FBR endpoint. That second part is where most of the practical difficulty sits, and it has almost nothing to do with tax.
Who has to integrate?
The obligation attaches to defined categories, chiefly Tier-1 retailers, along with restaurants and specified sectors such as textile and leather outlets. The definition of a Tier-1 retailer has moved more than once, and the thresholds and conditions that place a shop inside it are exactly the kind of thing that changes between one finance act and the next. So the honest answer to "does this apply to me" is that your tax advisor should confirm your category against the current law, in writing, before you buy any software. I have watched businesses spend on a system for a requirement that did not apply to them, and businesses ignore one that did. What I can tell you is what integration costs you operationally once the answer is yes.
What actually breaks during POS integration?
The internet connection, and nobody plans for it. Every invoice has to reach the FBR in real time. Your shop's connection does not have a service level agreement. When it drops at 6pm on a Saturday with eight people at the counter, a badly built integration stops printing invoices and you stop selling. A properly built one queues the invoice locally, prints, and pushes to the FBR when the line comes back. Ask any vendor this single question before you pay them: what happens to a sale when the internet is down? If they have not thought about it, they have not built this before. The next three, in the order they usually bite:
- Your product data. Integration wants clean item codes, consistent units and correct tax rates per item. Most shops have a register where the same product appears three times under three spellings. That cleanup is the real project, and it is unglamorous work that no software does for you.
- Returns and cancellations. A reported invoice cannot be quietly torn up. Your counter staff need a process for the customer who changes their mind, and it needs to exist before day one, not after the first argument.
- Staff habit. If someone at the till has spent nine years writing sales in a copy and entering them later, the change is not the software. It is that the sale must now be entered before the customer walks out. That is a management problem wearing a technology costume.
Should I buy an off-the-shelf POS or build one?
Buy, unless your operation has something in it that no packaged system handles. That is the honest default and it costs me work to say it. There are approved solutions on the market that handle the FBR link, and for a single-branch shop selling ordinary retail lines, paying for one is cheaper and faster than anything I could build for you. Buy it, spend the saved money on cleaning your product data, and get on with trading. Building is worth considering when the shape of your business fights the package. Multiple branches with stock moving between them and one owner who needs a single live view. Trade credit with named parties, part payments and running balances, which is how much of the Pakistani wholesale trade genuinely operates and which most retail packages handle badly or not at all. Items sold in one unit and bought in another. A pricing structure that changes by customer. I went through that decision at length, with what each option really costs, in this comparison of Busy, Tally, QuickBooks and going custom. The reasoning there applies directly to this choice.
What does integration give the business, beyond compliance?
A per-item record of every sale, in real time. Which, if you use it, is worth more than the compliance is costing you. Most shops that have never run a proper POS cannot answer basic questions about their own trade. Which twenty items produced most of last month's margin. Which lines have not moved since March. Which hours of which days are actually busy. What the average basket looks like on a weekday against a Sunday. Once every invoice is itemised, all of that is sitting in your database whether you look at it or not. The dead stock question in particular is where I have seen the most money quietly parked in Rawalpindi shops, and it is the first report I would build for anyone finishing an integration. I wrote about finding it in this piece on dead stock and what it costs to keep. The other half of this is payments. If invoices are now being reported in real time while your takings still arrive across cash, wallet and card with no method recorded against the sale, you have fixed one record and left the other broken. That side is covered in the piece on digital payments and what happens when the back office does not keep up.
How long does it take?
The FBR link itself is days. The data cleanup and the staff change are weeks, and they are the whole job. Any vendor promising a single-branch shop full integration inside a week is describing the software installation and quietly leaving out the part where somebody sits down with your item list and fixes nine years of inconsistent entries. That work does not disappear because it was not in the quote. It just lands on you after the invoice is paid.
What to do before you spend anything
- One. Get your tax advisor to confirm in writing whether you fall in a category that must integrate, under the law as it stands now.
- Two. Export your product list. Count how many duplicates and inconsistent units are in it. That number tells you the size of the real project.
- Three. Ask every vendor what happens to a sale when the internet drops, and what a return looks like on a reported invoice.
- Four. Decide who at the counter owns entering sales at the moment they happen. Without that person, no system works.
Related reading
- Why I argue against the expensive option more often than for it: nine years in electrical trading and what it taught me about software.
- The buy-or-build question in more detail, package by package: Busy, Tally, QuickBooks or custom.
- The payments half of the same counter: what the 92% digital payments figure means for a small shop.
If you want a second opinion before you buy
Send me what a vendor has quoted you and tell me how your shop trades: branches, whether you sell on credit, how many items, how the day gets closed. I will tell you whether the quote fits the business, and if the right answer is an off-the-shelf package rather than anything I would build, I will say so. Free consultation at devsioservices.com/contact. The POS and billing work is described at devsioservices.com/services/pos-software-development.
