A Guide on ISD Credit Allocation Engine

Introduction

Any large enterprise with a head office and multiple business units across states faces a common GST problem. The head office pays invoices for services that benefit all units – software licenses, audit fees, legal retainers, IT infrastructure, and facility management. Those invoices are raised in the head office’s name. But the credit sitting on those invoices belongs, proportionally, to each unit that uses the service.

The Input Service Distributor (ISD) mechanism exists to solve this problem. It lets the head office distribute input service credit to each unit in the correct proportion, so the credit does not get stuck at the top entity while the actual consuming units cannot claim it.

In practice, however, ISD credit allocation is one of the most calculation-intensive, error-prone workflows in group GST compliance. Determining the correct turnover ratio, applying it correctly to each tax head, handling ineligible credit separately, and filing GSTR-6 accurately every month – all of this has historically been done in spreadsheets with significant manual effort.

An ISD Credit Allocation Engine automates this entire workflow. This blog explains the ISD mechanism in full, how automated proportional allocation works, how custom ratios and turnover-based ratios are handled, what the audit log captures, and how GSTR-6 automation integrates the whole process from end to end.

What Is an Input Service Distributor (ISD)?

An Input Service Distributor is an office of a supplier – typically the head office or corporate office – that receives tax invoices for input services used commonly across multiple business units and distributes the ITC on those invoices to the recipient units through ISD invoices.

ISD is defined under Section 2(61) of the CGST Act, 2017. The mechanism applies only to input services – not to goods (inputs or capital goods). An ISD must take a separate GST registration as an ISD, distinct from its regular taxpayer registration. There is no turnover threshold for ISD registration.

Why ISD Exists

Consider a company with its corporate office in Bangalore and business units in Chennai, Mumbai, and Kolkata. The corporate office receives an invoice for a software license used across all four locations. The entire invoice is raised on the Bangalore entity.

Without ISD, the full ITC would sit with the Bangalore entity. The Chennai, Mumbai, and Kolkata units cannot claim it – even though they use the service and bear the economic cost. The ISD mechanism fixes this by letting the Bangalore office distribute the ITC to each unit in proportion to their turnover.

What ISD Can and Cannot Distribute

A critical point: ISD cannot discharge any tax liability or accept RCM supplies. If the head office wants to take RCM supplies, it must separately register as a regular taxpayer in addition to its ISD registration.

The ISD Registration Requirement

From Budget 2024 onwards, the ISD mechanism has been made mandatory for businesses that have a centralized billing arrangement for common input services across multiple GSTINs. The amendment to Section 20 of the CGST Act requires any office receiving common service invoices to register as ISD and distribute credit through the ISD mechanism rather than through cross-charge. This makes ISD compliance with a non-optional workflow for group entities.

ISD Credit Distribution Rules – The Legal Framework

Before understanding how automation works, it is essential to know exactly what the law prescribes for ISD credit distribution. The allocation engine must model these rules precisely.

Three Types of Input Service Credit for Distribution

The Turnover Ratio Formula

For common input service credit, the GST rules prescribe a specific formula for calculating each unit’s share:

Key points about the turnover ratio:

• Turnover used is from the preceding financial year, not the current month.
• For new units with no preceding year turnover, the turnover of last quarter is used.
• If a unit has no turnover in the preceding year but is operational in the current year, its current year turnover is applied.
• The ratio is recalculated each time a new financial year begins.

Tax Head Treatment in Distribution

The tax head of the distributed credit depends on whether the recipient unit is in the same state as the ISD or a different state:

This tax head conversion is one of the most error-prone steps in manual ISD computation. The allocation engine handles it automatically based on the registered state of each recipient unit.

The Distribution Timeline

Credit available for distribution in a month must be distributed in that same month. The ISD cannot carry forward undistributed credit to future months – except where the credit pertains to a financial year that is still within the ITC claim window under Section 16(4). GSTR-6, the ISD’s monthly return, must be filed within 13 days after the end of the month.

How the ISD Credit Allocation Engine Works Automatically

The ISD Credit Allocation Engine is the computational layer that translates the legal rules above into precise, audit-ready credit splits for every invoice every month. Here is how it works step by step.

Step 1 – Invoice Ingestion and Classification

The engine starts by ingesting all invoices received by the ISD entity in the month. Each invoice is classified into one of three categories:

• Exclusively attributable: The invoice is for a service used only by one unit. The supplier or the finance team flags this at the point of invoice booking. The full ITC goes to that unit directly.
• Common to multiple units: The service benefits more than one unit. The turnover-ratio engine kicks in for these invoices.
• Ineligible: The service is blocked under Section 17(5) or is linked to exempt supplies. The credit is still distributed – but marked as ineligible – so recipient units do not wrongly claim it.

The classification can be set up as a rule in the system.

Step 2 – Turnover Data Load and Ratio Computation

Once invoices are classified as common, the engine needs the turnover data for each recipient unit. This is pulled from one of three sources depending on the system setup:

• ERP integration – turnover data flows automatically from the accounting system.
• Manual upload – finance team uploads turnover details at the start of the financial year.

The engine uses the preceding financial year’s turnover by default. For new units, it switches to current year turnover automatically. The distribution ratios are computed automatically at the time of distribution. They are applied uniformly to all common invoices throughout the year unless manually overridden.

Example: ISD at Mumbai. Three recipient units – Delhi (40% turnover share), Chennai (35%), Hyderabad (25%). For any common service invoice of Rs 1,00,000 ITC (IGST), the engine allocates: Delhi Rs 40,000, Chennai Rs 35,000, Hyderabad Rs 25,000 – automatically, in the same month the invoice is received.

Step 3 – Tax Head Conversion

After computing the credit amount for each unit, the engine determines the correct tax head for distribution:

• Mumbai ISD distributing to a Delhi unit: CGST and SGST at ISD get converted to IGST for distribution.
• Mumbai ISD distributing to another Mumbai unit: CGST stays CGST, SGST stays SGST.
• IGST at ISD goes to all units as IGST regardless of their location.

The engine looks up the registered state of each recipient GSTIN from the master data and applies the conversion rule automatically. No manual intervention is needed.

Step 4 – ISD Invoice Generation

Once the credit split is computed, the engine generates ISD invoices – one for each recipient unit – containing:

• ISD’s GSTIN and name.
• Recipient unit’s GSTIN and name.
• Original supplier’s invoice reference.
• Credit amount being distributed (eligible and ineligible separately).
• Tax head – CGST/SGST or IGST as applicable.
• Period of distribution.

These ISD invoices are the legal document of credit transfer. They must clearly state that they are issued for distribution of ITC only – not for any supply of goods or services.

Step 5 – GSTR-6 Population

The ISD invoices flow directly into the GSTR-6 draft. The engine populates:

• Table 3 – Details of ITC received by the ISD (from supplier invoices) for distribution.
• Table 4 – Total ITC Available and eligible/ineligible ITC distributed
• Table 5 & 8- distribution of ITC (ISD invoices and ISD credit notes)
• Table 6A, 6B, 6C – Amendment details of Invoice, Debit notes and Crdit notes.
• Table 7 – Summary of credit distributed.

The GSTR-6 is validated within the platform before filing. Validation checks include GSTIN format of all recipient units, arithmetic consistency of total distributed vs total received, and tax head correctness. Filing happens directly to the GST portal via API.

Turnover-Based Allocation vs Custom Ratios

The GST law prescribes turnover ratio as the default method for common credit allocation.

Turnover-Based Proportional Allocation (Statutory Default)

This is the prescribed method under Rule 39 of the CGST Rules, 2017. The ratio is based on the turnover of each recipient unit in the State for the preceding financial year.

Worked Example – Turnover-Based Allocation

Common ITC available: Rs 12,00,000 IGST received at the Mumbai ISD.

The allocation engine computes this in seconds once the turnover data and invoice amount are entered. No spreadsheet required.

The Audit Log – What It Captures and Why It Matters

Every ISD credit allocation decision needs to be defensible. If a GST officer questions why Unit B received Rs 3,60,000 of IGST credit in March and not Rs 4,20,000, the answer must come from a documented, timestamped record – not from a spreadsheet that has been updated several times since.

The audit log is the backbone of that defensibility. A well-designed ISD Credit Allocation Engine captures the following for every distribution event:

What the Audit Log Records

How the Audit Log Is Used in Practice

• Audit and scrutiny: When a GST officer sends a notice asking why a particular unit’s ITC is higher than expected, the CA pulls the audit log for that period and provides a structured response with invoice references, ratios, and ISD invoice numbers.
• Annual reconciliation: At year-end, the audit log provides a complete picture of all credits distributed across units, the method used, and the original invoices. This feeds directly into the GSTR-9 annual return and the reconciliation statement.
• Internal audit: Group finance teams use the audit log to verify that credit has been distributed correctly and consistently across the year – catching any period where the wrong ratio was used or an invoice was missed.
• Dispute resolution: If a recipient unit disputes the credit it received, the audit log shows exactly what was distributed, from which invoice, on what basis, and what the ISD invoice number is for cross-checking with their GSTR-2A.
• Tax department review: During a GST audit, auditors look at ISD invoice trails to verify that credit distributed matches credit claimed by recipient units. The audit log provides this trail in a structured, exportable format.

An audit log is not just a compliance feature. It is a risk management tool. Every ISD credit allocation decision has a financial consequence for the recipient unit. A clean, complete log means every decision can be explained, every number can be traced, and every deviation can be justified.

GSTR-6 Automation – From Allocation to Filing

GSTR-6 is the monthly return filed by the ISD. It must be filed by the 13th of the following month. It captures all ITC received by the ISD and all ITC distributed to recipient units through ISD invoices.

Manual GSTR-6 preparation involves compiling supplier invoices, computing ratios, generating ISD invoices, mapping each distribution to the correct table, and verifying totals before filing. For a group with 10 to 20 recipient units and 50 to 100 monthly invoices, this is a 2-to-3-day exercise. Automated GSTR-6 compresses it to a review-and-file workflow.

The End-to-End GSTR-6 Automation Flow

1. Invoice receipt and GSTR-6A sync: The platform syncs supplier invoice data from GSTR-6A automatically. All invoices received by the ISD GSTIN appear in the system without manual entry.
2. 6A Reconciliation: The reconciliation process compares ISD Purchases recorded in the PR against 6A data synced from the Government Portal, with the resulting discrepancies categorized into distinct buckets.
3. Ratio application: The configured turnover ratios are applied. Credit amounts for each unit are computed and displayed for review.
4. Tax head conversion: The system converts CGST/SGST to IGST for out-of-state units automatically based on each recipient’s registered state.
5. ISD invoice generation: ISD invoices are generated for each recipient unit with auto-assigned invoice numbers. These are saved to the platform and shared with recipient units electronically.
6. GSTR-6 population: The allocation data maps to the correct GSTR-6 tables. The draft return is populated and displayed for review.
7. Validation: Pre-filing validation checks for GSTIN errors, arithmetic consistency, tax head mismatches, and missing invoices.
8. Filing: One-click to file to the GST portal via API. Filing confirmation and acknowledgement numbers are captured and stored.
9. Recipient notification: Recipient units are notified of the ITC distributed to them, with the ISD invoice reference and amount. They can reconcile this against their GSTR-2A/2B.

A group entity that previously spent 3 days on monthly ISD computation and GSTR-6 filing completes the same workflow in 3 to 4 hours with automation – primarily for the invoice classification review and final approval before filing.

GSTR-2A Reflection for Recipient Units

Once the ISD files GSTR-6, the distributed credit appears in the recipient units GSTR-2A for the same month. The recipients can see the ISD invoice details – the ISD’s GSTIN, the credit amount, and the tax head – and can match it against the ISD invoice they received. This auto-reflection eliminates the need for manual communication of credit details between the ISD and its recipients.

Challenges of Manual ISD Credit Allocation

Understanding what goes wrong without automation is the clearest argument for an allocation engine.

ISD Credit Allocation on Cygnet’s Platform

Cygnet’s GST platform includes a dedicated ISD Credit Allocation Engine that integrates the full workflow – from invoice ingestion to GSTR-6 filing – in one place. For group entities managing ISD compliance across multiple registrations, the platform eliminates the spreadsheet-based manual process entirely.

Platform Capabilities

What This Means for Group Tax Teams and CAs

• No spreadsheet maintenance: Turnover ratios are loaded once. The engine applies to them every month without any re-entry.
• No tax head conversion errors: The system knows the registered state of every recipient GSTIN and converts automatically. This is the most common source of GSTR-6 errors in manual workflows.
• No missed deadlines: The 13th-of-the-month GSTR-6 deadline is built into the platform’s compliance calendar with pre-deadline alerts.
• No ineligible credit mix-up: Invoice-level classification ensures ineligible credit is always separated and flagged before distribution.
• Audit-ready always: The audit log is complete, exportable, and structured for direct use in notices, audits, or internal reviews.

For a group entity with 15 recipient units and 80 common service invoices per month, Cygnet’s ISD allocation engine reduces the monthly ISD workflow from 3 days of manual computation to a 3-hour review and approve cycle – while producing a more accurate, documented, and audit-ready output.

Conclusion

ISD credit allocation is one of the most technically complex monthly compliance tasks in group GST management. The rules are precise – turnover ratios from the preceding year, tax head conversion based on recipient state, separate handling of ineligible credit, ISD invoices with specific format requirements, and GSTR-6 filing within 13 days. Each of these steps is error-prone when done manually, and each error has a direct financial consequence for the recipient units.

An ISD Credit Allocation Engine removes that error risk. It ingests invoices, applies the statutory turnover ratio or configured custom ratios, converts tax heads, generates ISD invoices, populates GSTR-6, and maintains a complete audit log – automatically, every month, with the accuracy and documentation that manual spreadsheets cannot consistently deliver.

For group entities managing 10 or more recipient units, the value is immediate: faster processing, fewer errors, clean audit trails, and recipient units that receive their correct credit on time every month. For CAs managing group GST compliance across multiple clients, the platform removes the most time-intensive part of the ISD workflow and replaces it with a review-and-approve process that takes hours, not days.

The combination of automated proportional allocation, flexible custom ratio support, structured audit logging, and direct GSTR-6 filing is what makes the ISD Credit Allocation Engine a compliance necessity for any group entity operating under the mandatory ISD framework.

FAQs