How to Fix FBR Error 0102 (3rd-Schedule Mismatch)

What error 0102 actually means

Error 0102 is FBR's way of telling you that the price base on your invoice doesn't match the declared retail price for a 3rd-Schedule item. In plain terms: the system expected tax calculated on one price, and your invoice submitted a different one. It is a fairly common rejection, and unlike some of the vaguer error categories it usually traces back to a specific, findable mismatch rather than a systemic problem.

If you're trying to make sense of FBR's error codes more broadly first, our complete guide to FBR invoice error codes explains where 0102 fits among the other categories.

Why 3rd-Schedule goods are priced differently for sales tax

Most goods are taxed on their actual sale price. 3rd-Schedule items — a category that includes pharmaceuticals and certain notified FMCG goods — are different: sales tax is charged on the declared retail price (the MRP printed on the pack), not on whatever price the transaction actually happened at. That single design choice is the reason this error category exists at all, and it's why pharmacies and pharma distributors are more exposed than a typical retailer selling non-Schedule goods.

The most common cause: MRP vs. invoice price base mismatch

In practice, error 0102 shows up when the price your invoicing software submits for tax calculation doesn't match the manufacturer-declared retail price on file for that product. This can happen for a few reasons: your product master data still has an old MRP after a price revision, a discount was applied to the tax base instead of just the customer-facing price, or a SKU was set up with the wrong price field in the first place.

Step-by-step: which field to check first

When you hit 0102, work through these in order:

1. Confirm the product's current declared retail price against the manufacturer's latest notification — pricing on 3rd-Schedule pharmaceuticals changes periodically, and your master data can lag behind.
2. Check which price field your software used as the tax base — it should be the declared retail price, not your cost price, discounted price, or a manually overridden sale price.
3. Check for a stale SKU record — a product added to your system before a price revision will carry the old figure until someone updates it.
4. Confirm the item is actually 3rd-Schedule — misclassifying a normally-taxed item as 3rd-Schedule (or the reverse) will also trigger a mismatch, since the system expects a different calculation method entirely.

How this shows up differently for pharmacies vs. distributors

A retail pharmacy usually hits this error at the point of sale — a single SKU with a stale or incorrect retail price on file. A pharma distributor, by contrast, is issuing higher volumes across many SKUs and buyer types at once, so a single upstream data error (an unrevised price list from a manufacturer, for instance) can produce the same rejection across dozens of invoices in one run. Distributors also carry additional tax mechanics on top of this — serial-81 treatment and further tax on unregistered buyers — that compound with 3rd-Schedule pricing issues.

Keep a record of the fix

Once you've traced and corrected a 0102 rejection, note what caused it — a stale SKU, a misapplied discount, a misclassified item — and when the underlying price list was last updated. This matters for two reasons: it helps you spot the same root cause recurring across other SKUs before they generate their own rejections, and it gives your tax advisor a clean explanation if FBR ever asks why a batch of invoices needed correction, especially if the fix relied on the edit/cancel window under STGO 01/2026 (confirm the current window with your tax advisor).

Preventing it with pre-flight validation

The sustainable fix isn't correcting 0102 invoice by invoice — it's catching the underlying data problem before submission. That means keeping your product master data (especially declared retail prices) current, and using software that checks the price base locally before it ever reaches FBR, so a stale SKU shows up as a warning in your own system instead of a rejected invoice at the counter.

Aboha Digital Invoicing is coming soon and is planned to check each invoice against FBR's rules before sending it, which should help catch this class of error. 0102 is only one of the many codes FBR can return, and our FBR compliance hub puts it in the context of the wider digital-invoicing regime. If you're fighting 0102 rejections regularly, contact us — we can look at where your specific mismatch is coming from.

This article is informational and is not tax or legal advice. Confirm your specific obligations with FBR or your tax advisor.