Introduction
Every consignment that moves under a GST e-way bill generates a trail of documents. There is the tax invoice or delivery challan that authorizes the supply. There is the e-way bill itself, with its two parts capturing the consignment and transport details. If the business is within the e-invoicing mandate, there is the signed e-invoice carrying the IRN and QR code. There may be a purchase order, a goods receipt note, a lorry receipt or railway consignment note, photographs taken at the loading bay, and – at the end of the journey – proof of delivery record. In a dispute or audit, each of these documents plays a role. Together, they form the consignment audit trail.
In most organizations today, these documents do not live together. The invoice is in the ERP. The e-way bill is on the NIC portal. The lorry receipt is emailed by the transporter. The goods receipt is in the warehouse management system. The proof of delivery is a photograph on the driver’s mobile phone. When an auditor or a department officer asks to reconstruct the complete documentary record for a consignment two years ago, pulling together these documents from their scattered locations is a project measured in days.
A dedicated e-way document repository change this entirely. Every document associated with every consignment is stored in one place, linked to the same consignment identifier, and accessible through a single search. The repository’s audit log records every action taken on every document – who uploaded it, who viewed it, who generated a report from it, and when. When a department officer issues a notice requesting all documentation for a specific period or a specific buyer, the compliance team generates an audit pack in minutes rather than days.
This blog explains what the repository stores, how the consignment audit trail is structured, what the audit log captures, how audit packs are assembled, and how the repository supports the complete spectrum of compliance events from routine GSTR-1 reconciliation to departmental audit responses.
What the Repository Stores – The Complete Consignment Document Set
The repository organizes documents at the consignment level. Every consignment has a unique identifier – typically derived from the e-way bill number, the IRN, or the source invoice number depending on which it was generated first. All documents for that consignment are linked to this identifier and accessible as a unified set.
Primary Compliance Documents
The primary compliance documents are those without which the consignment cannot legally move. These are generated before or at the point of dispatch.
| Document | What It Contains and Why It Is Stored |
| Tax invoice or bill of supply | The legal record of the supply transaction: supplier and recipient GSTIN, invoice number and date, line items with HSN codes, taxable value, tax amounts, delivery address. The foundational document against which all other consignment records are validated. |
| E-way bill (Form GST EWB-01) | The electronic transport authorization: EWB number, Part A consignment details, Part B transport details, generation timestamp, validity period, and complete update history including all vehicle changes and extensions. |
| E-invoice with IRN and signed QR code | For businesses within the e-invoicing mandate: the IRP-signed invoice carrying the 64-character IRN and the B2B QR code. Stored as a PDF and as the raw JSON payload returned by the IRP, enabling cryptographic verification of the signed content at any future date. |
| Delivery challan | For non-supply movements (job work, branch transfers, exhibition goods, returnable containers): the delivery challan that substitutes for the invoice as the primary document accompanying the consignment. |
Transport and Logistics Documents
Transport documents link the compliance record to the physical movement of goods. They are evidence that the goods traveled by the route and mode indicated in the e-way bill.
| Document | What It Contains and Why It Is Stored |
| Lorry receipt (LR) or goods receipt note (GRN) | The transporter’s acknowledgment that goods were received for transport, listing the vehicle number, the driver details, the origin and destination, and the goods description. The LR number may be referenced in the e-way bill as the transport document number. |
| Railway consignment notes or airway bill | For rail or air transport: the FOIS Parcel Management System receipt number (RR number) or the airway bill, both of which must now be validated in the NIC system since the January 2025 Railways integration update. |
| Bill of lading or sea waybill | For sea freight and coastal shipping: the shipping company’s transport document that records the consignment aboard the vessel. |
| Part B update records | Every instance where the vehicle number or transporter ID in Part B was updated – whether for a vehicle substitution, transshipment, or mode change – stored with the timestamp, the old and new vehicle details, and the reason code entered. |
| EWB extension records | Every validity extension applied to the e-way bill: the timestamp, the reason code (vehicle breakdown, natural calamity, transshipment delay, etc.), the updated location, the remaining distance, and the new validity expiry. |
Delivery and Receipt Documents
Delivery documents close to the consignment loop by confirming that goods reached the intended recipient in the expected condition. They are the last layer of the consignment audit trail.
| Document | What It Contains and Why It Is Stored |
| Proof of delivery (ePOD) | Electronic delivery confirmation: recipient’s authorized representative signature, delivery timestamp, geotagged delivery location where collected. Linked to the EWB and invoice as the final transaction event record. |
| Delivery photographs | Photographs taken at the delivery point: goods at the delivery location, loading/unloading confirmation, and – where a discrepancy was recorded – photographs of the specific items, quantities, or condition in question. |
| Discrepancy report | Where goods arrived with a shortage, damage, or HSN mismatch: the contemporaneous discrepancy report created by the delivery driver through the mobile interface, timestamped at the point of receipt. |
| Recipient acceptance or rejection record | The formal acceptance or rejection of action taken by the recipient through the e-way bill portal within the 72-hour window, or the deemed acceptance timestamp where no action was taken. Stored with the portal response for audit evidence. |
| Form GST EWB-04 (transporter detention report) | Where the vehicle was stopped or detained by a GST officer for more than 30 minutes: the EWB-04 filed by the transporter on the portal, stored against the affected consignment with the detention timestamp and location. |
| Form GST EWB-03 (inspection report) | Where a GST officer conducted a physical inspection under Rule 138C: the inspection summary (Part A of EWB-03 filed within 24 hours of inspection) and the final inspection report (Part B filed within 3 days). |
Supporting Commercial Documents
In many departmental audits and scrutiny proceedings, the officer asks for evidence beyond the compliance documents – the commercial documentation that confirms the transaction was genuine and at arm’s length.
| Document | Role in the Audit Trail |
| Purchase order | Evidence that the buyer placed a specific order for the goods described in the invoice and e-way bill. Relevant when the department questions the commercial reality of a transaction. |
| Goods receipt note (GRN) from the buyer | The buyer’s own records that the goods were received and accepted into their inventory. Corroborates the delivery record and the recipient of acceptance on the portal. |
| Payment remittance record | Evidence of payment against the invoice: bank transfer acknowledgment, FIRC for export payments, or payment voucher. Relevant when the department challenges the reality of the transaction or the export zero-rating conditions. |
| Credit notes and debit notes | Where a consignment was returned, short-supplied, or price-adjusted post-delivery: the credit or debit note linked to the original invoice and EWB, creating a complete amendment trail. |
| Weighbridge slips and inspection certificates | For bulk commodity consignments: the weighbridge record confirming the actual quantity dispatched matches the invoice quantity. Particularly relevant for coal, steel, grain, and other bulk goods where EWB discrepancies often arise from measurement differences. |
The Consignment Audit Trail – How Events Are Logged
The repository does not merely store documents. It records every event in the life of a consignment as an immutable log entry. This event log – the consignment audit trail – is what transforms a collection of stored files into a defensible compliance record.
The Event Log Structure
Every event in the consignment lifecycle generates a log entry. The log entry captures the event type, the timestamp, the user or system that triggered the event, the document affected, the before and after state of any data that changed, and the channel through which the event was initiated (portal, API, mobile app, manual upload).
| Event Type | When It Is Logged | What the Log Entry Records |
| Invoice created | At invoice posting in ERP | Invoice number, date, supplier and recipient GSTIN, taxable value, HSN, initiating user |
| IRN generated | At IRP response receipt | IRN, acknowledgment number, IRP timestamp, signed payload hash, portal through which generated |
| EWB generation attempted | At NIC portal submission | Full request payload, NIC response (EWB number or error code), submission timestamp, API session ID |
| EWB generated successfully | At NIC response receipt | EWB number, generation date and time, validity expiry timestamp, vehicle number in Part B |
| EWB generation rejected | At NIC rejection response | Error code, error description, submitted payload fields that triggered the rejection, corrective action taken |
| Part B updated (vehicle change) | At vehicle update submission | Old vehicle number, new vehicle number, update timestamp, reason code, user or system that initiated the update |
| Validity extended | At extension submission | Extension reason, updated location, remaining distance, new validity expiry, cumulative extension count against the 360-day cap |
| EWB cancelled | At cancellation confirmation | Cancellation timestamp, reason, initiating user, confirmation that goods were not in transit at the time of cancellation |
| Goods dispatched | At dispatch confirmation in TMS or WMS | Dispatch timestamp, warehouse location, vehicle number at departure, driver ID, seal or lock number if applicable |
| Recipient acceptance or rejection | At portal action or deemed acceptance expiry | Action type (accepted, rejected, deemed accepted), timestamp, specific discrepancies noted for rejection |
| Delivery confirmed (ePOD) | At ePOD signature capture | Delivery timestamp, geolocation, recipient representative name, OTP confirmation reference, photograph references |
| Detention recorded | At EWB-04 upload or alert receipt | Detention timestamp, location, officer details, reason stated, EWB-04 reference number, resolution action taken |
| Document uploaded | At every document storage event | Document type, filename, upload timestamp, uploading user, cryptographic hash of document content (for integrity verification) |
| Audit pack generated | At every audit pack export | Requesting user, scope of pack (consignment IDs or date range), generation timestamp, documents included, recipient of the pack |
Immutability of the Audit Log
The audit log is immutable by design. No user – including system administrators – can modify or delete a log entry after it is created. Every entry is appended to the log; none are overwritten. This immutability is enforced at the storage layer, not merely at the application layer, meaning the log’s integrity does not depend on any single user’s access privileges.
Each log entry carries a cryptographic timestamp issued by the storage system at the moment of creation. Any attempt to insert a backdated log entry or modify an existing one would produce a timestamp of inconsistency detectable during log validation. This makes the audit log a reliable evidentiary record – not merely an operational history.
Document Organization – The Consignment-Centric Repository Model
The repository is organized around the consignment, not around the document type. In a traditional filing system, invoices are in one folder, e-way bills in another, transport documents in a third. Finding all documents for a specific consignment means searching across multiple locations. In the consignment-centric model, every document for every consignment lives in one record, regardless of document type, and the record is accessible through any of its identifiers.
Consignment Record Identifiers
A consignment record can be retrieved through multiple identifiers: the EWB number, the invoice number, the IRN, the purchase order number, the lorry receipt number, the vehicle number that carried the goods, the supplier GSTIN, the recipient GSTIN, the dispatch date, or the delivery date. Cross-reference lookups are automatic – entering a vehicle number returns all consignment records where that vehicle was used in Part B, for any date range. Entering a recipient GSTIN returns consignments for that customer, with their complete document sets.
Multi-GSTIN Consignment Organization
For businesses operating multiple GSTINs across states, the repository maintains a clear GSTIN-level organizational hierarchy within the consignment-centric model. Each consignment is filed under the originating GSTIN’s record space, but cross-GSTIN consignments – such as inter-branch transfers that involve two GSTINs of the same PAN – are linked in both GSTIN records. Compliance teams at the corporate level can view the complete picture across all GSTINs; branch-level users see only the consignments from their registered location.
Version Control for Document Amendments
When a document is amended – an invoice is corrected and a revised version issued, a credit note replaces a portion of the original supply, or a transport document is updated – the repository maintains both the original version and every subsequent version with clear version labels and timestamps. The most recent version is the active record. Prior versions are archived but remain accessible and are clearly identified as superseded. In an audit context the complete version of history demonstrates when the amendment occurred, on whose authority, and what changed – establishing that the amendment was made in good faith rather than retrospectively fabricated.
Generating Audit Packs
An audit pack is a structured, exportable bundle of documents and log records compiled to respond to a specific compliance event: a departmental audit, a GST scrutiny notice, an advance ruling hearing, a statutory audit review, or a litigation matter. The repository’s audit pack generator assembles these bundles systematically from the stored consignment records.
Audit Pack Scope Configuration
The compliance team defines the scope of an audit pack through a configuration interface. Scope parameters include the period covered (financial year, quarter, month, or specific date range), the GSTINs covered (single entity or all entities under the PAN), the transaction categories to include (outward supplies, inward supplies, stock transfers, exports, specific HSN categories), and specific consignments or customer accounts flagged in the department notice.
For a narrow notice – say, the department has requested documentation for all consignments to a specific buyer in a three-month period – the scope is tightly defined. For a broad departmental audit covering a full financial year, the scope covers the complete consignment record for the period, potentially thousands of consignments with all their associated documents.
Audit Pack Export Formats
Audit packs are exported in formats suitable for the intended use. For departmental submission, the pack is exported as a structured PDF bundle with a table of contents, page numbers, and indexed document sections. For internal or statutory auditor review, an Excel workbook provides the registers and reconciliation data in a format compatible with audit software. For storage as part of the business’s own records, the complete pack is archived as a time-stamped ZIP file with an integrity manifest listing the cryptographic hash of every included document.
The audit log records every pack generation event: who requested the pack, what scope parameters were set, what documents were included, when the pack was generated, and to whom it was shared. This log entry is the chain-of-custody record for the audit documentation itself.
On-Demand Consignment Dossier vs. Period Audit Pack
The repository supports two modes of documentation assembly. For routine requests – a transporter asking for the documentation for a specific consignment that was detained at a check post, or a customer asking for their delivery records – the on-demand consignment dossier mode retrieves the complete document set for a single consignment and exports it as a self-contained PDF. For comprehensive audit requests covering a period or an account, the period audit pack mode assembles the complete multi-layer structure described above.
Supporting Specific GST Compliance Scenarios
Different compliance events draw on different parts of the repository. Understanding which scenarios use which repository capabilities helps the compliance team direct their document management effort toward the areas that matter most.
Responding to a Section 61 Scrutiny Notice
A Section 61 scrutiny notice under the CGST Act asks the taxpayer to explain discrepancies identified by the department’s automated scrutiny process. These discrepancies typically involve mismatches between EWB data and GSTR-1 data, or between declared values and the consignment values in e-invoices. The repository’s EWB-GSTR-1 reconciliation report directly addresses these discrepancies, showing the complete reconciliation for the scrutiny period and identifying legitimate explanations for each flagged item – credit notes that reduced the invoice value, return consignments matched against original supply EWBs, or timing differences in period allocation.
Responding to a Section 65 GST Audit
A GST audit under Section 65 is a comprehensive review of the taxpayer’s books and compliance records for one or more financial years. The audit team typically arrives with a list of specific requirements: all invoices above a threshold, all inter-state consignments above a value, all transactions with specific customers, all exports with corresponding FIRCs and LUT references. The repository’s multi-dimensional search and the audit pack generator address each of these requirements directly. The audit team can be given controlled read-only access to the repository for the audited period, allowing them to retrieve the documents they need directly without requiring the compliance team to be present for every query.
Defending Against a Section 129 Detention Notice
When goods are detained at a check post and a Section 129 notice is issued, the business has seven days to pay the penalty or mount a defense. The defense rests on the documentary record: evidence that the e-way bill was valid, that the consignment details matched the invoice, that any discrepancy was minor and within the CBIC circular’s defined safe harbor, or that the mismatch had a legitimate explanation that does not constitute tax evasion. The on-demand consignment dossier for the detained consignment – complete with the original invoice, the EWB print, the Part B update history, the vehicle’s transport documents, and the audit log showing when each document was created – provides the complete evidentiary package for the legal response.
Statutory Audit Support for Financial Statement Preparation
When statutory auditors review a company’s tax contingent liabilities and compliance posture, they examine whether the company has adequate documentation for its GST compliance. The repository’s audit pack for the financial year provides the statistical summary auditors need: total number of EWBs generated, total consignment value covered, EWB-GSTR-1 alignment rate, exceptions and their resolutions. For specific high-value transactions that auditors want to examine in detail, the per-consignment dossier mode provides the full document set. The repository’s immutable audit log is the auditors’ assurance that the records are complete and have not been manipulated after the fact.
Advance Ruling and Litigation Support
In tax litigation proceedings at the GST Appellate Authority, GSTAT, or High Court level, the consignment of documentation is often central to the factual dispute. A case about whether goods were correctly valued, whether the correct HSN was applied, or whether a specific delivery occurred turns on the documentary record. The repository’s long-term retention and version-controlled document storage provides a complete, tamper-evident evidentiary base for the litigation team. The audit log’s immutable timestamps establish the timeline of events with the precision that legal proceedings require.
Role-Based Access to the Repository
Not every user who generates e-way bills needs access to the complete document repository and audit log. The repository’s access model is aligned with organizational roles and the principle of least privilege.
| Role | Repository Access Level | What They Can Do |
| Compliance Head / Partner | Full access | View all consignment records and audit logs; generate audit packs for any scope; share packs with external parties; manage retention and legal hold settings |
| Tax Manager | Operational access | Search and retrieve consignment records; view audit logs for their assigned GSTINs; generate on-demand dossiers; upload additional documents; initiate audit pack generation (subject to compliance head approval for departmental submissions) |
| Logistics / Dispatch Team | Consignment-level read access | View EWB status and transport documents for active consignments; confirm dispatch and delivery events; upload transport documents and ePOD photographs; cannot access audit log or generate audit packs |
| Transporter Portal User | Read-only for assigned consignments | View EWB details for consignments assigned to their GSTIN or Transporter ID; upload lorry receipts and transport documents; view Part B update history; cannot access financial documents or audit log |
| Statutory Auditor | Time-limited read-only for audit scope | View and download documents within the defined audit scope and period; access reconciliation reports; cannot modify any record or access records outside the audit scope; access automatically expires at audit end date |
| Department Officer (via authorized access) | Read-only for requested scope | Where the business provides controlled access in response to an audit notice: view specific consignment records and their document sets; access is scoped to the notice’s stated requirements and logged in the audit trail |
Integration with the E-Way Bill Generation Workflow
The repository operates as a natural extension of the e-way bill generation workflow, not as a separate system that requires manual document uploads. Documents flow into the repository automatically as they are created, without requiring the compliance team to take any additional steps.
Automatic Document Capture at Generation
When an e-way bill is generated through the platform’s API integration with the ERP, the generation response from NIC – including the EWB number, generation timestamp, validity expiry, and the complete Part A and Part B payload – is automatically stored in the repository against the originating invoice record. If the generation was simultaneous with IRN creation, the signed e-invoice JSON and the IRN are stored at the same moment. The dispatch team does not need to take any separate action to archive these records.
Transport Document Upload at Dispatch
When goods are dispatched, the logistics team confirms the dispatch event in the platform’s mobile or desktop interface. At this point, the interface prompts the lorry receipt number, which creates a data field entry in the consignment record. The LR document can be uploaded as a PDF or photograph directly from the dispatch terminal. For businesses where the LR is emailed by the transporter, the platform’s email integration can be configured to automatically route LR documents to the correct consignment record based on the EWB number or invoice number referenced in the email subject.
ePOD and Delivery Documents
When the delivery driver uses the platform’s mobile delivery interface to capture the ePOD signature, the signed delivery confirmation, photographs, and any discrepancy records are automatically uploaded to the consignment’s repository record. No manual upload step is required. The delivery event also triggers the closure of the consignment’s active status in the validity register, marking the consignment as delivered and releasing it from the expiry monitoring dashboard.
FAQs
Every document is hashed at the point of storage using a cryptographic algorithm. The hash – a unique fingerprint of the file’s exact content – is stored alongside the document and independently logged in the immutable audit log. At any future point, the platform recomputes the hash and compares it to the stored value. A byte-level match confirms that the document is unchanged. Any modification, no matter how minor, produces a different hash and is immediately detectable.
Yes. The repository covers both inward and outward consignment documentation. For inward supplies, the repository stores the supplier’s invoice and the EWB generated against the business’s GSTIN as recipient. The business can additionally upload the goods receipt of note, inspection records, and any discrepancy reports for inward consignments. This inward documentation is relevant for ITC claims – the repository provides the documentary evidence that goods were received before ITC was claimed.
Job work, stock transfer, and other non-supply movements use a delivery challan as the primary document instead of a tax invoice. The repository recognizes delivery challans as a primary document type and organizes the consignment record around the challan number in the same way it would around an invoice number for a supply transaction. All the same transport, delivery, and audit log records are maintained for challan-based consignments.
Cancellation does not delete the repository record. A cancelled EWB’s record is retained with its complete pre-cancellation document set and a cancellation event log entry that records the timestamp, reason, and initiating user. The record is flagged with a ‘Cancelled’ status and removed from active monitoring dashboards, but it remains fully searchable and retrievable. In an audit context, cancelled EWBs are often specifically examined to verify that goods were not dispatched under a cancelled bill or that the cancellation reason was legitimate.
Yes. Export refund applications require the exporter to produce the original export invoices, IRNs, shipping bills, e-way bills, LEI-1 forms, and proof of receipt of foreign exchange. The repository stores all of these documents for export consignments and can generate a structured export refund documentation pack organized by shipping bill or by period. The pack includes the reconciliation of EWB consignment values against shipping bill values and GSTR-1 declared export values, which is typically required to support the refund claim.
A mid-journey transporter changes trigger a Part B update on the portal and a transport document change for the new carrier. Both events are logged in the consignment’s audit trail. The repository stores both the original transport document and the new one issued by the replacement carrier, with clear timestamps that establish when the handover occurred. This complete multi-carrier trail is important for consignments that are detained after a transporter change, as it demonstrates that the Part B was properly updated and that both carriers’ documentation is available.