Table 6A of GSTR-1: the fields your shipping bill must match

Table 6A of FORM GSTR-1 carries the export invoices for a tax period. Rule 96(2) of the CGST Rules provides that the details of the relevant export invoices contained in FORM GSTR-1 are transmitted electronically by the common portal to the system designated by the Customs, and that the Customs system transmits back a confirmation that the goods covered by those invoices have been exported out of India. The table is therefore not a disclosure. It is one half of a comparison, and the other half was filed by your customs broker weeks earlier.

What is Table 6A for, and who reads it?

Customs reads it, not the tax officer. The GST portal's own guidance on refund for export of goods with payment of tax sets out the sequence: the portal shares the export data declared in FORM GSTR-1, along with a validation that FORM GSTR-3B has been filed for the relevant tax period, with ICEGATE; the Customs system validates that data against its shipping bill and export general manifest records and processes the refund; and no separate refund application is required, because the shipping bill itself is treated as the refund application.

That routing explains why the table behaves so unforgivingly. Nothing in the path is interpreting anything. Two records are being lined up by machine, and a value that a human reader would recognise as the same document is treated as a different one if the string differs. The consequence is set out in the proviso to rule 96(1): where there is a mismatch between the data furnished in the Shipping Bill and those furnished in FORM GSTR-1, as amended in FORM GSTR-1A if any, the refund application is deemed to have been filed on the date the exporter rectifies the mismatch.

Which fields must agree with the shipping bill?

The GST portal's guidance on providing export invoice details names them, and they are worth reading as a checklist rather than as prose.

• Invoice number. The invoice numbers provided in Table 6A must be the same as those given in the Shipping Bill. Not equivalent, the same.
• Shipping bill number and date. Both provided correctly for each invoice, and both resolving to a live shipping bill at Customs.
• Port code. An alphanumeric six-character code as prescribed by ICEGATE.
• Invoice value. The total value of supplies to be exported covered by the invoice, including tax and other charges if any.
• Taxable value. The value of goods on which tax is to be paid, net of tax.
• Tax paid. Integrated tax and cess only, in the case where the export is done on payment of tax.

Invoice value and taxable value are the pair most often filled in wrongly, because the two are the same number on a domestic supply and are not on an export invoice carrying freight, insurance or other charges. Reporting the taxable value in the invoice value field produces a table that reconciles internally and disagrees with the commercial invoice, which is the hardest kind of error to see on a screen.

What does the with-payment flag decide?

Which of the two refund routes the invoice is claiming under. The GST portal's guidance requires that the WPAY or WOPAY flag, with payment or without payment of tax, is correctly selected for an invoice. It is a single choice on each line and it determines whether the invoice is asking for a refund of integrated tax paid or is a zero rated supply under a letter of undertaking, on which no integrated tax is due and no shipping bill refund will follow.

The failure it causes is a quiet one, because a wrongly flagged invoice is not an error in any system. ICEGATE's own IGST refund guidance lists export under a letter of undertaking or bond as one of the reasons a shipping bill can validate cleanly and still pay nothing. The invoice passed every check and simply was not claiming. GST refund on exports: the two routes sets out which route an exporter should be on in the first place.

What is the port code, and why does it break so often?

It identifies the customs location the shipping bill was filed at, in a six-character alphanumeric form prescribed by ICEGATE, per the GST portal's guidance. It breaks more often than its size suggests for two reasons. It is the field furthest from anything the accounts team handles, so it is usually copied rather than known. And it changes with the routing rather than with the customer, so a consignment that moved through a different gateway carries a different code even though every other detail on the file is unchanged.

The portal treats it more leniently than the other fields, which is worth knowing when a book of returns has the same wrong code repeated across it. Its guidance states that a taxpayer can add or amend the port code even after the specified period. That is a narrower exception than it sounds, but on a systematic error introduced by a template it is the difference between a correction and a write-off.

What does GSTR-3B have to say before Table 6A goes anywhere?

It has to have paid at least as much as Table 6A is claiming. The GST portal lists the validations the GST system performs before transmitting return data to ICEGATE: FORM GSTR-1 and FORM GSTR-3B for the corresponding period are filed; export invoices are filed under Table 6A; correct and complete shipping bill number, shipping bill date and port code are provided in that data; the integrated tax and cess amount is reported in Table 3.1(b) of FORM GSTR-3B and not in Table 3.1(a) or 3.1(c); and the amount paid through Table 3.1(b) is equal to or greater than the total shown under Tables 6A and 6B of FORM GSTR-1.

The portal is explicit about the consequence: if those conditions are not met, the data will not be sent to ICEGATE due to validation failure and the refund of integrated tax and cess paid on exports will be impacted. Note what that means in practice. A shipment can be perfect, a shipping bill can be perfect, and the record never leaves GSTN, so there is no status at ICEGATE to look up and nothing to escalate to Customs. The problem is in FORM GSTR-3B.

What is the export ledger, and why does it matter?

It is the running balance behind that comparison, and it is the single most useful screen in the area. The GST portal's manual for tracking refund status describes a ledger based approach that cumulates integrated tax and cess from export and special economic zone invoices in Tables 6A, 9A and 6B of FORM GSTR-1 or GSTR-1A and compares them against the tax paid under Table 3.1(b) of FORM GSTR-3B across all periods. Amounts from Table 3.1(b) are posted as credits and amounts from the export tables as debits, and the difference is the export ledger balance.

The rule the balance enforces is absolute. Eligible invoices are transmitted to ICEGATE only where the Table 3.1(b) amount is equal to or greater than the amount from Tables 6A, 6B and 9A, and in the case of a negative balance the portal will not transmit any eligible invoice at all. One under-reported month can therefore hold up every subsequent month's exports, which is why the ledger is worth reading before any individual shipping bill is investigated. It sits under Services, then Refunds, then track status of invoice data to be shared with ICEGATE, alongside a download of failed invoices.

How is a wrong Table 6A entry corrected?

Through Table 9A of a later return, and the window is not open forever. The GST portal's guidance provides that incomplete or incorrect export details filed in FORM GSTR-1 of previous periods can be amended through Table 9A, amended export invoices, of a subsequent period, and that an invoice left out of Table 6A in a particular month can be reported in Table 6A of a subsequent period. It adds two limits that decide how much of a book can be repaired: amendment can be done up to the specified period, and once an invoice has been used in a certain statement it cannot be amended further.

Errors in FORM GSTR-3B take a different route. The same guidance records that anomalies in a previous period's FORM GSTR-3B may be adjusted in a subsequent month's return in the manner set out in Circular No. 26/26/2017-GST dated 29-12-2017, including where integrated tax and cess on exports was declared in Table 3.1(a) or 3.1(c) instead of 3.1(b), declared as zero, or declared at less than the total from Tables 6A and 6B. Which correction you need depends entirely on which of the two returns was wrong, and diagnosing that is what the export ledger is for. Export refund error codes covers what happens after the data does reach Customs.

Where to go from here

Table 6A is one end of a comparison, so the guides below cover the other end of it and the decisions that put you in front of it.

• What happens after transmission. Export refund error codes takes each validation code apart and names who has to move to clear it.
• Whether this is your route at all. GST refund on exports: the two routes compares the two on cash cycle, document burden and failure mode.
• Why the values diverged upstream. One invoice value, thirteen assertions traces one number through every system that asks for it.
• The bank's version of the same shipment. Why your shipping bill is still showing as open in EDPMS covers the realisation side of the file.

Purser projects the export invoice, the shipping bill data and the values that reach the return from one shipment record, and flags a divergence between them before the return is prepared rather than after the refund stops. Purser never submits to a government portal, never files a return and never sends an outbound message without a recorded human approval event, so your accountant still files FORM GSTR-1 and your customs broker still files the shipping bill. What changes is that the two were compared against each other while both were still editable. Purser Outbound holds the record they are drawn from.

Frequently asked questions

Which fields in Table 6A must match the shipping bill?

The GST portal's refund guidance names the invoice number, which must be the same as that given in the Shipping Bill, the shipping bill number, the shipping bill date and the port code, which is an alphanumeric six-character code prescribed by ICEGATE. It separately defines invoice value as the total value including tax and other charges, taxable value as the value net of tax, and tax paid as integrated tax and cess only where the export is on payment of tax.

What is the port code in Table 6A of GSTR-1?

The port code identifies the customs location where the shipping bill was filed, and the GST portal's guidance describes it as an alphanumeric six-character code prescribed by ICEGATE. It must be provided correctly for each export invoice, and the portal states that a taxpayer can add or amend a port code even after the specified period, which matters where a wrong code has been repeated across many returns from a template.

Why is my Table 6A data not reaching ICEGATE?

Because one of the GST system's pre-transmission validations failed. The GST portal requires FORM GSTR-1 and FORM GSTR-3B to be filed for the period, export invoices to be in Table 6A with correct shipping bill number, date and port code, integrated tax and cess to be reported in Table 3.1(b) of FORM GSTR-3B rather than 3.1(a) or 3.1(c), and the Table 3.1(b) amount to be equal to or greater than the total under Tables 6A and 6B.

What is the export ledger on the GST portal?

It is the running comparison between what the export tables claim and what FORM GSTR-3B paid. The GST portal cumulates integrated tax and cess from Tables 6A, 9A and 6B of FORM GSTR-1 or GSTR-1A as debits against amounts from Table 3.1(b) of FORM GSTR-3B as credits, transmits invoices to ICEGATE only where the Table 3.1(b) side is equal or greater, and transmits nothing at all while the balance is negative.

How do I correct a wrong export invoice in Table 6A?

Through Table 9A, amended export invoices, of a subsequent period's FORM GSTR-1, per the GST portal's guidance. An invoice left out of Table 6A entirely can instead be reported in Table 6A of a subsequent period. Two limits apply: amendment can be done up to the specified period, and once an invoice has been used in a certain statement it cannot be amended further.