GST e-invoicing, explained from the billing counter

Most explanations of e-invoicing are written for accountants. This one is written for the person standing at the counter, because that is where the software either works or does not.

The one sentence version

For businesses it applies to, a tax invoice is no longer something you simply print. It has to be registered with the government portal first, which returns an Invoice Reference Number and a signed QR code, and those have to appear on the document you hand your customer.

Whether it applies to you depends on your turnover against the threshold in force. That threshold has been lowered several times since the scheme started, so the correct move is to check your slab against the current rule rather than relying on what was true when you last looked.

Why this is a software problem, not a paperwork problem

The sequence sounds simple until you put a queue in front of it. Your billing screen now depends on a government service responding before the customer can leave. That introduces failure modes that did not exist when printing was a local operation.

• The portal is slow. Your bill cannot sit waiting while six people queue behind it.
• The portal is down. You still have to trade.
• The request succeeded but the reply was lost. Retrying naively registers the same invoice twice.
• The connection dropped mid request and nobody knows which side of the line the invoice is on.

Billing software that was written assuming the portal always answers quickly will hang at the worst possible moment, which is the moment it is busiest. The correct design queues the registration, lets the counter continue, and reconciles afterwards, with something watching for invoices that never came back.

The bit that catches people at month end

UPI collections rarely match the books on amount alone. Money arrives net of gateway charges and frequently on a different day from the sale. If reconciliation is attempted by matching amounts, it will fail, and somebody will spend two days every month finding out why.

Match on the gateway's own reference instead, and record the charge as a separate line rather than quietly reducing the sale. Then the sale, the settlement and the fee are three facts that each tie out, instead of one number that nearly agrees.

What to check in your current system

Three questions will tell you most of what you need to know. Does billing continue when the internet drops? If the portal returns an error, does a person find out, or does the invoice simply vanish from the follow up list? And does the day close reconcile against the drawer and the UPI settlement separately, rather than against a single total?

If the answer to any of those is uncertain, that uncertainty is already costing somebody time at month end.