GST-Compliant Transactional Emails: Order Confirmations, Receipts & Invoices for Indian Businesses

An order confirmation email is a product decision. A tax invoice is a legal document. Indian businesses routinely ship both in the same message, and that is fine — but it changes what the message has to contain, and it changes what happens when it fails to arrive.

The failure is quiet, which is what makes it worth planning for. Nobody complains that your receipt email is missing an HSN code. Your registered business customers simply cannot claim input tax credit against it, and you find out weeks later during reconciliation, from an accounts team, about a transaction from last quarter.

This is what the document needs, how to structure the email around it, and where the mechanics usually go wrong.

When a Receipt Becomes a Tax Document

Not every confirmation email is an invoice, and conflating the two causes most of the confusion. Three different documents get sent at roughly the same moment in a purchase:

You can send all three as one email. Many businesses do. But the moment that email is acting as the tax invoice, the prescribed content applies to it — the label on the email does not decide that, the function does.

The distinction that matters commercially is who is buying:

• A GST-registered business buyer (B2B) needs a compliant tax invoice to claim input tax credit. If yours is deficient, they cannot claim, and they will come back to you to fix it.
• An unregistered consumer (B2C) cannot claim credit, so the invoice matters less to them — but you still have to issue and retain a compliant document.

What a Compliant Tax Invoice Must Carry

The particulars for a tax invoice are prescribed under the CGST Rules. In practice, this is the checklist:

Two of these cause most of the real-world problems.

Invoice numbering. It must be consecutive and unique within the financial year, and it must not exceed 16 characters. A surprising number of systems generate an internal order ID that is longer than that, or that resets in a way that breaks consecutiveness, and then reuse it as the invoice number. Keep the invoice series separate from your order IDs. They serve different purposes and only one of them is regulated.

HSN and SAC codes. These are per line item, not per invoice, and the number of digits required varies with turnover. If your catalogue does not carry these codes as product data, your invoice cannot be generated correctly — and this is a data problem in your product database, not something an email template can paper over.

Separately, businesses above a turnover threshold must generate invoices through the e-invoicing system, which returns an Invoice Reference Number and a signed QR code that must appear on the invoice. The threshold has been revised downward several times since e-invoicing was introduced, so check where it currently stands rather than relying on what was true when your system was built.

The Email Is Not the Invoice

This is the structural point, and getting it right removes a whole category of problems.

HTML email is a terrible container for a legal document. It renders differently across clients, it cannot be reliably printed, it cannot be signed, and it cannot be filed. A finance team that needs to archive an invoice cannot archive an HTML email in any useful way.

The right structure is almost always:

1. The invoice is a PDF. Generated by your billing system, carrying every prescribed field, digitally signed if applicable, with the IRN and QR code where e-invoicing applies.
2. The email delivers it — attached, and with the key details summarised in the body so the recipient can see what it is without opening anything.
3. A link to the invoice in your account area as a durable fallback, because attachments get stripped by corporate mail filters and emails get deleted.

That third point is not belt-and-braces; it is the one that saves you. Attachment stripping is common in enterprise mail environments, and “please resend my invoice” tickets are almost entirely avoidable with a permanent link.

Brixus365 supports attachments directly on the send request — up to 10 files, 5 MB each and 10 MB in total, base64-encoded inline with no separate upload step. Files are not stored after sending:

{
  "to": "accounts@customer.example",
  "templateId": "tmpl_invoice_v3",
  "data": {
    "invoiceNumber": "INV/2026-27/00412",
    "invoiceDate": "18 August 2026",
    "placeOfSupply": "Karnataka (29)",
    "taxableValue": "12,500.00",
    "cgst": "1,125.00",
    "sgst": "1,125.00",
    "total": "14,750.00"
  },
  "attachments": [
    {
      "filename": "INV-2026-27-00412.pdf",
      "contentType": "application/pdf",
      "content": "JVBERi0xLjQKJ..."
    }
  ]
}

GSTIN, Place of Supply, and the Tax Split

The tax split is determined by the place of supply relative to your own state, and it is not something the recipient chooses:

• Intra-state — place of supply in your state: the tax splits into CGST + SGST (or UTGST in a union territory).
• Inter-state — place of supply in a different state: a single IGST line.

For goods this generally follows the delivery location. For services the rules are more involved and depend on the service and whether the recipient is registered. Get this wrong and the invoice is defective in a way your customer’s accountant will notice immediately, because it directly affects what they can claim.

Two mechanical points for anyone building this:

Validate GSTIN format at collection. It is a 15-character identifier: two digits of state code, then the 10-character PAN, then an entity number, a fixed letter, and a checksum character. A format check at checkout catches typos at the point where they are cheap to fix, rather than after an invoice has been issued against a malformed number.

The state code in the GSTIN is a cross-check, not the answer. The first two digits tell you the state the buyer is registered in, which is useful validation — but the place of supply is determined by the supply rules, not by the buyer’s registration state. Deriving the tax split from the GSTIN prefix alone produces wrong invoices for drop-shipments and multi-location customers.

Never build the tax logic into the email template. The template’s job is to render numbers that have already been calculated correctly upstream. If the template is doing arithmetic, the arithmetic is in the wrong place.

Building the Template: Variables, Not Hardcoded Values

Every regulated field should be a template variable populated at send time. Nothing prescribed should be typed into the template body.

The reason is version drift. A hardcoded GST rate is correct until a rate changes, and then every invoice issued from that template is wrong until someone notices. A hardcoded company address survives an office move by producing incorrect invoices indefinitely.

A practical structure for the email body:

• Header: your legal entity name, address, GSTIN
• Invoice meta: number, date, place of supply
• Buyer block: name, address, GSTIN where registered
• Line items: description, HSN or SAC, quantity, rate, taxable value
• Tax summary: CGST / SGST or IGST as separate lines, never a merged “GST” total
• Total: in figures, and in words where your accounting convention requires it
• Footer: reverse-charge statement, signature block, link to the invoice in-account

The tax summary point is worth emphasising. Collapsing CGST and SGST into a single “GST 18%” line is one of the most common defects. Your customer needs the split to claim credit against the right head, and a merged line means they cannot.

{
  "to": "accounts@customer.example",
  "templateId": "tmpl_invoice_v3",
  "data": {
    "supplierGstin": "29AABCU9603R1ZM",
    "buyerGstin": "27AAACI1195H1ZW",
    "placeOfSupply": "Maharashtra (27)",
    "lineItems": [
      { "description": "Annual subscription", "sac": "998314", "qty": 1, "rate": "12500.00", "taxable": "12500.00" }
    ],
    "igst": "2250.00",
    "total": "14750.00",
    "reverseCharge": "No"
  }
}

Keep a versioned template per financial year. When a format requirement changes, you want to reissue an old invoice exactly as it was originally issued — which is impossible if you edited the template in place.

Sending Them So They Actually Arrive

An invoice that lands in spam is, for practical purposes, an invoice you did not send. A few things matter more here than for ordinary marketing mail.

Send invoices as transactional messages, not campaigns. They are triggered by a specific transaction and go to one recipient. Beyond being the correct mechanism, it keeps them out of your marketing consent scope entirely — an invoice is a legal obligation arising from a purchase, not marketing, and it should not be affected when someone unsubscribes from your newsletter.

Use a separate subdomain from marketing. Transactional mail from mail.yourdomain.com and campaigns from news.yourdomain.com build independent sender reputations. A promotional campaign that generates complaints then cannot drag your invoices down with it. The deliverability guide covers why this separation matters.

Use idempotency keys. Invoice emails are exactly the case where a retry after a network timeout must not produce a second send. Sending the same customer two copies of the same tax invoice creates real confusion in their accounts payable process. An idempotency key on the request makes the retry safe.

Handle bounces as a business event, not a metric. A bounced marketing email is a list-quality data point. A bounced invoice means a customer did not receive a document they are entitled to, and it needs to reach a human who can chase a correct address. Wire invoice bounces into your support or finance workflow rather than letting them sit in an email dashboard. The bounce management guide covers the mechanics.

Keep the subject line boring and specific. “Tax Invoice INV/2026-27/00412 from Acme Pvt Ltd” is findable in a mailbox search two years later. “Thanks for your order! 🎉” is not, and it is also more likely to be filtered.

If you are building this now, Brixus365 sends transactional email over a REST API with attachments, template variables, and idempotency support — the email API quick-start covers the request shape, and the transactional email guide covers the wider pattern. Start free — 9,000 emails a month, no card.

Frequently Asked Questions