Direct GSTN e-filing

Audience: Merchant·Plan: pro·Read: 10 min·Updated: 2026-08-03

Beta · Opt-in — requires setup

In 30 seconds

• Files GSTR-1 and GSTR-3B directly to the GST Network through a licensed GST Suvidha Provider, without leaving the app.
• Three roles, three people: a maker stages, a checker approves, and an authorised signatory signs. Separation of duties is enforced on identity.
• Filing is always a human signature — EVC one-time password or a digital signature certificate. It cannot be automated, by law.
• GSTR-3B applies the statutory input-tax-credit set-off per head, then raises a per-head PMT-06 challan for whatever cash is still needed.
• Submit is a one-way door. The state machine is built so a crash between "the portal acted" and "we recorded it" can never produce a double filing.
• This is off by default and requires configuration before it appears.

This feature is opt-in and needs setting up

Direct filing is disabled unless your deployment has enabled it and configured a GST Suvidha Provider. Until then, the Filing tab produces portal-format exports you upload yourself — which is a complete workflow, just not an automated one.

You also remain the filer of record. The app transmits on your behalf under your own authorisation; it does not become your tax agent.

Why a GSP is involved

There is no direct machine access to the GST Network. All programmatic filing goes through a licensed GST Suvidha Provider, with the app acting as an Application Service Provider on your behalf.

Two consequences follow from the regulations, and they shape the whole flow:

1. Filing requires a human signature — an EVC one-time password sent to the authorised signatory, or a digital signature certificate. There is no unattended path, and there should not be.
2. Submit freezes the return. Once submitted, the return cannot be edited at the portal. Everything before that point is reversible; nothing after it is.

The flow

Step	Who	What happens
Authorise	Anyone with filing permission	Records your authorisation for this GSTIN, with the signatory's name and the terms version
Authenticate	Signatory	Portal username plus a one-time password; the resulting session is encrypted at rest and lasts about six hours
Stage	Maker	Picks the generated return for this GSTIN and period and locks its content hash
Approve	Checker	Re-derives the hash from the current report — a regenerated return cannot be silently approved
Save	System	Invoices are saved at the portal
Settle (3B only)	Maker	Input tax credit set-off, then a challan for any cash shortfall
Submit	System	Freezes the return at the portal
Sign & file	Signatory	EVC or DSC. Returns an ARN

Separation of duties

Three distinct permissions, intended for three distinct people:

Permission	Role
tax:filing:submit	Maker — stages and runs
tax:filing:approve	Checker — approves a staged return
tax:filing:sign	Authorised signatory — signs and files

The checker cannot be the maker. And because approval is bound to the content hash of the return, changing the return after approval revokes it: declaring reverse-charge liability on an approved return sends it back to draft so the checker reviews what will actually be filed.

Choosing the right return

The staged report is selected by GSTIN, not merely by kind and period. The first two digits of a GSTIN are the state code, and a multi-state merchant has a GSTR-1 for each state in the same period. Matching on kind and period alone can transmit one state's invoices under another state's GSTIN; the selector requires a state match and refuses when the only candidate belongs elsewhere.

GSTR-3B: the set-off and the challan

GSTR-3B is payable, so it never submits straight through.

The statutory set-off is applied per head, following the CGST Act sections 49(5), 49A and 49B and Rule 88A:

Credit	Can discharge
Cess	Cess only
IGST	IGST first, then CGST, then SGST — and IGST credit must be fully exhausted before any CGST or SGST credit is used
CGST	CGST, then IGST. Never SGST
SGST	SGST, then IGST. Never CGST

After credit, each head's remaining liability is paid from that head's cash ledger. Anything still outstanding becomes a per-head PMT-06 challan.

Reverse-charge liability is cash-only. Input tax credit can never discharge it, so it is combined with the post-credit liability at the cash step. Reverse charge is declared by you before the return is saved — so the figure that appears in Table 3.1(d) of the filed return is the same figure the challan pays for.

The challan carries the full minor-head model: tax, interest, late fee and penalty. Interest and late fees are calculated on the net cash shortfall after credit, not on gross output tax — computing them on gross overstates them substantially when credit covers most of the liability.

Once the challan is funded through your bank, the app polls the portal, confirms the payment, and submits.

Signing

Method	How it works
EVC	A one-time password is sent to the authorised signatory's registered mobile and email. Enter it to file
DSC	Sign with your digital signature certificate using the portal's signing utility, and paste the resulting signature. The private key never leaves your machine

A wrong EVC code returns the submission to its previous state so you can retry. An expired code is a distinct state with its own retry path.

Crash recovery, and why it cannot double-file

Three states are write-ahead intents: saving, submitting and filing. The app records that it is about to make the irreversible call, before making it.

If the process dies mid-call, recovery does not retry blindly. It asks the portal what actually happened and settles the intent to whatever the portal recorded — which can be several steps ahead of where the crash occurred, if somebody continued through the portal directly in the meantime. The app never advances past what the portal confirms.

A recovery sweep runs every five minutes and picks up any submission stuck in an intent state for more than five minutes, so a crashed filing is never stranded.

Concurrency is handled by compare-and-swap on the state itself, so two clicks or two workers cannot both advance the same return.

Audit

Every call to the GST Network is written to a hash-chained audit log — each row carries the hash of the previous one, so a deleted or altered entry is detectable. The log stores hashes rather than raw payloads: it proves what happened without retaining copies of taxpayer data.

Session tokens and portal keys are encrypted at rest with an authenticated encryption envelope. In any environment where direct filing is enabled, a missing key is a hard failure rather than a fallback to a development default.

What you need before you can use it

Requirement	Notes
GSP account and credentials	A licensed provider; sandbox credentials are typically self-serve
Feature enabled	Direct filing is off by default
Encryption key	Provisioned from your key management service
Two or three users	Maker, checker and signatory must be different people
An active India registration	With a valid GSTIN
A generated return	Direct filing transmits an existing generated report — it does not build one

Your operations team will find the setup steps in the internal direct-filing runbook.

Plan tiers

Capability	Free	Starter	Pro	Agency	Enterprise
Direct GSTN e-filing	—	—	✓	✓	✓

Available on Pro and above where the deployment has enabled it.

Best practices

• Run one filing in the provider's sandbox first. The flow is identical, and the first live filing is not the moment to learn it.
• Assign the three roles to three people before you start, not at the approval step.
• Declare reverse charge before approval. Declaring it later revokes the approval by design.
• Reconcile before you stage. A return that fails the gate should not be reaching the portal.
• Treat submit as final. Everything up to it is reversible; nothing after it is.

See also

• Filing & close — generating the returns this transmits
• Reconciliation — the gate that must pass first
• Registrations & nexus — the GSTIN this files against
• Tax overview — the engine underneath