Mapping your ERP’s tax codes to what FBR actually checks

Answer first. FBR does not accept “tax: 18%” on an invoice line. It wants a sale type, a rate in FBR’s own wording, an HS code that is consistent with that sale type, a unit of measure from FBR’s list, and, whenever the rate isn’t the standard one, the SRO schedule and item serial that justify it. Your accounting system holds tax codes, tax rates and ledgers instead. The mapping is a small set of tables that translates one into the other: tax code to sale type, item to HS code and unit, customer to registration type and province. Build it once, keep it dated, and test it against FBR’s validation before anything is filed.

What FBR checks on every line

An FBR digital invoice has a header (who is selling, who is buying, the date and the document type) and one entry for each line. The line is where the tax logic lives, and FBR checks it field by field:

• HS code. Pakistan’s eight-digit PCT code, from FBR’s own list, in the form FBR documents (for example 0101.2100). Services use Chapter 98 codes in the same field.
• Sale type. What kind of supply this is — goods at the standard rate, at a reduced rate, zero-rated, exempt, Third Schedule retail-price goods, and so on.
• Rate. A string, not a number, and not always a percentage — FBR’s rates include values such as “18% along with rupees 60 per kilogram”.
• SRO schedule and item serial. Required whenever the rate is not the standard one; naming an SRO makes its item serial mandatory too.
• Unit of measure. FBR’s wording, from FBR’s list, and which units are acceptable can depend on the HS code.
• Values. Quantity, value excluding sales tax, the sales tax itself, and the other tax fields (further tax, extra tax, FED payable, tax withheld at source and discount) each in FBR’s expected form.

The buyer’s details matter to the line too. Whether the buyer is registered or unregistered changes what FBR expects, and the seller’s province is part of how the rate is determined.

Why a flat 18% breaks

A tempting shortcut in a first integration is to send every line at the standard rate with a hard-coded 18%. It works until the first reduced-rate, zero-rated or exempt line, and then every such invoice is rejected, or worse, accepted at the wrong rate.

The rate is not something your system should invent. FBR publishes a rate lookup keyed on three things: the invoice date, the sale type and the supplier’s province. The HS code is not one of them. So the right design stores the sale type against your tax code or item, and asks FBR which rate applies to that sale type on that date, rather than storing a percentage and hoping it is still right.

The HS code still has to agree with the sale type. A mismatch between the two is the single most common rejection seen during integration, error 0052 in FBR’s list, and it usually means the item master and the tax code were mapped by different people who never compared notes.

The mapping in three tables

However your system stores tax, the mapping reduces to three tables. Keeping them separate is what makes the mapping maintainable.

1. Tax treatment: your tax code → FBR sale type

One row per tax code (or tax rate, or tax ledger) your system uses on sales. Each row gives the FBR sale type and, where the treatment is not standard, the SRO schedule and item serial. A reduced-rate code for a specific item class might map to “Goods at Reduced Rate” with its SRO; your standard output tax code maps to the standard-rate sale type with no SRO at all.

2. Items: your product → HS code and unit

One row per product, or better, per product group with product-level overrides. Each gives the HS code — stored as text, exactly as FBR’s list returns it, because a number field eats the leading zero on chapters 01 to 09, and the FBR unit to use for that code. Your system’s own unit codes, such as PCS, NOS or KGS, are not FBR’s strings and must be translated.

3. Customers: your customer → registration type and province

One row per customer you invoice: the NTN or 13-digit CNIC as bare digits, whether FBR treats them as registered or unregistered, and their province — a province, not a city. The registration type can be looked up from FBR against the number and cached; it changes rarely, but it does change.

Where tax lives in your system

The first table is where systems differ most, because each models tax differently. The table below is a starting point for finding the thing you need to map; the system-specific guides go further.

One pattern repeats in every row: the system knows a rate but not a sale type, and it knows its own unit but not FBR’s. That is why the mapping is unavoidable, whichever system you run.

The fields people get wrong

• Tax-inclusive prices. Many systems let you enter prices including tax. FBR wants the value excluding sales tax on each line, so the tax has to be backed out consistently, and the lines must still add up to the invoice total after rounding.
• Tax withheld at source. FBR expects this to be either zero or the entire sales tax on the line. A partial figure is rejected.
• “Not applicable” versus zero. FBR distinguishes between a tax that doesn’t apply and a tax that applies at zero. Sending a blank where FBR expects a zero, or the reverse, is a rejection.
• Third Schedule goods. For goods sold at a printed retail price, tax is worked out on the notified retail price rather than the sale value, and the retail price goes in its own field.
• Further tax. Supplies to unregistered buyers can attract further tax. Whether it applies, and at what rate, is a question for your tax advisor — the mapping just needs a clear rule for when it is added.
• Units that don’t fit the HS code. Some HS codes accept only one unit. A unit that is valid in general can still be rejected for a particular code.

Our guide to FBR error codes lists the rejection each of these produces, so a failed test can be traced straight back to the table that needs fixing.

Testing the mapping

A mapping is only right when FBR agrees with it. Two tools make that cheap to find out.

1. FBR’s validation method. It takes the invoice you would file, applies every check a live filing gets and reports the same errors, but records nothing and issues no number. Run a spread of real invoices through it, one per tax code at least, plus a reduced-rate line, a zero-rated line, an unregistered buyer and a multi-line invoice with a discount.
2. FBR’s sandbox. Each business is assigned its own set of test scenarios, and passing them is what unlocks the production token. The scenarios exercise exactly the combinations the mapping has to get right.

If your invoicing runs through eInvoicePro, the reference lookups FBR publishes (HS codes, the units valid for each code, the rate and SRO fields for each sale type) are available directly, so the mapping can be checked against FBR’s own data rather than a spreadsheet someone downloaded months ago.

Keeping it current

Rates change with Finance Acts, SROs are issued and withdrawn, and the rate lookup is date-sensitive for exactly that reason. Three habits keep a mapping from drifting:

• Store the sale type, not the rate. Let FBR’s lookup supply the rate for the invoice date, so a rate change doesn’t require a mapping change.
• Date your SRO rows. An SRO reference that was valid last year can be the reason an invoice fails this year.
• Catch new items before they reach FBR. A new product with no HS code should stop at your own check with a clear message, not at FBR with a rejection after the customer has left.

Who owns which decision matters too. The software can hold the mapping and check it against FBR’s lists, but choosing an HS code or deciding that a supply is reduced-rate is a classification judgement for someone who knows the products, with your tax advisor. FBR does not check that an HS code actually describes what you sold, so a wrong code can pass validation and still be wrong.

FAQs

Can’t we just send the rate our system calculated? You can send it, but FBR checks it against the rate for that sale type, date and supplier province. Storing the sale type and taking the rate from FBR’s lookup avoids a whole class of rejections and survives rate changes without a code change.

Where should the mapping live — in our ERP or outside it? Either works. Some systems make it easy to add custom fields for HS code and sale type; others, like Tally, are better left untouched with the mapping kept alongside. What matters is that there is one mapping, that it is dated, and that new items are caught before they reach FBR.

Does the HS code decide the tax rate? No. The rate comes from the sale type, invoice date and supplier province. The HS code must be consistent with the sale type, so a wrong code can block a rate, but it does not set one.

How many invoices should we test before going live? At least one per tax code you use, plus the awkward cases: a reduced-rate line, a zero-rated line, an unregistered buyer, a discount and a multi-line invoice. Then pass the sandbox scenarios FBR assigns to your business.

Do services need an HS code too? Yes, a Chapter 98 code in the same field. Check first whether the service is within FBR’s digital invoicing at all — many services are taxed provincially by PRA, SRB, KPRA or BRA instead.

Related reading: PCT and HS codes for FBR invoicing, connecting your ERP to FBR and sandbox to go-live.