The eCTD, or electronic Common Technical Document, is a standardized format for submitting pharmaceutical regulatory dossiers to health authorities. It organizes all required documentation into a structured, machine-readable package that regulators can review consistently across submissions. The sections below answer the most common questions about how eCTD works in practice, from its basic structure to the tools used to build it.
What are the five modules that make up an eCTD?
An eCTD is organized into five modules, each covering a distinct category of regulatory information. Module 1 contains region-specific administrative documents. Modules 2 through 5 are harmonized across ICH regions and cover summaries, quality, nonclinical, and clinical data, respectively.
Here is a breakdown of each module:
- Module 1 – Administrative and prescribing information: Region-specific documents such as application forms, labeling, and country-specific requirements. This module differs between the EMA, FDA, and other agencies.
- Module 2 – Overviews and summaries: Concise summaries of the quality, nonclinical, and clinical data. Includes the Common Technical Document summaries and the overall quality summary.
- Module 3 – Quality: Detailed chemistry, manufacturing, and controls (CMC) documentation covering drug substance, drug product, and related analytical data.
- Module 4 – Nonclinical study reports: Pharmacology, pharmacokinetics, and toxicology study reports supporting the safety profile of the product.
- Module 5 – Clinical study reports: All clinical data, including study protocols, individual patient data, and integrated summaries of efficacy and safety.
This modular structure allows applicants to update individual sections without resubmitting the entire dossier, which significantly reduces administrative burden over the product lifecycle.
How does the eCTD backbone and XML structure actually work?
The eCTD backbone is an XML index file that tells the reviewing agency exactly what documents are included in the submission, where they are located, and how they relate to previous submissions. The XML file acts as a navigation map, linking every document in the dossier to a defined location within the five-module hierarchy.
Each submission contains a folder structure with the actual content files, typically PDFs, and an XML backbone file that references those files. The XML follows a defined document type definition (DTD) or schema, which health authorities specify in their technical guidance. This schema ensures that every submission is machine-readable and can be loaded into an agency’s document management system automatically.
The backbone also records the operation applied to each document, whether it is a new file, a replacement for a previously submitted document, or a deletion. This lifecycle tracking is what allows agencies to reconstruct the full current state of a dossier at any point in time by reading through all sequences in order.
What is the difference between an eCTD sequence and a submission?
A submission is the overall regulatory application, such as a Marketing Authorization Application (MAA) or a New Drug Application (NDA). A sequence is a single delivery of documents within that submission. Every time an applicant sends new or updated information to the agency, that package is assigned a sequence number, starting at 0000 for the initial submission.
Sequences are cumulative. Sequence 0000 represents the original application. Sequence 0001 might be a response to a question from the agency. Sequence 0002 could be a label update. Together, all sequences form the complete, evolving regulatory record for a product. Agencies use the sequence numbering to process updates in the correct order and to maintain a clear audit trail.
This distinction matters in practice because applicants must ensure that each new sequence correctly references prior sequences. A broken reference chain can prevent the agency’s system from reading the dossier correctly, which is one of the most common causes of technical validation failures. Working with an experienced regulatory partner — learn more about our background and approach — can help teams avoid these pitfalls from the outset.
Which regulatory agencies require eCTD submissions?
The eCTD format is required by all major ICH-region regulatory agencies, including the FDA in the United States, the EMA in the European Union, Health Canada, and the PMDA in Japan. In 2026, eCTD is also accepted or required by a growing number of non-ICH markets, including Australia, Switzerland, and several Gulf Cooperation Council countries.
Within the EU, the EMA requires eCTD for all centralized procedure applications. National competent authorities across EU member states also require eCTD for decentralized and mutual recognition procedures. The FDA mandated eCTD for all NDA, BLA, and IND submissions, with phased implementation completed several years ago.
It is worth noting that specific technical requirements vary by agency. The FDA follows its own eCTD technical specifications, while the EMA operates under the NeeS (Non-eCTD Electronic Submission) legacy system for some legacy products but has moved predominantly to eCTD. Always confirm the current technical specification version required by each agency before building a submission.
What software and tools are used to build and validate an eCTD?
Building an eCTD requires specialized publishing software that generates the XML backbone, organizes documents into the correct folder structure, and applies the appropriate operations to each file. Validation tools then check the submission against agency technical specifications before it is sent.
The most widely used eCTD publishing platforms include Lorenz docuBridge, Veeva Vault RIM, and ISI Toolbox. These tools automate much of the structural work, including generating the XML index and applying sequence numbering. Most also include built-in validation against the relevant DTD or schema.
Validation is a separate step from publishing. Agencies such as the FDA provide their own validation criteria, and third-party validation tools like Lorenz eCTD Checker or Extedo eCTD Validator allow applicants to run checks before submission. A clean validation report is a prerequisite for acceptance by most agencies. Submitting without prior validation significantly increases the risk of a technical rejection.
What are the most common eCTD submission errors and how are they avoided?
The most common eCTD submission errors fall into three categories: structural errors in the XML backbone, document-level issues with PDFs, and lifecycle management mistakes across sequences. Most of these errors are preventable with proper validation and internal quality checks before submission.
Structural and XML errors
Broken file references in the XML backbone are among the most frequent technical failures. These occur when a file path in the XML does not match the actual location of the document in the folder structure, often due to renaming files after the backbone has been generated. Running a full validation check after any last-minute file changes catches these issues before they reach the agency.
Another common structural error is using incorrect operation codes, for example, marking a document as a replacement when no prior version exists in the dossier. This confuses the agency’s document management system and can cause the submission to fail intake.
Document and lifecycle errors
PDF-level errors include bookmarks that do not function, non-searchable text due to incorrect scanning settings, and files that exceed agency size limits. These are best caught through a document quality checklist applied to every PDF before it enters the publishing workflow.
Lifecycle errors typically involve incorrect sequence chaining, where a new sequence references the wrong prior sequence, or where a document is deleted that should have been replaced. Maintaining a clear internal submission history log and reviewing the lifecycle of each document before publishing a new sequence reduces these risks considerably. If your team needs structured support in this area, explore the full range of regulatory services we offer to keep your dossier on track.
How Starodub supports your eCTD regulatory submissions
Navigating eCTD requirements across multiple agencies is time-consuming and technically demanding. We support biopharmaceutical and medical device companies at every stage of the regulatory submission process, from initial dossier planning to lifecycle management across sequences and updates. Our support includes:
- Dossier preparation and publishing: We prepare and structure your submission content across all five eCTD modules, ensuring documents meet agency-specific formatting and technical requirements.
- Validation and quality review: Before any submission goes out, we run thorough validation checks against the relevant agency specifications to catch structural, XML, and document-level errors.
- Multi-agency submissions: We manage submissions to the EMA, FDA, Health Canada, and other authorities, adapting Module 1 content and technical specifications for each jurisdiction.
- Lifecycle management: We track your submission history, manage sequence numbering, and ensure that updates and responses are correctly linked to prior sequences.
- CMC and regulatory strategy: With deep expertise in regulatory CMC, we align your quality documentation with both scientific requirements and the expectations of each reviewing agency.
If you are preparing a new application or managing an existing dossier and want to make sure your submissions are technically sound and strategically positioned, get in touch with us to discuss how we can support your regulatory goals.
Related Articles
- What is regulatory strategy validation and why does it matter?
- What are the benefits of having a regulatory affairs strategy?
- What are EMA requirements?
- How do you prepare for medical device audits?
- What is the difference between CE marking and FDA approval?
This content was generated with the help of AI and it may contain mistakes
