In the recent refund filings for unutilised ITC, one of the most noticeable changes on the GST portal is in Annexure-B. The updated offline utility now requires much more granular invoice-level details compared to the earlier format. While the intention seems to be better reconciliation with GSTR-2B and GSTR-3B, in practice it has increased the workload significantly for taxpayers and consultants.
As per the requirement under Circular No. 125/44/2019-GST, Annexure-B continues to be the supporting statement of invoices for refund of accumulated ITC. However, the revised utility has changed the way data needs to be captured and validated.
What has actually changed in Annexure-B utility
The most visible change is the addition of multiple new fields which were not there earlier. Now the invoice needs to be classified in more detail, especially:
- Type of inward supply
- Type of document (invoice/credit note/debit note / BoE etc.)
- Port code in case of imports
- Whether ITC is blocked under Section 17(5)
- Amount of ineligible ITC
- GSTR-2B period tagging
Earlier, most of these were either not required or were handled through working statements. Now they are directly part of the JSON structure, which means even a small mismatch leads to validation errors.
Type of inward supply - Practical Difficulty
This is one of the most sensitive fields in the new utility. Each category has to be selected correctly, and splitting is mandatory.
For example:
- Import of goods/services are separate
- SEZ to DTA supplies are separately classified
- RCM from registered and unregistered persons are split
- ISD credits have a separate category
In practice, the issue is not understanding these categories, but ensuring GSTR-2B mapping is consistent with how the system expects classification. Even a correct accounting entry may fail validation if classified under a different bucket.
Document type and date formatting issues
Another common issue faced while preparing JSON:
- Document number accepts only 16 characters (including special characters like “/” or “-”)
- Date must strictly be in DD-MM-YYYY format
- GSTR-2B period should be in MM-YYYY format
A small formatting mistake here leads to rejection at JSON upload stage itself.
Matching with GSTR-3B still remains critical
Despite the additional fields, the basic reconciliation requirement has not changed. The ITC reported in Annexure-B still needs to match with:
- Table 4(A) of GSTR-3B
and reversals must align with:
- Table 4(B)(1)
- Table 4(B)(2)
and reclaim should be considered under:
- Table 4(D)(1)
The difficulty arises especially in cases where ITC is temporarily reversed and reclaimed in later months. The same invoice tends to appear more than once in different contexts, which creates duplication issues in the utility.
Practical issue - 4(B)(2) reversals and reclaims
This is probably the most confusing part in actual working.
Where ITC is reversed due to non-receipt of invoice or other reasons under 4(B)(2), and later reclaimed under 4(D)(1), the invoice effectively gets reported twice in different months.
Technically it is correct from return perspective, but while preparing Annexure-B, it creates duplication in the dataset. In such cases, it becomes necessary to maintain a proper reconciliation statement to explain why the same invoice appears more than once.
Capital goods reporting confusion
Another grey area is capital goods. The utility does not clearly distinguish exclusion logic.
In practical terms:
- If marked as eligible ITC, it may get included in refund computation
- If marked under blocked credit (17(5)), it gets treated differently
However, capital goods ITC is generally not part of refund of accumulated ITC, so proper care is required while tagging such invoices. Otherwise, it may lead to incorrect inclusion in refund calculation.
Validation issues before JSON generation
Some of the frequent validation errors noticed:
- Decimal values restricted to 2 digits
- “Zero” values not accepted in certain tax fields
- Tax columns must be blank if not applicable
- Document number restrictions (16 characters limit)
- Mandatory port code for import entries
- Total ITC must match computed eligible ITC
Interestingly, even if JSON is generated successfully, the portal still performs its own validations after upload.
Errors after uploading JSON
After upload, additional mismatches are triggered mainly due to:
- GSTR-2B mismatch
- Incorrect period tagging
- HSN classification mismatch
- Wrong selection between goods vs services
- Inward supply type mismatch
In some cases, system also flags entries which are not part of GSTR-2B, especially:
- Imports of goods/services
- RCM under unregistered persons
- ECO-related supplies
These often appear as warnings, but do not always block processing of eligible ITC.
Practical takeaway
At present, Annexure-B preparation has become more of a reconciliation exercise than just data entry. The utility is still evolving, and there are several areas where clarity is not fully aligned with practical accounting scenarios.
Until further refinements are made in the portal, it is advisable to:
- Maintain detailed invoice-wise reconciliation
- Document reasons for duplication or mismatch
- Keep working papers ready for departmental queries
Most issues get resolved at the clarification stage rather than at the system level, so proper documentation becomes more important than ever.
Disclaimer: This article is based on practical experience and understanding of GST refund procedures. It is intended solely for academic and informational purposes. It does not constitute professional or legal advice. The author shall not be responsible for any loss arising from reliance on this content. Readers should verify provisions under the applicable GST law and consult a professional advisor where necessary.
CAclubindia
