Export Invoice Format Under GST: Fields, LUT & Types

An export invoice under GST is a tax-compliant commercial document that an Indian exporter issues to an overseas buyer for goods or services sold abroad. It is the proof of the export transaction: your bank uses it to close the remittance, and the GST system uses it to establish that the supply is zero-rated and eligible for an IGST refund or input tax credit.

There is no single government-prescribed layout, so "export invoice format" really means a normal tax invoice that carries the extra fields set out in Rule 46 of the CGST Rules 2017, plus the currency and FEMA details your bank needs. You can build it in Word, Excel or any billing tool such as Xflow Invoicing, as long as the mandatory fields are present.

There are three types by tax route:

• Export under LUT or bond: no IGST charged (the common route for service exporters).
• Export with payment of IGST: you pay IGST and claim it back as a refund.
• Supply to an SEZ unit: treated as a zero-rated supply too.

This guide is written for IT and services exporters (SAC-based, no shipping bill), with goods-export notes kept secondary.

The fields below sit under Rule 46 plus FEMA and customs practice. For a services export you use a SAC code and skip the port and shipping-bill rows a goods exporter needs. Here is an annotated sample for a service export invoice:

Each label on that sample maps to a specific rule. The table below is the field-by-field checklist, keyed to the same labels, so you can see exactly what is mandatory and which rows a goods exporter adds that a services exporter does not.

Take the sample above: Acme Analytics LLP bills Nimbus Corp USD 5,000 for software development. Because it is a service export under LUT, the invoice carries SAC 998314, the LUT declaration line and the FX block, and it skips the shipping-bill and port rows a goods exporter must add for customs.

Get the HSN code or SAC code right: goods use an 8-digit HSN, services use a SAC. The declaration line and the FX block are the two rows generic templates most often drop.

Exports are zero-rated, so you do not add GST to the buyer's bill either way. What changes is how you handle the tax internally, and that is the choice freelancers and SMBs get stuck on. You pick one of two routes and print the matching declaration line.

The LUT route keeps cash in the business because you never part with the tax. The IGST route means you pay first and wait for the refund. For a fuller decision walk-through see LUT vs IGST refund, and note that LUT filing specifics are best confirmed with your CA.

Yes. You invoice the buyer in the agreed foreign currency (USD, EUR, GBP), but the invoice must also show the INR equivalent for GST and FEMA. Which rate applies is set by Rule 34 of the CGST Rules, and it differs by supply type:

• Services (SAC-based): Rule 34(2) uses the rate determined under generally accepted accounting principles (AS-11) for the date of time of supply. In practice most service exporters take the FBIL reference rate for that date. RBI discontinued publishing its own reference rate in July 2018 and the FBIL rate now serves that role.
• Goods: Rule 34(1) uses the exchange rate notified by the CBIC (customs) for the date of time of supply.

Either way, use a published reference rate and the invoice date, not your bank's card rate or a figure you guess, and show both the rate and the rupee value.

Worked example for a service export (illustrative FBIL reference rate):

That INR 4,30,000 is the taxable value you report, even though the money lands later at whatever rate applies on the payment date. The gap between the two rates is a normal FX difference, not an error on the invoice.

These four get conflated constantly. In practice one document often does two jobs, but they are not the same thing.

For services there is usually no separate customs document, so your export invoice does the work. For goods, the commercial invoice for export accompanies the shipment. A proforma invoice is only a preview and carries no tax effect.

This is where goods and services genuinely differ, and where a lot of the freelancer confusion comes from.

• IEC (Import Export Code): needed for goods. Pure service exporters can often invoice without one, though many businesses hold an IEC anyway.
• HSN vs SAC: goods carry an 8-digit HSN; services carry a SAC code.
• Shipping bill and port of loading: goods only. A service export has no shipping bill, so those rows do not apply to you.

If your work is software, design, consulting or support delivered from India to a foreign client, you are on the services track. The conditions for zero-rating (place of supply, payment in convertible foreign exchange, LUT on file) are covered in export of services under GST.

E-invoicing follows one simple threshold: if your aggregate annual turnover (AATO) has crossed ₹5 crore in any financial year from 2017-18 onwards, you must generate an Invoice Reference Number (IRN) on the IRP portal, and that includes your export invoices (as of July 2026). Below that turnover, IRN does not apply to you, so most freelancers and small exporters do not need it.

Crossing the threshold once makes it permanent even if turnover later drops. The exact rule and edge cases are set out in the current e invoice limit guide.

Raising the invoice is only step one. The invoice has to close the loop: the money must come in, be evidenced, and reconcile back against that same invoice. This is the part template sites skip, and it is where compliance either stays quiet or turns into a chase.

The realisation loop

Once the buyer pays, the inflow is a foreign inward remittance tagged with an RBI purpose code (for example P0802 for software services). Your bank matches the receipt to your invoice, and the record flows to the RBI's EDPMS so the export is marked as realised.

FIRC and eFIRA as proof

The proof that the proceeds arrived is the Foreign Inward Remittance Certificate (FIRC) or its electronic advice, the eFIRA. Xflow issues an eFIRA automatically against each receipt, so the realisation and repatriation of export proceeds are documented without a separate bank request.

Matching for the IGST refund

If you took the IGST-payment route on goods, the refund is auto-processed through ICEGATE and GSTN, but only if the invoice number in your GSTR-1 matches the shipping bill exactly. A mismatch is the single most common reason refunds get stuck. Report the same invoice details in GSTR-1 for export of services that appear on the invoice itself.

Receiving the money cleanly

Where the funds land matters too. Multi-currency receiving accounts let the buyer pay in their own currency, convert at the mid-market rate (MMR), settle into your Indian bank account on a next-business-day (T+1) basis, and reconcile the eFIRA back to the invoice. Nothing downstream in your FIRC, EDPMS or GST-refund workflow changes.

Before you send it, confirm the invoice carries:

• Unique sequential invoice number and date
• Your name, address, GSTIN and (if held) IEC
• Buyer name and full foreign address
• SAC code and a clear service description
• Amount in foreign currency
• The exchange rate used (FBIL reference rate per Rule 34) plus the INR equivalent
• Place of supply marked "Outside India"
• The correct declaration line (LUT or IGST)
• LUT ARN and validity, if under LUT
• Authorised signature

Keep the same invoice number across your GSTR-1 and your FIRC for GST refund records so the paperwork reconciles on its own.

Issuing a compliant export invoice is step one. Getting paid and completing the compliance loop is where things slow down for most exporters. Your bank needs the invoice reference to match each inward remittance before they can issue a FIRA — and without the FIRA, your GST refund claim stalls. If your bank is slow to issue it on its own, a formal firc request letter can help move things along.

Is your exporting business struggling with delayed payments, invoice mismatches, or compliance hurdles when dealing with international clients?

Xflow helps Indian exporters streamline their export invoicing process and receive foreign payments directly, without hidden fees, US bank accounts, or any regulatory stress. Generate compliant export invoices, track cross-border payments, and save on FX costs, all in one place.