HSN codes and GST rates — how to map every item correctly

What HSN codes are, and why they decide your GST

HSN — Harmonised System of Nomenclature — is the international numbering system that classifies goods. Indian GST uses it to answer one question per invoice line: what rate does this item attract? Every goods line on a tax invoice carries an HSN code, and the notified rate for that code — 5%, 12%, 18% or 28% for most goods — is the GST the line must charge. Services carry the parallel SAC (Services Accounting Code) instead.

The code is hierarchical: the first two digits are the chapter, four digits the heading, six the sub-heading, eight the full tariff item. "Iron and steel" narrows to "flat-rolled products" narrows to a specific tariff line. That hierarchy matters because near-identical products can sit under different headings with different rates — which is exactly why the classification should be confirmed once, recorded in the item master, and never re-decided invoice by invoice.

How many digits you must print

You rarely print all eight digits. The mandated depth depends on your aggregate turnover, and has been tightened over the years. As a working orientation:

Treat the table as orientation, not law: thresholds and notifications change, so confirm the current rule for your turnover with your CA, set the digit depth once in your billing software, and let every invoice print it consistently. The GSTR-1 return also wants an HSN-wise summary of outward supplies, which is only painless when every invoice line already carries a correct code — the return then aggregates what billing already recorded.

Item-level and party-level tax — how they combine

A common confusion: if the item carries the rate, why do billing systems also hold tax settings against the party? Because the effective tax on a line is a combination of two decisions:

• The item decides the rate. Its HSN mapping says this line attracts, say, 18%.
• The party decides the split and applicability. The buyer's GSTIN and state turn that 18% into 9% CGST + 9% SGST for an in-state buyer, a single 18% IGST for an inter-state buyer, or zero-rated treatment for an export customer under LUT.

Billing software therefore keeps two linked masters — item-level tax mapping and party-level tax mapping — plus a tax configuration that defines the heads (CGST, SGST, IGST) and how they compute. At billing time the three resolve automatically: pick the party, pick the items, and every line lands with the right code, rate and split. The operator makes zero tax decisions, which is the goal.

Building the map — the one-day workflow

For a catalogue of any size, build the map as a single structured exercise rather than item-by-item over months:

• 1. Export the item master to a sheet — code, name, description, unit.
• 2. Group items by family. Most SME catalogues collapse into a few dozen HSN headings — classify the family, not each SKU from scratch.
• 3. Confirm HSN and rate per family with your CA, using the official rate schedule — not a competitor's invoice, not a guess.
• 4. Fill the sheet — every item now has an HSN column and a GST-rate column.
• 5. Bulk-import the sheet into the billing system, and spot-check a sample invoice per family.

The same exercise should sweep the party side: collect customer and supplier GSTINs and load them in bulk, because the GSTIN is what drives the CGST/SGST-vs-IGST decision on every future invoice. A party master with missing or mistyped GSTINs quietly produces wrong tax splits and reconciliation mismatches later.

Bulk import — items, HSN, rates and GSTINs

Bulk import is what turns the workflow above from theory into a one-day job. A billing system built for Indian SMEs provides three imports that matter here:

Item ↔ HSN ↔ GST import. One sheet, one pass: every item's HSN code and GST rate loaded into the item tax mapping together. This is also the route for future rate changes — when a notification moves a family of goods from 12% to 18%, you update the sheet and re-import, rather than editing hundreds of items by hand.

Party GSTIN import. Customer and supplier GSTINs loaded against the party master in bulk, so the state-code logic that splits CGST/SGST vs IGST has correct input for every party from day one.

Tax configuration. The tax heads themselves — CGST, SGST, IGST and how they apply — defined once in the tax configuration, with charge heads (freight, packing, insurance) alongside so invoice totals compute completely.

After import, validate the way an auditor would: raise one draft invoice per item family for one in-state and one out-of-state customer, and check code, rate and split on each. An hour of spot checks buys years of correct invoices.

The five mapping mistakes that cost money

The same handful of errors shows up in almost every GST-mismatch story:

• Copying a competitor's HSN. Their classification may be wrong, or their product subtly different. Classify from the schedule, confirm with your CA.
• One rate for everything. Applying 18% across the catalogue because most items are 18% — until the 12% and 28% items surface at assessment.
• Rates typed on the invoice. If the operator can override the rate per line, the master is decoration. The rate should flow from the mapping, with overrides exceptional and audited.
• Stale maps after rate changes. GST rates change by notification. Someone must own re-importing the affected families when they do.
• Missing party GSTINs. Without the buyer's GSTIN the system cannot decide the split, the buyer cannot claim credit, and B2B invoices degrade into guesswork.

How Fast Billing Software holds the map

Fast Billing Software treats the item ↔ HSN ↔ GST map as first-class master data. A dedicated bulk import loads the full item-HSN-rate sheet in one pass, and a matching import loads party GSTINs against the party master. Tax heads and how CGST/SGST/IGST apply are defined once in the tax configuration; item-level and party-level tax mappings then resolve the effective tax on every line automatically when a GST tax invoice is raised — code, rate and split, with freight and packing charge heads on top, rounding and amount in words at the end.

Because the same masters drive every document, the map you build once also powers credit and debit notes (which must reverse tax at the same rate the invoice charged), export invoice variants, and the party-wise GST reporting used for return preparation. And when documents post to Tally, the GST lands on the correct ledgers because the split was right at source. A wrong map, by contrast, propagates everywhere — which is the strongest argument for doing it properly once.

Frequently asked questions