e-SANCHIT: The Upload Failures That Stall Assessment and LEO

The ICEGATE e-SANCHIT procedure prescribes the file format precisely: the document must be rendered into PDF/A (ISO 19005-2), at a resolution of not less than 200 dpi in black and white, at a file size of not more than 75 KB per A4 page, within a maximum file size of 1 MB — which, as the guide itself computes, allows a supporting document of about 13 pages. A longer document is not ground for exemption; it "should be split and uploaded as two or more documents," each earning its own IRN.

Two properties of this spec catch exporters. First, it is a rendering spec, not a content spec — a perfectly accurate invoice fails on resolution or size alone, and accounting-software PDF exports that embed colour scans or high-resolution letterheads routinely blow the 75 KB/page budget. Second, the black-and-white, 200-dpi floor exists for officer legibility: the guide requires the submitter to acknowledge, by signing, that the document is "legible and authentic." Compression tricks that shrink the file below 1 MB by degrading legibility replace a size rejection with a legibility query later — the slower of the two failures.

An e-SANCHIT upload is validated against identity before content: the PDF must be digitally signed using the digital signature certificate registered on ICEGATE, and the guide's validation step exists precisely to reject files "not digitally signed by the same user." In practice the registered signatory is the exporter's ICEGATE account holder or the Customs House Agent's — and a packet assembled across two offices acquires signatures from the wrong one. The signature also carries legal weight: signing is the act by which the submitter vouches that the document is legible and authentic, which is why a defective scan signed and uploaded is not a technicality but a declaration.

The second selection the submitter makes is the document code, drawn from the Single Window code-map directory, and CBIC Circular 42/2019-Customs made specified uploads mandatory with code and IRN from 02.12.2019: an invoice is 380000, an invoice-cum-packing-list 331000, a bill of lading 705000, with distinct codes for master (704000) and house (714000) bills, sea waybills (710000) and air waybills (740000). A document uploaded under the wrong code is a document the assessing officer cannot find where the declaration says it should be — the practical equivalent of a missing document, discovered only as a query.

CBIC Circular 43/2018-Customs, which extended e-SANCHIT to all ICES locations for exports from 08.11.2018, also fixed the procedural geometry that still governs: during assessment, "ICES provides for a query to be raised in order to call for additional documents," and the response route is to upload the document on e-SANCHIT, obtain the IRN, and link it to the Shipping Bill by amendment at the Service Centre — after which the exporter proceeds to goods registration, document verification and LEO. The circular launched the facility as voluntary with a 15-day review toward mandatory use; the codified legal basis arrived with the Shipping Bill (Electronic Integrated Declaration and Paperless Processing) Regulations, 2019, whose regulation 3 requires the authorised person to "upload the supporting documents on the ICEGATE" with digital signature, enforced in practice through Circular 42/2019's document-code mandate and customs-house public notices.

Read as a dependency chain, the geometry is strict: specification → upload → IRN → declaration linkage → assessment → LEO. A break at any link surfaces at the next one, and the earlier the break, the later it is usually noticed. The costly version is the query raised after goods have reached the terminal, where the response cycle — re-scan, re-sign, re-upload, amend, re-assess — runs against accruing ground rent and a closing vessel cutoff; the arithmetic of those stacked charges is set out in What One Documentation Failure Costs.

The preventive discipline is to treat e-SANCHIT compliance as a property of the document packet, verified before filing, not a property of the upload attempt. Concretely, every supporting document headed for the Shipping Bill has four checkable attributes in advance: format (PDF/A, 200 dpi, within the per-page and 1 MB budgets), physical cleanliness (no marks over content, no folds, no skew), signature identity (the ICEGATE-registered DSC of the actual submitter), and code assignment (the correct directory code per document type). Each attribute is binary, and each maps to a named rejection ground in the published guide — which makes the pre-check mechanical rather than judgmental.

TradeWatch performs this render-and-linkage check as part of its Shipping Bill Readiness Packet: each supporting document is validated against the e-SANCHIT specification and its declared document code before the CHA files, with defects flagged against the guide's own rules. Kanan Labs prepares a readiness packet. It does not file Shipping Bills and holds no customs credentials — your licensed CHA files.