eCTD and Electronic Submission Requirements

Introduction

Regulatory submissions contain enormous amounts of scientific, clinical, statistical, manufacturing, and administrative information.

Historically, much of this information was submitted as paper documents. Modern regulatory submissions instead rely on structured electronic submissions that allow reviewers to navigate documents, follow references, identify relationships between submission components, and maintain a longitudinal regulatory record.

The electronic Common Technical Document (eCTD) is the standardized electronic implementation of the Common Technical Document (CTD). It is not simply a collection of PDF files inside folders.

This distinction is fundamental for statistical programmers, regulatory operations professionals, medical writers, data managers, and anyone involved in producing submission-ready content.

CTD vs. eCTD

The CTD describes the organization of regulatory information. The eCTD implements that organization electronically.

The Five CTD Modules

The CTD is organized into five major modules.

Module 1 — Regional Information

Module 1 contains information that is specific to the regulatory region.

Examples can include:

• Administrative information
• Application forms
• Cover letters
• Regional labeling or product information
• Environmental or patent-related information where applicable
• Regional submission metadata
• Other authority-specific documents

Module 1 is therefore not globally identical.

Module 2 — Summaries

Module 2 provides structured summaries of the detailed scientific information contained in Modules 3, 4, and 5.

Typical sections include:

• Quality overall summary
• Nonclinical overview
• Clinical overview
• Nonclinical written and tabulated summaries
• Clinical summary

Module 3 — Quality

Module 3 contains chemistry, manufacturing, and controls information.

It commonly includes:

• Drug substance information
• Drug product information
• Manufacturing processes
• Control strategies
• Specifications
• Analytical procedures
• Stability information

Module 4 — Nonclinical

Module 4 contains nonclinical study reports.

Examples include:

• Pharmacology studies
• Pharmacokinetic studies
• Toxicology studies
• Safety pharmacology
• Reproductive and developmental toxicity

Module 5 — Clinical

Module 5 contains the clinical evidence supporting the application.

This module is particularly important to clinical statisticians and statistical programmers.

Examples include:

• Clinical study reports
• Study protocols
• Statistical analysis plans
• Statistical analysis documentation
• Patient-level listings
• Clinical datasets where required
• Annotated CRFs
• Study data reviewer's guides
• Analysis data reviewer documentation

eCTD Is More Than a Folder Structure

A common beginner mistake is to think of eCTD as:

submission/
  module1/
  module2/
  module3/
  module4/
  module5/

This is incomplete.

An eCTD submission includes an electronic structure that connects the files through metadata and XML.

A simplified conceptual model is:

The XML Backbone

The XML backbone is one of the most important technical components of an eCTD.

It allows the submission to be interpreted by regulatory systems and review tools.

Conceptually, the backbone answers questions such as:

• What submission is this?
• Which application does it belong to?
• What documents are included?
• Where does each document belong?
• What is the document title?
• What operation applies to the document?
• What previous document does this replace or relate to?
• What metadata describe the document?

Leaf Files

An individual document in an eCTD submission is commonly represented as a leaf.

For example, a clinical study report might exist physically as:

clinical-study-report.pdf

The eCTD structure contains metadata describing that file and its location.

The reviewer therefore sees more than the file itself.

The regulatory system knows the document's:

• Title
• Location
• Document type
• Lifecycle operation
• Version relationship
• Metadata attributes

Sequences

An eCTD lifecycle is divided into sequences.

A sequence represents a particular submission event within an application.

A simplified lifecycle might look like:

The exact sequence conventions and regional rules must be followed for the target regulatory authority.

Why Sequence Numbers Matter

The sequence number provides chronological context.

A regulator can therefore distinguish:

• The original document
• A revised document
• A replacement document
• A document that has been withdrawn
• A newly added document

This allows the electronic dossier to function as a continuously maintained regulatory record rather than a collection of unrelated submissions.

Lifecycle Management

Lifecycle management is one of the most important concepts in eCTD.

Suppose a protocol is submitted in sequence 0000.

Later, the protocol is amended.

The sponsor generally does not need to reconstruct the entire dossier as a brand-new submission.

Instead, the subsequent sequence identifies the new version and its relationship to the previous version according to the applicable lifecycle rules.

The exact lifecycle operation vocabulary depends on the eCTD version and regional implementation.

A Practical Lifecycle Example

Imagine that a Statistical Analysis Plan is submitted in sequence 0000.

0000
  clinical/
    statistical-analysis-plan.pdf

The SAP is subsequently amended.

The new submission might conceptually contain:

0001
  clinical/
    statistical-analysis-plan-v2.pdf

The eCTD metadata establishes that the newer document is the appropriate lifecycle successor to the earlier document.

The regulator can therefore understand both versions in context.

Document Reuse

Modern eCTD implementations increasingly emphasize document reuse.

A document may already exist in the dossier and remain applicable to a later submission.

The sponsor should not automatically create unnecessary duplicate documents.

Correct lifecycle and reference mechanisms allow the regulatory dossier to retain a coherent history.

PDF Is Usually the Main Content Format

Although eCTD is an XML-based electronic framework, much of the scientific content is delivered as PDF.

However, a PDF that opens successfully is not necessarily an acceptable submission PDF.

Regulatory submission PDFs may need to satisfy requirements concerning:

• PDF version
• Fonts
• Font embedding
• Bookmarks
• Hyperlinks
• Navigation
• Security settings
• Page orientation
• Page numbering
• Scanned-document quality
• Searchability
• Document metadata

Searchable Text

A scanned document consisting only of images may create substantial review problems.

Where searchable text is required, the document should contain a usable text layer rather than simply displaying page images.

This is particularly important for:

• Clinical study reports
• Statistical reports
• Protocols
• Submission correspondence
• Integrated summaries
• Reviewer guides

Bookmarks

Long regulatory documents should generally contain meaningful bookmarks.

A good bookmark hierarchy should correspond logically to the document's structure.

For example:

Clinical Study Report
  1. Synopsis
  2. Introduction
  3. Objectives
  4. Methodology
     4.1 Study Design
     4.2 Statistical Methods
  5. Results
     5.1 Patient Disposition
     5.2 Demographics
     5.3 Efficacy
     5.4 Safety
  6. Conclusions

Bookmarks should take the reviewer directly to the appropriate page.

Hyperlinks

Hyperlinks are a major usability feature of electronic submissions.

A clinical study report may reference:

• Tables
• Figures
• Listings
• Appendices
• Other submission documents

Where permitted and technically appropriate, internal links should allow the reviewer to navigate directly to the referenced content.

File Naming

File names are another important component of submission quality.

File naming requirements are defined by the applicable eCTD and regional technical specifications.

Avoid casual file names such as:

final_final_v7_USE_THIS_ONE.pdf
newreport2.pdf
latestCSR.pdf

Instead, use controlled naming conventions that are consistent with the submission specification and the sponsor's document-management process.

Directory Structure

An eCTD directory structure reflects the CTD organization.

A simplified conceptual representation is:

0000/
├── index.xml
├── m1/
├── m2/
├── m3/
├── m4/
└── m5/

Actual production eCTD directories contain additional technical files, regional components, XML structures, schema-related components, and submission-specific metadata.

Therefore, this simplified structure should not be used as a production submission template.

eCTD v3.2.2

eCTD v3.2.2 remains an important implementation because many existing regulatory applications were established using this version.

For FDA submissions, v3.2.2 continues to be relevant to existing applications, while FDA has introduced eCTD v4.0 for new regulatory applications.

This creates an important practical distinction:

FDA states that CDER and CBER began accepting new regulatory applications in eCTD v4.0 on September 16, 2024. FDA's current implementation continues to develop forward compatibility for existing v3.2.2 applications.

eCTD v4.0

eCTD v4.0 represents a major evolution of the eCTD standard.

The goal is not simply to change the XML syntax.

The newer architecture provides improved support for:

• Structured metadata
• Document reuse
• Lifecycle management
• Improved interoperability
• More sophisticated submission relationships
• Future regulatory communication workflows

The ICH eCTD v4.0 implementation is accompanied by implementation guides, schema files, controlled vocabularies, and regional Module 1 requirements. The ICH implementation materials were updated in 2026, including an updated Implementation Guide and controlled vocabulary package.

FDA Electronic Submission Requirements

For FDA-regulated drug and biologic submissions, eCTD is the standard electronic format for a broad range of submission types.

FDA identifies electronic submission requirements for areas including:

• NDAs
• ANDAs
• BLAs
• Commercial INDs
• Master files
• Subsequent submissions to applicable applications

Some categories, such as certain noncommercial INDs, have different requirements or may have electronic submission standards that are optional or encouraged rather than mandatory.

FDA eCTD v4.0 Status in 2026

As of 2026, FDA CDER and CBER accept new regulatory applications in eCTD v4.0. FDA's published standards page was updated in August 2026 and lists current versions of the eCTD v4.0 implementation materials, validation criteria, technical conformance guide, file-format specifications, and transmission specifications.

This is an important example of why regulatory submission procedures should not be treated as static knowledge.

A sponsor preparing a submission should always verify:

• Current eCTD version
• Current regional Module 1 implementation guide
• Current validation criteria
• Current accepted file formats
• Current transmission specification
• Current technical conformance guide
• Current data standards requirements

FDA Electronic Submission Gateway

FDA electronic submissions are transmitted through the applicable FDA electronic submission infrastructure.

FDA's current submission guidance states that eCTD submissions of 10 GB or smaller are submitted through the Electronic Submissions Gateway (ESG), and FDA recommends establishing the ESG account and testing process well in advance.

The account setup process includes testing to ensure that the submitter can successfully transmit electronic submissions.

FDA Sample Submissions

FDA also provides an optional process for sponsors preparing eCTD v4.0 submissions to submit a sample for technical feedback.

This process is distinct from the testing performed as part of establishing the electronic submission gateway account.

FDA indicates that the sample process is intended to identify technical conformance issues rather than provide scientific review.

EU Electronic Submission Requirements

The European regulatory environment has its own regional implementation of eCTD.

For centrally authorised products, EMA states that eCTD is the required electronic format for applications and related submission types.

The EU also uses a regional Module 1 specification in addition to the harmonized CTD Modules 2–5.

This means that an EU eCTD submission is not simply an FDA package with a different transmission destination.

EU Module 1

EU Module 1 contains regional information that is specific to European regulatory procedures.

Examples include:

• European administrative information
• Application forms
• Product information
• Regional correspondence
• Procedure-specific information
• EU-specific metadata

The EU eCTD Module 1 specification is maintained separately from the harmonized ICH components.

EU eCTD v3.2.2 and v4.0

The EU is also transitioning toward eCTD v4.0.

During 2026, EMA's implementation includes pilots and optional-use phases for eCTD v4.0, while the established v3.2.2 framework remains important for existing regulatory lifecycles.

EMA published final EU eCTD v4.0 validation criteria version 1.1 in March 2026, with applicability beginning July 15, 2026.

Global eCTD Strategy

For a multinational development program, the submission team should maintain a matrix such as:

The purpose of the matrix is to prevent a common submission error: assuming that compliance with one regulator automatically establishes compliance with another.

Electronic Submission Validation

Validation is one of the most important steps in the eCTD production process.

A submission can be scientifically excellent and still fail technical validation.

Validation may identify issues involving:

• XML structure
• Schema compliance
• File paths
• Missing files
• Invalid files
• Metadata
• Lifecycle relationships
• Hyperlinks
• Bookmarks
• File formats
• Folder structure
• Regional requirements

Validation Is Not the Same as QC

Technical validation and submission QC are related but different activities.

A submission should pass all of these layers.

Validation Findings

Validation findings are commonly categorized by severity.

A simplified conceptual hierarchy is:

• Errors: conditions that generally require correction before submission.
• Warnings: conditions requiring investigation and documented justification where appropriate.
• Information: observations that may not prevent submission.

The actual severity classifications and rules are authority- and version-specific.

Submission Validation Workflow

Common eCTD Technical Problems

Broken Internal Links

A PDF may contain links that worked in the author's working environment but fail after the document is moved into the eCTD package.

Every hyperlink should therefore be validated in the final submission environment.

Broken Bookmarks

Bookmarks can point to the wrong page after document assembly.

This is particularly common when:

• Pages are inserted
• Tables are regenerated
• Appendices are merged
• Documents are converted between formats

Missing Files

A leaf may reference a physical file that was accidentally omitted from the submission package.

Incorrect Lifecycle Relationship

A document may incorrectly reference an earlier version or use the wrong lifecycle operation.

Incorrect Metadata

The document itself may be correct while its eCTD metadata are wrong.

Common PDF Problems

Submission Content QC

Technical validation cannot determine whether the wrong clinical study report was included.

Therefore, content QC remains essential.

A submission QC process should verify:

• Correct document version
• Correct study identifier
• Correct protocol number
• Correct analysis cutoff
• Correct treatment names
• Correct document title
• Correct report date
• Correct appendices
• Correct datasets
• Correct reviewer guides
• Correct references

Statistical Programming and eCTD

Statistical programmers may not assemble the final eCTD package, but their work directly contributes to submission quality.

Typical statistical-programming deliverables include:

• SDTM datasets
• ADaM datasets
• Define-XML
• Analysis tables
• Analysis listings
• Figures
• Data review documentation
• Statistical reports
• Programs and metadata where required

Each deliverable may ultimately become part of a regulated submission.

Why Define-XML Matters

For standardized study-data submissions, Define-XML describes the structure and metadata of submitted datasets.

This creates a connection between:

eCTD and Clinical Study Data

An important conceptual distinction is that eCTD and CDISC are not the same standard.

These standards interact within the regulatory submission ecosystem, but each solves a different problem.

Electronic Submission Package vs. Submission Content

It is useful to separate two questions.

Question 1: Is the scientific content correct?

Question 2: Is the electronic package technically correct?

Both must be true.

Receipt and Transmission

Transmission is not simply equivalent to regulatory acceptance.

A submission can be transmitted successfully while subsequently encountering technical validation issues.

The submission process therefore contains multiple stages:

1. Package preparation
2. Validation
3. Transmission
4. Receipt
5. Technical processing
6. Validation by the authority
7. Regulatory acceptance
8. Scientific review

The exact workflow differs by authority.

Receipt Date Considerations

Regulatory submission timing can have legal and procedural significance.

For that reason, submission teams should distinguish:

• Time the package was released internally
• Time the package was transmitted
• Time the gateway received the package
• Time the authority processed the package
• Official regulatory receipt date

Sponsors should rely on the applicable authority's rules rather than assuming that the timestamp of an internal transmission system is the official regulatory receipt date.

Electronic Submission Security

Regulatory submissions contain highly confidential information.

Submission operations should therefore address:

• Access control
• Credential management
• Transmission security
• Controlled release
• Audit trails
• Version control
• Document integrity
• Change management

Checksums and File Integrity

Electronic submission systems use mechanisms to verify file integrity.

A checksum can be viewed conceptually as a fingerprint of a file.

If the file changes after the checksum is calculated, the resulting checksum will generally change.

Submission Freeze

A formal submission freeze should occur before final eCTD assembly.

At freeze, the team should establish exactly which versions of documents, datasets, metadata, and supporting materials are authorized for submission.

A simplified freeze checklist is:

Common Submission Mistakes

1. Treating eCTD as a collection of PDFs. The XML structure, metadata, lifecycle, and regional requirements are equally important.
2. Using an outdated specification. Regulatory technical standards are updated over time.
3. Assuming one global package fits every region. Module 1 and technical requirements differ by authority.
4. Ignoring lifecycle relationships. Incorrect lifecycle metadata can make the dossier difficult to interpret.
5. Failing to validate after final document replacement. A seemingly minor PDF replacement can invalidate previously validated relationships.
6. Using broken hyperlinks. Electronic review depends heavily on navigation.
7. Failing to check bookmarks. Long regulatory documents should be easy to navigate.
8. Submitting the wrong document version. Technical validation may not detect scientific-content version errors.
9. Confusing transmission with acceptance. Successful upload does not necessarily mean regulatory acceptance.
10. Waiting until the submission deadline to test the gateway. Electronic transmission infrastructure should be established in advance.

Advanced eCTD QC Checklist

Building a Regulatory Submission Pipeline

A mature submission organization should treat eCTD production as a controlled pipeline rather than a last-minute packaging activity.

How Statistical Programmers Fit Into the Pipeline

Statistical programmers often interact with eCTD requirements indirectly but critically.

For example, a programmer may produce:

ADSL.xpt
ADAE.xpt
ADLB.xpt
ADTTE.xpt
define.xml
analysis-tables.pdf
analysis-listings.pdf
analysis-figures.pdf

Those outputs may then be incorporated into the regulatory submission.

A change in an analysis dataset can therefore propagate into:

• Tables
• Listings
• Figures
• Statistical reports
• Reviewer guides
• Define-XML
• Submission metadata

This is why submission readiness requires coordination across programming, biostatistics, data management, medical writing, regulatory operations, and quality functions.

Traceability Across the Submission

A strong regulatory submission maintains traceability from source data through analysis and reporting.

Conceptually:

Source Data
    ↓
SDTM
    ↓
ADaM
    ↓
Tables / Listings / Figures
    ↓
Clinical Study Report
    ↓
eCTD
    ↓
Regulatory Review

The eCTD does not replace this traceability.

Instead, it provides the regulatory framework through which the resulting content is submitted and maintained.

eCTD and Reviewer Experience

One of the most useful ways to think about eCTD quality is from the reviewer's perspective.

Ask:

• Can the reviewer quickly find the relevant document?
• Can the reviewer navigate a long PDF?
• Can the reviewer follow references?
• Can the reviewer distinguish current and superseded content?
• Can the reviewer understand the submission lifecycle?
• Can the reviewer identify the relevant study data?
• Can the reviewer understand the relationship between documents?

Good eCTD production reduces the amount of unnecessary work required from the reviewer.

eCTD Is a Lifecycle, Not a One-Time Event

A common conceptual mistake is to think of an eCTD as the package submitted with the original application.

In reality, an eCTD dossier may evolve for many years.

The lifecycle can include:

• Initial applications
• Information requests
• Amendments
• Clinical updates
• CMC updates
• Safety reports
• Labeling changes
• Supplements
• Variations
• Post-approval commitments
• Renewals

The submission system therefore needs to preserve historical context while clearly identifying current information.

What Makes an eCTD "Submission Ready"?

An eCTD is submission-ready only when several dimensions align.

Practical Submission Checklist

Key Differences Between FDA and EU eCTD Operations

The Most Important Practical Principle

The most important concept in eCTD production is that regulatory submission compliance is multidimensional.

A submission can fail even when the underlying science is excellent.

For example:

• The statistical analysis can be correct.
• The clinical study report can be correct.
• The datasets can be correct.
• The PDFs can open successfully.

Yet the submission may still have problems if:

• The wrong regional specification is used.
• The XML backbone is incorrect.
• A lifecycle relationship is wrong.
• A required file is missing.
• A document has invalid metadata.
• The submission fails technical validation.
• The electronic transmission process is not configured correctly.

References

U.S. Food and Drug Administration. Electronic Common Technical Document (eCTD).
https://www.fda.gov/drugs/electronic-regulatory-submission-and-review/electronic-common-technical-document-ectd

U.S. Food and Drug Administration. eCTD Submission Standards for eCTD v4.0 and Regional M1.
https://www.fda.gov/drugs/electronic-regulatory-submission-and-review/ectd-submission-standards-ectd-v40-and-regional-m1

U.S. Food and Drug Administration. eCTD Submission Standards for eCTD v3.2.2 and Regional M1.
https://www.fda.gov/drugs/electronic-regulatory-submission-and-review/ectd-submission-standards-ectd-v322-and-regional-m1

U.S. Food and Drug Administration. Providing Regulatory Submissions in Electronic Format — Certain Human Pharmaceutical Product Applications and Related Submissions Using the eCTD Specifications.
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/providing-regulatory-submissions-electronic-format-certain-human-pharmaceutical-product-applications

U.S. Food and Drug Administration. Submit Using eCTD.
https://www.fda.gov/drugs/electronic-regulatory-submission-and-review/submit-using-ectd

International Council for Harmonisation. ICH electronic Common Technical Document (eCTD) v4.0.
https://admin.ich.org/page/ich-electronic-common-technical-document-ectd-v40

European Medicines Agency. eSubmission — eCTD.
https://esubmission.ema.europa.eu/ectd/

European Medicines Agency. Pre-authorisation guidance — Submission, validation and fees.
https://www.ema.europa.eu/en/human-regulatory-overview/marketing-authorisation/pre-authorisation-guidance

European Medicines Agency. eCTD v4.0 implementation roadmap.
https://www.ema.europa.eu/en/documents/other/ectd-v40-eursnext-roadmap_en.pdf