How to Create GST-Compliant Invoices in India.

Most freelancers don't discover an invoicing problem while invoicing. They discover it nine months later, when a client's accountant refuses to release a payment, or when the numbers in a return don't reconcile with the numbers in a bank account, and nobody can say which version is real.The invoice is the first place your income becomes a record. Everything downstream, what you think you earned this year, what you can actually show, what eventually goes into a return, inherits whatever the invoice said. Get it right at that point and the rest is arithmetic. Get it wrong and you're reconstructing a year of work from bank statements and memory.So rather than a list of rules to read, here's the thing itself, in pieces you can poke at.

Start here: what's actually on a tax invoice

Click any field below. Each one is doing a job, and two of them do considerably more work than the rest.

The question that causes the most damage: which split applies?

When your client is in your state, the tax splits into two components. When they're in a different state, it's a single one. When they're outside India, or an SEZ unit, it's a different treatment again.

This isn't a preference, it follows from where the supply is treated as happening. It sounds trivial until you have clients in four states and you're setting it by hand thirty times a year. Try it:

Two more things that go wrong quietly

A GSTIN that doesn't hold up. Fifteen characters, usually pasted from a WhatsApp message. It can be mistyped. It can belong to a registration since cancelled. It can be the client's registration in a different state from the one you're billing, a business operating in five states has five GSTINs, and they aren't interchangeable. None of this announces itself. The invoice looks fine, and the problem surfaces on the client's side, months later.

Zero-rating an export without cover. If you invoice a client outside India, there's a document that has to be in place for that financial year before you can raise the invoice without charging tax. If it isn't, the invoice is still issued, the client still pays what it says, and the shortfall doesn't disappear, it lands on you. This is the most expensive invoicing mistake an Indian freelancer with overseas clients can make, and it's invisible at the moment it happens.

Doing this in Variabl, step by step

The idea is that you shouldn't have to hold any of the above in your head. You enter facts about the client and the work; the tax treatment is derived from those facts rather than typed in.

What gets caught before a number is assigned

Four checks run at issue. They exist because these are the four mistakes that are cheap to catch beforehand and expensive to catch afterwards. Pick a scenario and see what fires.

Exports, SEZ, and the document behind them

If you work with overseas or SEZ clients, read this twice.

Variabl keeps a record of your cover per financial year, and can tell you two different things. The first is which years you have on file. The second, the one that matters is which of your already-issued invoices are exposed: raised zero-rated in a year with nothing backing them. That's a list of specific invoices with a total, not a status light.

One practical note: cover can't be added from a chat or from the assistant. It needs the actual document uploaded, which happens in the app.

Keeping the number series clean

The series is what people damage without realising. Three rules make it hard to get wrong:

• Drafts don't take numbers. Experiment freely, numbers are assigned at issue, not at creation.
• Cancelling doesn't delete. A cancelled invoice stays on record with its number intact, and that number isn't reused. An invoice that simply vanishes from a series is a worse problem than one marked cancelled.
• Closing isn't the same as paying. If something is written off or settled outside the system, closing it stops the chasing without claiming money arrived. Recording a payment that didn't happen makes your books wrong in the direction nobody thinks to check.

Retainers: set it once, let it run

If you bill the same client the same amount every month, put the invoice on a schedule instead of duplicating last month's. Take an invoice that's already correct and repeat it, the schedule copies the client, lines and amounts, and each generated invoice takes its own number when it's raised.

Two things worth knowing. A start date in the past doesn't backfill months that have gone by. And if a client asks for their invoice early you can raise the next one immediately, but that consumes a real number, so it isn't a way to test whether the schedule works.

Why any of this matters beyond the invoice

Every invoice you raise correctly is a row of clean data. Across a year, those rows are your income record, what you earned, from whom, in which state, taxed which way, and how much is still outstanding. That record is what makes "how did this year go?" answerable in a sentence instead of a weekend.

It's also what a return is built from. If the invoices are right, filing is a summarisation exercise. If they aren't, filing is an investigation. Same work either way, the only variable is whether you do it in March, or in the thirty seconds it takes to read a preview.

Common questions