Build an eSanchit document-readiness checklist around the shipment

A shipment folder contains several PDFs, so the team marks the documentation complete. One certificate has been superseded, its replacement has not been verified, and another attachment has no clear issuer. Counting files has hidden the two requirements that remain unresolved.

An eSanchit document-readiness checklist should track requirements and evidence at shipment level. The authorised customs professional determines what the transaction needs; the coordination process makes missing, stale and unverified records visible before submission.

Start with the shipment's requirements

Record the shipment or job, importer or exporter, relevant filing reference where available, transaction context and the person responsible for the document list. The list should reflect the actual goods, movement and applicable process.

Do not use a generic internet list as proof that every required document is present. Requirements can depend on the transaction and the relevant authority. A workflow can organise evidence without deciding classification, valuation, exemption eligibility or the sufficiency of a certificate.

For each requirement, identify the expected document type, responsible provider, review owner and decision needed. A requirement may be satisfied by a particular document version, may be not applicable with an approved reason, or may remain open.

Count requirements separately from files

The following illustrative shipment J-89 has four document requirements specified by its authorised reviewer. These are example requirements for this fictional file, not a universal customs checklist.

There are five files: I-3, P-2, C-1, C-2 and A-1. Only two of the four requirements are ready. The old and new certificate files cannot be counted as two completed requirements.

The two open items need different actions. C-2 needs verification against the expected issuer and scope. A-1 needs clarification of who issued it and whether it supports the required authority. Neither gap is solved by renaming the PDF “final.”

Retain the source correspondence and the person who completed each review. The readiness register should explain the basis for the status without requiring someone to reconstruct an email chain.

Preserve version and scope

A document can be genuine yet refer to the wrong shipment, period, goods or party. Capture its reference, issue and expiry information where relevant, issuer, beneficiary, covered scope and the exact file version reviewed.

Link replacements to the superseded version. Keep historical files available for audit while preventing them from appearing as the current filing candidate. An old certificate should not remain selectable merely because it was uploaded first.

When an underlying shipment quantity or party changes, identify which documents need reassessment. Do not automatically invalidate everything, but do not assume the previous review still covers materially changed information.

The authorised reviewer should decide whether an apparent discrepancy requires a corrected document, explanation or a different filing action. The coordinator records that decision and its evidence.

Understand the document references

ICEGATE's FAQ distinguishes the Image Reference Number, or IRN, for an individual document from the Document Reference Number, or DRN, for an upload batch. Preserve the returned references at their proper levels instead of treating them as interchangeable document IDs. ICEGATE — FAQs on eSANCHIT document references

A local filename is another identifier. Keep the mapping from the reviewed local version to the resulting IRN, along with its document type and relevant shipment association.

Where a batch contains several documents, a batch reference alone cannot tell a reviewer which certificate version was selected. The readiness record needs the specific document reference.

Use current official instructions for the supported file format, digital-signature requirements and submission channel. Those interface conditions can change; a local “ready” label should state which validated file is intended for the authorised submission.

Separate upload from filing linkage

A successful upload does not establish that the document is correctly associated with the relevant customs filing or that a substantive query has been answered.

ICEGATE's Advisory 35/2020, dated 9 October 2020, specifically addresses additional documents uploaded for an existing Bill of Entry without the corresponding amendment linking them. It explains why upload alone can leave those documents unavailable to the assessing officer. ICEGATE — Advisory 35/2020 on adding supporting documents to a Bill of Entry

Use that distinction in the readiness workflow while following the current authorised amendment and reply process for the transaction. The register should retain upload outcome, document reference, filing-linkage outcome and any query-response outcome separately.

For an added certificate, the team needs to know which version was uploaded and which reference was included in the filing action. “Sent to broker” is a handoff status, not evidence that either external step completed.

Handle a wrong or superseded upload

ICEGATE's FAQ states that a document cannot be deleted once its IRN is generated. The local process therefore needs a controlled supersession and reference-selection path rather than assuming the upload can simply be erased. ICEGATE — FAQs on eSANCHIT document references

If a wrong version was already linked, route it to the authorised filing owner to determine the permitted correction. Preserve the original record and the corrective action. Do not change the local filename and present the external reference as though it now points to different content.

If an acknowledgement is missing, check the actual submission state before uploading again. Repeated files can make version selection harder even where they do not create a new customs obligation.

Keep failed or uncertain outcomes in a queue with an owner. A connection error should not become a completed readiness check.

Use a register that the reviewer can audit

A controlled shipment checklist may be enough for modest volumes. A document-management workflow can add version control and approval history. Integration becomes useful when it reliably links the approved file, returned reference and actual filing outcome.

Test the five-file example, a replacement after review, an unknown issuer and an upload whose response was not received. The reviewer should identify the current candidate for every requirement and the reason any requirement remains open.

Measure missing requirements, wrong-version selections and time awaiting each document owner. A larger number of uploaded PDFs is not a useful success measure on its own.

Make readiness mean a known requirement is satisfied

The practical result is a shipment file that an authorised reviewer can assess without guessing which document is current or where it was used. The checklist supports that judgement while preserving the separate external filing steps.

Next actions

1. Obtain the shipment-specific requirement list and name the authorised review and filing owners.
2. Map every requirement to a verified document version, or record the precise unresolved gap.
3. Retain local file, IRN and DRN relationships at their correct levels.
4. Reconcile upload, filing linkage and any response outcome before closing the documentation task.