Why Do Importers Struggle to Reconcile Bills of Entry with GST and ERP Records?

Introduction

For importers, reconciling Bills of Entry with GST returns and ERP records is far more complex than it appears. Each import transaction passes through multiple systems of customs, GST, and internal ERP, often with differences in valuation methods, timing, and data formats. These inconsistencies make it difficult to achieve a clean match between records.

Even small gaps, such as differences in assessable value, missing entries, or delays in data capture, can lead to ITC mismatches, reconciliation delays, and compliance risks. This blog explores why these challenges persist, and what makes Bill of Entry reconciliation such a persistent struggle for import driven businesses.

Why reconciliation matters more than ever

India’s GST and Customs administrations now share information through a system that provides data updates almost immediately. The ICEGATE system delivers Bill of Entry (BoE) information to the GST Network, which uses it to verify GSTR-2B and GSTR-3B records. When an importer’s ERP shows different details about assessable value and IGST amount and BoE number, the system creates a mismatch which activates a scrutiny flag that can lead to a demand notice.

 The finance and compliance teams still use manual methods to complete BoE reconciliation because they need to combine multiple sources of data, including customs broker exports, ICEGATE downloads, GSTR-2B data from the GST audit preparedness and purchase entries from SAP or Tally, into a spreadsheet which someone updates only once every three months.

Three documents, three worlds

Before diagnosing why reconciliation fails, it helps to understand what each document is built for and why they were never designed to match each other perfectly.

The basic conflict arises because BoE functions as a Customs document which requires assessment through its assessable value and tariff headings and duty rates. GSTR-2B functions as a GST document because it contains IGST amounts and GSTIN references. The ERP system uses purchase orders together with accounting entries for its operations. The entities lack any primary key that they can share as a standard.

The 9 core reasons importers struggle

• Discrepancy occurs between assessed value and actual invoice amount. Customs determine the amount of IGST taxes based on the assessable value which includes CIF values but excludes actual invoice amounts. The system records the commercial invoice as its standard operation. The resultant difference between values establishes a permanent base value gap which leads to all subsequent values showing different results.

• The process begins with provisional assessment, which leads to its later reassessment phase. The Customs process grants provisional clearance for goods which results in a future BoE issuance that contains an updated IGST value. The ERP system records provisional amounts while the GSTR-3B ITC claim already exists, thus creating an unreconciled state which requires manual updates to both systems.

• Differences in timing occur between ICEGATE GSTR-2B and ERP systems. The GSTR-2B will receive the BoE which was submitted on March 30 after the 13th cut-off date of April. The ERP system creates a GRN entry during March. The GSTR-3B for March has an ITC claim that needs GSTR-2B validation, but this validation does not exist. The GSTR-2B in April shows credit which remains unmatched by any ERP entry. The process of three-way reconciliation encounters failures at both operational points.

• ERP receives Customs broker data without any verification process. Importers depend on their CHA (Customs House Agent) to deliver BoE information to them. The accounts team enters the information through manual keying after they receive it as either PDFs or emails. The typographical mistakes in BoE documents occur with numbers and dates and IGST amounts which remain undetected until an actual audit happens.

• A single commercial invoice receives multiple BoEs. Multiple BoEs emerge from major shipments that divide into smaller deliveries which match a particular purchase order or vendor invoice. The ERP system operates according to a rule which permits only one invoice of entry to match each receipt of entry. The process of mapping multiple BoEs to single PO lines or mapping single BoEs to multiple POs leads to a failure in standard ERP three way matching.

• ITC excludes cess and surcharge while BoE includes these charges as expenses. The BoE document displays Basic Customs Duty together with IGST and Social Welfare Surcharge and multiple cess charge totals. Only IGST qualify as ITC eligible. SWS is not. ERP teams record all duty expenses under one line item which results in them applying for ITC claims beyond their authorized limits.

• The BoE and ERP systems show different exchange rate values. Customs require using the CBIC notified exchange rate which applies to the date of the BoE. The ERP system allows three different exchange rate options the RBI reference rate, the bank’s TT rate or any rate determined by the company. The rupee amounts between the BoE and the purchase entry show differences while their calculated IGST values also display dissimilarities.

• The process handles returned goods after the BoE submission. Customs executes a reassessment process after imported goods get rejected and sent back for re-export. The ERP system creates a debit note or returns entry. The GSTR-2B may show the reversal process, or it may not show it at all. The ITC position shows an inflated state until all three systems achieve complete reconciliation.

• The three systems lack any common point of identification. The BoE number serves as a Customs reference point. The ERP system identifies two elements which include PO numbers and vendor invoice numbers. GSTR-2B requires a combination of GSTIN and

BoE Number but if the CHA entered the BoE number incorrectly in ICEGATE then nothing will match. The process of reconciliation requires manual key search every month because there is no validated common key.

IGST on Imports: The Credit Chain Explained

You can start using reconciliation frameworks after you learn all the details about how IGST transfers from the port to your GSTR-3B. The process begins with IGST payment at Customs when the importer or their CHA uses ICEGATE to pay IGST with the importer’s GSTIN. The ITC entitlement gets created at this moment when the payment takes place. The amount is computed on the assessable value (CIF + landing charges at 1%), not the commercial invoice value. ICEGATE transmits BoE data which includes GSTIN, BoE number, and IGST paid within days of clearance. The data automatically fills the importer’s GSTR-2B under the section of “import of goods.” The critical timing constraint is the 13th of the month: only BoEs cleared on or before the 13th of month M+1 appear in month M’s GSTR-2B. The GSTR-2B statement for the following month includes BoEs cleared after the 13th regardless of their actual BoE date. This single issue creates the largest number of period boundary mismatches between ERP systems and GSTR-2B documents. GSTR-2B serves as the required proof to support the claim because claiming credit for a BoE not yet reflected in GSTR-2B is a compliance risk even if the IGST was genuinely paid. The GST portal’s automated scrutiny tools now flag GSTR-3B claims that exceed GSTR-2B import figures, which automatically generate ASMT-10 notices.

Where ERP Systems Break Down

Most ERP systems such as SAP, Oracle, Microsoft Dynamics were designed without considering the specific workflow requirements of Indian Customs. The operational processes of BoE reconciliation are affected by structural gaps which arise from the system’s design and function. The standard modules cannot be fully fixed through configuration, which leads to complete resolution of structural gaps that exist in the system.

The purchase order and goods receipt note workflow lacks a native BoE number field which creates the most significant structural gap. The teams must use remarks or notes fields for storing BoE references because there is no validated field which they can use for this purpose. The addition of a single custom field to the GRN or import PO which requires validation at entry eliminates this problem.

The second deep structural problem is how ERP systems handle duty booking. Standard AP workflows expect a single vendor invoice with a single tax line. A Bill of Entry has multiple duty components BCD, IGST, SWS, and sometimes additional cess each with different tax treatments. Many ERP setups route all of these to a single “import duty” account or a single “IGST input” account which makes it impossible to separate the ITC eligible component (IGST only) from the non-creditable components (BCD, SWS) without using manual journal entries.

The process of handling exchange rates presents serious difficulties. ERPs use a single exchange rate which is determined by a treasury or finance controller to calculate all transactions during a specified period. The customs department utilizes the CBIC notified rate which gets updated every two weeks and is applicable according to the date of each Bill of Entry. The use of a different ERP booking rate compared to the CBIC rate guarantees permanent value discrepancies between the BoE and ERP records for any company that imports large quantities.

The root structural problem: ERP systems reconcile vendor invoices with purchase orders. A Bill of Entry is neither. It is a government clearance document with its own value computation logic, exchange rate, and duty structure. Forcing BoE data into a vendor invoice workflow creates mismatches that no amount of manual correction fully resolves.

A Practical Reconciliation Framework

The monthly three-layer reconciliation process which occurs before GSTR-3B filing provides better results than the quarterly method which starts after the damage has occurred. The three systems use different interfaces to create specific exceptions which need to be investigated from each of the three layers.

Layer 1 ICEGATE vs. GSTR-2B The import section of GSTR-2B can be compared to the ICEGATE BoE register which needs to be downloaded for the entire month. GSTR-2B should show every BoE that was cleared and paid with the same IGST amount. The three types of exceptions which need to be flagged include two categories of IGST amounts which require GSTR-2B updates to claim the difference and one category which needs Customs to handle an amendment filing because credit cannot move until ICEGATE corrects the record.

Layer 2 GSTR-2B vs. ERP. The BoE number serves as the primary key which matches GSTR-2B import lines to ERP to purchase entries for their matching process. The entries which exist in ERP but lack GSTR-2B support should be flagged because they show ITC which has been claimed too soon and requires credit reversal until GSTR-2B displays the BoE. The entries which exist in GSTR-2B but lack ERP support should be flagged because they typically show goods which have not yet arrived with pending GRN entries or shipments whose CHA has not provided BoE information yet. The GSTR-2B IGST figure needs to be treated as the final amount for ITC claims while the ERP-booked figure should not be used.

Layer 3 ERP vs. Physical BoE Documents The actual BoE PDFs should be checked through spot-checking to compare IGST amounts and exchange rates and duty breakups with what ERP has recorded. The layer detects data entry errors from CHA operations before they result in ITC mistakes. The verification must check that the SWS line routes to an expense account instead of directing an ITC account. The verification process needs to establish that the ERP entry used the correct exchange rate which the CBIC notified for the BoE date. GSTR-3B filing requires all exceptions to be resolved before proceeding.

Best practice: Establish a shared BoE tracker maintained jointly by the CHA and the accounts team, updated within 48 hours of clearance, and validated against GSTR-2B each month before GSTR-3B filing. A single shared register with BoE No., clearance date, IGST paid, GSTR-2B month, and ERP entry reference eliminates 80% of reconciliation disputes before they start.

What Auditors and Scrutiny Notices Look For

GST officers run ASMT-10 scrutiny or conduct audit proceedings on importers to identify high-value red flags which they use to examine importers who show suspicious activity. The most effective method to defend against these threats requires advance knowledge of their existence because it enables precise identification of reconciliation points which need resolution.

The GST portal reconciliation engine uses automated processes to create an ASMT-10 notice through its reconciliation engine without requiring any human actions. The importer needs to deliver BoE documents together with CHA correspondence and a timeline which shows when the BoE appeared in GSTR-2B.

The second most common audit finding is SWS or BCD included in the ITC claim. Officers check whether the IGST amount in GSTR-3B matches the CHS-specific IGST section on the BoE which shows pure IGST instead of total duty outgo. The ITC claim for SWS (10% of BCD) generates an excess amount which can be reclaimed along with interest. Customs officers who work in electronics textiles and chemical industries regularly discover this mistake during their inspections.

The third area of focus is ITC on blocked imports under Section 17(5). Imports of food and beverages personal conveyances goods for employee welfare and certain membership services face ITC blockage because IGST has not been paid at the port. Auditors verify the BoE descriptions together with tariff headings which companies from hospitality aviation FMCG and pharmaceuticals use to file their ITC claims.

The officers check who claimed incorrect GSTIN ITC. The branch must claim IGST as ITC through the ISD mechanism or cross-charge to transfer credit from head office. The audit team usually rejects direct branch claims which involve head office BoE documents.

Conclusion: The Reconciliation Gap Is a Process Problem, not a Data Problem

Importers do not face difficulties with BoE reconciliation because the necessary data remains unavailable as it exists across ICEGATE, GSTR-2B, and the ERP. The three systems function as separate entities because they operate with distinct languages and distinct operational schedules, and they lack any ability to connect with each other because of their design.

The companies that achieve success in this area execute three distinct actions which differ from their current practices. The BoE number serves as their primary key which they treat sacred, and they keep it in a dedicated validated field across all systems starting with the moment the CHA shares it. They conduct monthly reconciliation operations which take place before GSTR-3B filing instead of performing quarterly reconciliation after receiving a notice. The organization educates its ERP and accounts payable staff members about Bill of Entry properties which distinguish it from vendor invoices because it possesses unique value computation standards and exchange rate requirements and ITC eligibility procedures. The department’s ability to identify reconciliation errors decreases as ICEGATE-GSTN data sharing expands, and its analytical capabilities develop. The importer who fixes this process today escapes the demand notice which will come two years later.

Frequently Asked Questions