If you talk to ten exporters about e-invoicing, you'll probably get ten slightly different answers about what it actually requires. That's not because the rule is complicated. It's because most people first heard about it from a WhatsApp forward or a half-finished conversation with their CA, and the details never quite got filled in.
So let's clear it up properly.
E-invoicing isn't a new invoice. It's a new step.
The commercial invoice you already send your buyer doesn't change. What changes is what happens on the GST side before that invoice is considered valid for reporting purposes. Once you cross the applicable turnover threshold, every export invoice (yes, including zero-rated ones under LUT, and ones with IGST paid) needs to be reported to the Invoice Registration Portal. In return, you get an Invoice Reference Number and a QR code. Without that IRN, the invoice technically isn't a valid tax document, no matter how correct the numbers on it are.
For a lot of exporters, this comes as a surprise. There's a common assumption that exports are "outside GST" in some general sense, so surely the e-invoice rule is for domestic sales only. It isn't. Export invoices fall squarely within scope once you're above the threshold, and shipping bills, LUT filings, and GST returns all eventually need to tie back to that IRN.
Where this actually bites exporters
The problem isn't the concept. It's the timing.
Export documentation usually gets prepared under some amount of pressure. The container is booked, the forwarder needs the invoice and packing list to file the shipping bill, and everyone is trying to move fast. If your invoice has to be generated, sent for IRN registration, and then have that QR code and IRN printed back onto the document before it goes anywhere near customs, that's an extra round trip you didn't have to make before. Miss it, and you're either refiling the invoice or explaining to your forwarder why the shipping bill data doesn't match.
There's also a smaller but annoying issue around invoice value. IRN generation has its own validation rules for how amounts, HSN codes, and units are formatted. An invoice that looks perfectly fine to a human reviewer can still get rejected by the portal over something like a decimal mismatch or an unrecognised UQC code. If you're preparing that invoice manually, you often find out about the rejection only when you're already trying to submit it.
What "e-invoice software for exporters" should actually mean
This is where the phrase gets used a bit loosely. Plenty of tools will tell you they support e-invoicing. What matters is where in your workflow that support sits.
The useful version looks something like this: you prepare the export invoice the way you normally would, using the same product, buyer, and shipment details already in your system. The software checks the invoice against the formatting rules before you try to register it, so the common rejection reasons get caught early. Once the IRN and QR code come back, they attach to that same invoice record automatically, so the version you hand to your forwarder is already the final, registered one. Nobody is copying numbers between three different screens to make it work.
The less useful version is a bolt-on where you're still preparing the invoice in one place and pushing it into a separate e-invoicing tool by hand. It technically satisfies the requirement, but it just moves the manual work around instead of removing it.
A quick way to check where you stand
If you're not sure how exposed you are to this, ask yourself three questions. Is your export turnover anywhere near the applicable threshold, including previous years, not just the current one? Does whoever prepares your invoices know the exact IRN rejection reasons that have come up in the last few months? And when a shipment is urgent, does the invoice-to-IRN-to-shipping-bill sequence still work without someone chasing it manually?
If the answer to that last one is "it depends on who's in the office that day," that's usually the sign that the process needs to move into the software rather than living in someone's head.
Where this fits with the rest of your documentation
E-invoicing doesn't exist on its own. It sits between your commercial invoice and everything downstream of it, your packing list, your shipping bill filing, your bank documentation for realisation. If your export documentation software treats these as separate, disconnected steps, e-invoicing just becomes one more disconnected step. If it treats them as one continuous record, e-invoicing is just one more field that gets filled in automatically along the way.
That second version is the one worth aiming for, whether that's through ExpoMaster or otherwise. The rule itself isn't going anywhere, and the exporters who build it into their existing invoice workflow now will spend a lot less time thinking about it a year from now than the ones still treating it as a separate compliance task bolted onto the side.