Back to Home Back to Previous

Electronic Data Interchange (EDI) is simply a set of data definitions that permit business forms, that would have been exchanged using paper in the past, to be exchanged electronically. This simple set of definitions has spurred a number of organizations to put in place an operational environment in which the exchange of electronic business forms substitutes for the exchange of paper forms. This has resulted, in some cases, in the establishment of an EDI environment, which arguably represents the most advanced state of electronic commerce today, causing some to view EDI and electronic commerce as one and the same. We view EDI only as a subset of electronic commerce, albeit a very important one. As such, EDI provides an excellent example of a working electronic commerce environment and is a good starting point for examining electronic commerce.

Electronic data interchange aims at single point collection of data for use by various agencies participating in a common activity.
Click on the following for details

The basic documents for transaction of business will be taken only once by one agency and other agencies will take the information from that agency, electronically, avoiding the need to either physically take the document from one office to another or keying in the data again and again involving the attendant problems of manual labor and errors creeping in at each stage of data entry.


  • Customs to Port Trusts/Airport authority.
  • Customs to Customs.
  • Customs to DGFT (Min of Commerce).
  • Customs to Export promotion councils,like AEPC, HEPC, etc,
  • Customs to RBI/Banks.
  • Customs to Importers/Exporters
  • Customs to Custom House Agents
  • Customs to Shipping Lines/Airlines



It should be possible to create a few or even a single message/document for the entire process of transactions in the course of foreign trade. Steamer agents would file manifest with the Customs Electronically that would be used also by Port Trust. CHA's/Importers file B/E / S/B electronically with the Customs which could cover more data so that Port Trust, CFS's, Transport authorities, Sales Tax Dept. are able to use the same. The Certification of Licence would be available on-line once EDI connectivity is established with these agencies (like DGFT, ASI, AEPC etc), when electronic fund transfers (EDI for banks) are established, Importer / Exporter can make payments without drafts or coming to Nodal bank for the purpose and can receive his refund drawback payment directly to his account.

Once VSAT connectivity is established with all Customs / Excise formations in India, all modvat verifications, end use certificate, rewarehousing certificate for transfer bonds, TRA's could be made immediately. Above all there would be uniformity in assessment decision all over India.

EDI is a way of business life. It is based on the principle of trust and contractual obligations. Once Evidence act and other laws of the land recognise EDI transactions and provide for the same by fast settlement of disputes, it should be possible to do away with requirements for paper documentation, i.e., there would be no necessity to submit invoices, packing list, B/L etc in paper. Records need only be kept at the offices of Importers / Exporters / CHA's for a minimum period, for verification by concerned authorities, if required. Since EDI is based on trust, there would be not need for examination of cargo in a routine manner, the facility of Green Channel would apply to almost 80% of cases of regular Importers with a clean tract record. Therefore it is essential that Govt., trade and transporters recognise the likely benefits and move forward to establish a regime of mutual trust and confidence.

Electronic Data Inter-change (EDI) is a way of business life, which thrives in an environment based on trust of faith, whereas in the present manual system the procedures and practices are all based on lack of trust and faith. Attitudinal change in the officers and the business people is required to adopt to EDI. EDI is a reality, EDI cannot be introduced in a significant way unless we have complete overhaul of working system, methods and procedures. Above all unless the Laws/Acts governing business in the country are amended to recognise EDI transactions, full-fledged EDI is not possible. Unless sincere efforts are made to transform the working environment, with a distinct positive attitude we would be left behind in the interest of the nations economic prosperity we adopt ourselves to global scenario and move towards paperless transaction system.


With the issual of Tender Document dated 01st February 2000, CBEC has invited bids for "Supply, Installation and Commissioning Of Electronic Commerce/EDI Gateway and Network for Indian Customs".

It is now proposed to extend EDI services to all trading partners by setting up the Customs gateway, which would handle all transactions centrally and route it to the concerned Customs Commissionerate over ICENET. Tenders are called to propose a complete solution on a turnkey basis comprising hardware, software and networking arrangements. The selected vendor would be required to customize the solution to suit the needs of ICES and maintain the system on a continuing basis for an initial period of three years. For this purpose, the vendor would be required to work in close association with domain experts from the Customs department. The proposed Customs gateway will enable data interchange partners to transmit messages (including lodging of documents) to the Customs computer system and also receive messages form it, in any format. The messages could be based on international messaging standards such as UN/EDIFACT or in the form of ASCII files. The department proposes to enable the users to send/receive messages through web based forms, email attachments of File Transfer Protocol (FTP) over the Internet. The proposed solution will be versatile enough to receive, transmit and process messages in any of these modes or a variant or combination thereof, and enable seamless conversion into ICES formats



The Indian Customs EDI System (ICES) now operational in 19 major Customs Stations envisages electronic filing and capturing of declarations regarding goods. Members of the trade, importers, exporters, airlines, shipping lines etc., are required to file their declarations i.e., Bills of Entry, Shipping Bills, Import and Export General Manifests electronically, either from their respective office premises (for those who have established connectivity either through NICNET or any other Value Added Network service provider), or through the Service Centres established for this purpose. Messages are also exchanged with other Government agencies, Trade Promotion organizations, Port authorities, Airports Authority of India, Container Corporation of India, Container Freight Stations and other Customs Warehouse operators.

In addition, the monthly/quarterly Central Excise returns of assesses would also be filed through the proposed gateway and routed to the concerned Central Excise Commissionerate.


bull_1.gif (2285 bytes)
Connectivity using VAN (X.400

The trading partners of Indian Customs can use the services of any Value Added Network (VAN) Service Provider. The trading partner at any location can dial into the local node of the VAN to which he is a subscriber and transmit the message as an EDIFACT file or a flat file. The VAN would route the messages to the Customs EC/EDI gateway router, which would be located in the premises of the Directorate of Systems, Customs and Central Excise in Central Revenues Building, Indraprastha Estate, New Delhi. Connectivity between the VANs and the Customs EC/EDI gateway will be the sole responsibility of the VANs. Customs will make available a port on its gateway router to the VAN depending on the proposed connectivity, for a charge to be specified at a later date. The gateway would route the message through the firewall to the EDI engine. The EDI engine would act as a translator to convert the file into the proprietary ICES flat file format. The EDI engine to the concerned port would then rout the flat file format over ICENET for processing by local ICES server at the Customs nodes. Similarly, messages from the local ICES servers would be routed through the EDI engine, converted into the corresponding EDIFACT document and routed to the trading partner through the VAN. The successful bidder will be responsible for the development and deployment of applications for handling the message interchange excluding the backend ICES server operations that would be handled by the application vendor. The backend processes will include loading of the flat file into the ICES database and generation of messages as flat files (that would then be handled by the proposed application). 

bull_1.gif (2285 bytes)
Connectivity using Internet

It is proposed to use the medium of Internet whereby the user would be allowed to interchange documents through any of the following: 

bull_1.gif (2285 bytes)
Hosting of Customs and Central Excise forms on the web server

that could be downloaded for entry by the trading partner. The process of filing the import declaration (Bill of Entry) and the export declaration (Shipping Bill) will be the same as in practice at the EDI stations. The service centre module for imports and exports has been developed on Oracle 7.1 and consist of approximately 10 Forms accessing 50 tables (including look-ups) each. The EDI alternative to the service centre data entry module for remote filing of Customs documents has been developed in Clipper and has been functioning for over four years at Delhi. Both versions provide the functionality of preparing the import and export declarations to the Custom House Agents, importers and exporters. These declarations include importer/exporter, consignment and assessment details etc. The same forms will be available on the web server as downloadable forms for the members of the trade using Internet as their medium of transacting business.

bull_1.gif (2285 bytes)
File Transfer Protocol (FTP) / as an attachment to email

There are several Custom House Agents/importers/exporters with a high level of automation who are able to generate the import/export declaration using data available with them. It is expected that such clients would prefer to send the import and export declarations by using File Transfer Protocol (FTP) or as attachments to email (which would need to be detached from the mail). These declarations could be sent as UN/EDIFACT messages in which case the EDI engine would be customized to translate them into the proprietary flat file messages that could be loaded into ICES.

bull_1.gif (2285 bytes)

Message Exchange Server

In the case where messages are to be interchanged between Customs and custodians of cargo (namely ports, Airports Authority of India, and CONCOR) and between Customs and bank the interchange will take place by connecting the Local Area Network of the ICES and those of the banks/custodians through a message exchange server router. The bidders are required to customize these servers/connectivity devices for uninterrupted, secure and seamless interchange.

In addition, an HTTP server is proposed to be hosted in the public area for posting general Customs and Excise related information. Work on this web server is at an advanced stage of completion.



The Indian Customs and Excise Network (ICENET) are proposed to be set up between EC/EDI gateway and the Customs nodes. The network would cater to all traffic between the gateway and the nodes, which would primarily be related to transactions, as well as inter node data, which would be in the nature of messaging and database queries. ICENET has been designed as a redundant terrestrial network with VSAT backup where necessary (Jaipur, Ludhiana, Petrapole, Raxaul & Haldia). VSATs would be operational using ICENET and would be provided by Customs. The backbone of ICENET would be E1 lines of 2.048 Mbps or higher bandwidth to be leased from the Department of Telecommunications, Government of India. The E1 lines would terminate at the cluster locations in the metropolitan cities of Delhi, Mumbai, Calcutta and Chennai from where leased lines of smaller bandwidth (64/128 Kbps) would be used to connect the Customs nodes to the cluster locations. The selected vendor would be responsible for setting up ICENET on a turnkey basis (including interfacing with all other agencies such as the Department of Telecommunications) and managing the network for a period of three years from the date of commissioning.


a. Delhi – IGI Airport, ICD Patparganj, ICD, Tughlakabad.
b. Mumbai – Sahar Air Cargo, Nhava Sheva, Mumbai Customs House (Ballard Estate) and CFS, Mumbai.
c. Chennai – Air Cargo (Meenambakkam) and Customs House (Rajaji Salai)
d. Calcutta – Air Cargo, Custom House (Strand Road)
e. Bangalore Air Cargo
f. Hyderabad Air Cargo
g. Cochin Custom House
h. Trivandrum Air Cargo
i. Kandla Customs House
j. Ahemedabad – ICD, Sabarmati and Air Cargo
k. Tuticorin Port
l. Surat
m. Goa – New Customs House, Marmagoa
n. Haldia
o. Mangalore Port
p. Jaipur
q. Ludhiana
r. Petrapole land Customs (Bangladesh border)
s. Vizag Customs House
t. Raxaul land Customs (Nepal border)



ICES Version 2 is the biggest project involving the total redesign of the Indian Customs EDI System. The work involves the entire lifecycle of the software design and development and would use the latest information technology.

Presently, high-level committees such as Project Steering Committees (headed by members of the CBEC), Project Advisory Groups and core working groups comprising of domain specialists’ from Customs and Central Excise have been set up by the Board. These groups are in the process of finalizing the documentation of business processes, which would govern the Customs and Central Excise administration in the coming 5-7 years. Once this documentation is ready, the respective automation projects of Customs and Central Excise would begin. Vendors may be chosen for development and could be expected to bring in IT related skills.



Current Status: Planning and Systems Specification Stage:

It is proposed establish data warehouse to harvest data generated out of the automated systems. The Data warehouse would extract data from ICES and SERMON transactional systems to enable easy, flexible analyses by Customs and Central Excise officers. The department’s own automated applications would themselves require data analysis (for the purposes such as risk analysis etc.,) Data warehouse would also acquire data through a number of additional applications and systems providing organization-wide capabilities to use data effectively. Although the basic design is still under consideration, the data warehouse would broadly consist wholesale data warehouse, the data marts, the mechanisms to transport data among the data transaction systems and the wholesale and retails warehouse (data marts), and the coordination necessary to ensure timely and appropriate delivery of data. The wholesale data warehouse would acquires data from ICES, Sperry, Sermon and other future systems other sources of data and would store the data in a versatile repository. Data from the main data warehouse would then pushed periodically to smaller data marts on individual databases running on specified RDBMSs and operating systems. The data marts are required to be custom designed for specific departmental users and applications. These users would be able to analyse the data in the data marts using sophisticated web based tools. Skills are required in database design, data management including data mining, cleaning and data harvesting.