An eCTD submission is technically compliant when it meets the structural, formatting, and validation requirements defined by the relevant regulatory authority, allowing the submission to be received, parsed, and reviewed without technical errors. Compliance covers everything from the XML backbone and document hyperlinks to file naming conventions and module organization. The sections below address the most common questions regulatory teams have about achieving and maintaining that compliance.
What are the technical requirements for an eCTD submission?
An eCTD submission must conform to the ICH M8 guideline, which defines the electronic Common Technical Document standard. This includes a valid XML backbone, correctly structured modules (1 through 5), PDF documents formatted to specification, functioning hyperlinks, and file names that follow the prescribed naming conventions. Every element must be consistent with the relevant regional implementation guide.
Beyond the backbone, technical requirements include:
- PDF specifications: Documents must be text-searchable, use embedded fonts, and meet resolution standards. Scanned images without an OCR layer are generally not acceptable.
- Hyperlinks: Internal cross-references within documents and links between the table of contents and individual files must all resolve correctly.
- File naming: File names must follow the authority-specific naming rules, avoiding special characters, spaces, or names that exceed character limits.
- Sequence numbering: Each submission sequence must be numbered correctly and consistently with prior sequences in the application lifecycle.
- Leaf attributes: The XML backbone must accurately reflect the operation type (new, replace, append, delete) for each document leaf.
Regional implementation guides from the EMA, FDA, and other authorities add further layers of specificity on top of the ICH M8 foundation, so teams must always consult the authority-specific guidance alongside the international standard.
What is the eCTD validation process and who performs it?
The eCTD validation process is a structured technical check that verifies a submission package against published validation criteria before it reaches the regulatory authority. Validation is performed first by the publishing team using eCTD publishing software, and then again by the regulatory agency upon receipt. A submission that fails agency-side validation may be rejected without review.
Validation criteria are published by each regulatory authority and cover hundreds of individual criteria, grouped into error levels. At the EMA, the validation criteria are maintained in a publicly available document and updated periodically. At the FDA, the Technical Rejection Criteria and validation rules are published by CDER and CBER. Errors flagged as “critical” or “rejection criteria” must be resolved before the submission is considered technically acceptable.
The internal validation step is where most issues should be caught. Publishing teams run the compiled sequence through validation software, review the report, resolve any flagged errors, and revalidate before dispatch. A clean validation report does not guarantee a flawless review, but it eliminates the most common technical barriers to acceptance.
What are the most common eCTD technical errors that cause rejection?
The most common technical errors that cause eCTD rejection include broken hyperlinks, incorrect XML backbone structure, invalid leaf operations, non-compliant PDF formatting, and incorrect sequence numbering. These errors are consistently flagged across both EMA and FDA submissions and are largely preventable with thorough pre-submission validation.
Specific errors that regularly appear in rejection notices include:
- Broken or missing hyperlinks: Links that point to files that have been renamed, moved, or deleted after the hyperlinks were created.
- Non-searchable PDFs: Documents that were scanned without OCR processing, making them image-only files that cannot be searched or annotated.
- Incorrect leaf operations: Using a “new” operation for a document that should reference or replace a prior document in the application history.
- Oversized files: Individual files or the overall package exceeding the authority’s file size limits.
- Incorrect module placement: Documents placed in the wrong module or section of the eCTD hierarchy, which disrupts the reviewer’s navigation.
- Outdated DTD or stylesheet: Using a document type definition or stylesheet version that the authority no longer accepts.
Many of these errors stem from manual steps in the publishing workflow, such as editing documents after hyperlinks are set or restructuring folders after the backbone has been built. A consistent, sequenced publishing workflow reduces the risk significantly.
How does eCTD compliance differ between the EMA and FDA?
eCTD compliance at the EMA and FDA shares the same ICH M8 foundation but diverges in regional implementation requirements, submission portals, validation criteria, and Module 1 structure. Teams submitting to both authorities must maintain separate, authority-specific sequences and cannot simply reuse the same package without adaptation.
EMA-specific requirements
EMA submissions are made through the eSubmission Gateway or the Common European Submission Portal (CESP). The EMA publishes its own eCTD validation criteria and requires compliance with EU-specific Module 1 content, including the application form, cover letter, and regional administrative documents. The EMA also mandates specific file naming conventions and has requirements around the use of the EU regional backbone.
FDA-specific requirements
FDA submissions are made through the Electronic Submissions Gateway (ESG). The FDA’s technical rejection criteria are distinct from the EMA’s validation criteria and are reviewed separately by CDER and CBER. The FDA has specific requirements for the study tagging file (STF), granularity of document leaves, and the use of standardized data formats such as CDISC for clinical study data. Module 1 content at the FDA follows US-specific administrative requirements.
For companies running parallel regulatory submissions, the practical approach is to build the common technical modules (2 through 5) to the highest shared standard, then create authority-specific Module 1 packages and sequences for each market. Maintaining clear version control across parallel dossiers is essential to avoid cross-contamination of authority-specific content. If you would like to learn more about how we approach multi-authority submissions, visit our regulatory services overview.
What tools and software support technically compliant eCTD publishing?
Technically compliant eCTD publishing is supported by dedicated eCTD authoring and publishing software that automates backbone generation, validates against current criteria, and produces submission-ready packages. Widely used platforms include Veeva Vault RIM, EXTEDO eCTD Manager, DocuBridge, and Lorenz docuBridge, among others. The right tool depends on submission volume, budget, and integration needs.
Key capabilities to look for in eCTD publishing software include:
- Built-in validation against current EMA and FDA validation criteria
- Automated XML backbone generation and leaf management
- Hyperlink checking and repair tools
- Lifecycle management to track prior sequences and operations
- Integration with document management systems to reduce manual file handling
- Audit trails for regulatory compliance purposes
Software alone does not guarantee compliance. The tool must be configured correctly, kept up to date with the latest validation criteria releases, and operated by staff who understand both the technical requirements and the submission context. Outdated validation criteria in a publishing tool are a common source of errors that pass internal checks but fail at the agency.
When should a regulatory affairs team involve an eCTD specialist?
A regulatory affairs team should involve an eCTD specialist when preparing a first submission to a new authority, managing a complex lifecycle with multiple prior sequences, recovering from a technical rejection, or when internal publishing capacity is insufficient for the submission timeline. Early involvement prevents costly errors and delays. To understand the full range of expertise our team brings to these situations, take a look at our company background.
Specific situations where specialist support adds clear value include:
- First submissions: Setting up the initial sequence correctly establishes the application lifecycle foundation. Errors at this stage can propagate through every subsequent submission.
- Technical rejections: Diagnosing and correcting the root cause of a rejection requires both technical publishing knowledge and an understanding of the authority’s specific validation logic.
- Legacy dossier migrations: Converting paper or non-eCTD submissions to eCTD format requires careful reconstruction of the application history.
- Parallel submissions: Managing simultaneous submissions to multiple authorities with different requirements benefits from a specialist who knows each authority’s current expectations.
- Capacity gaps: When internal teams are stretched across multiple projects, outsourcing eCTD publishing maintains quality without delaying timelines.
The cost of involving a specialist early is almost always lower than the cost of a delayed submission or a technical rejection that pushes back a review clock by weeks or months.
How Starodub supports technically compliant eCTD submissions
We support biopharmaceutical and medical device companies at every stage of the eCTD submission process, from initial dossier setup through lifecycle management and technical troubleshooting. Our regulatory affairs team combines deep knowledge of EMA and FDA technical requirements with hands-on publishing experience, ensuring that every submission we handle meets current validation criteria before it reaches the authority.
Our eCTD support includes:
- Full eCTD publishing and validation for new applications, variations, and renewals
- Authority-specific adaptation for EMA, FDA, and other markets
- Technical rejection analysis and remediation
- Legacy dossier conversion and lifecycle reconstruction
- Regulatory submissions strategy and pathway guidance for complex products including biologics, ATMPs, and combination products
- Single point of contact backed by a multidisciplinary team with short reporting lines
Whether you need support for a single submission or ongoing publishing capacity across a product portfolio, we are ready to help. Contact Starodub today to discuss how we can ensure your next regulatory submission is technically compliant from the first sequence.
Related Articles
- How does GMP compliance differ between FDA and EMA standards?
- What is the difference between GMP compliance and GMP certification?
- How to Build and Maintain a Quality Management System for Medical Devices
- Annex XVI Products Under MDR: What Non-Medical Devices Need to Know
- How do you navigate medical device regulations for combination products?
This content was generated with the help of AI and it may contain mistakes
