Most GST software failures are not accounting failures. They are data-entry failures that compliance then faithfully carries into a return.
The pattern is consistent. Somebody picks CGST and SGST from a dropdown when the supply was interstate. A GSTIN is typed with a transposed character and nothing objects. An e-way bill is raised on figures re-keyed from an invoice, so the two now disagree about a value a checkpoint can compare. None of this is a difficult accounting question. It is software that asked a human to make a determination the software already had enough information to make.
This is a practical guide to what your billing software has to get right under GST — what the mechanisms actually are, what to test before you trust a system with them, and where the avoidable notices come from. Thresholds and formats under GST change by notification, so treat every figure here as a pointer to check against the current rules rather than as a settled fact.
Place of supply is the determination everything else rests on
Whether a transaction attracts CGST plus SGST or IGST follows from the place of supply. That is a rule, applied to information the invoice already contains: where the supplier is registered, where the recipient is, what is being supplied, and for services, a set of specific rules for particular categories.
Which means it should never be a dropdown. If your software asks a billing clerk to choose the tax heads, you have converted a rule into a judgement call made a hundred times a day by whoever is at the desk, and a proportion of those will be wrong. The errors are not random, either — they cluster on exactly the transactions that are unusual, which are the ones most likely to be looked at.
What to test, with a real transaction in front of you:
- Raise an invoice to a customer in your own state and to one outside it, and confirm the tax heads change by themselves.
- Try a GSTIN with one character altered and confirm the software refuses it. A GSTIN carries a checksum; validating it is arithmetic, not a lookup, and software that accepts anything fifteen characters long is not checking.
- Raise a zero-rated export and an SEZ supply. These are where generic billing software usually falls apart, and where getting it wrong is expensive.
- Check that HSN and SAC codes sit on the product master rather than being typed per line, and that the reporting detail matches what your turnover requires.
E-invoicing: what the mechanism actually is
E-invoicing does not mean emailing a PDF. For businesses in scope, an invoice is reported to an Invoice Registration Portal before it is a valid document. The portal validates the payload, assigns an Invoice Reference Number, signs it, and returns the IRN with a signed QR code, which then has to appear on the invoice you give the customer.
Three consequences that catch people out:
- The document is not valid until the portal has accepted it. A PDF generated locally and never reported is not an e-invoice, whatever it looks like.
- The scope has ratcheted downwards repeatedly by turnover, and it covers credit and debit notes as well as invoices — not just B2B sales. Check the current threshold against the latest notification rather than against what applied when you last looked, because this is the single most common reason a business discovers it has been out of compliance for months.
- There are reporting time limits for larger taxpayers, and they have been tightened and extended to lower turnover bands. A system that lets an invoice sit unreported for weeks is storing up a problem it will not warn you about.
Reporting happens either through direct API access to the portal or through a GST Suvidha Provider. For most businesses a GSP is the sensible route — it absorbs the certificate handling, the authentication lifecycle and the portal's periodic changes. Orbis files e-invoices and e-way bills through a GSP, and builds and validates the payload from the invoice record itself rather than from anything re-typed, which is the part that matters: the document you issue and the document you reported are generated from one source.
Where e-invoice payloads get rejected
Rejections are tedious rather than hard, and they are nearly always one of a short list. Software that validates before submitting turns each of these from an interruption into a message at the point of entry.
| Rejection | Underlying cause | Prevented by |
|---|---|---|
| Invalid recipient GSTIN | Typed, never checksum-validated | Validation on the customer master, not at submission |
| Tax amounts do not reconcile | Rounding applied per line and again on the total | One rounding rule, applied once, defined in the system |
| Wrong tax heads for the transaction | Heads chosen by hand rather than derived | Place-of-supply derivation |
| Missing or wrong HSN detail | Codes typed per line instead of held on the product | HSN on the product master |
| Duplicate document number | Numbering series not enforced, or restarted | Enforced numbering, with a reference minted before issue |
| Reported outside the time limit | Nothing watching the gap between issue and reporting | A queue that is visible and alerts |
E-way bills: the one that stops a truck
The e-invoice is a compliance problem. The e-way bill is an operational one, which is why it generates more frustration per rupee than anything else in GST. Goods moving above the prescribed value need a bill with Part A — the consignment details — and Part B, the vehicle. It has a validity tied to distance, and the intra-state thresholds vary by state while the inter-state one does not.
What makes it painful in practice is almost never the rule. It is that the bill gets raised on the portal from numbers re-typed off an invoice, by someone under time pressure, while a vehicle waits. That produces three predictable problems: the bill and the invoice disagree about a value that a checkpoint can compare, the bill expires before the goods arrive because nobody tracked validity, and a vehicle change mid-journey never makes it onto Part B.
What to insist on:
- The bill is generated from the invoice record, not from re-entered figures. If a human retypes the value, the two documents will sometimes disagree.
- Part B can be updated when the vehicle changes, by the person who knows it changed, without going back to the accounts desk.
- Validity is visible against the consignment, and somebody is warned before it lapses rather than after.
- Bills can be raised in a batch for a day's dispatches, because one at a time is how dispatch becomes a bottleneck.
- Cancellation and the time limit on it are handled in the system, so a mistake does not become a permanent one.
The rest of the statutory surface
GST is the loudest part, not the whole of it. A system that handles GST well and these badly has simply moved your month-end problem rather than solved it.
TDS and TCS are deducted by section, and each section has its own rate, its own base and its own threshold. Software that offers one TDS field and asks a human which rate to put in it is not handling TDS; it is storing a number somebody guessed. What you want is deduction by section, monthly liabilities assembled with their challans, and the quarterly and annual statements — Form 24Q and Form 16 for salaries — produced from the same records rather than compiled separately. Orbis computes TDS and TCS by section on the right base for each, which is the distinction worth asking any vendor to demonstrate rather than confirm.
Then there is the question of whether documents post their own entries. If raising an invoice does not create the corresponding ledger entry and the GST output liability automatically, then there is a window in which the invoice exists and the accounting does not, and the size of that window is how wrong your books are at any given moment.
A test you can run this week
Pick one real transaction that is slightly awkward — an interstate sale of something with a batch, to a customer whose GSTIN you have never validated, moving on a vehicle that will change en route. Take it end to end in your current system and count how many times a human has to decide something the system could have derived, and how many times the same figure is typed twice.
The count is your exposure. Every one of those is a notice waiting for a bad week.
If it comes out higher than you would like, book a walkthrough and bring that transaction. Watching one awkward invoice go through a system end to end tells you more than any feature list, which is why it is how we would rather demonstrate it.
Frequently asked questions
Which businesses have to issue e-invoices?
Scope is set by aggregate annual turnover and has been extended downwards repeatedly since e-invoicing began, so the only safe answer is the current notification rather than the threshold that applied when you last checked. Two things are worth knowing regardless: the obligation covers credit and debit notes as well as invoices, and businesses most often discover they are in scope months after they crossed the line, because nothing tells them. If your turnover has grown materially in the last two years, check now.
What is a GSP, and do we need one?
A GST Suvidha Provider is an authorised intermediary between your software and the government portals. The alternative is direct API access, which means you own the certificate handling, the authentication lifecycle and every change the portal makes. For most businesses a GSP is the sensible route and the cost is small relative to maintaining the integration yourself. Orbis files e-invoices and e-way bills through a GSP.
Why do our e-invoice payloads keep getting rejected?
Almost always one of six things: an unvalidated recipient GSTIN, tax amounts that do not reconcile because rounding was applied twice, tax heads chosen by hand instead of derived from the place of supply, missing HSN detail, a duplicate document number, or reporting outside the time limit. Each one is preventable at the point of entry rather than at submission — which is the difference between software that validates and software that forwards.
Can e-way bills be generated automatically from an invoice?
They should be, and this is worth testing rather than taking on trust. The failure that causes real trouble is a bill raised from figures re-typed off an invoice, because the two documents then disagree about a value a checkpoint can compare. Ask to see a bill generated from the invoice record, a vehicle number updated in Part B by the person who knows it changed, and a warning before validity lapses.
Does GST software remove the need for a CA?
No, and be wary of anyone implying otherwise. What good software removes is the assembly work — hunting down invoices, reconciling a stock sheet against the ledger, and producing figures by hand that should have been by-products of documents you already raised. Your CA's judgement on positions, classifications and disclosures is the part you are actually paying for, and it gets better when the underlying records are clean.
