Electronic invoicing arrives in a country in a predictable order. First large taxpayers in a few sectors, then a widening list of notified categories, then everyone who issues an invoice to a business or a consumer at any scale worth collecting from. Pakistan is partway through that sequence, and the categories being named have moved well beyond manufacturing into ordinary consumer-facing businesses: restaurants, hotels, courier services, salons, private education, retailers, healthcare providers.
If your sector has not been named yet, that is a schedule, not an exemption. And the useful thing about being later in the sequence is that you can watch what goes wrong for everyone else.
What goes wrong is almost never the software. Integrating with a tax portal is a solved problem and a vendor will sell you the connector. What goes wrong is the data being asked to travel through it.
One standing note. No dates, thresholds, sector lists or technical specifications appear below, because that is exactly what is being revised. The Federal Board of Revenue publishes the notified categories, the timelines and the technical requirements, and that is the only source worth relying on. Confirm your own position there and with your tax adviser.
The short version
- The blocker is data quality, not integration. Buyer identifiers, product codes, tax rates per line and invoice numbering all have to be correct before anything can be transmitted.
- Every invoice becomes a filing. You lose the month-end window in which errors were quietly corrected, so mistakes surface immediately and publicly.
- Your customers' registration status becomes your problem. You cannot issue a compliant invoice against a buyer whose details you never collected.
- Start with a data audit, not a software purchase. A vendor demo will not tell you that a third of your customer records are unusable.
- The businesses that handle this well treat it as a records project. The ones that struggle treat it as an IT project.
Why does the software never turn out to be the problem?
Because transmitting an invoice is mechanical. Producing a valid one is not. A compliant electronic invoice typically needs, on every line: a correctly identified buyer, a product or service code from a prescribed classification, a unit of measure, the applicable tax rate for that specific line, and an invoice number from an unbroken sequence.
Now compare that to how invoices are actually produced in a typical Pakistani SME. The customer is recorded as a name and a phone number. Products are described in free text that varies between staff members. Tax is applied at the invoice level rather than the line level. Invoice numbers restart per branch, or per book, or when someone starts a new file.
None of this is unusual and none of it matters while invoices are summarised monthly. All of it becomes blocking the moment each invoice must validate on its own before it can be issued.
The readiness audit: six questions
Run these against your last three months of invoices. The answers tell you how much work you have, and they take an afternoon.
1. Can you identify every business customer properly? Pull your invoices to registered businesses and count how many carry a complete, correct tax registration identifier. If the answer is most of them, you are in good shape. If the answer is a surprise, that is your biggest task, because it requires contacting customers.
2. Is every product and service coded? Not described. Coded, against a fixed internal list that maps to the prescribed classification. Free-text descriptions cannot be validated, and "as per order" is not a product.
3. Is tax applied per line or per invoice? If a single invoice can contain items at different rates and your system applies one rate to the total, that is a structural change to how invoices are produced, not a setting.
4. Is your invoice numbering a single unbroken sequence? Per legal entity, no gaps, no restarts, no parallel books at different branches. Gaps invite questions you would rather not spend a week answering.
5. What happens when an invoice is wrong? Today somebody probably edits or reissues it. Under e-invoicing a transmitted invoice is generally cancelled or credited through a defined process, not edited. Your staff need that process before they need the software.
6. Can you reproduce any invoice from the last several years on request? Retention and retrieval obligations come with this, and they are not satisfied by a folder of scans nobody can search.
What to do, in order
| Stage | Work | Who does it | Rough effort |
|---|---|---|---|
| 1. Audit | Run the six questions above against real invoices | Finance, with whoever raises invoices | An afternoon |
| 2. Clean the master data | Customer records, product codes, tax rates per item | Finance plus operations | The bulk of the project |
| 3. Fix numbering and process | One sequence, defined credit and cancellation flow | Finance | A week |
| 4. Choose the software path | Existing system with a connector, or replace | Owner, with advice | A fortnight to decide |
| 5. Parallel run | Issue both ways, compare, fix what fails | Everyone who invoices | A month |
| 6. Train and switch | Including the correction process | Whoever touches an invoice | Ongoing |
The ordering is the point. Stages one to three are independent of any vendor decision, they are worth doing regardless, and skipping them is why implementations stall: you cannot clean master data during a parallel run, but that is when most businesses discover they have to.
Should you extend your existing system or replace it?
Three routes, and the right one depends mostly on where your data already lives.
Keep your system and add a compliance connector. Right when your existing accounting or POS system holds clean data and is actively supported. Cheapest and fastest. Confirm the vendor supports the current specification rather than an earlier one.
Replace with an integrated system. Right when you are running on spreadsheets, on an unsupported product, or across several systems that do not reconcile. The compliance deadline is a reason to do the thing you already needed, and for manufacturers that conversation is usually a wider one, which we set out in ERP for Pakistani manufacturers.
Build or extend something custom. Right only when your invoicing genuinely differs from the standard pattern, for example complex project billing or unusual multi-party arrangements. Otherwise the standard product is cheaper and someone else maintains the compliance layer. The general version of this decision is in build versus buy.
What this is actually worth, beyond compliance
Two genuine benefits, worth naming because they make the budget easier.
You find out what your margins are. Line-level product codes and tax rates are, incidentally, the data you need to know which products and which customers actually make money. Most businesses doing this discover at least one product line they were selling at a loss.
Receivables get better. A system that issues invoices immediately and consistently, with correct buyer details, reduces the number of invoices disputed on a technicality and shortens collection. For a business managing cash tightly, that is worth more than the compliance cost, and it feeds straight into the thirteen-week cash flow forecast.
Frequently asked questions
My sector has not been notified. Should I do anything now?
Do stages one to three. They cost little, they improve the business independently of any deadline, and they are the stages you cannot compress later. Wait on the software decision until the requirement and specification that apply to you are actually published.
What if my customers will not give me their registration details?
This is the most common practical obstacle and it takes longer than any technical task, so start early. Ask at the point of sale and as part of account setup rather than in a bulk email nobody opens, and make it a standing field in your order process.
Does this apply if I mostly sell to consumers rather than businesses?
Several of the notified categories are consumer-facing, so yes in principle. The requirements differ from business-to-business invoicing, which is one more reason to take the detail from FBR rather than from general advice.
Is this connected to the e-commerce deductions everyone is talking about?
Same direction of travel, different mechanism. Deductions at the payment and courier layer document the money; e-invoicing documents the transaction. We covered the first in what changed for online sellers in Pakistan.
Where to go next
If you would rather have the audit, the data cleanup and the system decision handled as one piece of work instead of three separate errands, that is how we run startup and business setup consulting, and anything that needs building or integrating sits with custom software development. If you want to know how much work you are facing before committing to anything, talk to us and we will tell you.
