Common eCTD Validation Errors: Diagnose, Fix and Retest

This guide addresses selected technical problems using current FDA CDER/CBER criteria. “Common” describes recognizable troubleshooting categories; no submission dataset establishes their frequency or ranking here. The examples are synthetic applications of real rules, with expected correction and rerun outcomes. They are not executed vendor reports or evidence of agency acceptance. Sources were checked September 14, 2026.

Start with the finding and the exact input

Preserve the original report and candidate package. Record the rule code and message, affected file or XML location, tool release, authority/version profile, criteria revision and relevant settings. Also record whether the message came from a local validator, a publishing application or an agency response.

If the report only says “invalid submission,” request its detailed log before selecting a remedy. If the input or configuration cannot be reconstructed, reproduce the check under a recorded setup. Do not guess a root cause from a generic label or compare a local report with an agency response without confirming that they describe the same submission.

Use the eCTD validation guide for the broader preparation and release process. The lookup below starts the narrower job of diagnosing an observed error.

Current FDA error lookup: choose the correct version

FDA lists criteria 4.6 for eCTD 3.2.2 and criteria 1.6 for eCTD 4.0, both with support beginning August 28, 2026. The respective PDF revision histories say August 17, 2026 and August 2026. These are criteria versions, not interchangeable eCTD formats or vendor releases. FDA 3.2.2 standards, FDA 4.0 standards

Preserve these source labels instead of assigning every category a generic “Critical” rating. Individual rules also have effective dates: FDA's 3.2.2 document explains TBD status, and the 4.0 list includes rules such as eCTD4-085 whose effective date remains TBD. A rule's presence in a posted document does not establish an active agency rejection condition. 3.2.2 effective-date definition, 4.0 eCTD4-085

This is a selected FDA lookup, not a global rule catalogue. For another authority, obtain its current criteria and preserve its severity terminology. If a vendor code differs from the source code, obtain the mapping rather than treating similar wording as proof of equivalence.

Missing file or wrong reference? Diagnose 1323 and 1306

These findings describe opposite sides of the file/reference relationship. A reference can point to an absent file, and a present file can lack a reference. FDA's corrective descriptions distinguish actual omission from a mismatch between the referenced filename and the file supplied. Criteria 4.6, 1306 and 1323

Start with a pre-submission candidate, P0, intended for FDA eCTD 3.2.2. The approved output is study report 101, and no other leaf references that report in this example. The following worksheet shows only the relevant basenames within one controlled study folder; it is not a complete package or a proposed directory specification. In the actual investigation, retain the full relative paths and the originating leaf/XML location.

The reference does not match the intended file. This supports the missing-target condition described by 1323; the unreferenced file may also produce 1306, depending on the checks performed. Two messages can arise from one mismatch. Their count does not establish two independent document defects.

The discriminating evidence is the approved output identity plus the directory and reference comparison. In this example, correct the publishing reference to csr-101.pdf and produce P1. Do not create an empty csr-110.pdf merely to satisfy the reference. Do not delete the approved report to eliminate an unreferenced-file message.

Now change the facts. Suppose the leaf correctly names csr-101.pdf, but that file is absent from the candidate. Inspect the export inventory and source approval. If the required approved output was omitted, restore that output through the publishing process. Renaming another study's report would make a path resolve while introducing a content-identity error.

A third possibility is that the operator checked the wrong root folder or a partial extraction. Compare the actual selected input with the complete candidate inventory before changing either the reference or document. If the full candidate contains the target at the correct referenced path but the validator received only a subset, fix the intake and repeat the check on the intended package.

For P1, verify the intended report is present and referenced, then rerun the same applicable checks with the relevant settings retained. Expect the 1323 finding for this target, and any associated 1306 finding for this file, not to recur after the mismatch is corrected. Inspect navigation and integrity checks affected by rebuilding. If the finding remains, capture the exact reference, resolved path, input root and file identity for escalation. These are expected observations to obtain, not results of a test performed for this article.

XML syntax failure is not the same as schema failure

For eCTD4-001, begin with the parser's location and the actual XML bytes. For eCTD4-002, inspect the schema diagnostic and the configured schema package. A well-formed message can still violate the schema. Correcting a parser error therefore does not establish that the message satisfies the next check. FDA 4.0 XML message criteria

For example, a literal ampersand in ordinary XML text must be escaped appropriately. The text fragment Research & Development differs from Research & Development in serialized XML. W3C XML 1.0, section 2.4

These are syntax illustrations, not complete eCTD messages or approved field values. Find which source field or export operation produced the bad serialization and correct that boundary; avoid repeatedly hand-editing each published output.

After republishing, expect the original syntax problem to be resolved while schema and applicable business checks remain active. A schema error becoming visible after parsing succeeds is not necessarily a new regression: the earlier parse failure may have prevented the later check from completing. Inspect the logs to establish what actually ran.

For 3.2.2, use its own XML and DTD context. Do not search every package for a universal backbone.xml file or apply a 4.0 schema to an older-format input. The XML backbone guide provides structural background for that distinction.

Checksum mismatch: establish which bytes should be present

The lookup shows why “checksum error means immediate rejection” is too broad: 1374 and eCTD4-064 carry different version-specific classifications. Diagnosis still starts with the approved file, the file checked and the digest recorded for it.

Compare those identities before regenerating integrity metadata. If an unapproved edit changed the output, merely recomputing its checksum can conceal the deviation from the approved source. Restore or approve the correct content through the responsible workflow, then regenerate and check the candidate as appropriate.

If the approved file's bytes are correct but the recorded checksum is wrong, inspect how the publishing process selected the file and generated the value. If the local and transferred copies differ, preserve both and investigate the transfer or later modification. The mismatch alone does not identify antivirus, compression or a particular application as its cause. Do not disable security controls as a generic correction.

Retain the affected file identities, applicable algorithm, recorded value, independently calculated value and relevant event timestamps. For an already submitted package, follow the agency's actual finding and version-specific corrective instructions; pre-submission rebuilding is not a universal post-submission remedy.

PDF, navigation and content findings need different evidence

For a PDF finding, inspect the named document and setting rather than rebuilding every PDF. FDA's current linked PDF specifications are version 4.1; they accept PDF 1.4–1.7, PDF/A-1 and PDF/A-2, and address security and reviewability. A generic “PDF/A” label or an old three-region comparison table cannot establish the applicable requirement. FDA PDF specifications

For a broken link, record the source document, page, target and destination. Distinguish an absent file from an absent named destination, changed pagination or a reference to the wrong version. After correction, open the intended destination in the assembled output. A successful file open alone does not establish that it is the correct study or passage.

For a naming or length finding, record the complete value and the rule's counting boundary. Filename length and full path length are different checks. A long-looking basename without its path cannot prove a path-limit violation. Use the file-naming reference for detailed scope rather than shortening unrelated files until the message disappears.

For a summary/body inconsistency, compare approved sources, population, units, cutoff and document version. Different values can be intentional; identical values can both be wrong. Route the issue to the qualified content owner. A technical package repair cannot determine scientific completeness or prevent every later review question.

Prove that the correction worked with the check still active

Keep P0 and its configuration as the failure record. Compare each follow-up with the original operation, not merely the number of messages displayed.

A display filter and a disabled check are also different. Removing a filter may reveal an existing finding without changing the package. Enabling a previously disabled check changes execution coverage. Record both settings so the reviewer can distinguish a genuine correction from a presentation change.

Keep related checks active after the fix: reference resolution, file identity, integrity and the applicable XML/lifecycle checks. Preserve the corrected source, revised output, new report and disposition together. The scope of closure is the demonstrated defect; it is not a guarantee of agency acceptance or scientific approval.

Use the eCTD software proof-of-concept pack to retain the expected result and operator actions across demonstrations.

Escalate with evidence when the diagnosis remains unresolved

Send the responsible publishing or support owner the exact rule/message, authority/format, criteria and software versions, input identity, relevant paths or XML location, and the smallest permitted evidence that reproduces the issue. Include the observed before/after behavior and configuration differences. Identify what you expected and which source supports that expectation.

If the message came from an agency, retain the agency response and submission identifiers. FDA describes center checks after retrieval from ESG, followed by eCTD-tool checking; a local vendor report is a separate record. Resolve the actual agency finding through the appropriate regulatory owner. FDA technical-processing overview

Assyro publishes this guide. For eligible FDA eCTD 4.0 work, discuss a scoped validation evaluation using the failure record and expected correction. Assyro does not currently support eCTD 3.2.2; retain a supported tool or publishing service for that requirement. Any proposed product must demonstrate the exact input and checking workflow before you rely on it.

The validator evaluation protocol helps compare whether candidate tools preserve the input, finding and corrected rerun evidence. For an eligible v4.0 use case, bring the input and finding to an Assyro eCTD validation evaluation; an existing v3.2.2 requirement needs a tool that supports that format.