PCT and HS codes for FBR invoicing

Answer first. A PCT code is an HS code. It is Pakistan’s eight-digit national line, built on the World Customs Organization’s six-digit subheading, and it lives legally in the First Schedule to the Customs Act 1969. On a digital invoice it goes in the hsCode field, which FBR documents in the form 0101.2100. Services use the same field, populated with a Chapter 98 code. The code does not set your tax rate — the rate comes from your sale type, the invoice date and your province — but it must be consistent with the sale type, so it does constrain which rates you can legitimately reach. The only list FBR validates against is its own, served by the reference endpoint /pdi/v1/itemdesccode.

One code, three names

The WCO fixes the first six digits: two for the chapter, two for the heading, two for the subheading. Pakistan Customs adds digits seven and eight as national splits, and the resulting eight-digit line is what everyone here calls the PCT code or PCT heading. The schedule is issued under section 18(1) of the Customs Act 1969 and republished each fiscal year; the current edition is the Pakistan Customs Tariff FY 2025-26. Chapters run 01 to 99, with chapter 77 reserved and empty. FBR uses “HS code” and “PCT heading” interchangeably, and its invoicing API field is called hsCode.

It is on the invoice because the Sales Tax Rules put it there, not the Act. Rule 150R(13) lists what an electronic invoice must contain, and item (x) is the HS code and item (y) the unit of measurement. The proviso that relieves a retailer issuing invoices to the general public covers extra tax, further tax, FED payable in sales tax mode and the SRO and serial number — items (s), (t), (u) and (z). It does not cover (x) or (y). A plain retailer still carries the HS code and the unit of measurement on every invoice. Section 23 of the Sales Tax Act 1990, which sets the older minimum particulars, does not mention an HS code at all.

The exact format, and the trap in storing it

The current specification (DI API v1.12) documents hsCode as a required string with the sample value 0101.2100 — eight digits with a dot after the fourth, nine characters in total. Other FBR documents use the same eight digits without the dot: the 2024 predecessor specification defined the field as eight characters and its sample payload carried 32159090, and FBR’s standalone services list prints codes as 98153000.

Both forms are in FBR’s own publications, so do not normalise. Send back byte for byte what the reference endpoint returns, and store the value as text. A numeric column silently eats the leading zero on chapters 01 to 09, which is a whole class of goods you cannot then invoice. Legacy systems built against the 2024 specification hold undotted codes, and that is a real migration check when moving onto the current API.

Services use the same field, with a Chapter 98 code

The most common blocker for a services business is the belief that there is no HS code for what it sells. There is, and it is in the same field. FBR’s invoicing HS list contains 211 Chapter 98 codes, spanning headings 9801 to 9805 and 9807 to 9824 — there is no 9806. That set matches, row for row, FBR’s standalone list of HS Codes for Services published at e.fbr.gov.pk/SOP/Services_HS_Codes.pdf, which also carries 211 rows running from 98010000 to 98240000. Both counts are taken from those documents; the live endpoint is the version that counts on the day you submit.

Codes people look for most often:

• 98010000 hotels, restaurants, marriage halls, clubs and caterers, with 98011000 hotels and 98013000 marriage halls and lawns
• 98020000 advertisements, with 98024000 advertisement in newspapers and periodicals
• 98080000 courier services
• 98120000 telecommunication services
• 98151000 medical practitioners, 98152000 legal practitioners, 98153000 accountants and auditors, 98154000 management consultants, 98156000 software or IT-based system development consultants
• 98222000 maintenance or cleaning, 98230000 franchise services, 98240000 construction services

The item row is explicitly for both: v1.12 describes productDescription as “Details of the product or service sold.”

One boundary to settle before you map anything. FBR’s digital invoicing covers goods, services in Islamabad Capital Territory, and federal excise duty charged in sales tax mode. Sindh (SRB), Punjab (PRA), Khyber Pakhtunkhwa (KPRA) and Balochistan (BRA) tax services under their own laws, with their own schedules and their own portals. An FBR e-invoice on its own does not discharge a provincial services obligation, so confirm with your advisor which regime your services actually fall under before building a Chapter 98 mapping.

Where the authoritative list lives

GET https://gw.fbr.gov.pk/pdi/v1/itemdesccode takes no request input and returns the HS code and its description. It needs a bearer token, like every other reference endpoint, so you cannot pre-populate an HS list without credentials.

That endpoint is the list FBR validates your invoice against, which makes it the one that decides whether a submission passes. Three other sources answer different questions:

• The Pakistan Customs Tariff FY 2025-26 First Schedule (published on download1.fbr.gov.pk) carries the legal text plus the section and chapter notes that decide a contested classification. A description search will not settle an argument; the notes will.
• FBR’s tariff search and the Pakistan Single Window / Trade Information Portal are useful for description-based lookup and for the regulatory conditions attached to a code.
• The services list above, for Chapter 98.

None of them tells you whether a code is acceptable for the sale type you are about to send. That check has no published source at all, which is covered below.

Finding the right code

1. Describe what you actually sell, as sold — the form, the material, the packing. Classification follows the goods in the state they leave you, not the category in your catalogue.
2. Goods: find the heading in the Customs Tariff. Services: go straight to Chapter 98. For goods, the section and chapter notes are the deciding text.
3. Confirm the exact eight-digit line exists in FBR’s invoicing list. A six-digit international code from an export document, or a ten-digit foreign tariff code from a supplier catalogue, is not on that list and will be rejected.
4. Get the units of measure FBR allows for that specific code from /pdi/v2/HS_UOM, and use the description string it returns.
5. If you are claiming anything other than the standard rate, find the schedule entry that supports it and record the SRO and its serial number. Rule 150R(13)(z) requires them on the printed invoice anyway.

Worked case, services. An IT firm billing software development finds nothing in chapters 01 to 97 that describes it; 8471.3010 is a portable computer, and it circulates in sample payloads for exactly that reason. The correct line is 98156000, software or IT-based system development consultants. An audit firm bills under 98153000.

Worked case, goods with a schedule entry. The Sales Tax Act’s schedules quote codes in three incompatible shapes, and knowing which one you are looking at saves an afternoon. Some entries give a full eight-digit PCT — 6309.0000 second-hand clothing, 0910.3000 turmeric, 2105.0000 aerated waters, 3306.1010 shaving cream. Some give a bare four-digit heading written with a dot after two digits — 09.10, 22.01, 19.02. And many say only “Respective headings”: cigarettes, cement sold in retail packing, rice, wheat and meslin flour, paints, foam mattresses, household gas appliances, telephone sets. Where the schedule says “Respective headings” the law is handing the classification back to you under the tariff’s General Rules of Interpretation, and defaulting to a residual .9000 or “Others” line is the first thing an auditor challenges. The Fifth Schedule, which governs zero-rating, has only a serial number and a description with no PCT column at all — codes appear only inside the descriptions, as in “Exercise books (PCT heading 4820.2000)”.

One code, two treatments. FBR’s own FAQ settles this: items having the same HS code but different SKUs can be added as distinct items on an invoice using a unique description for each. You do not need, and should not invent, a second HS code to carry a different sale type. Split the line and vary the description.

What happens when the code is wrong

At submission, FBR runs a small number of checks and they are unforgiving:

• Missing. “HS Code cannot be empty, please provide valid HS Code.”
• Not on the list. Rejected.
• Inconsistent with the sale type. This is error 0052, and FBR’s own worked example of a rejected submission is:

{
  "dated": "2025-05-13 13:09:05",
  "validationResponse": {
    "statusCode": "01",
    "status": "Invalid",
    "errorCode": "0052",
    "error": "Provide proper HS Code with invoice no. null",
    "invoiceStatuses": null
  }
}

Its brief description is “HS Code that does not match with provided sale type, Please provide valid HS Code against sale type.”

• Wrong unit for the code. “UOM is not valid. UOM must be according to given HS Code.” Some codes are single-valued: only KWH is allowed for certain codes, and potassium chlorate must be invoiced in KG.

Item-level failures are reported per line, in the invoiceStatuses array, so check every entry rather than the envelope alone.

What FBR does not check is whether the code describes what you actually sold. A plausible but incorrect code that exists on the list and does not clash with your sale type will be accepted, and it then becomes durable reporting data: Annexure-C of the sales tax return is auto-filled from your electronic invoices, and Annex-H1 stock reporting is laid out as serial number, HS code, unit of measure, sales tax rate, value of goods and quantity of goods. The code you pick at product-master time is a stock reporting dimension for the life of that product, which is where a wrong-but-accepted code eventually surfaces.

How the code interacts with the rate and the SRO schedules

The rate does not come from the HS code. It comes from GET /pdi/v2/SaleTypeToRate?date=&transTypeId=&originationSupplier=, keyed on the invoice date, the sale type and the province ID of the supplier. There is no hs_code parameter anywhere in that call.

The rate field is a string carrying the rate description the endpoint returns. Usually that is "18%". For compound rates it is the entire phrase, such as "18% along with rupees 60 per kilogram", which is why parsing the value as a percentage breaks the first time someone sells a compound-rated item.

What the HS code does control is consistency. It has to agree with the sale type you send, and the sale type determines the rate — so the code constrains which rates you can reach without ever setting one itself. Teams that try to change a rate by adjusting the HS code are working on the wrong field.

Where the rate is not the standard rate, two more fields bind:

• /pdi/v1/SroSchedule?rate_id=&date=&origination_supplier_csv= returns the SRO or schedule, keyed on rate, date and province.
• /pdi/v2/SROItem?date=&sro_id= returns the item serial number, as a string like "50" or "9".

The field table marks sroScheduleNo and sroItemSerialNo optional, and they become mandatory in a cascade the moment your rate is non-standard: “SRO/Schedule Number cannot be empty”, and once you supply one, “Item serial number cannot be empty”. Both lookups are date-sensitive and the schedule lookup is province-sensitive, so a back-dated or cross-province invoice needs the right date and province passed through, not today’s defaults. Note also that the reference lookups take dates as dd-MMM-yyyy (for example 04-Feb-2024) while invoiceDate on the invoice itself is YYYY-MM-DD. Reusing one date formatter across both quietly breaks the lookups.

Units of measure are bound to the code, not chosen freely. GET /pdi/v2/HS_UOM?hs_code=&annexure_id= returns the permitted units for a specific code, and the invoice field takes the description string, not an internal unit code. ERP unit codes such as PCS, NOS or KGS are not FBR’s strings.

Resolving codes instead of typing them

If your invoicing runs on eInvoicePro, these lookups are available directly: the HS code list, the valid units of measure for a given HS code, and the applicable rate for a transaction type, along with the SRO schedule and item serial chain that follows a non-standard rate. Where a code permits exactly one unit of measure, there is nothing for a user to choose and nothing to get wrong; where it permits several, the choice is limited to the ones FBR will accept. That removes the unit-of-measure rejection entirely and keeps the rate string byte-identical to what FBR returned.

It does not solve the classification problem, and no lookup can. There is no FBR endpoint that answers “which HS codes are valid for sale type X” — that question is the one behind the sale-type mismatch rejection, and it is answered only by curating your product master so that each item carries a code, a sale type and a unit that agree with each other. Any vendor claiming to automate that is automating a guess.

One dated item to put in the calendar rather than a plan: the WCO’s HS 2028 amendments, accepted in January 2026, take effect on 1 January 2028 with 428 new subheadings and 172 deleted, and Pakistan’s tariff is rebuilt on that nomenclature, so a share of stored codes will stop resolving.

FAQs

Is a PCT code the same as an HS code? Yes. The PCT code is Pakistan’s eight-digit line in the First Schedule to the Customs Act 1969, built on the WCO’s six-digit subheading with two national digits added. FBR uses both terms for the same thing, and its invoicing field is called hsCode.

What HS code do I use for a service? A Chapter 98 code, in the same hsCode field you would use for goods. FBR publishes 211 of them, running 98010000 to 98240000 across headings 9801 to 9805 and 9807 to 9824. Software and IT system development consultants are 98156000; accountants and auditors are 98153000. Check separately whether your service is federally taxed or falls under SRB, PRA, KPRA or BRA.

Does the HS code decide my tax rate? No. The rate is returned by FBR’s rate lookup keyed on sale type, invoice date and supplier province, with no HS code involved. The code has to be consistent with the sale type, and since the sale type sets the rate, an incompatible code will block a rate rather than change one.

Should I store the code with the dot or without? Store exactly what the reference endpoint returns, as text. FBR’s current specification samples a dotted form and its services list prints an undotted form, so normalising in either direction risks sending something FBR did not issue. Storing it as a number also destroys the leading zero on chapters 01 to 09.

The schedule just says “Respective headings”. What do I put on the invoice? You classify the goods yourself in the Customs Tariff, using the section and chapter notes and the General Rules of Interpretation, and you invoice the eight-digit line you land on — after confirming that line exists in FBR’s invoicing list. Reaching for a residual “Others” code because the schedule was vague is the pattern auditors look for.

Related reading: the FBR digital invoicing API and getting through sandbox to go-live.