AD Code Registration on ICEGATE: The Gate Before the Scroll

The asymmetry is the single fact to internalise. Since DG Systems Advisory 10/2022 dated 14.06.2022, as CBIC Instruction 25/2023 records, "AD code registered at one port [is] automatically applicable at all customs locations" — the code that took a fresh application at every new port now propagates from the first registration. But the same instruction continues: "with respect to bank account registration for IGST refund/Drawback purpose, option is available in ICEGATE portal for applying registration of bank account for every port where exporter intends to transact."

The practical trap follows directly. An exporter opening a new lane through a new port checks ICEGATE, sees the AD Code already recognised, files, and clears — and then waits for a refund that cannot disburse, because the account was never registered for that port's scrolls. The friction has since been reduced but not removed: under CBIC Circular 24/2025-Customs (07.10.2025), ICEGATE auto-approves a bank-account/IFSC registration request at a new port where the same combination was already approved elsewhere — the request must still be made, but no officer touches it. The onboarding checklist for any new customs location is therefore one line long and specific: submit the refund-account registration for that port, even though the AD Code needs nothing.

Instruction 25/2023-Customs ended the document-list lottery. The complete application is: (a) the bank's authorisation letter on its letterhead, carrying the exporter's name and address, IEC, PAN, bank account number, and the bank's AD Code and IFSC; and (b) a cancelled cheque — or, where cheque-books are not issued, the latest bank statement endorsed by the bank. Nothing else is prescribed; GST certificates, rent agreements and the rest of the folklore demanded by individual counters are outside the standard. The instruction also sets the tempo: applications made before 2 PM are dealt with the same day, later ones by 2 PM the next working day.

For the CHA-exporter relationship this is a small constitution: it defines exactly what the exporter owes the process and when the process owes an answer. A registration pending beyond the instruction's timeline, or a demand outside its two-document standard, is now a deviation from a written national norm — worth flagging as such, politely, with the instruction number.

Steady-state hygiene is four checks, quarterly: the AD Code registration matches the bank branch actually handling the export account (the EDPMS and realization machinery runs through the same AD relationship); the refund account is registered at every port in use, verified against the ICEGATE account management module; the PFMS Invalidated Accounts report is empty for the IEC; and any banking change — branch shift, merger, account migration — triggers re-registration before the next filing, not after the first missing scroll.

TradeWatch runs these as standing readiness checks: port-wise account-registration coverage, PFMS validation status, and change-event triggers, each anchored to Instruction 25/2023 and the ICEGATE advisory. Kanan Labs prepares a readiness packet. It does not file Shipping Bills, holds no customs credentials, and does not operate the exporter's ICEGATE account — your licensed CHA files, and registrations are made by the exporter or its authorised agent.