India: GST E-Invoicing and the Reporting Stack
India does not have one obligation; it has a stack of them, and they have been quietly locking together. E-invoicing, a thirty-day reporting clock, a non-editable return, an invoice acceptance system and a three-year filing bar now interact — and a failure at the bottom is very hard to repair at the top.
Country briefing · September 2026 · CFOs, tax and finance leads
Download Full Briefing (PDF, EN)₹5 cr
Turnover threshold above which e-invoicing applies, once crossed in any year since the regime began
30 days
The window to report an invoice for larger taxpayers — after which the portal refuses it
3 years
After which a return can no longer be filed at all, however willing you are
0·5·18·40
The rate structure after the 2025 rationalisation, with a demerit band at the top
Key takeaway for finance and tax leaders: in India deadlines are enforced by the portal and there is no late filing: a document without a valid reference number leaves your customer without credit, and after thirty days you cannot repair it. The highest-value control is a daily reconciliation between invoices issued and invoices with a valid reference. The question this month: how many invoices did we issue last month, and how many carry a valid reference number?
A Stack That Has Been Tightening for Three Years
India’s GST regime has moved from “file a return” to “report every invoice, on time, and reconcile what everyone else reported about you”. Each individual change looked modest. Together they have removed almost all the slack that finance teams used to rely on.
What Changed, and When
| Change | What it does | In force |
|---|---|---|
| E-invoicing threshold at ₹5 crore | Brings mid-sized businesses into invoice-level reporting for B2B and export supplies | Since August 2023 |
| Invoice Management System | Gives the buyer an explicit accept, reject or pending decision on every supplier document | Since October 2024 |
| Thirty-day reporting limit | The portal refuses invoices older than thirty days for taxpayers above ₹10 crore | Phased from 2024–25 |
| Three-year filing bar | Returns can no longer be filed once three years have passed from the due date | From mid-2025 |
| Hard-locked summary return | Auto-populated values in the summary return become non-editable; corrections must be made upstream | From the July 2025 period |
| Rate rationalisation | The slab structure simplified, with a high demerit rate for specified goods | From September 2025 |
The Question to Ask This Month
“How many invoices did we issue last month, and how many carry a valid reference number?” If those numbers differ, some of your customers cannot claim credit on the difference — and after thirty days you cannot fix it by reporting late.
Why the Combination Matters More Than Any Single Rule
- Errors can no longer be fixed downstream. When the summary return is locked to what was reported at invoice level, a mistake has to be corrected where it was made — which means the invoice data must be right when it leaves your system.
- Your customer’s credit depends on your discipline. An invoice without a valid reference number is not a valid tax document, so the buyer cannot claim credit. Your reporting failure becomes their loss, and then a commercial conversation.
- Deadlines are enforced by software, not by officers. The thirty-day limit and the three-year bar are portal behaviour. There is no negotiation and no late filing.
Registration, Not Clearance — with Consequences Either Way
India’s model is often described as clearance, and that is not quite right. You issue the invoice; you report it to a registration portal, which validates it and returns a unique reference number and a QR code. Without those, the document is not a valid tax invoice — but the portal is not approving your sale, it is registering it.
Step by Step
| Step | What happens, and where it fails |
|---|---|
| Generate | The invoice is created in your system in the prescribed schema. Anything the schema does not accept is rejected outright |
| Report | It is sent to a registration portal. Access now requires two-factor authentication, which has operational consequences for automated processes |
| Receive the reference | The portal returns the reference number and a signed QR code. This is the moment the document becomes a valid tax invoice |
| Print and send | The QR code must appear on the document given to the customer. A printed invoice without it is not compliant |
| Flow onward | Reported data populates your outward-supply return and can feed the transport documentation, reducing duplicate keying — if the systems are connected |
| Cancel or amend | Cancellation is possible only within a short window and only in full. After that the correction is a credit note, not a deletion |
Who Is in Scope, and Who Is Not
| In scope | Generally excluded |
|---|---|
| Business-to-business supplies and exports, once the turnover threshold has been crossed in any year since the regime began | Consumer supplies, though QR-code obligations may apply separately |
| Supplies to government registrations, and credit and debit notes against in-scope invoices | Specified sectors including banking, insurance and non-banking finance |
| Reverse-charge documents in defined circumstances | Goods and passenger transport services, and cinema admissions |
Three Operational Details That Break Automation
| Detail | Why it matters in practice |
|---|---|
| Two-factor authentication | Portal access requires a second factor. An unattended overnight billing run that depends on a person receiving a code is not a design — it is an incident waiting for a date |
| Cancellation is narrow | A registered document can only be cancelled in full and only within a short window. Everything else is a credit note, so the commercial process must accommodate corrections rather than deletions |
| Schema validation is strict | Fields the schema does not expect, or values it does not recognise, are refused rather than warned about — so validation belongs in your system, before transmission |
The Threshold Is Sticky
The obligation is triggered by turnover in any financial year since the regime began — not by current-year turnover. A business whose revenue has since fallen does not leave the regime, and groups that assume a quiet entity is out of scope are frequently wrong. Check each registration individually.
The Rule That Turns a Backlog into a Permanent Loss
For larger taxpayers, an invoice must be reported to the registration portal within thirty days of its date. After that the portal refuses it. There is no late-reporting mechanism, no penalty that buys forgiveness, and no way to obtain a reference number for that document afterwards.
What a Missed Reference Number Actually Costs
| Consequence | Who bears it |
|---|---|
| The document is not a valid tax invoice | You — the sale is billed on paper that does not meet the legal definition |
| Credit is denied to the buyer | Your customer, who will pass it back to you commercially, usually by withholding the tax element |
| Reported and declared figures diverge | You — the difference is visible to the administration and invites scrutiny |
| The correction is a new document | Both parties, through a credit note and a fresh invoice, with the commercial conversation that implies |
Where the Thirty Days Are Usually Lost
- Invoices issued outside the main system. A service branch, a project team or a local application bills in its own way and reaches the portal late — or never.
- Documents held for approval. An invoice parked pending an internal sign-off is still dated, and the clock runs from the date, not from the approval.
- Failures nobody reads. A rejection at the portal produces an error somewhere. If no one owns that queue, thirty days is ample time for it to be missed.
- Period-end backlogs. A push to bill everything at quarter-end creates a volume spike, and a portion of it fails on validation at exactly the moment nobody has capacity to look.
The Control That Prevents All Four
A daily reconciliation between invoices issued and invoices with a valid reference number, by source system, with anything ageing beyond a few days escalated. It is not sophisticated, and it is the single highest-value control in the Indian stack — because it is the only one that catches the failure while the failure is still repairable.
Who Owns This Control
The daily completeness check does not belong to IT, because the action it triggers is commercial: an invoice that failed validation has to be corrected and reissued by someone who can decide what the invoice should say. In practice it works best owned by the billing or shared-service team, with IT responsible only for making the two numbers available automatically each morning.
The Transport Document Connection
Movement of goods requires its own electronic documentation, and the two obligations are related: reported invoice data can generate the transport document, and a mismatch between them is an obvious inconsistency for the administration. Where the two are maintained separately by different teams, differences accumulate — and a vehicle stopped in transit against a mismatched document is an operational problem, not a tax one.
Five Layers, Each One Now Constraining the Next
A failure at the bottom is very hard to repair at the top: the returns are locked to what was reported upstream.
The Five Layers
| Layer | What it is | What constrains it |
|---|---|---|
| The invoice | Reported to the registration portal, returning a reference number and QR code | The thirty-day clock, and schema validation |
| Outward supplies | The statement of what you sold, largely populated from reported invoices | What was reported — and only what was reported |
| The amendment statement | The mechanism for correcting outward supplies before the summary return is filed | It must be used before filing; afterwards the window has closed |
| The summary return | The return that actually pays the tax | Auto-populated values are locked to the statements above |
| Inward credit | The credit statement built from what your suppliers reported, as filtered by your own decisions | Supplier behaviour, and your acceptance decisions in the invoice management system |
What Hard-Locking Changed
A difference between the detailed statements and the summary return used to be absorbed by editing the summary. That door is closed: auto-populated values are non-editable, and corrections must be made upstream before filing. The effect is that the reconciliation moved forward in the month.
What a Monthly Close Should Now Include
| Check | What a difference tells you |
|---|---|
| Issued ↔ registered | Completeness — documents your customers cannot claim credit on, with a clock running against you |
| Statement ↔ summary return | Whether a correction is needed, and it must now be made upstream before filing |
| Credit statement ↔ purchases | That the credit claimed matches what was received and recorded |
The Three-Year Bar
- Returns cannot be filed once three years have passed from the due date — the facility is simply withdrawn
- It applies across the return family, including annual returns and reconciliations
- Old periods left open by an acquisition, a dormant registration or a dispute can become permanently unfilable
- An inventory of open periods per registration is worth producing now rather than discovering later
A Group-Level Blind Spot
Multinationals typically monitor the registrations that matter commercially. The ones that cause trouble are the quiet ones — a state registration kept for a single contract, an entity acquired with its own history, a registration nobody has looked at since a reorganisation. Those are where unfiled periods sit, and the three-year bar turns a housekeeping task into a permanent exposure.
Every Supplier Document Now Needs a Decision
The Invoice Management System gives the buyer an explicit choice on each document a supplier reports: accept, reject, or leave pending. Accepted documents flow into the credit statement; rejected ones do not; pending ones move to a later period. Inaction has a default — and the default is acceptance.
The Four Possibilities
| Action | Effect | When to use it |
|---|---|---|
| Accept | The document flows into your credit statement for the period | The invoice is correct and the supply is genuine |
| Reject | The document is excluded from credit | It is not yours, it is duplicated, or it is materially wrong |
| Pending | It carries forward without affecting the current period | Genuine but not yet verified — goods not received, or a dispute in progress |
| No action | Treated as accepted | Never deliberately — this is what quietly claims credit you may not be entitled to |
Rules on how long specified documents may remain pending have tightened, with deemed acceptance after a limited period. Confirm the current treatment for each document type before designing a process around it.
Why This Is an Accounts-Payable Change, Not a Tax One
- The decision window is monthly and it is real. Someone has to look at every supplier document in time, which is a resourcing question before it is a systems question.
- Accepting by default is claiming by default. Credit taken on a document the business has not verified is credit taken at risk, and it is now a recorded decision rather than an omission.
- Rejection has commercial consequences. Rejecting a supplier’s document affects their position too, so the process needs a defined path and a conversation, not a silent click.
- It only works if you can match. Comparing what suppliers reported against what you received and posted is the underlying capability — without it, the accept-or-reject decision is guesswork.
What Has to Exist Before the Decision Can Be Made Well
- Supplier documents visible alongside the purchase order and goods receipt, not in a separate portal
- A matching rule that clears the obvious accepts, so people spend time on the exceptions
- A defined path for rejection, including who tells the supplier and how it is recorded
- A monthly cut-off early enough to act before the credit statement is fixed for the period
The Supplier Conversation This Creates
Rejecting a document is visible to the supplier, so a process that operates silently generates disputes. Agree in advance what you will reject and what you will hold as pending, tell your larger suppliers how you will communicate it, and record the reason.
The Practical Test
Ask how last month’s decisions were made. If the answer is “we accepted everything” or “the system does it”, the control does not exist — and the credit claimed rests on suppliers’ accuracy rather than on your own verification.
Two Sides of the Same Solution
SAP addresses the Indian requirements through SAP Document and Reporting Compliance. The electronic-document side reports invoices and brings the reference number and QR code back to the billing document; the statutory reporting side produces the periodic returns. Both read the same ledger, which is what makes the reconciliations possible — or, when they are configured independently, impossible.
What a Healthy Indian Setup Contains
| Element | What “good” means |
|---|---|
| Determination | Every in-scope document is reported, across every registration and every source system — driven by rule, not by which team remembered |
| Reference handling | The reference number and QR code stored against the billing document, printed correctly, and available for reconciliation and audit |
| Ageing control | A daily view of documents issued but not yet registered, aged, with escalation well inside the thirty-day window |
| Authentication | Two-factor requirements handled in a way that does not depend on one person’s phone during a billing run |
| Return preparation | Statements produced from the same data as the invoices, with differences identified before filing rather than after |
| Inbound matching | Supplier-reported documents compared with receipts and postings, so acceptance decisions rest on evidence |
Platform Is Rarely the Constraint for Invoicing — but It Is for Returns
The electronic-document framework used to report invoices exists on both SAP S/4HANA and classic SAP ERP, so remediating the invoicing side rarely requires a platform move. The periodic returns depend on the statutory reporting side, which is not available on older platforms — so a group running an older system may find the two obligations split across different tools, which is precisely the arrangement that makes the reconciliations in the reporting-stack section hard to perform. Confirm country content and prerequisites with SAP for your exact release.
A Note on Multiple Registrations
India is administered state by state, so a single legal entity may hold many registrations, each with its own returns, its own credit position and its own deadlines. Completeness has to be measured per registration, not per company code — an aggregate that looks healthy can conceal one registration that has been failing for months.
Five Questions for Whoever Supports Your System
- Show me last month’s completeness figures — invoices issued against invoices with a valid reference number, by registration and by source system.
- What is the oldest unregistered invoice right now, and who is watching it?
- Which billing sources bypass the main system, and how do they reach the portal?
- How are supplier documents matched before an acceptance decision is taken?
- Who applies portal and schema changes, and is regression testing included?
Twelve Questions, and What a Poor Answer Costs
Each answer should rest on a number or a document. Anything answered with “it should be fine” is a finding.
The Twelve Questions
| No. | Question | If the answer is unclear |
|---|---|---|
| 1 | Invoices issued against invoices registered, last month, per registration? | Customers may be unable to claim credit, and you cannot prove otherwise |
| 2 | What is the oldest unregistered invoice? | The thirty-day window may already have closed on it |
| 3 | Which systems other than the ERP issue invoices? | An unreported population exists and nobody is measuring it |
| 4 | Who clears portal rejections, and how fast? | Failures age into permanent losses |
| 5 | Does the QR code appear correctly on every printed form? | Documents handed to customers are not compliant |
| 6 | How were last month’s acceptance decisions made? | Credit is being claimed without verification |
| 7 | Are supplier documents matched to receipts before acceptance? | The decision is guesswork, and the exposure is real money |
| 8 | Do the detailed statements and the summary return agree before filing? | Corrections can no longer be made in the return itself |
| 9 | Do we have an inventory of open periods per registration? | The three-year bar may close some permanently |
| 10 | Do invoice and transport documents agree? | An obvious inconsistency, and a risk to goods in transit |
| 11 | Did the 2025 rate changes flow through all master data? | Systematic misstatement across affected products |
| 12 | Who applies portal and schema changes after go-live? | Silent drift, discovered through rejections |
Questions 1, 2 and 3 are the ones to fix first. Completeness is the control everything else depends on, and it is the only one where a delay of a few weeks converts a repairable problem into a permanent one.
What We Typically Find
- One registration, or one billing source, quietly failing while the aggregate looks healthy
- Rejections held in an interface queue with no owner and no age limit
- Supplier documents accepted wholesale because nobody has capacity to review them
- Reconciliation performed after filing rather than before, now that the return is locked
- Open periods on dormant registrations, ageing towards the three-year bar
- Two-factor authentication resting on one person, with no documented alternative
Scoring It Honestly
Three or more unclear answers is common, and it usually reflects how fast the rules changed rather than anyone’s negligence. The difference in India is that some of what you find cannot be corrected — which is the argument for looking sooner rather than at year-end.
An SAP Finance and Compliance Practice
Most Indian engagements we are asked for are not implementations. They are proving completeness, closing the gaps it reveals, and building the controls that keep them closed.
Completeness review
Two to three weeks against the twelve-question check, evidenced from your system — issued against registered, per registration and per source, with ageing. Output: a quantified gap list with dates.
Remediation and controls
Bypassed billing sources connected, rejection handling given an owner, the daily ageing control built, and supplier matching put behind acceptance decisions. Output: failures caught while repairable.
Run and legal change
Portal and schema changes watched and applied in controlled windows, returns reconciled before filing, and the same design extended to your other jurisdictions. Output: compliance that stays compliant.
What Makes This Different
We measure per registration. A company-level number hides the one state that has been failing quietly, which is exactly where the exposure sits.
We treat completeness as the deliverable. Reporting invoices is easy; proving all of them were reported, in time, is the control that protects you.
We connect issuing and returns. They share a data foundation, so we fix it once rather than twice.
We say what we are not. We are not your tax adviser. We work alongside the people who are, and we are explicit about where that line sits.
What a Completeness Review Produces
Completeness evidence: issued against registered, by registration, by source system and by month, with the gap quantified rather than estimated.
An ageing position: every document not yet registered, with its age against the thirty-day window and an owner.
An open-period inventory: unfiled periods per registration, with the date each becomes permanently unfilable.
A Sensible First Step
Ask for three numbers per registration: invoices issued, invoices with a valid reference number, and the age of the oldest that has neither. If they arrive quickly and they agree, you are in good shape. If they do not, you have found the work — and in India the cost of finding it late is not a fine, it is a document you can never fix.
Founder-led
Finance + SAP DRC depth
SAP DRC delivery: France and Germany
Boutique agility
Sources consulted 25 September 2026: ClearTax, Tally Solutions, IndiaFilings and practitioner commentary on e-invoicing applicability, the thirty-day reporting limit, the Invoice Management System, hard-locking of the summary return and the three-year filing bar; press and advisory coverage of the 2025 rate rationalisation. SAP behaviour from the SAP Help Portal and partner commentary on SAP Document and Reporting Compliance.
Prepared by 30 Advisory (status at 25 September 2026). Information only — not tax, legal or accounting advice. It summarises publicly available material as at that date; Indian GST rules, thresholds, portal behaviour and advisories change frequently and secondary sources disagree on detail. Confirm the position for your own registrations with the GST authorities or a qualified adviser before acting. 30 Advisory accepts no liability for decisions taken on the basis of this document.
Do You Have Three Numbers per GST Registration?
We’ll measure invoices issued, invoices with a valid reference number and the age of the oldest unregistered one in our free 60-minute diagnostic.
Three things to check first
- Whether every invoice issued carries a valid reference number, per registration and per source system.
- How IMS acceptance decisions on supplier documents are made today.
- Whether any open periods are approaching the three-year filing bar.
Want the full picture? Score your DRC readiness →