eCTD Validation Rules: The Complete 2026 Guide for Regulatory Teams

Every eCTD submission goes through automated validation before a reviewer ever opens it. Here is what validators check, what fails, and how to pass on the first try.

eCTD Validation Rules: A Technical Guide for Regulatory Operations

Every regulatory professional who has submitted an eCTD sequence knows the sinking feeling: a validation error appearing hours before a deadline, forcing a scramble to identify root causes, rebuild documents, and revalidate. Understanding eCTD validation rules at a technical level isn’t optional—it’s the difference between routine submissions and regulatory fire drills.

This guide breaks down what validation actually checks, where the rules come from, and how to prevent the failures that derail timelines.

What eCTD Validation Actually Means

eCTD validation is not a single check. It’s a layered verification process that confirms your submission package meets the technical requirements of target health authorities before you transmit. Validation operates across three distinct domains:

• XML schema validation: Confirms your index.xml and regional.xml files conform to the published DTD (Document Type Definition) and XSD schemas. This is syntactic validation—structure, element order, required attributes.
• Business rules validation: Applies health authority-specific logic to your submission content. These rules check things that schemas cannot: lifecycle sequencing, metadata completeness, cross-reference integrity, and regional requirements.
• Content checks: Validates the actual files within your eCTD—PDF specifications, file naming conventions, bookmark structures, hyperlink resolution, and checksum integrity.

A submission can pass schema validation while failing business rules. It can pass both while containing unreadable PDFs. Robust validation addresses all three layers.

The Two Validation Tiers

Tier 1: Schema and Structural Validation

Schema validation is the foundation. It parses your XML backbone against the ICH eCTD DTD (currently v3.2.2 for most regions, with v4.0 adoption in progress) and verifies:

• Well-formed XML syntax (no unclosed tags, proper encoding declarations)
• Element hierarchy matches DTD specifications
• Required attributes are present (operation, checksum, checksumType)
• File paths resolve correctly and follow naming conventions
• Stylesheet and DTD references point to valid locations within the package

Structural validation extends this to the physical file system: folder hierarchy, file naming patterns (lowercase, no special characters beyond permitted sets), and presence of mandatory files like index.xml at the root.

Tier 2: Business Rules Validation

Business rules encode the regulatory logic that schemas cannot express. These include:

• Lifecycle operations: You cannot “replace” a leaf that was never created with “new.” You cannot “delete” something already deleted.
• Sequence logic: Sequence numbers must be properly incremented. A sequence 0004 implies 0000–0003 exist.
• Cross-reference integrity: Internal hyperlinks must resolve to valid targets within the submission or prior sequences.
• Regional metadata: Module 1 administrative information must meet region-specific requirements (application numbers, submission types, contact information).
• Content standards: PDF version, font embedding, page size, bookmark depth, and navigational structure.

Major Validation Rule Sources by Region

Each health authority publishes its own validation criteria, and keeping current with updates is a continuous requirement:

• FDA (United States): The FDA eCTD Validation Criteria (often referenced as eCTDxRc) are implemented in their eValidator tool. FDA publishes updates quarterly, with criteria documents available on the FDA ESG website. Current rules address M1 specifications, study tagging files, and US-specific metadata.
• EMA (European Union): EMA validation criteria are published alongside the EU Module 1 specification. The eSubmission Gateway runs validation at the point of receipt, meaning failures result in rejected transmissions—not warnings.
• Health Canada: Publishes the Common Electronic Submissions Gateway (CESG) validation rules. Canada has specific requirements for Module 1 regional content and bilingual considerations.
• PMDA (Japan): Japanese eCTD validation includes specific requirements for Module 1.12 (Japanese-specific documents) and has historically required JP-specific DTD extensions.
• MHRA (United Kingdom): Post-Brexit, MHRA maintains its own validation criteria that largely mirror EMA but include UK-specific Module 1 requirements.

The challenge for global sponsors is that eCTD validation rules differ by region. A sequence valid for FDA may fail EMA validation, and vice versa. Multi-regional submissions require validation against each target authority’s criteria.

Severity Levels: Understanding Validation Output

Not all validation findings carry equal weight. Health authorities categorize issues by severity:

A common mistake is treating all warnings as ignorable. Some warnings—particularly around hyperlink failures or PDF issues—indicate problems that will frustrate reviewers even if they don’t trigger gateway rejection.

Top 10 Validation Failures and How to Fix Them

1. Missing or Malformed index.xml

Cause: The index.xml is absent from the root, contains syntax errors, or references an incorrect DTD path.
Fix: Validate XML syntax before package assembly. Ensure DTD reference matches the eCTD version in use.

2. Invalid Leaf Operation (Replace Without Prior New)

Cause: A leaf is marked “replace” but no prior sequence contains that leaf with operation “new.”
Fix: Review the cumulative submission backbone. Ensure lifecycle operations follow logical sequence: new → replace → delete.

3. File Naming Violations

Cause: Uppercase characters, spaces, special characters beyond allowed set, or paths exceeding length limits.
Fix: Implement automated file naming enforcement at document check-in. Standard pattern: lowercase alphanumeric, hyphens, underscores only.

4. Bookmark and Hyperlink Failures

Cause: Bookmarks missing from PDFs, hyperlinks pointing to non-existent files, or links broken during path restructuring.
Fix: Validate PDF bookmarks post-render. Test all hyperlinks after final package assembly, not before.

5. PDF Version or Font Issues

Cause: PDF version incompatible (e.g., PDF 2.0 where 1.4–1.7 required), fonts not embedded, or unsupported compression.
Fix: Standardize PDF creation settings. Validate PDF/A compliance or region-specific PDF requirements at authoring stage.

6. Stylesheet or DTD Path Errors

Cause: Relative paths in XML declarations that don’t resolve correctly within the package structure.
Fix: Verify util folder contents and path references. Test package on a clean machine before submission.

7. Module 1 Metadata Missing

Cause: Required regional administrative information incomplete—submission type, application numbers, or contact details absent.
Fix: Use region-specific Module 1 templates. Validate regional.xml separately against regional schemas.

8. Sequence Numbering Gaps

Cause: Submitting sequence 0004 when 0003 doesn’t exist in your cumulative backbone.
Fix: Maintain a centralized submission tracking system that prevents out-of-sequence publishing.

9. Empty or Duplicate ectd:title

Cause: Leaf titles left blank or identical titles across multiple leaves at the same level.
Fix: Audit leaf titles for uniqueness and descriptive value. Many validators flag duplicates as warnings.

10. File Hash Mismatches

Cause: The MD5 checksum in the XML doesn’t match the actual file content—usually because the file was modified after XML generation.
Fix: Generate checksums at final package assembly, never before. Implement file-locking during build process.

Preflight vs. Final Validation

Preflight validation runs during document preparation, before the eCTD package is assembled. It checks individual components: PDF compliance, file naming, document-level issues. Preflight catches problems when they’re cheap to fix—while authors still have context and source files are accessible.

Final (gateway) validation runs on the complete, assembled eCTD package. It validates XML backbone integrity, cross-references, lifecycle logic, and the full submission against health authority criteria. Final validation catches integration issues invisible at the document level.

The distinction matters operationally. An organization running only final validation discovers PDF problems after the package is built, requiring disassembly, re-rendering, and reassembly. Organizations running preflight validation catch those issues days earlier.

The Economics of Early Validation

Catching a validation error during preflight takes minutes to resolve. Catching the same error during final validation—after sequences are numbered, stakeholders have signed off, and gateway transmission is imminent—can cost days of rework.

In deadline-driven regulatory operations, one hour of preflight validation routinely prevents two or more weeks of downstream schedule disruption. The ROI isn’t theoretical; it’s measured in avoided expedite fees, reduced weekend work, and preserved submission windows.

Integrated Validation in Modern Publishing Platforms

Legacy regulatory publishing workflows treat validation as a separate step: build the package, export it, run it through a validator, review the report, fix issues, rebuild, re-export, re-validate. Each cycle introduces delay and error potential.

Modern publishing platforms—including DnXT—integrate eCTD validation rules directly into the build process. Validation runs continuously during sequence assembly, flagging issues as they’re introduced rather than after the fact. This shifts validation from a quality gate to a quality process.

DnXT’s validation engine supports both preflight (document-level) and final (package-level) validation against FDA, EMA, Health Canada, and other regional criteria. Rules are updated as health authorities publish new criteria, without requiring manual configuration from your team.

Free Validators vs. Commercial Validators

Free validators (including FDA’s publicly available tools) provide baseline validation against published criteria. They’re useful for confirming compliance after packaging and are the definitive reference for what the gateway will accept.

Commercial validators (standalone or platform-integrated) add value through:

• Multi-regional validation in a single pass
• Deeper PDF content inspection
• Preflight capabilities for early issue detection
• Integration with publishing workflows to eliminate manual steps
• Enhanced reporting and audit trails

For occasional submissions, free validators may suffice. For ongoing regulatory operations, commercial validation integrated into your publishing platform reduces cycle time and operational risk.

Frequently Asked Questions

How often do health authorities update their eCTD validation rules?

FDA typically updates validation criteria quarterly. EMA updates align with EU Module 1 specification releases, usually annually but with occasional interim updates. Regulatory publishers should monitor HA websites and subscribe to notification lists to stay current.

Can a submission fail validation at the gateway even if it passed my local validator?

Yes. This typically occurs when your local validator uses outdated criteria, or when the gateway has additional checks not fully documented in public criteria. Always validate against the most recent published criteria before submission.

What’s the difference between ICH eCTD validation and regional validation?

ICH eCTD validation covers the common technical document structure (Modules 2–5) and core backbone specifications. Regional validation adds region-specific requirements, primarily for Module 1 administrative information. Both must pass for successful submission.

How should we handle validation warnings versus errors?

Errors must be resolved—they typically result in gateway rejection. Warnings require review and judgment. Document your rationale for any warnings you choose not to address, as reviewers may question them.

Does DnXT keep validation criteria current automatically?

Yes. DnXT maintains validation rules for FDA, EMA, Health Canada, and other supported regions. When health authorities publish updated criteria, DnXT updates the validation engine—typically before the new rules become mandatory—without requiring customer action.