Statement 3 and Annexure B errors: causes and fixes
Fix Statement 3 and Annexure B validation errors: return mismatches, BRC/FIRC details, duplicate rows, dropdowns, JSON uploads and split-file reversals.
Start with the statement, the failing stage and the downloaded error report. Statement 3 contains export documents and realisation details; Annexure B contains inward-supply records and ITC information. Their validation checks are different.
Use the Statement 3 section for export invoices and receipt evidence, or the Annexure B section for purchase records and input tax credit (ITC). Correct the working copy, regenerate the file and check the accepted result after each retry.
Save the evidence before retrying
Keep the original file and how it was made (the JSON generator, or the offline utility’s workbook and its version), the generated filename, selected refund category and period, upload time, screenshot and downloaded error report. Work on a copy. If you use the offline utility, check that you downloaded the current one for the same refund category. Check that you are using the correct statement upload section.
Distinguish three stages: the checks before the file is created, file upload, and portal document validation. A file accepted for upload can still contain invalid documents. A validated document does not establish legal refund eligibility.
You can run the first stage without Excel. The JSON generator applies the offline utilities’ checks in a browser and lists every problem with its row. It also opens a JSON file that either utility made, so a failed file can be corrected there.
Statement 3 errors and resolutions
For this service-export route, the GST portal validates Statement 3 documents against the export information declared in GSTR-1. Start with the official Statement 3 FAQ and upload manual.
A document row fails the checks before the file is created
Check required fields, document type, date format and application header. The JSON generator lists each problem with its row and field. In the utility, read the row’s Error column, correct the source cells, then run Validate & Calculate again. Compare the row with the invoice, debit note or credit note. Header From/To periods use mmyyyy.
A services row asks for shipping-bill or goods details
Check goods/services selection. Select the service option for an actual service export. Services require BRC/FIRC evidence; goods have shipping-bill/EGM requirements. Do not enter invented goods details to get past validation.
BRC/FIRC details fail local validation
Check for a missing certificate, unsupported reference or incorrect format. Use the real bank evidence. The manual specifies 3–30 alphanumeric characters for the reference. Investigate a nonconforming source reference with the issuing bank; do not silently truncate it. Use separate rows for unique bank references.
One invoice has several receipts, or one receipt pays several invoices
Check receipt allocation and double counting. The manual permits multiple BRC/FIRC references for a document and the same reference against several invoices. Keep an allocation sheet proving how much of each receipt is used, without counting its full value repeatedly.
“Future date is not allowed for Document” despite a correct document date
Check the document date and the computer’s system date. The official FAQ specifically says an incorrect system date can cause this message. Correct the computer clock if wrong; preserve the real document date. If it persists, retain the evidence for support.
A BRC/FIRC predates the export invoice
Check whether this is supported by the actual remittance records. The manual permits a BRC/FIRC date before, on or after the document date. Do not move the date just to make the chronology look simpler. Review advance receipts and the refund-period treatment separately.
Upload succeeds but portal validation identifies invalid documents
Check differences from filed GSTR-1, wrong document details, wrong GSTIN/period or missing applicable returns. Download the Invalid Document report and compare each identified field with the source document and filed return. Correct a preparation error in your entries and create the file again; where the return itself is wrong, review the proper return-correction route. Do not alter a real invoice simply to force a match.
Check applicable return filing before starting the refund. The manual requires due returns and the relevant latest GSTR-3B to be filed for the selected claim. Local JSON generation cannot resolve an unfiled return.
Example: prevent a repeated receipt amount
Suppose one bank certificate records ₹13,000: ₹5,000 settles invoice EX26-001 and ₹8,000 settles EX26-002. Those allocations sum to ₹13,000. Treating the same certificate as ₹13,000 realised for each invoice would imply ₹26,000 of receipts. Retain the real certificate and the allocation working; do not invent a second certificate. All amounts and references in this example are fictional.
Use the Statement 3 worked example for the complete working. If bank evidence is missing, follow the FIRC and bank-document guide. If the export invoice itself needs checking, use the foreign-client invoice guide.
Annexure B errors and resolutions
GSTN’s 18 May 2026 Annexure B advisory, sections 2–10 gives the following checks. Several concern the Excel utility itself; if you use it, read them together with the Read Me in your current download.
A pasted dropdown value fails
Check exact spelling, spaces, available choices and protected cells. Select the utility’s dropdown option. If pasting, match it exactly and remove accidental leading/trailing spaces. Do not paste into frozen/protected fields.
Copy/paste behaves unexpectedly in a newly downloaded utility
Check whether an older Annexure B workbook is still open. Close the previous version completely, then use the new utility. The advisory explicitly identifies simultaneous older workbooks as a possible cause.
Duplicate-document validation fails
Check supplier GSTIN, invoice number, date, input category and HSN/SAC, within the same inward-supply and document type. For an identical combination, consolidate the genuine amounts into one line and reconcile to the invoice. Keep distinct HSN/category lines separate. Do not change an invoice number or HSN merely to evade the check.
Two suppliers used the same invoice number
These rows are not duplicates. The duplicate check includes the supplier GSTIN, so invoices from two suppliers with the same number are valid in one file.
If the portal’s GSTR-2B validation still reports one of them as invalid, CA Abhas Halakhandi reports that uploading the two invoices in separate Annexure B files lets both validate. An application accepts up to 25 files; give each file its own name and enter the reversals only in the last file, as described below. GSTN’s advisory does not describe this case. If separate files do not resolve it, keep the Invalid Documents Report and raise a ticket with GSTN. (Checked 22 October 2026.)
One invoice has several HSNs or input categories
Check whether the whole value/tax was repeated on every row. Split by category and HSN/SAC, allocating the value and tax across the rows. The sum must reconcile to the original invoice.
A document fails GSTR-2B validation
Check actual GSTR-2B period, supplier/document details and the invalid-report reason. Compare with the relevant downloaded GSTR-2B and source invoice. Correct a preparation mismatch; investigate missing or incorrectly reported supplier data separately. Use the actual applicable 2B period rather than copying the refund header period.
A period up to October 2024 is described as not validated against GSTR-2B
Check whether it is the older-period message described by GSTN. The advisory says automated 2B validation is not performed for those periods and these rows can appear among validated documents. That message alone is expected behaviour. Continue the documentary and eligibility review; it is not proof that the credit is eligible.
JSON generation/upload fails after manual changes
Check extra spaces, edited JSON or an altered generated filename. Correct the entries where the file was made, in the JSON generator or the utility, check them again and create a fresh file. Upload the generated file with its original filename. GSTN advises against editing JSON or renaming it after creation.
Consolidated Net ITC is unexpectedly low with several files
Check whether reversals were entered in every file. Reconcile to GSTR-3B and the reversal working. Enter the claim’s reversals only in the final file; preceding files use zero reversals. Check the consolidated portal summary after all files are uploaded.
For November 2024 and later GSTR-2B periods, GSTN says mismatches and validation failures appear in the Invalid Documents Report. A missing invoice and a formatting problem need different investigations; repeated uploads cannot substitute for resolving the underlying record. See which GSTR-2B period to use.
Example: a genuine split versus an accidental duplicate
A fictional invoice contains ₹30,000 of one HSN and ₹20,000 of another, with ₹5,400 and ₹3,600 tax respectively. Two properly classified rows preserve ₹50,000 of taxable value and ₹9,000 of tax. Repeating ₹50,000 and ₹9,000 on both rows doubles the purchase. Two rows with the same category and HSN need consolidation where the other duplicate-key fields also match.
For a full purchase-side working, use the Annexure B example. Keep ITC eligibility and reversals separate from the mechanics of passing validation.
Which rows should you upload again?
For Statement 3, the official manual distinguishes an error-document retry from replacing an already valid statement:
- After validation with errors, download the report, correct the affected records and upload only the error documents again.
- To change a statement that already validated without errors, the documented route is to delete the whole statement and upload its replacement. Save the existing downloads and complete replacement working before doing this.
For Annexure B, use the report and replacement instructions on its current portal screen. GSTN’s May advisory describes the valid/invalid reports and regeneration process, but does not establish that every Annexure B retry uses the same replacement scope as Statement 3. Do not delete accepted records or resend every invoice based solely on a generic upload-error message.
In both cases, maintain a log of generated filename, row count, upload result and accepted/failed count. A stale JSON from before the correction is a common preparation risk to rule out. Regenerating from the reviewed entries also preserves an auditable source, rather than patching the upload output.
Annexure B split-file limits and reversals
GSTN documents 10,000 line items per file and up to 25 files, totalling 250,000 line items per application. Beyond that, its advisory describes providing remaining invoices as PDF supporting documents; confirm the current portal facilities before preparing an unusually large claim.
Enter reversals only in the final file. If those claim-wide reversals exceed that file’s credit, its standalone arithmetic can be negative; review the combined calculation after all files are uploaded rather than deleting valid reversals to make one file positive. Reconcile line counts, tax heads and totals to the complete working. GSTN advisory, sections 6 and 10.
When the documented checks do not fix it
Keep the exact message and failing stage, how the file was made (with the utility’s version if you used it), category, period, time and error report for a GSTN technical-support ticket. Share taxpayer records only through the appropriate support channel, not a public comment. Do not repeatedly change genuine dates, classifications or amounts without a source-backed correction.
An upload error occurs before or during statement preparation. If the application is already filed and you received an officer’s memo or notice, use the RFD-03 and RFD-08 response guide instead.