What Is eCTD? The Definitive 2026 Guide to Electronic Common Technical Document

Everything regulatory affairs professionals need to know about the Electronic Common Technical Document (eCTD) standard — modules, lifecycle, validation, and modern publishing tools.

What Is eCTD? The Complete Guide to Electronic Common Technical Document

For regulatory affairs professionals navigating global drug submissions, understanding what is eCTD is foundational knowledge. The Electronic Common Technical Document has become the universal language of regulatory submissions, replacing decades of paper-based filings with a standardized digital format accepted by health authorities worldwide.

This guide provides a comprehensive overview of eCTD—its origins, structure, technical specifications, and the evolving landscape that regulatory operations teams must navigate in 2024 and beyond.

Defining eCTD: Origin and Purpose

The Electronic Common Technical Document (eCTD) is a standardized format for submitting regulatory applications to health authorities. Developed under the International Council for Harmonisation (ICH), eCTD emerged from the ICH M2 (electronic standards) and M4 (CTD organization) guidelines as a way to harmonize how pharmaceutical companies present data to regulators across different regions.

Before eCTD, companies faced a fragmented landscape. A single drug seeking approval in the United States, Europe, and Japan required three entirely different submission formats. The FDA had its own structure. The EMA had another. Japan’s PMDA required something else entirely. This meant regulatory teams were essentially building the same submission three or more times, reformatting identical clinical data to meet each authority’s unique requirements.

The Common Technical Document (CTD) solved the organizational problem by creating a unified structure for content. eCTD took this further by defining how that content should be packaged electronically—specifying the XML backbone, file formats, naming conventions, and metadata that allow health authorities to receive, validate, and review submissions consistently.

When people ask what is eCTD at its core, the answer is both simple and complex: it’s a specification that turns regulatory submissions into structured, machine-readable packages that can be validated automatically and reviewed efficiently by assessors anywhere in the world.

The Five Modules of eCTD

Every eCTD submission follows a five-module structure. Modules 2 through 5 are globally harmonized—identical regardless of which health authority receives them. Module 1 remains region-specific, accommodating the administrative and legal requirements unique to each jurisdiction.

Module 1: Regional Administrative Information

Module 1 contains forms, cover letters, labeling, and administrative documents specific to each health authority. For FDA submissions, this includes Form 356h, the prescribing information, and patent certifications. For EMA submissions, it contains the application form, SmPC, package leaflet, and environmental risk assessments. Because regulatory requirements differ by region, Module 1 cannot be harmonized and must be rebuilt for each market.

Module 2: CTD Summaries

Module 2 provides high-level summaries and overviews of the data contained in Modules 3, 4, and 5. This includes:

• 2.1 – CTD Table of Contents
• 2.2 – CTD Introduction
• 2.3 – Quality Overall Summary (QOS)
• 2.4 – Nonclinical Overview
• 2.5 – Clinical Overview
• 2.6 – Nonclinical Written and Tabulated Summaries
• 2.7 – Clinical Summary

Reviewers often begin their assessment in Module 2, using these summaries to understand the submission before diving into detailed reports.

Module 3: Quality (CMC)

Module 3 contains Chemistry, Manufacturing, and Controls information—everything related to how the drug substance and drug product are made, tested, and controlled. This includes manufacturing processes, specifications, stability data, container closure systems, and control strategies. For complex biologics, Module 3 can be the largest section of the submission.

Module 4: Nonclinical Study Reports

Module 4 houses pharmacology, pharmacokinetics, and toxicology data from animal and in vitro studies. This includes study reports for single-dose toxicity, repeat-dose toxicity, genotoxicity, carcinogenicity, and reproductive toxicity, along with pharmacology studies demonstrating the drug’s mechanism of action.

Module 5: Clinical Study Reports

Module 5 contains human clinical trial data—the Phase 1, 2, and 3 study reports that form the evidentiary basis for approval. This module typically includes tabular listings of all studies, clinical study reports (CSRs), and literature references. For large development programs, Module 5 can span thousands of documents and hundreds of thousands of pages.

eCTD Technical Structure: Backbone, Leaves, and Lifecycle

Understanding what is eCTD requires looking beyond content organization to the technical architecture that makes electronic submissions work.

The XML Backbone

At the heart of every eCTD submission is an XML file (typically named index.xml for FDA or eu-regional.xml for EMA) that serves as the “table of contents.” This backbone file doesn’t contain the actual documents—it contains metadata and pointers that tell the health authority’s system where each document lives, what it’s called, and how it relates to documents in previous sequences.

Leaf Documents

The actual content—PDFs, datasets, images—are called “leaf” documents. Each leaf is referenced in the backbone XML with attributes including the file path, title, checksum (for integrity verification), and operation type. Leaf documents must meet specific technical requirements: PDFs should be version 1.4-1.7, bookmarked, text-searchable, and properly paginated.

Lifecycle Operations

eCTD uses four lifecycle operations to manage documents across submission sequences:

• New – Introduces a document for the first time
• Replace – Supersedes a previously submitted document with an updated version
• Append – Adds to an existing document without replacing it (commonly used for safety reports)
• Delete – Removes a document from the current view (the original remains in the archive)

These operations create a cumulative record. Health authorities can view the submission at any point in its history, seeing exactly what documents were current at any sequence.

Sequence Numbering and the Submission Lifecycle

Every eCTD submission exists as a series of sequences, numbered starting from 0000. The initial application is typically sequence 0000. Each subsequent interaction—an amendment, a response to questions, a safety update—becomes a new sequence: 0001, 0002, 0003, and so on.

This numbering system creates a complete audit trail. Sequence 0015, for example, represents the fifteenth update to the submission. Reviewers can navigate to any sequence to see the state of the dossier at that moment, or view the “current” state that reflects all accumulated changes.

Managing this lifecycle becomes increasingly complex as programs mature. A marketed product might have 50+ sequences accumulated over years of post-approval changes, safety updates, and label revisions. Modern publishing platforms like DnXT maintain this lifecycle automatically, tracking which documents are current, which have been superseded, and how each leaf relates to its predecessors.

Validation: What Gets Checked and Why

Before any eCTD submission reaches a reviewer, it passes through validation software that checks for technical compliance. Validation happens at multiple levels:

Technical Validation Criteria

• XML well-formedness – Is the backbone syntactically correct?
• Schema compliance – Does the XML conform to the published DTD/schema?
• File integrity – Do checksums match? Are all referenced files present?
• PDF specifications – Correct version, fonts embedded, no encryption, proper bookmarks
• Naming conventions – File and folder names within character limits, no special characters
• Lifecycle integrity – Do replace/delete operations reference valid prior leaves?

Common Validation Errors

The most frequent errors include missing or broken hyperlinks, PDFs with embedded fonts that fail validation, incorrect lifecycle references, and file names exceeding character limits. Each health authority publishes its own validation criteria—FDA’s are documented in the eCTD Validation Criteria, while EMA publishes the EU Module 1 Specification and associated rules.

Professional publishing tools run both preflight validation (during assembly) and final validation (against the complete submission package). DnXT, for example, integrates validation throughout the publishing workflow, catching errors before they propagate into the final submission rather than discovering them at the end.

Health Authorities Accepting eCTD

eCTD has achieved near-universal adoption among major regulatory agencies:

Regional variations exist. Each authority maintains its own Module 1 specification, validation rules, and submission gateway. Publishing to multiple regions requires understanding these nuances—the same Module 3 content might be valid for FDA but trigger validation errors for Health Canada due to differing file-naming rules.

eCTD vs. NeeS vs. Paper Submissions

While eCTD dominates today, regulatory professionals occasionally encounter other formats:

NeeS served as a transitional format, allowing electronic submission without the technical complexity of eCTD’s XML backbone. As health authorities have built systems around eCTD validation and lifecycle management, NeeS has been retired in most major regions.

eCTD 4.0: What’s Changing

The ICH has developed eCTD 4.0, a significant update to the specification. Key changes include:

• RPS (Regulated Product Submission) standard – A new messaging framework replacing the current XML backbone
• Enhanced lifecycle management – More granular tracking of document states and relationships
• Improved metadata – Richer descriptive information about submission contents
• Better support for complex products – Designed with combination products and advanced therapies in mind

Transition timelines vary by region. FDA has published implementation plans, while other authorities are at different stages. Organizations should monitor announcements from relevant health authorities and ensure their publishing tools support the transition. Platform vendors including DnXT are building eCTD 4.0 capabilities in preparation for regional mandates.

How Modern Publishing Tools Automate eCTD

While understanding what is eCTD at a conceptual level matters, the practical reality is that manual eCTD assembly is error-prone and unsustainable. Modern publishing platforms automate the technical complexity:

• Automatic backbone generation – XML files built from document metadata, eliminating manual coding
• Integrated validation – Errors caught during assembly, not after completion
• Lifecycle tracking – Systems maintain document history and generate correct operations
• Multi-region support – Single content base published to region-specific formats
• Document classification – AI-assisted placement of documents into correct eCTD locations

Cloud-native platforms like DnXT represent the current generation of publishing technology—built on modern architecture, offering rapid implementation compared to legacy systems, and integrating publishing with submission planning and document management. The 12-week typical implementation for such platforms contrasts sharply with the 9-18 month deployments historically associated with enterprise RIM suites.

Frequently Asked Questions

Is eCTD mandatory for FDA submissions?

Yes. FDA requires eCTD format for NDAs, BLAs, ANDAs, and INDs (with limited exceptions for certain small-volume submission types). The mandate has been in effect since 2017 for commercial applications and 2018 for certain investigational applications.

What software do I need to create an eCTD submission?

eCTD publishing requires specialized software to generate the XML backbone, validate the package, and manage lifecycle operations. Options range from enterprise RIM platforms to focused publishing solutions. Organizations typically evaluate based on submission volume, regional coverage requirements, integration needs, and implementation timeline.

How long does it take to prepare an eCTD submission?

Timelines vary dramatically based on submission complexity. A routine amendment might take days. An original NDA with extensive clinical programs can require months of publishing effort. Key variables include document volume, how well source documents meet eCTD specifications, and the maturity of the organization’s publishing processes.

What happens if my eCTD submission fails validation?

Health authority gateways reject submissions with critical validation errors. The submission isn’t accepted until errors are corrected and the package is resubmitted. This can impact regulatory timelines, particularly for time-sensitive safety updates or applications approaching PDUFA dates. Comprehensive pre-submission validation is essential.

Can I convert a paper submission to eCTD?

Yes, though it requires significant effort. Paper documents must be scanned to searchable PDFs, organized into eCTD structure, and published with proper backbone XML. Organizations typically undertake this for products needing ongoing lifecycle management in regions that have discontinued paper acceptance.

How does eCTD handle amendments and supplements?

Each amendment becomes a new sequence building on the previous submission state. The backbone XML specifies which documents are new, which replace previous versions, and which are deleted. Health authorities see both the incremental change and the cumulative current state of the dossier.