It's 4pm on April 1, 2026. We've been on calls with three SMB clients since 9am — a Coimbatore textile exporter, a Hyderabad SaaS company, and an Indore distributor of FMCG goods. All three hit a real production issue inside the first three hours of GST 2.0. This is what we saw, what broke, and the fixes that worked.
3
SMB clients with first-day breaks (out of 18 we audited)
9:42 AM
First IRP error logged in our queue
~4-7 sec
IRP response latency this morning vs ~1-2 sec normal
4
Bug categories we have repro steps for
## The four bug categories we are seeing
We log every client incident into a shared ticket queue. By 3pm today, the tickets cluster into four buckets. Each one is fixable in under 90 minutes if you know where to look.
A
Document-series collision
Custom apps reusing FY 2025-26 invoice numbers. IRP returns duplicate-number error. Fixed by resetting the prefix and the counter in your invoices table.
B
Stale API token without MFA
ERPs storing a 2024-era IRP token without MFA enrolment. First IRN call fails with 401. Re-login manually with OTP, regenerate token, redeploy.
C
IRP timeout, no retry
IRP under load. Calls timing out at the default 5-second client setting. Custom apps without retry logic mark the invoice as "IRN failed" and don't try again. We add exponential-backoff retry up to 60s.
D
GSTR-3B Table 3.1 override macro
Accountant's Excel macro overwriting auto-populated values. Won't surface until first GSTR-3B filing, but worth disabling now. We comment out the offending rows in the macro.
## Bug A — the document-series gotcha
This is the most common one we're seeing today. Custom Node/PHP/Laravel invoicing apps that auto-increment from a single sequence (no financial-year scoping). On April 1, the first invoice goes out as INV-14502 (continuation of FY 2025-26) instead of INV/2026-27/00001.
The IRP doesn't reject this on schema — the invoice number is technically valid. But when the same buyer's GSTIN is reused in May, the IRP starts flagging duplicates if you've now corrected to the FY 2026-27 prefix and the new sequence loops back to a number you used in March.
The fix is two lines in your invoices table:
-- For Postgres/MySQL — adjust syntax for your DB
ALTER TABLE invoices
ADD COLUMN financial_year VARCHAR(7);
ALTER TABLE invoices
ADD CONSTRAINT uq_invoice_per_fy
UNIQUE (gstin, financial_year, invoice_number);
Then in your invoice-creation code, derive financial_year from the invoice_date (April 1 to March 31 = FY YYYY-YY+1). Restart the sequence at 1 for every (gstin, financial_year) combination. Add the prefix INV/2026-27/ at render time, not in the database.
Don't change historical records: Apply the new scheme only for invoices dated April 1, 2026 or later. Backfilling old invoices with the new prefix breaks reconciliation with already-filed GSTR-1 returns.
## Bug B — the stored-token problem
This one bit a Hyderabad SaaS client this morning at 10:14am. Their billing service had an IRP API token from August 2024, before MFA became mandatory for their AATO band. The token still authenticated until 11:59pm on March 31. From midnight, the IRP started returning a 401 on every call.
Fix sequence:
1. Manually log in to einvoice1.gst.gov.in with the master username. You'll be prompted for OTP — complete it.
2. Once inside, go to API Registration. Note your client ID and secret.
3. Hit the /eivital/v1.04/auth endpoint with the new credentials to get a fresh token.
4. Update your billing service's environment variable. Redeploy.
5. Add a job that refreshes the token every 5.5 hours (tokens last 6).
For Tally Prime users, this is automated through TallyConnect once you've re-authenticated the human user. Zoho Books re-auths via OAuth — sign back in once and Zoho refreshes its own tokens.
## Bug C — IRP latency and retry
The IRP is running slower than usual today. We measured 4-7 second response times on our test invoices between 10am and noon, versus the typical 1-2 seconds. Likely due to volume — the new ₹5 Cr cohort is making first-day calls.
If your client library has a 5-second timeout (the default in many HTTP clients), every other call fails and your app marks the invoice as "IRN failed". Customers don't get a valid invoice. Your dispatch tool refuses to print.
The fix is a retry block with exponential backoff. Here's the Node pattern we ship:
async function generateIRN(invoice, attempt = 1) {
try {
const res = await axios.post(IRP_URL, invoice, {
timeout: 15000, // 15s, not 5s
headers: { Authorization: 'Bearer ' + token }
});
return res.data;
} catch (err) {
const isRetryable = err.code === 'ECONNABORTED'
|| (err.response && err.response.status >= 500);
if (isRetryable && attempt < 4) {
const delay = Math.min(2000 * Math.pow(2, attempt - 1), 16000);
await new Promise(r => setTimeout(r, delay));
return generateIRN(invoice, attempt + 1);
}
throw err;
}
}
Total worst-case wait: ~30 seconds. Acceptable for B2B invoicing. Unacceptable for consumer checkout — but B2B is the only place IRN matters.
## Bug D — the macro that overwrites GSTR-3B
This won't fail today. It'll fail around April 18 when your CA tries to file GSTR-3B for the previous month. But fix it today while you remember.
The macro pattern, ported from FY 2024-25 templates, opens GSTR-3B in spreadsheet form and writes inter-state vs intra-state splits into Tables 3.1 and 3.2. From April 2026, those tables are non-editable — auto-populated from GSTR-1. The portal will reject the upload.
In Excel, hit Alt+F11 to open VBA. Look for any Sub that references "Sheet 3B" or "Table 3_1" — comment those lines out. The macro should still be allowed to populate ITC tables (Table 4), which remain editable for now.
## Live observations from the cutover
A few patterns we noticed across the day:
- The IRP UI was slower to load than the API. Manual users complained more loudly than API integrators.
- e-Way Bill portal MFA was firmly enforced — multiple users hit OTP-not-received issues; the SMS gateway was overloaded between 9-11am.
- Tally Prime users with the "Restart numbering: Yearly" setting had zero issues. Tally users on "Continuous" had to scramble.
- Zoho Books handled the cutover cleanly for everyone we checked. Their GSP integration auto-handled the document series.
- BUSY Accounting users with custom invoice templates needed a manual prefix update — BUSY's auto-reset is opt-in, off by default in older builds.
- Marg ERP users on the cloud edition had it handled silently overnight. Desktop edition users had to apply a patch released March 28 — many hadn't.
## A 90-minute incident from this morning
This is what one of the three live incidents looked like, in actual ticket-log form.
09:42 IST — Indore distributor calls. First IRP upload of the morning failed with HTTP 401. Their dispatch tool (a custom Laravel app from 2023) threw the standard "Invoice not generated" error to the warehouse staff. Three trucks were waiting on printed tax invoices to depart.
09:48 — We pull their stored IRP API token from their .env. Token issued August 2024. We test it against /eivital/v1.04/auth — confirms 401.
09:52 — We log into einvoice1.gst.gov.in with their master GSTIN credentials. OTP arrives within 30 seconds. We complete MFA setup (the option was previously unset).
10:01 — Generate fresh API client_id and client_secret under API Registration. Update their Laravel .env. Restart the worker process.
10:05 — Test invoice fires. IRN returns in ~5 seconds (latency-affected). PDF prints to the dispatch printer.
10:08 — We add a pre-check job to their cron that hits /eivital/v1.04/auth every 5 hours and emails the team if it returns non-200. This catches future token expiries before customers do.
10:32 — All three pending trucks dispatched. We invoice the client for 90 minutes of emergency support. They asked us to retainer for next week as well — there's no shortage of similar clients on the same Laravel-Razorpay-Tally stack who might hit the same wall on day three or day five when their auto-rotated tokens fail.
## What changes for an SMB in week 2
The first 48 hours are about catching bad config. Week 2 onwards, the focus shifts:
- Filing the first GSTR-1 of the new financial year. Cleaner reconciliation now that document series is correct, but check that the GSTR-1A draft matches your invoice register before submission.
- Watching IRP latency normalise. Build a simple dashboard in Google Sheets pulling response times via your ERP logs — you'll spot regressions early.
- Educating your CA's office on the new GSTR-1A correction route. Their habit may still be to edit GSTR-3B; that doesn't work anymore.
- Reviewing IMS rejections from suppliers. Your buyers might reject your invoices on IMS if your data has typos. Catch this early — by month-end you'll be tied up with returns.
The active discussion threads on [r/IndiaTax](https://www.reddit.com/r/IndiaTax/) since 8am today mirror exactly these four buckets. CAs from Mumbai, Delhi, and Pune are reporting variants of the same failures.
## A note on what didn't break (and that's the news)
For our 15 clients who completed the pre-April audit checklist we published on March 30, today was non-eventful. They issued invoices, IRNs generated, the world rotated. The "GST 2.0 is breaking everything" headlines online today are largely from businesses that didn't reset their invoice series or didn't re-enrol MFA. The compliance burden is real, but it's a one-time setup cost, not an ongoing tax on operations.
## When NOT to panic
If your first invoice today is to a buyer who's not in the e-invoicing net (B2C, or B2B with GSTIN unregistered), you don't need an IRN. Don't waste time forcing a system that's correctly declining the call. Verify the buyer's GSTIN at gst.gov.in/services/searchtp before re-trying.
Similarly, if the IRP is slow, don't issue duplicate invoices to "retry". Wait for the first call to return — your system might already have an IRN and just hasn't received the response yet. Idempotency is on you, not the IRP.
## A 30-minute same-week patch you can ship
For SMBs without a dev team, here's the order:
- Confirm invoice prefix shows FY 2026-27 on the first 5 invoices of the day
- Re-login to einvoice1.gst.gov.in manually and complete MFA — check on every machine that has IRP access
- If using a custom app, bump the HTTP timeout to 15s and add a retry block (or ping your dev team)
- If using Tally, set F11 > Features > Statutory > Restart numbering = Yearly
- If using Zoho Books, no action — Zoho handles this
- Flag any GSTR-3B macros to your CA for deletion before April 18
- Block 45 min on Friday 4pm for weekly IMS review
- Print one test invoice end-to-end with a real buyer GSTIN; verify the IRN renders correctly
## FAQ
### Why is the IRP slow today?
First-day volume. The new ₹5 Cr threshold pulled ~200,000 additional businesses into the e-invoicing net. The IRP infra absorbed the load but not without latency. We expect normalisation by April 4-5 based on the FY 2023-24 cutover pattern.
### My IRN generated but I never got the response — should I retry?
Not immediately. The IRP follows at-most-once semantics on the create side — duplicate calls with the same invoice payload may either return the existing IRN or throw a duplicate error. Wait 60 seconds, then GET /eivital/v1.04/Invoice/irn?irn=
to check if it was actually generated. Only re-POST if the GET returns 404.
### Can I retroactively renumber my March 2026 invoices to fit FY 2026-27?
No. The invoice number is locked to the invoice date. Renumbering breaks reconciliation with GSTR-1 returns already filed for the March 2026 tax period. If you've issued April invoices with the old FY 2025-26 prefix by mistake, issue a credit note and a fresh invoice with the new prefix.
### Does the 30-day IRP rule start counting today?
Yes, but only for ATTO ≥ ₹10 Cr. If you issue an invoice dated April 1, 2026, you have until April 30 to report it to the IRP. After that, the IRN cannot be generated and the buyer cannot claim ITC.
### My buyer is asking me to backdate an April 1 invoice to March 31 — can I?
No, and don't. Backdating is a recipe for an audit notice. The fact that buyers ask reveals their ITC planning was lazy. Issue the invoice with the correct April 1 date; the ITC just lands in the buyer's GSTR-2B for April instead of March.
### Are e-Way Bills affected today too?
Yes — same MFA enforcement, and the e-Way Bill portal shares infra with the IRP for load. We saw e-Way Bill generation latency in the same 4-7s band this morning. The 30-day reporting rule doesn't apply to e-Way Bills.
### How long until we know GST 2.0 is "stable"?
Based on the 2023 (₹10 Cr threshold) cutover, expect 7-10 days of elevated incidents, then steady state. The bigger inflection will be the first GSTR-3B filing cycle (April 18-22), when IMS reconciliation gets its first real-world stress test.
Need a Same-Week GST 2.0 Patch on Your Software?
We're shipping IRP integration patches for SMBs this week — invoice-series fix, retry/timeout block, MFA token refresh, GSTR-3B macro cleanup. Typical fix: 4-8 working hours. Suitable if you have a custom Node, Python, PHP, or Java billing app. Tally and Zoho Books rarely need code changes; we'll tell you on the first call if you don't need us.
Get a Same-Week Quote
If you're running a custom billing flow and want a longer look at how we structure GST integrations into custom software, drop a note to contact@softechinfra.com. We'll send the patch checklist and a sample retry-block diff before the call.