Is an Electronic POD Legally Valid? ESIGN, UETA and IT Act 2000

A consignee writes back nine weeks after delivery: the pallet never arrived, and the squiggle on your driver's handset is not anyone they employ. Your team opens the ePOD record and finds a signature image, a timestamp from the phone clock and a location pin. Nobody can say who typed the receiver name, whether the image was edited, or whether the export you are about to send will be accepted as evidence.

An electronic POD can carry the same legal weight as a paper receipt in both the US and India, provided the record shows who signed, that they meant to sign, and that nothing changed afterwards. The sections below cover signature rules under ESIGN, UETA and the Information Technology Act, 2000, retention conditions, the Indian evidence certificate, carrier claim clocks, a worked dollar and rupee comparison, a timestamped dispute and a vendor checklist.

What US and Indian law requires of an electronic delivery signature

Both markets refuse to reject a signature merely because it is electronic, but neither treats every screen tap as a signature. The record has to show a signing act by an identifiable person who meant to sign that specific delivery record.

In the US, the federal ESIGN Act at 15 U.S.C. 7001(a) says a signature or record relating to interstate or foreign commerce may not be denied legal effect solely because it is electronic. Section 7006(5) defines an electronic signature as a sound, symbol or process attached to or logically associated with a record and executed or adopted with the intent to sign. Intent and association are the two words most POD disputes turn on.

State law adds the Uniform Electronic Transactions Act. Maine's enactment, 10 M.R.S. section 9407, is typical: an electronic signature satisfies a law requiring a signature. New York applies its own Electronic Signatures and Records Act instead, and State Technology Law section 304(2) gives an electronic signature the same validity and effect as one affixed by hand.

India sets a higher technical bar. Section 3A(2) of the Information Technology Act, 2000 treats an electronic signature or authentication technique as reliable only if the signature data is linked to the signer and no other person, was under the signer's control at signing, and any later alteration to the signature or the information is detectable. A finger-drawn image on a shared driver phone meets none of those conditions by itself.

Intent, attribution and the problem of a shared driver handset

The weakest point in most ePOD records is attribution, not technology. A signature captured on the carrier's device, with a name typed by the driver, proves that someone touched the screen; it does not prove that the consignee's authorised receiver adopted the record.

Maine's UETA text at 10 M.R.S. section 9409(1) says a signature is attributable to a person if it was the act of the person, and that the act may be shown in any manner, including the efficacy of a security procedure. That is the opening for stronger capture: a one-time code sent to the consignee's registered contact, a badge scan, or a login on the receiver's own device.

• Receiver-side code: a one-time code sent to the consignee's registered number or email and keyed into the driver app ties the act to someone with access to that channel.
• Typed name plus image: a printed name entered by the receiver, not the driver, beside the drawn mark, with the device recording which field the driver can and cannot edit.
• Authorised receiver list: a consignee-supplied list of people allowed to sign, checked at capture rather than after a dispute.
• Refusal path: a separate record type for "receiver declined to sign", with photo and reason, so the driver never signs on someone's behalf.

Intent needs the same care. The receiver should see the consignment reference, the quantity being acknowledged and any exception remarks before signing, and the screen text shown at that moment should be stored with the record. A signature captured on a blank pad, with quantities filled in later by the back office, invites the argument that the signer never agreed to what the record now says.

The ePOD evidence fields a claims desk or court will examine

A legally usable ePOD is a bundle of facts, each captured by the device at the moment of delivery and sealed so that later changes show. Store the facts, the sealing method and the screen the receiver saw as one record.

• Identity of the signer: receiver-typed name, role, and the verification method used (one-time code, badge, account login), with the result.
• Intent evidence: the acknowledgment text shown, the quantity and condition fields displayed, and the explicit action taken ("Accept with exceptions").
• Time from two clocks: device time and server receipt time, with the offset, so a manipulated phone clock is visible.
• Location with accuracy: latitude, longitude and the reported accuracy radius, compared against the consignee's geofence.
• Photographs: load at the door, damage close-ups and any paper document, each with its own hash and capture time.
• Tamper evidence: a hash of the full record computed on the device and re-checked on the server, plus a chain to the previous record.
• Audit trail: every later read, correction or export, with user, time and reason, never overwriting the original values.

The hash is the field most teams skip and later regret. A SHA-256 digest of the canonical record, calculated before upload and stored separately, lets you show that the export sent to a claimant matches what the device captured. India's evidence certificate now asks for a hash value expressly, so computing it at capture is cheaper than reconstructing it later.

{
  "podId": "EPOD-2026-118204",
  "consignmentRef": "LR-DEL-55871 / BOL 7712093",
  "receiver": { "typedName": "R. Menon", "role": "Stores supervisor",
                "verification": { "method": "consignee_otp", "sentTo": "registered_mobile", "result": "match" } },
  "acknowledgment": { "screenText": "I accept 38 of 40 cartons; 2 cartons short",
                      "action": "ACCEPT_WITH_EXCEPTION" },
  "time": { "device": "2026-11-04T10:42:13+05:30", "server": "2026-11-04T10:42:19+05:30", "offsetSec": 6 },
  "location": { "lat": 28.5355, "lon": 77.3910, "accuracyM": 12, "geofence": "PASS" },
  "photos": [ { "file": "door.jpg", "sha256": "9f2c7a01e41a" } ],
  "seal": { "algorithm": "SHA-256", "recordHash": "5b7d22f90c93", "prevHash": "a11846c377fe" }
}

Chain rule:  H(n) = SHA256( canonical(record n) || H(n-1) )
Check:       recompute H(n) from the stored record; any mismatch = altered or out-of-order record
Tolerance:   offsetSec above 120 flags the record for review (company threshold, not a legal rule)

Hash values above are shortened for display. The 120-second clock threshold is an illustrative internal control; set yours from your own device fleet data.

Retention conditions under ESIGN 7001(d), UETA and IT Act section 7

Keeping the file is not enough; the law asks that the retained copy stay accurate and readable for everyone entitled to it. Retention design therefore matters as much as capture design.

ESIGN 15 U.S.C. 7001(d)(1) accepts an electronic copy where a law requires retention, provided it accurately reflects the information and remains accessible to all persons entitled to it for the required period. Maine's UETA, 10 M.R.S. 9412(1), uses similar words: the record must accurately reflect the information after it was first generated in final form and remain accessible for later reference.

ePOD retention under ESIGN 15 U.S.C. 7001(d)(1) and IT Act 2000 section 7(1) requires an accurate, accessible copy that keeps origin and receipt-time details. A carrier archive should hold 100% of original capture bundles read-only, with every correction stored as a linked entry rather than an overwrite.

Section 7(1) of the Information Technology Act, 2000 is more specific. A retained electronic record satisfies a retention law only if three conditions hold:

• Accessible for reference: the information remains accessible so as to be usable for a subsequent reference (clause (a)).
• Original or faithful format: the record is kept in the format in which it was generated, sent or received, or one shown to represent that information accurately (clause (b)).
• Origin and time details: details identifying origin, destination, and the date and time of despatch or receipt are available (clause (c)). A POD exported to PDF without its server receipt time can fail here.

For how long to keep POD images and who may view consignee details, see the companion guide on POD retention and access policy. The legal tests above set the quality of what you keep; that page sets the duration and access rules.

Proving an ePOD in an Indian court under section 63(4)

In India, an electronic POD offered as evidence normally travels with a certificate in the form set out in the Schedule to the Bharatiya Sakshya Adhiniyam, 2023. Plan for that certificate when you design capture, not when a summons arrives.

Section 63(4) of the Adhiniyam replaced Section 65B of the Indian Evidence Act, 1872. In Pune Bar Association v Union of India, an order of 22 May 2026, the Supreme Court declined to entertain a challenge to section 63(4) and described the certificate: Part A discloses the hash value of the electronic record, and Part B is a declaration signed by an expert. The Court did not admit the petition and left the question of law open, so the order is guidance, not binding precedent.

An Indian ePOD offered under Bharatiya Sakshya Adhiniyam section 63(4) needs a Schedule certificate with Part A disclosing the record's hash value and Part B signed by an expert. Capturing a SHA-256 digest at the door, before upload to the transport management system, avoids recomputing 100% of disputed records months later.

The same order addressed who may sign Part B. The Court said that, besides an Examiner of Electronic Evidence notified under section 79A of the IT Act, a person whom the court accepts as having special skill in computer science and cyber forensics may sign, while leaving the wider question of law open. For a carrier, the practical step is to name in advance who will sign Part A for the ePOD platform and which qualified expert will sign Part B.

On the US side, Maine's UETA at 10 M.R.S. 9413 states that evidence of a record or signature may not be excluded solely because it is electronic. Admissibility still depends on ordinary evidence rules about authentication and business records, which is why the audit trail and a records custodian who can explain it matter as much as the signature.

Where POD evidence meets carrier liability and claim clocks

A legally sound POD is only useful if it is ready before the claim and suit deadlines run. Those deadlines differ sharply between the two markets.

• US interstate motor carriage: 49 U.S.C. 14706(a)(1) requires the carrier to issue a receipt or bill of lading and makes it liable for actual loss or injury to the property. Section 14706(e)(1) bars carriers from allowing less than 9 months to file a claim, or less than 2 years to sue from written notice that a claim was disallowed.
• India road carriage: section 16 of the Carriage by Road Act, 2007 bars a suit against a common carrier for loss or damage unless written notice was served within 180 days from the date the consignor booked the consignment. Section 10 limits liability to a prescribed amount unless the consignor paid the higher risk rate under section 11.

In both markets the POD is often the carrier's main proof that loss did not occur in its custody, which is why its legal quality decides so many claims.

Carrier claim timing differs by market: 49 U.S.C. 14706(e)(1) gives US shippers at least 9 months to file a freight claim, while Carriage by Road Act 2007 section 16 requires written notice within 180 days of booking. ePOD evidence packs should therefore be complete within 30 days of delivery.

The 30-day target is an operating choice, not a legal rule; it leaves time to answer a claim inside the shorter Indian window. For the operational side of disputes, such as reading an unclear signature or a "two short" remark, our guide to what proof of delivery establishes in a dispute covers handoff evidence; this article covers whether the electronic record itself will stand up legally.

The figures are illustrative and assume the carrier's liability is not separately capped below invoice value; in India, a section 10 limit could reduce both the exposure and the benefit. The point is the ratio: an evidence pack costing about 5-6% of the defended amount is cheap insurance when the alternative is paying the whole claim.

A disputed delivery traced minute by minute

Most disputed ePODs fail on one missing link rather than on the law. The trace below shows a shortage claim in which the signature was valid but the record could not prove what the receiver accepted.

• 10:42, 4 November: driver delivers consignment LR-DEL-55871 to a Noida warehouse; receiver draws a signature on the driver's phone. The quantity field shows 40 because the driver had pre-filled it at departure.
• 10:44: receiver tells the driver two cartons are crushed; the driver types "2 dmg" into a free-text note after the signature was captured, so the note is outside the signed content.
• 17:10, 6 November: transport management system posts POD status DELIVERED and billing releases invoice INV-26-88341 for 40 cartons.
• 11:30, 9 January: consignee files notice claiming 6 cartons short and states the signer was a contract loader, not an authorised receiver; carrier's export has no identity check and no hash.
• Corrected process: receiver identity verified by one-time code, quantity entered by the receiver, exception remark inside the signed screen, record hashed on the device; the same dispute now turns on two documented cartons.

The fix cost no new hardware. It changed field order on the signing screen, blocked the driver from pre-filling quantities, and added a code step that took under a minute at the door.

Which POD checks are fixed rules and where software only assists

Legal defensibility comes from rules the system enforces every time, not from software judgment. Use automated reading and scoring to point reviewers at weak records, and keep the accept, bill and release decisions as fixed checks.

Electronic POD release in a transport management system should depend on fixed checks, not model scores: a SHA-256 hash recomputed on upload, a receiver one-time code result, and IT Act 2000 section 3A(2)(d) alteration detection. Software reading of photographed remarks should only queue suggestions for a clerk, with 0% automatic overwrite.

Building the dispute evidence pack before the claim window closes

An evidence pack should be assembled from stored records by a repeatable export, not rebuilt by hand. If the export cannot run within an hour of a claim arriving, the capture design is incomplete.

1. Index sheet: consignment reference, bill of lading or lorry receipt number, delivery date, claim reference and the list of files with their hash values.
2. Original capture bundle: signature, receiver identity result, acknowledgment screen text and photographs in the format the device produced.
3. Audit trail extract: every view, correction and export after capture, with user, timestamp and reason.
4. Clock and location evidence: device and server times with the offset, and the geofence check with its accuracy radius.
5. Related documents: invoice, packing list, any paper receipt image, and exception photos linked by reference.
6. India certificate: the section 63(4) Schedule certificate, with Part A naming the hash values and Part B signed by the chosen expert.

Freight claims also need commercial documents that sit outside the POD, such as the claimant's invoice and inspection reports. Our guide to building a freight-claim file for operations and finance covers that wider file; the pack above is the part that proves the delivery record itself.

Questions to put to an ePOD vendor about legal defensibility

Ask vendors to demonstrate each legal test live, on a device, with a record you then try to alter. A slide stating "ESIGN compliant" proves nothing about your evidence.

Capture and offline behaviour are covered in more depth in our ePOD software evaluation for offline capture and partial delivery. Combine both lists in one scorecard so legal tests sit beside the operational ones, and browse related guides on the logistics and supply chain hub.

If you are writing an ePOD requirement and want the legal evidence fields, hash handling and certificate support written into it, you can send us your scope for a proposal. We will map each requirement to the US and Indian test it supports.