The Rate That Depends On Whether Your Customer Filed
Pakistan adds four points to your invoice when the buyer is not an active taxpayer — and "active" lapses because of something your customer's accountant did not do. Most systems model the other party's tax standing as a box ticked at onboarding, which was the right model until 2022.
Every finance system has a place to record whether a customer is registered for tax. It is almost always a checkbox and a number, captured once when the account is opened, and for most of the world that is a perfectly good model. Pakistan breaks it — not by having an unusual rate, but by making the correct rate on your invoice depend on whether your customer filed their return.
This came out of verifying a tax profile rather than out of a support ticket, which is worth saying plainly: nobody complained. The figure in our own table is right, the country is right, and the defect only becomes visible when you read the charging section next to the definition three hundred pages earlier.
The four points that arrive from somebody else's filing cabinet
Pakistan's Sales Tax Act 1990 charges tax at 18% on taxable supplies made by a registered person and on goods imported into Pakistan. That is section 3(1) and it is the number in our country table. Then section 3(1A) adds this:
Section 3(1A), read at the Act
"…where taxable supplies are made to a person who has not obtained registration number or he is not an active taxpayer, there shall be charged, levied and paid a further tax at the rate of four percent of the value in addition to the rate specified in sub-sections (1), (1B), (2), (5), (6) and section 4…" — with a proviso letting the Federal Government exempt named supplies by notification.
So the tax on a supply is 18%, or it is 18% plus 4%, and which one is correct is not a fact about the goods, the price, the date or the place. It is a fact about the person receiving the invoice.
Registered is an attribute. Active is a status.
The Act defines the second condition rather than leaving it to be inferred. An active taxpayer is a registered person who is not blacklisted, whose registration is not suspended, and who has not failed to file the return. Read that as a data question and the shape changes completely.
| Has a registration number | Is an active taxpayer | |
|---|---|---|
| What kind of fact is it | An attribute | A status |
| When is it established | Once | Continuously |
| Who can change it | The taxpayer, by registering | A missed return, a suspension, a blacklisting |
| Does your customer tell you when it changes | Usually | There is no reason they would |
| What a system needs to hold it | A string | A status with a date it was last true |
The second column is the hard one and it did not always exist. Sub-section (1A) was inserted by the Finance Act 2013, and for its first nine years it turned on one thing only: whether the buyer had obtained a registration number. That is genuinely an attribute — you capture it at onboarding, it does not lapse, and a checkbox models it correctly.
The words "or he is not an active taxpayer" were inserted by the Finance Act 2022. In one clause, the trigger stopped being something you can capture and became something you have to check. Any system built against Pakistan before 2022 modelled this correctly and has been quietly wrong since — not because the software changed, and not because anybody made a mistake, but because the kind of fact it was storing changed underneath it.
The rate is wrong in the under-charging direction, which is the direction nobody reports. Your customer will not ring to say you should have charged them four points more.
The other half, which we are deliberately not putting a number on
There is a second Pakistani structure worth knowing before anyone treats one row in a tax table as the country. The 18% is a federal tax on goods. Sales tax on services is a provincial subject: Sindh, Punjab, Khyber Pakhtunkhwa, Balochistan and the Islamabad Capital Territory each levy their own, at their own rate, through their own revenue authority, with their own return.
We are naming the structure and not the rates on purpose, because we verified the federal Act and did not verify five provincial ones, and a rate published without a source is worse than a rate not published. The operational consequence stands without the numbers: a business selling both goods and services to one customer is not filing one return with one authority. Which government the line belongs to is decided by what was sold, and no field on a customer record can answer it.
What our own system stores, and what it does not
The honest version, since a post that describes a problem and implies it is handled is worse than one that never raised it. All of this was read from the schema and the model on the day this was written.
What AWRA OpsHub does today
- A per-customer tax settings record, separate from the customer itself, holding a VAT-registered flag, a VAT number, a tax identifier, an exemption flag, a default tax type and a per-customer rate override.
- A registration date, captured on the customer form and validated as a date.
- A per-customer rate override, so a customer whose treatment genuinely differs from the organisation default can be given one and it is read when the document is priced.
- A per-customer exemption flag, read at pricing time, which is the closest thing we have to "this counterparty changes the tax".
What it does not do
- Any notion of a registration that lapses. The status shown against a customer is one of three phrases — Registered, Registered (Exempt), or Not Registered — and it is derived from the registered flag alone. The registration date we captured is stored and never consulted. In our model a registration begins and then is true forever.
- Any "still valid as at" date, which is what Pakistan's active-taxpayer test actually needs. Nothing holds one and nothing computes one.
- Any additional charge triggered by the counterparty's standing. The override is a replacement rate, not an addition, so the shape "the standard rate plus four points because of who this is" cannot be expressed as a rule — only typed in by hand, per customer, by somebody who already knew.
- Any tax registration on the supplier side at all. A supplier record carries an active flag, a blacklist flag and the date of blacklisting — which reads like Pakistan's definition and is not it. Those flags describe our relationship with the supplier, not the supplier's standing with a revenue authority. Same vocabulary, different subject.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a tax authority pipeline, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax authority pipelines and reporting
Electronic invoicing or invoice registration against your authority's published interface, with retries, a failure queue and a daily report of sales that carry no reference. The regimes across this region differ enough that this is one build per country rather than one build for the region, and the local bench is deep in most of them — so the honest question is usually whether you need this from us at all, or whether you need the operations layer that feeds whatever you already file with.
Local payment rails and bank feeds
Real-time payment collection matched to the invoice, bulk payment files in your bank's format, and statement feeds wired into the Payments Register.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Statutory payroll and social security schedules computed on live records and produced in the layout each filing body expects. Per-state and per-province variation is the norm rather than the exception here, and it is what makes this a country build rather than a regional one.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThe last one is the one we would most like to walk back and cannot. Finding an active flag, a blacklist flag and a blacklisted-on date against a supplier, while reading a statute that defines "active taxpayer" as not blacklisted, not suspended, returns filed, is a coincidence of wording — and exactly the kind of coincidence that gets a demonstration through a meeting. Those flags are real. They are about whether you have stopped buying from someone.
Four questions that separate a real answer from a reassuring one
-
Can the counterparty's tax status expire?
Not "can you store a date" — storing a date and resolving by one are different things, and the field is the easy half. Ask to see a document priced on two different days, against a customer whose status changed in between, and check that the two documents differ. If the answer is a screenshot of a form with a date on it, the question has not been answered.
-
Is the extra charge a different rate, or the same rate plus something?
These look identical on a total and are not the same object. A replacement rate loses the fact that the base tax was the standard one and something was added for a reason; a return that needs the split cannot recover it from a blended figure. This is the same defect as the Canadian one described in "Two Taxes, Two Governments, One Column", arriving from a completely different direction.
-
Who is responsible for noticing the change?
If the honest answer is "the salesperson raising the invoice", the control does not exist. The person raising a document has no way to know that a customer three hundred miles away missed a filing deadline last month, and no reason to look.
-
What happens to the documents raised while the status was stale?
This is the question that decides whether the exposure is a nuisance or a reconstruction job. Ask whether the system can list every document raised against a counterparty between two dates, priced under an assumption that has since been corrected. Most can, via an ordinary date-range report. It is worth confirming rather than assuming, because it is the difference between an afternoon and a quarter.
The general version
Pakistan is the worked example and not the argument. The argument is that finance systems draw a line between things that are true of a party and things that are true of a transaction, and put tax registration firmly on the first side. That line holds in most jurisdictions and it is not a law of nature. It is a modelling convention, and a legislature can move a fact across it — as Pakistan did, in a single clause, in 2022 — without anybody's software being notified.
The practical instruction is small. When you configure a country, do not only ask what the rate is. Ask what the rate depends on, and then check whether your system can hold that thing at all. A rate you can type in is never the hard part.
Frequently asked questions
Is the 18% figure in your country tax table wrong for Pakistan?
No. 18% is the rate charged under section 3(1) of the Sales Tax Act 1990 on taxable supplies and imports, and it is the right default for a federal supply of goods. What one row cannot express is that a further 4% applies where the buyer has no registration number or is not an active taxpayer, and that sales tax on services is a provincial matter entirely. The row is correct and incomplete, which are different faults with different repairs.
Where do these figures come from?
The Federal Board of Revenue publishes the Sales Tax Act 1990 consolidated up to 2025-26, with an amendment footnote against each clause. Both figures and both amendment dates in this post were read from that text rather than from a summary. We record the source and the date for every tax figure we publish, and where a figure could not be verified at an authority we say so rather than printing it.
Does AWRA OpsHub handle the further tax automatically?
No, and there is no partial version of that answer worth giving. We hold a VAT-registered flag and a per-customer rate override, so somebody who already knows a particular customer is not an active taxpayer can set a rate for them by hand. Nothing detects the change, nothing expires, and nothing expresses "the standard rate plus four points". If you operate in Pakistan this is a manual control and you should treat it as one.
Is this only a Pakistani problem?
The specific clause is. The shape is not: any rule that makes your tax depend on the other party's continuing standing with an authority has the same requirement, which is a status with a date rather than an attribute with a value. It is worth asking the question of every market you operate in before assuming the checkbox is enough.
