Data retention policies in e-invoicing

Data retention policies in e-invoicing

For any Indian business now required to generate e-invoices, every Invoice Reference Number (IRN) created today may become critical evidence in a tax dispute that surfaces years later. Under Rule 56(20) of the CGST Rules 2017, GST records must be retained for 72 months from the annual return due date — but adding the Income Tax Act's six-assessment-year rule and the Companies Act's eight-financial-year obligation means FY 2026-27 records must survive until 31 March 2035. Layer in the Digital Personal Data Protection Act, 2023 and you face a four-statute compliance problem that demands one coordinated, documented policy — not four separate afterthoughts.

What e-invoice data you actually need to retain

Most finance teams file the PDF and move on. That is not enough. The complete e-invoice artefact set consists of six distinct categories, and a gap in any one of them can cost you in an audit.

Artefact 1 — The outbound JSON payload: The structured invoice data your ERP or billing system pushes to the Invoice Registration Portal (IRP). This is the primary record of supply details, HSN/SAC codes, applicable tax rates and the counter-party's GSTIN.

Artefact 2 — The signed JSON and IRN response: What the IRP returns after validation — a 64-character SHA-256 IRN, a digitally signed invoice JSON, and an embedded QR code payload. This is your legal proof that the invoice was reported to the government. Without it, the invoice is not valid under Rule 48(5) of the CGST Rules. This artefact, specifically, is what an assessing officer will ask for first.

Artefact 3 — Cancellation records: Cancelled IRNs must be retained in full, including the reason code and cancellation timestamp. Cancellation is only allowed within 24 hours of IRN generation; after that, a credit note carries its own IRN. Both the original and the credit note records must co-exist in your archive.

Artefact 4 — Linked e-way bill data: Where an e-way bill was auto-generated from the e-invoice JSON (Part A pre-populated by the IRP), the e-way bill number and its final status form part of the supply chain evidence.

Artefact 5 — Supporting commercial documents: Purchase orders, contracts, delivery challans and proof of payment. In a transfer-pricing enquiry, a Section 40A(2) disallowance proceeding, or a commercial dispute, these give context that the IRN alone cannot.

Artefact 6 — Buyer-side IRNs: Buyers must retain their suppliers' signed IRNs independently. If a supplier is later cancelled or deregistered for GST, the buyer's Input Tax Credit (ITC) defence on past transactions rests entirely on its own archived copy of the supplier's signed JSON — not on a portal lookup that may no longer function.

Build your retention system around all six categories from day one.

The statutory retention matrix

Three statutes — plus the IT Act as a procedural baseline — set the minimum retention periods. The longest applicable period governs. You cannot default to the shortest.

Section 35 of the CGST Act and Rule 56(20)

Section 35(1) of the Central Goods and Services Tax Act, 2017 places a positive obligation on every registered person to maintain a true and correct account of all records and documents. The minimum retention period is prescribed in Rule 56(20) of the CGST Rules, 2017: 72 months from the due date of furnishing the annual return (GSTR-9) for the financial year to which those records relate.

GSTR-9 for FY 2026-27 has historically been due by 31 December 2027 (verify the notified deadline on the GST portal, as due dates are periodically extended). That means every e-invoice record from FY 2026-27 must be retained until at least 31 December 2033 under GST law alone.

The rule contains a critical extension clause: if you are under audit, scrutiny, or are a party to an appeal or investigation under Chapter XIX of the CGST Act, retention extends to one year after the final disposal of that proceeding — whichever is the later date.

Income Tax Act 1961: six assessment years

Rule 6F(5) of the Income Tax Rules, 1962 requires books of account and supporting documents to be preserved for six years from the end of the relevant Assessment Year. For FY 2026-27 (Assessment Year 2027-28), that window closes on 31 March 2034. A Section 147 re-opening or a search/survey under Section 132 can extend this further depending on the proceedings.

Companies Act 2013: eight financial years

Section 128(5) of the Companies Act, 2013 requires every company to maintain books of account for not less than eight financial years immediately preceding the current financial year. In practice, records from FY 2026-27 cannot be destroyed until FY 2034-35 is underway — that is, not before 1 April 2035. For most companies, this is the longest statutory clock.

IT Act 2000: the electronic records baseline

Section 7 of the Information Technology Act, 2000 confirms that electronic records satisfy any statutory retention obligation — but only if they remain accessible, legible and unaltered throughout the required period. This has direct implications for archive format. A proprietary ERP export format that may not be renderable in 2035 fails this test. Standard formats — JSON, PDF/A, CSV — are the defensible choice.

The governing retention window at a glance

If any proceeding is open, add one year after final disposal to the relevant statutory deadline.

Why the IRP is not your archive

This is the single most dangerous misconception in practice. The IRP is a reporting and validation portal, not a long-term archive. The NIC-operated IRP — and the other authorised IRPs — are designed to register invoices at the moment of generation and confirm their authenticity. Post-generation retrieval from the portal is possible for a limited period, but you cannot reasonably expect reliable portal-based retrieval eight years from now. Neither CBIC nor GSTN has positioned the IRP as a substitute for your own record-keeping obligation.

The practical consequence: if your team generates IRNs but does not immediately download and store the signed JSON response in your own infrastructure, you are creating an unrecoverable compliance gap in real time.

Similarly, the GSTN's AIS (Annual Information Statement) and TIS (Taxpayer Information Summary) capture summarised transaction data for income-tax matching purposes. They do not carry the complete signed e-invoice payload, the QR code content, or the cancellation trail. They are not a substitute for the original IRN-signed JSON.

The fix is straightforward: build a post-IRN webhook or API polling step into your billing workflow so that the signed JSON is written to your own storage system automatically at the point of generation — not retrieved as an afterthought when a notice arrives.

The DPDP Act overlay: when invoices carry personal data

The Digital Personal Data Protection Act, 2023 and the DPDP Rules notified in 2025 apply wherever e-invoice data contains personal data — that is, data relating to an identified or identifiable natural person.

B2B invoices addressed to registered companies typically fall outside the DPDP scope for the invoice data itself, because DPDP covers natural persons, not legal entities. However, proprietorship invoices (where the GSTIN belongs to an individual proprietor), partnership firm invoices that record partners' names or addresses, and B2C invoices in categories where they are now mandated — all carry personal data and attract DPDP obligations on the data fiduciary generating them.

The tension is real: GST and Companies Act law require long retention; DPDP's storage limitation principle requires deletion once the purpose is fulfilled. The resolution is available but must be explicitly documented:

1. Identify personal data fields in your e-invoice artefacts — buyer name, address, PAN, contact details where present in the JSON schema.
2. Document the overriding legal obligation: CGST Rule 56(20), Companies Act Section 128(5) and Income Tax Rule 6F(5) constitute statutory obligations that supersede the DPDP storage limitation principle for those specific fields and that specific duration.
3. Apply data minimisation at the point of collection: do not capture personal fields beyond what the e-invoice JSON schema requires for compliance.
4. Implement reasonable security safeguards as mandated under Schedule I of the DPDP Act. Failure to do so attracts a penalty of up to Rs. 250 crore per incident for significant data fiduciaries; for others, the Board may impose a penalty as notified.
5. Operationalise data principal rights: if an individual data principal requests correction or erasure, respond in writing, explaining that the overriding legal retention obligation applies and erasure cannot be completed until the statutory deadline passes. Document this response for your compliance file.

Designing a tiered storage architecture

An eight-year retention obligation does not require eight years of live database storage. A three-tier model balances retrieval speed against cost and security risk.

Tier 1 — Hot storage (current FY + prior FY)

Your active ERP or billing system, with full-text and IRN-based search. This covers the period when invoices are most frequently referenced: GSTR-1 and GSTR-3B reconciliation, ITC claims and disputes, e-way bill queries, credit note matching and audit trail requests during the current assessment cycle. Retrieval target: within seconds.

Tier 2 — Warm storage (Years 3–4)

A structured, indexed repository — a cloud object store with metadata tagging by GSTIN, invoice date and IRN, or an on-premises document management system with search capability. Used for responding to tax notices, refund applications and assessment proceedings. Retrieval target: within minutes.

Tier 3 — Cold archive (Years 5–8+)

Compressed, AES-256 encrypted, write-once-read-many (WORM) storage. This is where the bulk of your 72-month and eight-year obligation lives, at minimal ongoing cost. Critical requirements for this tier:

• Archive in open standard formats: JSON for the signed payload, PDF/A for human-readable versions
• Generate and store a SHA-256 hash of each archived file to provide cryptographic proof of non-tampering
• Store the hash index separately from the archive itself (so tampering with one does not compromise the other)
• Define and enforce a destruction protocol (see below) — the WORM property ensures no accidental deletion

Worked example: retention deadlines for a real FY 2026-27 invoice

Scenario: A Bengaluru-based manufacturer (turnover Rs. 80 crore in FY 2026-27) generates 4,800 e-invoices during the year. One invoice — IRN dated 15 July 2026, invoice value Rs. 14,20,000 for a B2B supply to a Pune buyer — is later disputed. The buyer claims short-delivery in FY 2029-30 and files a civil suit. The GST department opens a scrutiny assessment of the seller in January 2028.

Retention deadlines for this single invoice:

• CGST Rule 56(20): 31 December 2033 as baseline; extended to one year after final disposal of the scrutiny assessment (potentially 2030 or later)
• IT Act Rule 6F(5): 31 March 2034
• Companies Act Section 128(5): 31 March 2035
• Civil proceedings: retain until final decree plus one year (timeline uncertain but potentially 2031–2033)
• Governing deadline: 31 March 2035, or later if proceedings extend beyond that

What the company must produce if called: The IRP-signed JSON for that specific IRN, the linked e-way bill record, the delivery challan, evidence of the buyer's GSTIN status at the time of supply, and the GSTR-1 filing entry confirming the IRN was reported in the correct return period. If any of these are unavailable because the business relied on portal retrieval rather than local archival, its ITC position (for the buyer), its output tax defence (for the seller), and its civil litigation posture are all simultaneously weakened.

Cost of non-compliance: Under Section 122(1)(xiii) of the CGST Act, failure to maintain required accounts and records attracts a minimum penalty of Rs. 10,000 or the amount of tax evaded, whichever is higher. If the assessing officer treats missing records as indicative of Rs. 20 lakh of undisclosed output tax — a conservative assumption on a Rs. 14.2 lakh invoice in a scrutiny context — the demand alone is Rs. 20 lakh. Add 18% interest per annum on the tax for five years: approximately Rs. 18,000 per month × 60 months = Rs. 10.8 lakh in interest before any penalty is levied. The total cost of one incomplete archive: upward of Rs. 30 lakh, exclusive of litigation fees.

Common mistakes and how to fix them

Mistake 1: Retaining the ERP export but not the signed IRP JSON The ERP export is your internal record. The signed IRP JSON is the government-authenticated record. Both are necessary; the signed JSON is the one that will be demanded in any formal proceeding. Fix: Automate a post-IRN API call that writes the raw IRP response to your archive immediately on generation. Treat it as mandatory as booking the accounting entry.

Mistake 2: Deleting cancelled IRNs Cancelled invoices remain part of your audit trail. The cancellation record — reason code, cancellation timestamp and IRN — must be preserved for the same 72-month period. Deletion of cancelled invoices is one of the most common omissions found in GST audits. Fix: Configure your system to mark cancelled invoices as archived-not-deleted.

Mistake 3: Storing data in personal email or unmanaged shared drives This fails the IT Act's accessibility and integrity requirement and violates the DPDP Act's security safeguard obligation simultaneously. Fix: Move to a business-grade, access-controlled system with audit logging. Even a well-configured cloud storage account with role-based access and versioning is materially better than a shared drive.

Mistake 4: Ignoring buyer-side retention Buyers focus on their own invoice generation and overlook the obligation to archive supplier IRNs. Where a supplier later becomes GST-inactive, the buyer's ITC on prior-period transactions is defensible only from its own archived copy of the signed JSON. Fix: Build supplier IRN archival into your purchase-to-pay workflow, not just your accounts-payable process.

Mistake 5: Calculating the destruction date from the invoice date The retention clock under Rule 56(20) starts from the GSTR-9 due date — not the invoice date, not the financial year end. An invoice from 1 April 2026 still falls under FY 2026-27, and retention runs from the GSTR-9 due date for that year. Fix: Parameterise your destruction workflow against return due dates, not document creation dates.

Mistake 6: No format migration plan An archive format that cannot be rendered in 2035 is legally useless regardless of how well it was stored. Fix: Schedule a format review every three years. Convert to current open standards before obsolescence, regenerate SHA-256 hashes after conversion, and document the migration in your policy file.

Step-by-step: building a defensible retention policy document

A policy that exists only in writing but is never operationalised offers no real protection. Follow this sequence.

1. Inventory your artefacts: Map all six categories of e-invoice data against your current systems and confirm which categories are actually being captured, stored and retrievable today.
2. Build a retention schedule: Apply the matrix from the statutory section above. Use 31 March 2035 as the baseline destruction date for FY 2026-27 records. Flag any open proceedings that extend this baseline.
3. Define storage tiers and automate transitions: Document which system hosts Tier 1, 2 and 3 data, who has access to each, and the retrieval SLA. Automate the move from Tier 1 to Tier 2 at the start of Year 3 and from Tier 2 to Tier 3 at the start of Year 5.
4. Document DPDP lawful bases: For every artefact containing personal data, record the overriding legal obligation that justifies retention beyond any DPDP storage limitation default.
5. Write a destruction protocol: Destruction requires — at minimum — (a) written confirmation that the governing deadline has passed and no proceedings are open; (b) authorisation from a named officer (CFO, Tax Head or equivalent); and (c) a signed destruction certificate retained permanently.
6. Train staff and log attendance: Finance, tax and IT teams must be trained at onboarding and refreshed annually. An untrained team is a liability even when the written policy is correct.
7. Conduct an annual records audit: Retrieve three random IRNs from Tier 2 or Tier 3 each year, verify legibility and completeness, and document the test result. This creates contemporaneous evidence of a functioning policy — useful in any regulatory inspection.
8. Schedule an annual policy review on 1 April: Tie the review to CBIC, CBDT, MCA and MeitY notification trackers. Any change in GSTR-9 due dates, IRP technical standards or DPDP Rules triggers an immediate revision, not a wait for the annual cycle.

Key takeaways

• The governing retention period for FY 2026-27 e-invoice records is 31 March 2035 — set by the Companies Act's eight-financial-year obligation, which is longer than both the CGST 72-month and the Income Tax six-assessment-year clocks.
• The IRP is a registration portal, not a long-term archive. Download and store the signed IRN JSON at the moment of generation; you cannot rely on portal retrieval years after the fact.
• Cancelled IRNs carry the same 72-month retention obligation as live invoices — never delete them on cancellation.
• The DPDP Act does not require early deletion where a statutory obligation overrides it — but you must document that legal basis explicitly, not simply assume it.
• Buyers face the same retention obligation as sellers — supplier IRNs are ITC evidence and must be independently archived, even if the supplier later deregisters.
• Premature destruction is a common and costly error — always calculate the destruction date from the GSTR-9 due date, not the invoice date, and never run a destruction routine without a written authorisation and a destruction certificate.
• A retention policy is only as strong as its least-controlled operational step — automate tier transitions, log all destructions, and test retrievability every year, or the policy document is compliance theatre.