UETA vs ESIGN Act: US E-Signature Compliance & Audit Trail Guide (2026)

1. The Dual Statutory Architecture: Federal ESIGN vs. State UETA

When software engineers and legal product teams build contract execution workflows in the United States, they frequently encounter references to both the Uniform Electronic Transactions Act (UETA) and the federal Electronic Signatures in Global and National Commerce Act (ESIGN Act). Understanding why both statutes exist—and how federal preemption rules determine which law governs a given database transaction—is essential when evaluating the best e-signature APIs for developers in 2026.

In 1999, the National Conference of Commissioners on Uniform State Laws (NCCUSL, now the Uniform Law Commission) promulgated UETA to harmonize dozens of conflicting state digital signature laws that had emerged during the late 1990s. Because contract law in the United States is traditionally governed at the state level, UETA was designed to be enacted individually by each state legislature. However, to prevent interstate commerce from fracturing while states debated adoption—and to stop individual states from passing protectionist laws favoring specific proprietary certificate authorities—the U.S. Congress enacted the federal ESIGN Act (Pub. L. 106-229, 114 Stat. 464, codified at 15 U.S.C. §§ 7001–7006) on June 30, 2000, taking effect October 1, 2000.

The core non-discrimination mandate of both statutes is virtually identical. Under 15 U.S.C. § 7001(a)(1) and UETA Section 7(a):

“A signature, contract, or other record relating to such transaction may not be denied legal effect, validity, or enforceability solely because it is in electronic form; and a contract relating to such transaction may not be denied legal effect, validity, or enforceability solely because an electronic signature or electronic record was used in its formation.”— 15 U.S.C. § 7001(a)(1)–(2) (The Federal ESIGN General Rule of Validity)

How Reverse Preemption Works Under ESIGN Section 102(a)

The relationship between ESIGN and UETA is governed by an unusual legal mechanism inside 15 U.S.C. § 7002(a) known as conditional reverse preemption. Under this section, a state statute may modify, limit, or supersede the provisions of the federal ESIGN Act if—and only if—one of two conditions is satisfied:

• Prong 1 (Uniform UETA Enactment): The state statute constitutes an enactment or adoption of the official 1999 Uniform Electronic Transactions Act as approved and recommended by NCCUSL. If a state adopts clean UETA, UETA governs intrastate and applicable state-law transactions without federal preemption.
• Prong 2 (Technology-Neutral Alternative): If a state enacts an alternative statute (such as New York's ESRA) or modifies UETA, that state law is preempted to the extent that it is inconsistent with the federal ESIGN Act OR if it accords greater legal status or effect to a specific technology or technical specification (for example, mandating a state-licensed X.509 PKI vendor for ordinary commercial contracts).

2. The 50-State Statutory Map: 49 UETA States, New York ESRA & Recent Modernization

For years, legacy legal guides claimed that three states—New York, Illinois, and Washington—had not adopted UETA. That historical trivia is outdated in 2026:

• Washington State (Adopted UETA in 2020): Washington repealed its legacy 1997 PKI-only Electronic Authentication Act and enacted the Uniform Electronic Transactions Act (RCW Chapter 19.360, Senate Bill 6028), effective June 11, 2020.
• Illinois (Adopted UETA in 2021): Illinois replaced its 1998 Electronic Commerce Security Act with the Uniform Electronic Transactions Act (815 ILCS 333/, Public Act 102-0038), effective June 25, 2021.
• New York (The Sole ESRA Jurisdiction): Today, 49 states, the District of Columbia, Puerto Rico, and the U.S. Virgin Islands enforce UETA. Only New York operates under its own statute: the Electronic Signatures and Records Act (ESRA), codified at N.Y. State Technology Law §§ 301–309 and administered via regulations at 9 NYCRR Part 540.

In practice, New York's ESRA and UETA converge on identical engineering requirements. In 2002, the New York State Legislature amended ESRA § 302(3) to match the federal ESIGN Act's broad, technology-neutral definition of an electronic signature: “an electronic sound, symbol, or process, attached to or logically associated with an electronic record and executed or adopted by a person with the intent to sign the record.” Furthermore, California's UETA (Cal. Civ. Code §§ 1633.1–1633.17) includes a longer list of specific statutory notice exclusions (such as certain home solicitation contracts and Medi-Cal notices), where the federal ESIGN Act's consumer consent rules and preemption boundary require careful attention.

3. Engineering the Four Statutory Pillars of US E-Signature Enforceability

When a commercial or consumer contract is challenged in state or federal court, judges do not evaluate the brand name of the software vendor. You do not need an expensive enterprise seat license—as detailed in our DocuSign API pricing breakdown and 2026 e-signature API pricing comparison—to prevail in litigation. Instead, courts inspect the technical evidence against four statutory pillars codified across UETA and ESIGN:

4. Deep Dive: Implementing the 15 U.S.C. § 7001(c) Consumer Disclosure Gate

One of the most misunderstood areas of US e-signature engineering is ESIGN Act Section 101(c) (15 U.S.C. § 7001(c)). Does every contract require a multi-paragraph consumer disclosure screen before signing? No.

The § 7001(c) consumer consent mandate applies specifically when a statute, regulation, or other rule of law requires that information relating to a transaction be provided or made available to a consumer in writing. The statute defines a consumer (15 U.S.C. § 7006(1)) as an individual who obtains, through a transaction, products or services used primarily for personal, family, or household purposes. When you are building a fintech lending app, residential solar financing portal, auto lease checkout, or retail insurance flow—especially with a white-label e-signature API—you must present and log the six statutory disclosures required by 15 U.S.C. § 7001(c)(1)(B) prior to obtaining consent:

1. Right to Paper or Non-Electronic Form: Inform the consumer of any right or option to have the record provided or made available on paper or in non-electronic form.
2. Right to Withdraw Consent & Consequences: Inform the consumer of the right to withdraw consent to have the record provided electronically and of any conditions, consequences (which may include termination of the parties' relationship), or fees in the event of such withdrawal.
3. Scope of Consent: Specify whether the consent applies only to the particular transaction that gave rise to the obligation to provide the record, or to identified categories of records that may be provided or made available during the course of the parties' relationship.
4. Withdrawal & Contact Update Procedures: Describe the procedures the consumer must use to withdraw consent and to update information needed to contact the consumer electronically (such as their email address).
5. Paper Copy Request & Fee Disclosure: Inform the consumer how, after consenting, they may obtain a paper copy of an electronic record and whether any fee will be charged for such copy.
6. Hardware & Software Requirements + “Reasonable Demonstration” (§ 7001(c)(1)(C)): Provide a statement of the hardware and software requirements for accessing and retaining the electronic records (e.g., a modern web browser supporting TLS 1.3 and a PDF viewer), and ensure the consumer consents electronically in a manner that reasonably demonstrates that the consumer can access information in the electronic form that will be used to provide the information.

import crypto from "node:crypto";

export interface EsignConsumerConsentEvidence {
  consumerId: string;
  consumerName: string;
  consumerEmail: string;
  disclosureVersion: string;
  disclosureTextSha256: string;
  pdfSampleAccessVerified: boolean; // Satisfies 15 U.S.C. § 7001(c)(1)(C)(ii) "reasonable demonstration"
  clientIp: string;
  userAgent: string;
  consentedAtIso: string;
}

const ESIGN_DISCLOSURE_V2026 = `
ELECTRONIC RECORD AND SIGNATURE DISCLOSURE (15 U.S.C. § 7001(c))
1. Right to Paper Copy: You may request a paper copy of any agreement at any time by emailing support@acme-lending.com at zero cost ($0.00).
2. Right to Withdraw Consent: You may withdraw your consent to transact electronically prior to execution without penalty, though online loan origination requires electronic execution.
3. Scope of Consent: This consent applies to your Retail Installment Contract and Truth in Lending Act (TILA) disclosures.
4. Hardware & Software Requirements: A device with internet access, TLS 1.2+ browser, an active email account, and a PDF reader capable of viewing A4/Letter PDF documents.
`.trim();

export async function dispatchConsumerAgreementWithEsignGate(
  consent: EsignConsumerConsentEvidence,
  contractMarkdownBody: string
) {
  if (!consent.pdfSampleAccessVerified) {
    throw new Error(
      "ESIGN_COMPLIANCE_ERR: Consumer must reasonably demonstrate PDF access ability under 15 U.S.C. § 7001(c)(1)(C)(ii)."
    );
  }

  const expectedHash = crypto
    .createHash("sha256")
    .update(ESIGN_DISCLOSURE_V2026, "utf8")
    .digest("hex");

  if (consent.disclosureTextSha256 !== expectedHash) {
    throw new Error("ESIGN_COMPLIANCE_ERR: Disclosure hash mismatch.");
  }

  // Embed the verified § 7001(c) Consumer Consent Annex directly into the immutable contract markdown
  const compositeMarkdown = `${contractMarkdownBody}

---

### Statutory Electronic Consent Record (15 U.S.C. § 7001(c) & State UETA)

| Compliance Field | Verified Value |
|---|---|
| **Consumer Name & Email** | ${consent.consumerName} (${consent.consumerEmail}) |
| **15 U.S.C. § 7001(c) Disclosure Version** | ${consent.disclosureVersion} |
| **Disclosure Text SHA-256 Digest** | \`${consent.disclosureTextSha256}\` |
| **Reasonable Demonstration (PDF Access)** | Verified (${consent.pdfSampleAccessVerified}) |
| **Consent Timestamp (UTC)** | ${consent.consentedAtIso} |
| **Originating Client IP & User-Agent** | ${consent.clientIp} / ${consent.userAgent} |
`;

  const response = await fetch("https://signb.ee/api/v1/send", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.SIGNBEE_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      title: `Consumer Installment Contract — ${consent.consumerName}`,
      markdown: compositeMarkdown,
      sender_name: "Acme Lending Compliance Operations",
      sender_email: "compliance@acme-lending.com",
      recipient_name: consent.consumerName,
      recipient_email: consent.consumerEmail,
      expires_in_days: 14,
      webhook_url: "https://api.acme-lending.com/webhooks/signbee",
    }),
  });

  if (!response.ok) {
    const errorBody = await response.text();
    throw new Error(`Signbee dispatch failed (${response.status}): ${errorBody}`);
  }

  return await response.json();
}

5. Federal Rules of Evidence FRE 902(13) & FRE 902(14): Self-Authenticating SHA-256 Hashes

Satisfying UETA and the ESIGN Act makes an agreement valid, but winning a summary judgment motion in federal or state court requires proving that the PDF presented to the judge is authentic under the Federal Rules of Evidence (FRE). Historically, introducing server logs and signed electronic documents required calling a live custodian of records or forensic engineer to testify on the stand under FRE 901(b)(9)—adding $15,000 to $40,000 in litigation expenses per dispute.

On December 1, 2017, the U.S. Supreme Court and Judicial Conference amended the Federal Rules of Evidence by adding FRE 902(13) and FRE 902(14), establishing a direct cryptographic bridge for self-authenticating digital evidence:

• FRE 902(13) (Certified Records Generated by an Electronic Process or System): Declares that a record generated by an electronic process or system that produces an accurate result—such as Signbee's automated UTC audit trail and two-party execution ledger—is self-authenticating when accompanied by a certification under FRE 902(11).
• FRE 902(14) (Certified Data Copied from an Electronic Device, Storage Medium, or File): Declares that data copied from an electronic file is self-authenticating if authenticated by a process of digital identification. The official Advisory Committee Notes to FRE 902(14) specifically single out cryptographic hash values (such as SHA-256): when the post-execution SHA-256 hash of a PDF file presented in court matches the original SHA-256 hash recorded at the moment of signing, the document is presumptively authentic without live forensic testimony.

How Signbee's Two-Pass SHA-256 Signing Certificate Works

Many open-source tools (which we evaluate in our open-source e-signature API comparison) store audit events only in a mutable application database table without cryptographically binding the final PDF bytes. Signbee executes a strict two-pass cryptographic sealing pipeline when Party B completes the signing ceremony:

1. Pass 1 (Pre-Seal Document Digest): Signbee compiles the agreement body and both parties' visual signature blocks into a canonical PDF buffer and computes the SHA-256 hash of those exact content bytes.
2. Pass 2 (Appended A4 Certificate & Final Seal): Signbee generates an immutable A4 Certificate of Completion page containing the document ID, title, Party A and Party B names, verified email addresses, IP addresses, UTC timestamps, signature graphical marks, and public verification URL (https://signb.ee/verify/[id]). It embeds the cryptographic SHA-256 hash and persists the final sealed hash to immutable storage.

{
  "id": "doc_01j9x8k2m4p7q9r2",
  "title": "Master SaaS Subscription Agreement — Acme Corp",
  "status": "SIGNED",
  "created_at": "2026-10-23T14:12:08.419Z",
  "signed_at": "2026-10-23T16:45:22.904Z",
  "expires_at": "2026-11-06T14:12:08.419Z",
  "cryptographic_seal": {
    "algorithm": "SHA-256",
    "document_sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "sealed_pdf_sha256": "8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4",
    "verification_url": "https://signb.ee/verify/doc_01j9x8k2m4p7q9r2",
    "fre_902_14_compliant": true
  },
  "parties": {
    "sender": {
      "role": "Party A (Sender)",
      "name": "Marcus Vance",
      "email": "mvance@acmecorp.io",
      "auth_method": "API_KEY_BEARER_VERIFIED",
      "ip_address": "198.51.100.42",
      "executed_at": "2026-10-23T14:12:08.419Z"
    },
    "recipient": {
      "role": "Party B (Signer)",
      "name": "Elena Rostova",
      "email": "elena.rostova@horizonlogistics.com",
      "auth_method": "EMAIL_SINGLE_USE_TOKEN",
      "signature_type": "DRAWN_CANVAS_AND_CONSENT_CHECKBOX",
      "ip_address": "203.0.113.88",
      "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_7) AppleWebKit/605.1.15",
      "viewed_at": "2026-10-23T16:43:10.112Z",
      "executed_at": "2026-10-23T16:45:22.904Z"
    }
  },
  "audit_trail": [
    {
      "event": "DOCUMENT_CREATED_AND_PARTY_A_BOUND",
      "timestamp": "2026-10-23T14:12:08.419Z",
      "ip": "198.51.100.42",
      "metadata": "Dispatched via POST /api/v1/send (Key: sb_live_...9a4f)"
    },
    {
      "event": "SIGNING_INVITATION_DELIVERED",
      "timestamp": "2026-10-23T14:12:09.105Z",
      "ip": "213.188.197.151",
      "metadata": "TLS 1.3 SMTP delivery to elena.rostova@horizonlogistics.com"
    },
    {
      "event": "CEREMONY_OPENED_BY_RECIPIENT",
      "timestamp": "2026-10-23T16:43:10.112Z",
      "ip": "203.0.113.88",
      "metadata": "Single-use token validated; full PDF rendered in viewport"
    },
    {
      "event": "ELECTRONIC_SIGNATURE_ADOPTED_AND_SEALED",
      "timestamp": "2026-10-23T16:45:22.904Z",
      "ip": "203.0.113.88",
      "metadata": "SHA-256 certificate appended: 8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4"
    }
  ]
}

6. Statutory Exclusions: What Cannot Be Signed Under Standard UETA & ESIGN

Both 15 U.S.C. § 7003(a)–(b) and UETA Section 3(b) carve out specific high-stakes legal instruments where standard electronic signatures are excluded unless authorized by separate, specialized legislation. Before building an automated workflow using an affordable e-signature API integration or starting on our free e-signature API tier, verify your document category against the statutory exclusion matrix below:

7. Automating FRE 902(14) Hash Verification & Archival Compliance in Python

To satisfy 15 U.S.C. § 7001(d) (Retention of Contracts and Records) and prepare an airtight FRE 902(14) evidentiary package, legal operations teams should listen for Signbee's document.signed webhook, download the sealed PDF, verify its SHA-256 digest independently, and archive both the PDF and the JSON audit certificate into WORM (Write-Once-Read-Many) storage such as AWS S3 Object Lock.

import hashlib
import json
import os
from datetime import datetime, timezone
import urllib.request

SIGNBEE_API_KEY = os.environ["SIGNBEE_API_KEY"]

def verify_fre_902_14_and_build_certificate(document_id: str) -> dict:
    """
    Fetches a signed document metadata & PDF from Signbee, independently recomputes
    the SHA-256 digest of the binary PDF, and generates a Federal Rule of Evidence
    902(14) Self-Authentication Verification Record.
    """
    req = urllib.request.Request(
        f"https://signb.ee/api/v1/documents/{document_id}",
        headers={
            "Authorization": f"Bearer {SIGNBEE_API_KEY}",
            "Accept": "application/json",
        },
    )
    with urllib.request.urlopen(req, timeout=15) as resp:
        doc_meta = json.loads(resp.read().decode("utf-8"))

    if doc_meta.get("status") != "SIGNED":
        raise RuntimeError(f"Document {document_id} is not yet in SIGNED state.")

    pdf_url = doc_meta["signed_pdf_url"]
    expected_sha256 = doc_meta["cryptographic_seal"]["sealed_pdf_sha256"]

    with urllib.request.urlopen(pdf_url, timeout=30) as pdf_resp:
        pdf_bytes = pdf_resp.read()

    computed_sha256 = hashlib.sha256(pdf_bytes).hexdigest()

    if computed_sha256 != expected_sha256:
        raise ValueError(
            f"TAMPER_ALERT: Computed SHA-256 ({computed_sha256}) != Expected ({expected_sha256})"
        )

    evidence_bundle = {
        "statutory_framework": [
            "15 U.S.C. § 7001 (Federal ESIGN Act)",
            "Uniform Electronic Transactions Act (UETA §§ 7, 9, 12)",
            "Federal Rules of Evidence 902(13) & 902(14)",
        ],
        "document_id": document_id,
        "document_title": doc_meta["title"],
        "pdf_byte_length": len(pdf_bytes),
        "expected_sha256": expected_sha256,
        "independently_verified_sha256": computed_sha256,
        "hash_match_verified": True,
        "verified_at_utc": datetime.now(timezone.utc).isoformat(),
        "public_verification_url": f"https://signb.ee/verify/{document_id}",
        "audit_trail_snapshot": doc_meta.get("audit_trail", []),
    }

    return evidence_bundle

if __name__ == "__main__":
    bundle = verify_fre_902_14_and_build_certificate("doc_01j9x8k2m4p7q9r2")
    print(json.dumps(bundle, indent=2))

8. Pre-Production US E-Signature Compliance Checklist for Engineering Teams

Before deploying an automated contract or onboarding flow to production across all 50 U.S. states, verify these six engineering safeguards:

• Classify B2B vs. B2C Workflows: Separate commercial business contracts (governed by standard UETA § 5(b) consent) from consumer statutory writings that require the pre-signature 15 U.S.C. § 7001(c) hardware/software disclosure and PDF reasonable-demonstration check.
• Eliminate Browsewrap Ambiguity: Require an explicit signature input plus an affirmative execution button click so intent to sign (UETA § 2(8)) is indisputable.
• Enforce Multi-Point Attribution Logging: Capture both parties' verified emails, IP addresses, user-agent strings, and UTC timestamps in the PDF Signing Certificate (UETA § 9).
• Verify Automatic Counterparty Copy Delivery: Ensure every signer automatically receives a downloadable, self-contained PDF copy of the fully executed contract so the agreement cannot be voided under 15 U.S.C. § 7001(e).
• Seal Every PDF with SHA-256: Compute and persist a cryptographic SHA-256 digest of the final signed PDF to qualify for self-authentication under FRE 902(14).
• Screen Out Excluded Instrument Types: Block testamentary wills, family law court decrees, and residential utility/foreclosure notices from standard electronic pipelines unless routed through specialized statutory workflows.