Why HSN classification needs a better workflow
For an Indian handicraft business, the product catalogue may include carved wood, handloom textiles, metalware, terracotta, jewellery, bamboo products, paintings, and mixed-material gift sets. Each item can have different tax and reporting implications depending on its material, function, composition, degree of processing, and intended use. A short marketplace description such as “traditional handmade decor” is rarely enough to classify a product reliably.
That is why automation should not mean asking a general-purpose chatbot to guess a code. A useful system combines structured product information, the current GST and HSN references, confidence scoring, and a human review step for ambiguous products. As of 2026, this approach is more practical for Indian sellers than attempting to remove expert judgement entirely.
Businesses already using no-code data analytics platforms in India can often build an initial classification dashboard without developing a full machine-learning system.
What the AI system should classify
Before choosing a model, define the output and the evidence required for every recommendation. The system should capture:
- Suggested HSN code: Include the relevant number of digits required for the business’s GST and invoicing workflow.
- Product category: For example, textile furnishing, wooden article, metal decor, pottery, jewellery, or painting.
- Material: Record the primary material and meaningful secondary materials.
- Function: Distinguish between utility products, decorative articles, apparel, accessories, packaging, and raw or semi-processed goods.
- Manufacturing characteristics: Note whether the article is hand-carved, woven, embroidered, assembled, painted, plated, or otherwise treated.
- Confidence score: Separate high-confidence recommendations from cases requiring review.
- Reason and source: Store the product attributes that led to the recommendation and the reference used to validate it.
This structure is important because HSN classification depends on more than keywords. “Bamboo basket” and “bamboo lamp shade” may not be treated identically if their function and construction differ. Likewise, a cotton product with zari, synthetic lining, or metal fittings may need a closer review than a simple material search suggests.
Step 1: Build clean product data
AI cannot compensate for incomplete catalogue data. Start by standardising product records across your website, ERP, marketplace feeds, and spreadsheets. Create mandatory fields for:
- Product name and customer-facing description
- Primary and secondary materials
- Product dimensions and weight, where relevant
- Intended use and customer segment
- Manufacturing or finishing process
- Country of origin and place of manufacture
- Whether the item is sold individually, as a set, or with accessories
- Existing HSN code, GST rate, and the person or source that approved it
Use controlled values wherever possible. For example, replace free-text variations such as “wood,” “wooden,” and “sheesham timber” with a material hierarchy while preserving the original description for audit purposes. Keep regional craft names too: they can help retrieval, but should not determine the code on their own.
For multilingual catalogues, retain the original Hindi, Tamil, Bengali, Marathi, or other regional-language description alongside a standardised English or Hindi field. A multilingual workflow can use the same principles applied in automated multilingual support systems: translate or normalise text first, then classify using consistent fields rather than relying on a language model’s unsupported inference.
Step 2: Choose the right automation architecture
Most small and mid-sized handicraft businesses should begin with a rules-plus-AI design rather than a fully autonomous model.
Rules for known cases
Use deterministic rules for products already reviewed by a tax expert. A rule can identify a stable product family, flag missing material data, or block a code when the description contradicts the approved classification. Rules are also useful for enforcing formatting and preventing the system from producing a code outside the approved reference table.
Retrieval for current references
Connect the system to an approved, versioned HSN and GST reference maintained by the business. The AI should retrieve relevant entries and show the source and effective date instead of relying on memorised information. Tax treatment can change, and a model trained on old catalogue data may produce an outdated answer.
Language models for extraction
A language model can extract material, function, and construction details from unstructured descriptions. It can also ask targeted questions, such as whether a “decorative box” is made primarily of wood or metal. It should propose a shortlist—not silently finalise a classification where the evidence is weak.
Supervised models for repeatable catalogues
If a business has several thousand reviewed products, a conventional text-classification model or embedding-based similarity system can identify close matches. It should still route new materials, mixed products, and low-confidence cases to a reviewer.
Step 3: Design human review and controls
Set a confidence threshold before going live. For example, high-confidence matches may flow to an invoice draft, medium-confidence cases may require a quick operator confirmation, and low-confidence or novel products should be escalated to a tax professional.
A reviewer interface should show:
- The original product description
- Extracted attributes and missing fields
- Top alternative HSN suggestions
- Similar previously approved products
- The reference entry and date used
- A field for the reviewer’s decision and rationale
Do not allow the AI to overwrite an approved code without creating a new version. Maintain an audit log containing the model version, prompt or ruleset, source reference, recommendation, reviewer, timestamp, and final decision. These controls matter during GST reconciliations, internal audits, marketplace disputes, and catalogue updates.
If staff will interact with the system through a conversational interface, a voice agent for Indian businesses can collect missing product details from artisans or catalogue teams. Voice input should supplement—not replace—structured records and written approval.
Step 4: Test with real handicraft edge cases
Do not evaluate the system only on clean, common products. Build a test set covering:
- Mixed-material products
- Product sets and gift hampers
- Decorative items that resemble utilitarian goods
- Finished and unfinished articles
- Products with lining, plating, fittings, or embellishment
- Regional craft names and spelling variations
- New designs with no close catalogue match
- Descriptions translated from Indian languages
- Items whose material and primary function point to different categories
Measure top-one accuracy, top-three recall, abstention quality, reviewer override rate, and the percentage of products with complete evidence. A model that makes fewer guesses and escalates difficult cases can be more useful than one with a higher headline accuracy but poor auditability.
Integration with commerce and GST operations
The classification service should connect to the product master, invoicing software, inventory system, and marketplace feeds through an API or controlled spreadsheet export. A practical workflow is:
1. A new product record is created.
2. The system checks required fields and normalises the description.
3. AI retrieves candidate codes and explains the match.
4. Rules validate the output against the approved reference table.
5. A reviewer approves, edits, or rejects the recommendation.
6. The final code is published to the invoice and catalogue systems.
7. Later corrections feed back into evaluation data, subject to approval.
Keep classification separate from tax-rate calculation unless both are maintained against the same current official source. An HSN recommendation is not, by itself, proof of the applicable GST treatment.
Common implementation mistakes
- Treating a product name as sufficient evidence
- Training on old or unverified HSN mappings
- Using marketplace categories as tax classifications
- Letting the model invent a code when no confident match exists
- Ignoring sets, accessories, and mixed materials
- Failing to preserve the reviewer’s reasoning
- Measuring only speed instead of correction and escalation rates
- Publishing codes across channels before approval
For a growing company, Indian open-source AI developer projects may provide useful components for document retrieval, language processing, and evaluation. However, open-source software does not remove the need for current tax references, access controls, and professional review.
A practical 30-day rollout plan
Week 1: Audit the catalogue, define mandatory fields, collect approved historical classifications, and identify the highest-volume product families.
Week 2: Build a rules and retrieval prototype. Add multilingual normalisation, source citations, confidence thresholds, and an approval screen.
Week 3: Test on edge cases and a held-out sample. Ask a GST professional or experienced tax reviewer to inspect errors and revise the data model.
Week 4: Pilot on one catalogue or sales channel. Compare processing time, reviewer overrides, missing-field rates, and invoice corrections against the manual baseline.
Scale only after the pilot shows that the workflow is accurate, explainable, and easy for staff to use. The goal is not simply faster code assignment; it is a defensible classification process that helps Indian handicraft businesses sell across channels without losing control of compliance.