Skip to content

e-Invoice Setup

Applies to: e-Invoice · Which modules do I have?

Purpose

Prove the e-Invoice module works end to end in the sandbox — including its failure paths — before any integration depends on it.

Audience

The implementation consultant, with the customer's tax operations team.

Prerequisites

  • GST Configuration gate passed
  • Provider connection test passing, against sandbox
  • Master data loaded and verified
  • Users with generation authority available for testing

Steps

1. Prepare test documents

Prepare real-shaped documents, not minimal samples. A sample carrying only the fields you thought of proves nothing about the population that will fail.

Type Purpose
Domestic tax invoice, single line The baseline
Domestic tax invoice, many lines Array handling
Inter-state invoice Place of supply and tax structure
Export invoice The most commonly missed edge case
Reverse charge invoice Different tax treatment
Credit note Different routing and a preceding-document reference
Debit note Same
An invoice with a discount and rounding Where arithmetic fails

2. Take one document all the way

Step Confirm
Ingest Accepted, with an identifier
Validation Not quarantined
Route Status matches the expected route
Generate Reference number, signed QR and acknowledgement all stored
Print Renders; QR scans from a printed copy
Status Reflects registration correctly

3. Test every document type

Repeat for each type in the list. Each will surface something the baseline did not — export documents in particular, which have their own place-of-supply rule.

4. Test the failure paths

Do not skip this. A system that fails usefully is what makes every later stage diagnosable. A system that fails vaguely produces tickets nobody can close.

Test Expected
A required field left empty Quarantined, with the field named
A malformed registration number Quarantined, specifically
A wrong-length classification code Quarantined, specifically
The same document number twice Rejected as a duplicate
A document dated outside the reporting window Isolated at ingest, with a clear reason
A document for an unonboarded registration Rejected as out of scope

Each failure must produce a specific, actionable message. A generic error at this stage becomes an unresolvable ticket after go-live.

5. Test correction and promotion

Take a quarantined document, correct it in the Correction Cockpit, promote it, and register it. This is the loop operations will run daily, and the team should perform it themselves rather than watch it.

6. Test cancellation

Cancel a registered test document in the sandbox and confirm three things:

Confirm Why
The status becomes cancelled The action worked
The document number remains consumed Cancelling does not release it — the single most misunderstood behaviour in the product
The team understands the consequence A corrected document needs a new number

7. Confirm authority is enforced

Sign in as a maker and attempt to register a document. Refused, when segregation is enforced. This verifies stage 4 in the context that matters.

8. Decide on automatic registration

Leave it off through implementation. Revisit at stage 10, only once validation quality is demonstrated over real volume.

Validation

Gate: this stage is complete when all of these pass.

Check Pass condition
Every document type registers In the sandbox
Edge cases work Export, reverse charge, multi-line, discounts, notes
Printing verified from paper QR scans from a printed copy
Every failure path tested Each produced a specific, actionable message
Duplicate detection works Second submission rejected
Reporting window enforced A stale document isolated at ingest
Correction loop works Performed by the customer's team, not the consultant
Cancellation understood Including that the number stays consumed
Authority enforced A maker cannot register
Automatic registration off Deliberately

Rollback

Situation Action
Test documents clutter the sandbox Leave them. They are sandbox records; deleting them proves nothing
Wrong configuration found Correct it and re-test. Documents already registered in the sandbox stay registered
A test document registered in production This cannot be undone. The number is permanently consumed. Treat as an incident and fix the environment separation before continuing

The last row is the only irreversible outcome in this stage, and it is entirely preventable by using sandbox credentials.

Common mistakes

Mistake Consequence Avoid by
Testing with minimal samples Real documents fail after go-live Use real-shaped documents
Skipping edge cases A wave of failures weeks later Test export and reverse charge explicitly
Skipping failure paths Unresolvable tickets after go-live Test every one
Verifying print on screen A QR that fails on paper Print and scan
The consultant performing the correction loop The team cannot do it on day one They perform it; you watch
Not testing cancellation The number-consumption behaviour is discovered in production Test it and explain it
Enabling automatic registration early Rejections at volume Leave it off
Using production credentials A permanently registered test document Sandbox only

Troubleshooting

Symptom Cause Action
Documents quarantine unexpectedly Master data incomplete for what registration requires Fix the master data, not the document
Generation fails with a numbered error A government rule Look it up; act by its classification
Generation fails with no code Provider connectivity or capability Run the connection test
A whole batch quarantines Outside the reporting window Expected for historical documents
Printing fails, generation succeeded Rendering or configuration, never the government See Print Configuration
A failure message is vague Investigate now A vague failure now is an unresolvable ticket later