SAC code

SAC code, defined without the mythology

A SAC code is a six-digit number that classifies a service for Indian GST. It comes from the Scheme of Classification of Services notified by the Central Board of Indirect Taxes and Customs, which is itself aligned with the United Nations Central Product Classification. The first digits place the service in a family, and the later digits narrow it to a specific activity. When a registered business issues a tax invoice for a service, the invoice is expected to describe the service and identify it with the applicable SAC.

The code is a classification, not a charge. It does not set the rate by itself, it does not determine whether the supply is exempt, and it does not tell you what to charge a customer. Those outcomes come from rate notifications, exemption notifications and the place-of-supply rules read together with the classification. Teams get into trouble when they treat the code as a lookup that produces a tax rate, because two services with adjacent codes can be treated differently and the difference usually turns on facts rather than on the number.

What a SAC is not: it is not an HSN code for goods, it is not a company registration number, it is not a GSTIN, and it is not a universal identifier that a vendor can assign for convenience. It is a description of the supply. If the description is wrong, the invoice is wrong even when the arithmetic is perfect.

How SAC differs from HSN

HSN stands for Harmonised System of Nomenclature, the international classification for goods. SAC is the services counterpart used in India. A goods invoice carries an HSN code, usually four, six or eight digits depending on turnover and the notified requirement. A services invoice carries a SAC, generally six digits. The two schemes share a habit of hierarchical numbering, which is why people assume one is a subset of the other. They are separate schemes for separate kinds of supply.

The distinction matters on mixed invoices. A company that sells a hardware device with a software subscription and an installation visit is making more than one supply, and each line may need its own classification. Putting the whole invoice under a single code because the customer sees one monthly charge is a classification claim, not a formatting choice. If the supply is a composite supply, the principal supply determines the treatment; if it is a mixed supply, each constituent may be treated separately. Those are legal tests, not label choices.

A useful discipline is to write the description as a customer would understand it and then ask which classification family that description belongs to. If the description is managed agent platform with support and onboarding, the answer may be more than one line. If the description is one annual subscription to a hosted application, the answer is narrower. The invoice should reflect the supply, not the sales deck.

Where the code appears on a tax invoice

Rule 46 of the Central Goods and Services Tax Rules sets out what a tax invoice must contain. Among the required particulars are the name, address and GSTIN of the supplier, a consecutive invoice number, the date, the recipient’s details, the description of goods or services, the quantity, the taxable value, the rate and amount of tax, and the place of supply for services. The SAC belongs with the description of the service. It is not a decoration at the bottom of the page.

In practice a clean service invoice has one line per distinct supply. Each line shows the description, the SAC, the taxable value and the rate, and then the tax columns split according to whether the supply is intra-state or inter-state. The totals show the taxable value, the central and state tax or the integrated tax, and the invoice value. A credit note follows the same logic in reverse and should reference the original invoice, because a credit note that cites a different code from the invoice it adjusts creates a reconciliation problem for the buyer.

The invoice is also a data source. Once it enters the buyer’s accounts payable system, the SAC is part of what determines whether the input tax credit is accepted, questioned or rejected. A wrong code does not always block a credit, but it gives a reviewer a reason to ask, and a queue of questions is expensive even when it ends in approval.

How the correct code is chosen

Classification starts with the facts of the supply, not with the name of the product. What did the supplier do? Was it design, development, hosting, support, consulting, training or a managed service? Who is liable for the outcome? Is the customer buying capacity, an outcome or advice? The answers narrow the family before any code is selected. A product called a platform can be a hosted service, a licence to use software, a development project or a support contract depending on the contract.

Two legal ideas do most of the work. A composite supply is a bundle naturally supplied together where one element is principal and the others are ancillary; the principal supply determines the classification. A mixed supply is a bundle of separate supplies supplied for one price where no element is principal; the treatment can differ. The distinction is fact-specific. An onboarding fee that is inseparable from a subscription is not the same as a training workshop sold alongside it.

Where the value is material or the position is unclear, an advance ruling is the honest route. It costs time, but it produces a written answer that survives an audit and a change of finance staff. For smaller amounts, a documented internal position reviewed by a chartered accountant is proportionate. What is not proportionate is copying a code from a competitor’s invoice because it looked plausible.

• Describe the supply in plain language before opening any code list.
• Identify the principal element if the supply is composite.
• Check whether the contract splits deliverables or sells one outcome.
• Document the reasoning and the date, not just the number.
• Use an advance ruling for material, recurring uncertainty.

The 9983 family and technology services

Most technology and business services sit in the 9983 group, which covers professional, technical and business services. Within it, 998314 is widely used for information technology design and development services, and it is the code LoopNow’s own glossary cites as a common example while asking readers to confirm the classification with their accountant. Adjacent codes cover consulting, support, hosting and other arrangements. The existence of an adjacent code is exactly why the description has to be specific.

A SaaS subscription is a good test case. The customer is paying for access to a hosted application, with support, updates and uptime commitments. That may look like hosting, like a licence, or like a managed service, depending on how the contract is written and what the supplier actually does. Two companies selling similar dashboards can reasonably reach different classifications if one sells a development project and the other sells access to a running service. The number follows the facts.

The practical approach is to build a small catalogue that maps each product and service line to a code, a description and the reasoning behind the choice. Review it when the product changes, not only when the financial year ends. A new managed service line launched in October should not inherit the subscription code by default, because the supply is different even if the invoice template is the same.

Rate, place of supply and the tax split

The SAC tells you what the service is. The rate notification tells you how it is taxed, and the place-of-supply rules tell you which tax applies. For many business and IT services the notified rate is eighteen percent, which is why software invoices commonly show that figure, but the rate is not a property of the code in the way many teams assume. Exemptions and concessional rates exist for specific services, and a classification change can move a supply between treatments.

Place of supply decides whether you charge central and state tax or integrated tax. For business-to-business services the default is the location of the recipient. For business-to-consumer services the default is the location of the recipient as well, with exceptions for immovable property, event-related services, transportation and a few others. Get the place of supply wrong and the tax heads are wrong even if the total looks plausible, which is a harder error to unwind than a wrong amount.

Exports add another layer. A supply that qualifies as an export of services is zero-rated, and the supplier usually chooses between exporting under a letter of undertaking and paying integrated tax with a refund claim. The SAC still appears on the invoice, and the shipping bill or statement still needs to agree with it. For a team selling to customers outside India, the classification, the place of supply and the export evidence have to be designed together.

Why product and finance teams both care

For finance, the code affects input tax credit, reconciliation and audit. A customer’s accounts payable team compares the invoice with the purchase order, the GST return and the vendor master. A code that changes without explanation triggers a query, and a code that is missing altogether can hold up payment. In a large enterprise the delay is not caused by the tax amount; it is caused by an exception in a workflow that is designed to stop on exceptions.

For product, the code is a constraint on how the offer is constructed. If a bundle mixes a clearly separate service with a subscription, the invoice may need more than one line and the billing system has to support that. If a new product is priced as one monthly fee but delivered as a project plus a retainer, the finance team will eventually ask for a split. Discovering that during an audit is more expensive than designing the billing model with the classification in mind.

The shared artefact is a product-to-code map with an owner. Product supplies the description of what is delivered; finance supplies the classification and the rate; engineering enforces the mapping at invoice creation. When one of the three changes, the map changes in the same release. That is the whole control, and it is enough for most companies.

Common mistakes, and what they cost

The most common mistake is using an HSN code for a service because the billing template was copied from a goods business. The second is using one SAC for the entire catalogue, including training, support and development, because the invoice only ever shows one total. The third is copying a code from another company’s invoice without checking whether the supply is the same. Each of these produces an invoice that looks complete and is hard to defend.

Mismatches between an invoice and its credit note are common and avoidable. If the original line used one code and the credit note uses another, the buyer’s reconciliation breaks and the seller’s return shows a classification change that nobody documented. The same applies to recurring invoices that silently change code after a billing system migration. A code change should be a versioned event with a reason, not a side effect of a deploy.

Rate shopping is the mistake with the sharpest edge. Choosing a code because it appears to carry a lower rate, without a change in the actual supply, is not classification; it is a position that will be tested. The defence is contemporaneous documentation: the contract, the description, the reasoning and the accountant’s review. If those documents do not exist, the number on the invoice is doing work it cannot do.

Worked example: one subscription invoice

Take the Growth plan at ₹7,999 per month, exclusive of GST, supplied to a business customer in the same state. The invoice carries one line for the platform subscription, a description that matches what is delivered, the SAC the company has documented for that supply, a taxable value of ₹7,999 and a rate of eighteen percent. Because the supply is intra-state, the tax splits into central tax of ₹719.91 and state tax of ₹719.91, for an invoice value of ₹9,438.82.

If the same customer were registered in another state, the line would carry integrated tax of ₹1,439.82 instead of the two halves, and the total would be the same ₹9,438.82. The total is not the evidence that the invoice is right. The tax heads, the place of supply and the recipient GSTIN are. A customer once received an invoice with the correct total and the wrong head, and the credit was rejected until a revised invoice was issued.

Now add a one-time onboarding engagement of ₹25,000. That is a separate supply with its own description and its own classification question. If it is genuinely part of a composite supply, the principal supply may govern; if it is a distinct service, it gets its own line. The arithmetic is easy. The judgement is not, which is why the invoice should show the lines rather than hiding the decision inside a single blended figure.

Keeping the classification correct over time

Build a catalogue with one row per billable supply. Each row holds the product name, the customer-facing description, the SAC, the rate basis, the place-of-supply rule and the date the position was last reviewed. Give the catalogue an owner in finance and a reviewer in the product team. The owner is accountable for the code; the reviewer is accountable for the description being true. Neither can do the job alone.

Enforce the mapping where invoices are created. A billing system that accepts a free-text code will eventually contain a typo, and a typo in a six-digit field is hard to spot in a PDF. Validation against the catalogue, a required description and a required place of supply turn classification from a habit into a control. Add an alert when a product’s code changes, and require a reason before the change is saved.

Review the catalogue annually and whenever a new product line launches. Keep the old versions. When a customer or an auditor asks why an invoice from two years ago used a particular code, the answer should be a dated document rather than a recollection. That is a modest amount of administration for a control that protects both the input tax credit and the company’s position.

• One catalogue row per billable supply, with a named owner.
• Validate codes and descriptions at invoice creation.
• Version every code change with a reason and a date.
• Review annually and at every product launch.
• Keep the accountant’s sign-off with the version it approved.