Multi-State GST Registration: Running One Business as Several Tax Entities

One company does not mean one GST unit

A retailer may have one legal company, one PAN, one brand and one annual financial statement. Add warehouses or places of business across Karnataka, Maharashtra, Delhi and Tamil Nadu, and the operational model changes. GST registration, invoicing, input tax credit, returns and inter-state movements must follow the appropriate state registration.

Section 25 of the CGST Act requires a person liable to register to apply in each State or Union territory where that liability arises. It also treats multiple registrations of the same person—within one state or across states—as distinct persons for GST purposes. CBIC's sectoral FAQ gives the practical consequence: a movement from a unit in one state to a branch in another can be a taxable supply between distinct persons even without consideration.

The ERP therefore needs two truths at once:

• the company is one legal and financial reporting person for some purposes;
• each GSTIN is a distinct transactional and tax-reporting unit for GST.

Flattening either truth creates errors.

This article explains system design, not case-specific tax advice. Registration liability, valuation, place of supply, input tax credit and documentation should be reviewed under current law with a GST professional.

Model a GST registration as more than an address

Many systems store GSTIN only on the invoice header. That is too late. A GST registration controls master data and process throughout the transaction.

Create a registration master containing:

• GSTIN and legal name;
• trade name;
• PAN and legal entity;
• state or Union territory and state code;
• registration type and effective date;
• principal and additional places of business;
• registration status and cancellation date;
• authorised invoice series;
• linked warehouses, stores, cost centres and bank arrangements;
• return calendar and responsible team;
• permitted document and transaction types;
• e-invoice and e-way-bill configuration where applicable;
• input tax credit and reverse-charge settings;
• source and date of last verification.

The GST Portal's taxpayer search manual describes public verification of details including GSTIN, legal and trade names, registration status, principal place of business and return filing information. Use authoritative records to validate the master rather than relying on vendor spreadsheets.

Effective dates matter. An invoice issued before a new registration becomes effective cannot be repaired merely by changing today's customer or branch master.

Choose the right ERP architecture

There are three common patterns.

One company code with GSTIN dimensions

The statutory company remains one ledger; each transaction carries a GST registration dimension. This simplifies financial consolidation and shared banking, but demands strong controls to prevent cross-GSTIN posting and mixed document sequences.

One operational ledger or company code per GSTIN

Each registration has stronger transaction isolation, local stock and tax controls. Consolidation becomes more involved, and internal movements may create both GST documents and financial inter-unit entries.

Hybrid design

One legal-entity ledger contains controlled registration subledgers, locations and tax books. This can provide isolation without multiplying every financial structure.

No architecture is universally correct. Choose based on transaction volume, ERP capability, statutory reporting, centralisation, inventory ownership and control risk. Whatever the design, it must provide GSTIN-level trial balance or tax reconciliation, document traceability and consolidated legal-entity financial statements.

Do not use a cost centre alone as a GSTIN. Cost centres describe management responsibility and can change; registrations carry legal identity and tax rules.

Determine the supplying GSTIN before invoicing

The system should determine the supplying registration from the actual transaction, not from a user's preferred state.

Inputs can include:

• legal entity and order-owning unit;
• place from which goods are dispatched;
• warehouse ownership and registration;
• location from which services are supplied;
• contract and customer order;
• bill-to and ship-to locations;
• item or service type;
• fulfilment route;
• applicable place-of-supply rules.

If the order changes warehouse or fulfilment location, tax determination must rerun before dispatch. A marketplace order originally assigned to Maharashtra but fulfilled from Karnataka cannot retain the first registration merely to avoid document change.

Store the facts used in determination. An invoice should be reproducible after master data changes.

Customer and supplier masters need registration-level records

One customer may have several GSTINs and delivery locations. Treat the commercial party and its tax registrations as related but distinct records.

For each customer GST registration, retain GSTIN, legal name, state, status, addresses, effective dates and evidence. An order should select the correct bill-to GSTIN and ship-to address; tax determination uses both where relevant. Prevent users from typing a GSTIN directly onto the invoice without validation.

Supplier design follows the same logic. A vendor group may issue from different registrations. Purchase order, receipt and invoice must agree on supplier GSTIN and recipient GSTIN. A mismatch should enter an exception queue, not silently post to a generic tax account.

Central vendor and customer governance reduces duplicates, but local teams need a fast correction workflow. Blocking a genuine shipment because a master-data ticket waits for days encourages workarounds.

Inter-state stock transfers are not simple warehouse moves

In a single-state inventory system, moving stock between warehouses changes location but not ownership or revenue. Between GST registrations treated as distinct persons, the movement may require a supply document, valuation, tax, e-way bill and corresponding recipient entry, depending on the facts and current requirements.

The ERP flow should connect:

1. transfer request and replenishment reason;
2. supplying and receiving GSTIN;
3. item, quantity and valuation basis;
4. tax invoice or applicable document;
5. tax calculation;
6. dispatch, e-way-bill reference where required and goods issue;
7. goods in transit;
8. receipt and quantity exception;
9. recipient tax record and eligible credit workflow;
10. inter-unit settlement or elimination.

Do not generate an external customer sale for management reporting merely because a GST invoice exists. Use internal supply accounts or dimensions that can be eliminated in consolidated financial reporting while retaining the taxable transaction.

Goods in transit need visibility by supplying GSTIN, receiving GSTIN, document and expected arrival. Month-end should identify dispatches not received, receipts without source invoice, quantity differences and tax posted before operational confirmation.

Valuation must be configured and evidenced

Supplies between distinct persons need a defensible value under applicable GST valuation rules. The system should not default automatically to zero because no external customer pays.

Maintain the approved method by transaction class, inputs used, effective date and reviewer. The appropriate value may depend on open-market information, like kind and quality, cost or other rules and provisos relevant to the facts, including recipient credit eligibility. Do not embed one hard-coded percentage without tax approval.

Where transfer pricing or management-cost policies also apply, keep their objectives distinct from GST valuation. One internal amount may serve several processes only when it satisfies each requirement and is consistently evidenced.

Analyse manual valuation overrides, unusual margins and transfers missing a method. Preserve calculation inputs with the document so later master-data changes do not alter historical evidence.

Separate tax ledgers and credit by GSTIN

CBIC's GST FAQ states that where a firm is registered in more than one state, each registration is treated as a separate registered person and credit cannot simply be cross-utilised between them. An enterprise dashboard may show group-wide credit, but the posting and usable balance belong to the relevant registration and tax heads under applicable rules.

Maintain registration-specific accounts or subledger dimensions for:

• input CGST, SGST or UTGST and IGST;
• output CGST, SGST or UTGST and IGST;
• reverse-charge liability and related credit;
• credit temporarily blocked, disputed or ineligible;
• cash and credit ledger reconciliations;
• interest, late fee and other adjustments;
• refund or carry-forward positions.

The ERP must prevent a journal from moving tax credit between GSTINs as if it were cash. Management may decide where to procure or invoice based on legitimate operational and tax considerations, but it cannot cure a stranded balance with an unsupported ledger transfer.

Reconcile input tax credit as a document process

Input credit depends on more than a debit in the purchase ledger. Build a reconciliation workflow matching purchase order, receipt or service evidence, supplier invoice, GSTINs, taxable value, tax amount and relevant portal data.

Exception reasons should be structured:

• supplier invoice not reflected in available statement data;
• wrong recipient GSTIN;
• value or tax mismatch;
• duplicate invoice;
• goods or service not received;
• credit note pending;
• supplier registration issue;
• blocked or ineligible category;
• timing difference;
• reverse-charge treatment;
• master-data error.

Assign each exception to procurement, receiving, accounts payable, tax or supplier follow-up. Record ageing and financial exposure. A spreadsheet that marks invoices “matched” without preserving source, date and rule is weak evidence.

The same invoice number can legitimately exist under different supplier GSTINs; matching keys need registration, document number, date and other relevant identifiers.

Shared services and common input costs require a policy

Head office may procure software, advertising, professional services and other inputs benefiting several registrations. The tax and ERP design must determine which registration receives the invoice and how costs or eligible input tax are allocated or distributed under applicable mechanisms.

CBIC materials describe the Input Service Distributor mechanism and distribution of credit to recipient units. Other inter-unit service and cross-charge questions depend on facts and current law. Configure only the method approved for the organisation's circumstances.

The ERP should preserve:

• original supplier invoice and recipient GSTIN;
• beneficiary registrations;
• allocation basis and period;
• tax eligibility by component;
• ISD or internal document where applicable;
• turnover or other driver source;
• approvals and reconciliation to recipient records.

Shared cost allocation for management accounting is not automatically the same as tax-credit distribution. Keep separate calculation layers where required and reconcile them.

Invoice series and document control

Each supplying GSTIN needs controlled document numbering by document type and financial year in line with applicable requirements. Configure tax invoice, bill of supply, debit note, credit note, delivery challan and other relevant documents separately.

Prevent duplicate numbers within the required scope. Voided documents should remain in the sequence with reason, user and timestamp. Never delete an invoice to remove a gap.

Credit notes must reference the original supply and correct GSTIN. A credit raised from the head-office registration against a sale made by another state does not repair the original tax record.

Returns and cancellations need an operational link. When goods return to a different warehouse, determine whether an internal movement is also required to restore stock to the appropriate registration.

E-commerce makes registration determination operational

Marketplace and direct-to-consumer orders can be routed dynamically. The order-management system, warehouse system and ERP must share the same GSTIN and tax decision.

At order allocation, reserve stock owned by the intended supplying registration. At pack, verify that the physical warehouse and registration still match. At invoice, freeze tax facts. At cancellation or return, reverse the correct registration and document. Track marketplace fees, tax collected at source where applicable and settlement deductions by GSTIN.

Do not let a marketplace SKU map to one default GSTIN nationally. The same SKU may be fulfilled from several states, but each unit of stock and order needs a specific owner and supply path.

GSTIN-level month-end close

Run close controls for every registration before consolidating:

• sales register to output tax and return preparation;
• purchase register to input tax and reconciliation status;
• stock transfer dispatch to receipt;
• e-invoice and e-way-bill references to source documents where applicable;
• credit and debit notes to originals;
• reverse-charge transactions and payment or credit treatment;
• tax subledger to general ledger;
• electronic ledger balances to books;
• invoice sequence and cancellation review;
• registration status, new locations and master-data changes;
• unresolved inter-unit balances.

Then consolidate the legal entity. Eliminate internal revenue, cost and receivables or payables according to accounting policy without deleting the GST documents. The tax view and the consolidated financial view must reconcile through explicit elimination entries.

Governance for a growing state footprint

Expansion teams often lease premises, store stock or commence activity before tax and ERP teams understand the plan. Create a registration and location-readiness gate.

The gate should cover liability assessment, registration evidence, place-of-business master, invoice configuration, warehouse ownership, tax codes, bank and payment setup, returns ownership, customer and vendor communication, stock-opening process and go-live date.

No warehouse should receive saleable stock until its registration relationship and system ownership are approved. No sales channel should route orders until invoicing and returns are tested.

When a registration is cancelled or a location closes, stop new transactions, resolve inventory, credits, open orders, advances, returns and documents, then preserve records. Deactivation is a controlled process, not deletion of the GSTIN from the master.

A scenario-based test pack

Before go-live, test at least:

1. local sale within a state;
2. inter-state customer sale;
3. bill-to and ship-to involving different states;
4. stock transfer between registrations;
5. partial dispatch and partial receipt;
6. customer return to original and alternate locations;
7. supplier invoice addressed to the wrong GSTIN;
8. shared head-office service allocation;
9. credit note after a tax-period boundary;
10. order rerouted after stock reservation;
11. registration effective-date change;
12. month-end goods in transit and return reconciliation.

Trace each scenario from order to stock, document, tax posting, portal output, settlement and consolidated reporting.

FAQ

Is every GSTIN a separate legal company? No. Several GSTINs can share one PAN and legal entity. They are treated as distinct persons for GST, which requires transaction and tax separation without necessarily creating separate Companies Act entities.

Can input credit from one state be used in another state's GSTIN? Not by a simple cross-ledger transfer. Each registration's credit and utilisation follow GST rules. Approved distribution or supply mechanisms may apply to particular facts.

Does an inter-state branch transfer need an invoice if no money changes hands? Transfers between distinct persons can constitute supplies even without consideration. The exact document, value and tax treatment should be determined under current rules.

Should the ERP use one company code per GSTIN? Not necessarily. A controlled registration subledger can work. The chosen design must isolate documents and taxes by GSTIN and reconcile to one legal-entity financial view.

Can one warehouse fulfil orders for several GSTINs? Only with a system and operating model that clearly controls stock ownership, registration, documentation and place-of-business requirements. Physical co-location must not blur tax identity.

Where a system helps

A multi-registration ERP can determine the correct GSTIN before fulfilment, separate stock and tax by registration, automate internal supply documents, reconcile input credit and consolidate financial reporting without losing state-level evidence. Exception workflows make mismatches visible before return filing.

Explore RetailOS for SMB ERP.

Related reading: UAE Trade Licence Activities and Your ERP Chart of Accounts (KB-461) and Omnichannel Stock Accuracy (KB-464).

Sources

• CBIC, Central Goods and Services Tax Act — Section 25
• CBIC, GST Registration Rules
• CBIC, Sectoral FAQs
• GST Portal, Search Taxpayer Manual