The question of eCTD vs CTD confuses many teams because the two terms are often used as if they meant the same thing. In short, the CTD defines what goes into a dossier and where it belongs, while the eCTD defines how that content is packaged, linked and tracked electronically. This article explains the difference, how an eCTD submission is built and maintained, the errors that fail validation, and how to move from paper or PDF to eCTD.

eCTD vs CTD: what is the difference?

The CTD is a content structure. Defined in ICH M4, it sets out the five modules of a registration dossier and the numbered sections inside them, without saying anything about the medium: the same CTD can be printed, saved as PDF files or delivered electronically.

The eCTD is the electronic format for delivering that structure. Defined in ICH M8, it is a technical specification covering the folder layout, the XML files that index everything, the permitted file formats and the way documents are updated over time. Every eCTD is a CTD, but not every CTD is an eCTD.

Side by side, the main differences are these:

  • Purpose and guideline. The CTD (ICH M4) organises the content. The eCTD (ICH M8) transmits and maintains it electronically.
  • Navigation. A paper or PDF CTD relies on contents pages and page references. An eCTD adds an XML index, bookmarks and hyperlinks that the reviewer's software reads.
  • Updates. Updating a CTD usually means supplying replacement documents. An eCTD records each update as a numbered sequence with defined operations, so the history can be traced.

If the five modules are new to you, read the overview of the Common Technical Document and its five modules first, because this article builds on that structure.

How is an eCTD built?

An eCTD application is a set of folders. Each submission is a sequence with its own numbered folder, which holds a folder for each module, and documents sit in the sections the CTD structure defines. Most are PDF files, and the specification allows some other file types.

The XML backbone is the index that makes a submission an eCTD. For every file it records the section it belongs to, the title the reviewer sees, its location, a checksum confirming that it has not been altered, and the lifecycle operation that applies to it. The reviewer's software reads the backbone to draw the table of contents, so a file that is missing from it, or filed in the wrong section, is hard to find.

Granularity is the level of detail at which content is split into files, and it has long-term consequences. When every study report or specification is a separate file, one document can be replaced later without resubmitting its neighbours; when large sections are merged, every small change forces a bigger replacement. Authorities may publish their own granularity guidance, so check it first.

How do eCTD sequences and lifecycle operations work?

An eCTD application grows one sequence at a time. Sequences are numbered in order, commonly starting at 0000 for the initial application, and later ones carry query responses, variations, renewals and other updates. A sequence can also state which earlier sequence it relates to.

Every file in a sequence carries a lifecycle operation that tells the reviewer's system how to treat it:

  • New adds a document that has not been submitted before.
  • Replace substitutes an updated document for an earlier one. The earlier file leaves the current view but stays in the history.
  • Delete takes a document out of the current view without erasing it from the history.
  • Append adds a file to a document that is already in the application without replacing it. It is the least used of the four, and some authorities discourage it, so check the regional guidance first.

An example shows why this matters. When an authority queries a drug product specification, the reply letter is added as a new document where the regional specification says, the revised specification replaces the earlier file, and the Module 2 quality summary is replaced too, so that it still matches Module 3. Forget one step and the current view of the dossier contradicts itself.

Because later sequences depend on earlier ones, plan them as a series. A sequence plan records what each contained, which documents are current and what comes next, since a wrong operation or mislabelled document in an early sequence is inherited by every later one.

What does eCTD validation check, and why do submissions fail?

Before a sequence is sent, validation software checks it against technical rules: the ICH specification plus the authority's own criteria where they exist. Findings are usually graded into errors that must be corrected and warnings that need assessment. An authority may also run its own checks on receipt, and a sequence that fails them may be refused or returned for correction. The same problems recur:

  • Broken hyperlinks and bookmarks. Links to a file that was renamed, moved or replaced, or documents with no bookmarks, so the reviewer cannot move from a summary to a report.
  • File format and PDF problems. Scanned pages without searchable text, fonts that are not embedded, password protection or other security settings, and file types the specification does not allow.
  • Wrong placement. A document filed in the wrong section, or titled so differently from its content that nobody can find it.
  • Inconsistent sequence numbering. Duplicated or out-of-order numbers, unexplained gaps, and references to related sequences that do not exist.
  • Wrong lifecycle operations. A replace that points to a file never submitted, or a new file used for an update, which leaves two versions open at once.
  • Invalid names and metadata. File or folder names that break the naming rules, and missing regional information in Module 1.

A clean validation report is necessary but not sufficient. Validation checks structure, not science: a link can be technically valid and still lead to the wrong document, and a correctly placed file can still contradict its summary. Add a manual check of navigation and content.

What are the benefits of the eCTD?

Done well, the eCTD gives both the applicant and the reviewer practical advantages:

  • Version control. The backbone records what is current and what it replaced, so nobody has to guess which version the authority holds.
  • Searchability. Searchable PDFs and structured indexing help both sides locate a statement or a study without paging through printed volumes.
  • Review efficiency. A reviewer can follow a link from a summary to the underlying report and can tell which documents are new or updated compared with the last sequence.
  • Reuse. Unchanged documents are not resubmitted, and technical modules written for one authority are often reusable for another, once Module 1 is rebuilt.

These benefits depend on discipline. An eCTD with poor granularity, weak titles and broken links delivers little of this value.

How do regional Module 1 specifications affect an eCTD?

The eCTD is international only up to a point. Modules 2 to 5 follow the common ICH specification, but each authority publishes its own Module 1 requirements: which documents go where, how they are named, what metadata accompanies them and which validation criteria apply. A sequence built for one authority usually cannot be sent to another just by swapping the regional files.

Acceptance of electronic formats differs too. Some authorities require the eCTD for certain application types, some accept it as an option, some accept CTD-structured PDF files on electronic media without an XML backbone, and some still work mainly on paper. The specification itself exists in more than one version, including 3.2.2 and 4.0, and the newer one structures the backbone differently, so the version an authority accepts also matters.

For Egypt, the position of the Egyptian Drug Authority (EDA) on electronic submission, the formats it currently accepts and the technical requirements for your product category should be confirmed with the authority or through a regulatory consultant before you invest in a publishing set-up, because they can change over time. Preparing your CTD content in a clean, well-structured form keeps your options open either way.

Is your team ready for eCTD?

An eCTD is a team product: authors write the documents, a publisher builds the sequence and a reviewer checks it. Readiness is mostly a set of habits that start well before publishing:

  • Authoring templates. Documents written with real heading styles produce clean bookmarks. Documents formatted by hand do not.
  • Naming and granularity rules. Agree file titles, section placement and granularity before the first document is finalised.
  • Final content. Freeze documents before publishing, because every late change means re-linking and re-validating.
  • Software and skills. Choose tools that can build the regional Module 1 and validate against the authority's criteria, test them on a trial sequence, and train the people who author, publish and check.

Whether a team publishes in-house, uses an external publisher or combines the two, practical CTD and eCTD training lets it rehearse structure, publishing and validation before its first live submission.

How do you move from paper or PDF to eCTD?

The right moment is usually when the authority you deal with accepts or requires the eCTD, or when a new application or a run of variations gives you a natural starting point. A small project with clear steps works well:

  1. Confirm the target. Find out which formats the authority accepts today, for which application types, and whether a change is planned.
  2. Decide the scope. Many teams begin with new applications and upcoming sequences rather than converting every historic file. For an existing paper or PDF application, ask the authority whether it may continue electronically and whether it expects a baseline of the current dossier.
  3. Prepare content, tools and partners. Update templates, set granularity and naming rules, make sure source documents are final, searchable and unprotected, and select software or a publishing service that meets the authority's Module 1 and validation requirements.
  4. Run a pilot. Build and validate a test sequence from real documents, and review the findings with everyone involved.
  5. Plan the lifecycle. Map the sequences you expect over the product's life, including queries, variations and renewals, and keep the plan current.
  6. Make quality control routine. Combine technical validation with a manual check of links, titles and content before every release.

Next step: plan your eCTD with the right support

The CTD tells you what to submit and where it goes, and the eCTD tells you how to package and maintain it electronically. A clean eCTD depends on sound source documents, a planned lifecycle and careful validation, and requirements differ between authorities and change over time.

We publish eCTD sequences with Extedo software and support teams that publish in-house. Our eCTD publishing and submission service covers structure, lifecycle planning and validation, and our CTD dossier preparation service helps make sure the content going into each sequence is consistent. You can also talk to us about your submission plan.