PointCross Life Sciences has standardized nonclinical study data for FDA and PMDA submissions since 2009, and in that time one pattern has repeated itself across sponsors of every size: the submission package clears the validator, the team exhales, and six weeks later an FDA reviewer flags the data as unusable. The validator was never designed to catch the problem. The problem lives in the architecture underneath.
The FDA’s March 2026 Study Data Technical Conformance Guide (TCG v6.2) now dedicates an entire appendix, Appendix I, to SEND data verification best practices prior to submission. It organizes the most common usability failures into three categories, and only one of them is what your conformance validator checks. The other two sit in places automated tools cannot reach: submission-level packaging errors and data representation failures where the SEND dataset and the study report tell two different stories.
This article examines why those failures are structurally predictable, what FDA and PMDA actually expect before your data reaches a reviewer, and where the architecture of your validation workflow determines whether a submission survives first contact with the agency.
What does FDA’s 2026 Technical Conformance Guide actually require for SEND verification?
Appendix I of the March 2026 TCG establishes minimum verification practices that go well beyond running a conformance check. A submission-ready SEND package must satisfy five criteria: full traceability from every value in the SEND dataset back to both the study raw data and the study report; accurate representation of the study design in the trial design datasets (TE, TA, TX, DM); reproducible group-level analyses that match the study report summary tables for both quantitative endpoints and qualitative incidence counts; documented completeness covering every endpoint within the scope of the applicable SENDIG version; and a complete nonclinical Study Data Reviewer’s Guide (nSDRG) that explains the multi-step process by which SEND was created.
Meeting this standard through informal spot checks is not sufficient. Meeting it requires structured, documented reconciliation completed before submission. The TCG is explicit: SEND submitted with certain errors is classified as unusable, meaning reviewers will not attempt to work with the data or send it back with a request for correction.
For regulatory operations teams managing submission timelines, this changes the calculus. The question before any nonclinical submission is no longer whether the validator passed. It is whether every value in the SEND package tells the same story as the study report, and whether you have documentation to prove it.
Why do SEND datasets pass validation but fail review?
Conformance and quality are different things, and the distinction explains most submission delays.
Conformance means the dataset follows the structural rules of the SEND Implementation Guide: correct variable names, correct data types, required fields populated, valid controlled terminology applied. Automated validators, including the FDA’s own eCTD validation criteria (Technical Rejection Criteria codes 1734, 1735, and 1736), test for conformance. A SEND package can pass every conformance rule and still contain errors that only surface when a reviewer attempts to use the data.
Quality means the dataset accurately and completely represents the study that was actually conducted, as described in the final study report. No automated tool tests for this. It requires human-driven, structured reconciliation.
The March 2026 TCG names the specific failure modes that validators cannot touch. Group summary means in SEND that do not match the summary tables in the study report. Incorrect set definitions where terminal and recovery animals are placed in the same set. Qualitative incidence counts that cannot be reproduced from the SEND data. Multiple records for the same animal, endpoint, day, and timepoint with conflicting values.
These are not edge cases. They are the most common cause of SEND being classified as unusable by FDA reviewers. A body weight that reads 245g in your SEND file but 254g in your study report raises questions about your entire data management process.
Where does metadata drift create traceability risk in multi-region submissions?
For sponsors filing in both the United States and Japan, the metadata layer is where validation diverges and where traceability risk compounds.
Both the FDA and PMDA use Pinnacle 21 Enterprise as the core validation engine. But they do not treat the results the same way. The FDA has deprecated formal severity classification. Its expectation is straightforward: every unresolved issue must be explained. PMDA maintains a strict severity hierarchy of Reject, Error, and Warning, and enforces it at the gateway level. Reject-level findings stop review entirely. PMDA will not begin or continue review when Reject issues are present.
The operational consequence is that PMDA submissions require a more rigorous documentation layer than FDA submissions. The PMDA reviewer guide must include the validation tool and version, the engine version explicitly named, the rule version, and for each unresolved finding, the rule ID, severity, and justification.
Metadata drift enters the picture when submissions are delayed. PMDA publishes acceptable rule versions tied to submission windows. If your validation engine is no longer acceptable at submission time, validation must be rerun, findings must be reassessed, and the reviewer guide must be updated. This is a re-validation requirement, not a documentation update.
For multi-study programs, PMDA expects one validation engine version across the entire application. If Study A was validated with PMDA engine 2211.1 and Study B with PMDA engine 2311.0, someone must reconcile that before submission. It does not fix itself.
The PharmaSUG 2026 paper on multi-region filings underscores the practical challenge: the ‘global core’ dataset strategy works at the data layer, but the validation and documentation layers must be managed per-region. Building nonclinical data to FDA SEND standards gives you a machine-readable foundation, but that foundation only holds if the metadata, controlled terminology version, define.xml, and reviewer guide are synchronized to each agency’s current requirements at the time of filing.
What makes the traditional SEND workflow structurally prone to discrepancies?
The conventional workflow is where most validation failures originate, and understanding its architecture explains why the failures are predictable rather than random.
In the traditional model, the Study Report and the SEND dataset are generated by two completely separate teams, running two completely separate processes, from the same underlying study data, but without a shared data model connecting them. The Study Report team finalizes the report, and then the SEND team begins. They extract, re-integrate, and rebuild what was already built once.
This creates three compounding problems. First, timeline inflation. SEND generation begins only after the Study Report is complete, so the total submission package timeline stacks sequentially: roughly four to five weeks for the Study Report, followed by another four to six weeks for SEND generation and QA. That is eight to ten weeks total for a package that could theoretically be completed in half that time if both processes ran concurrently from shared data.
Second, duplicated integration effort. Protocol metadata, LIMS data, non-LIMS sources (bioanalysis, ADA, FACS, omics, ECG, immunology markers), and Study Report methods sections all have to be extracted and interpreted independently by both teams. Every step of that duplication is an opportunity for divergence.
Third, reconciliation cost that reflects structural risk. Mechanically comparing the SEND dataset against the study report, which includes digitizing the PDF, extracting summary tables, and harmonizing terminology to CDISC controlled terminology, accounts for a significant portion of total SEND generation cost in conventional workflows. That cost exists precisely because the two processes created inconsistencies that now have to be found and fixed.
When two independent teams work from the same source data without a shared data model, inconsistency is a structurally expected outcome. PointCross Life Sciences addresses this by generating both the Study Report and the SEND dataset concurrently from a single Universal Data Model (UDM), a canonical data source that eliminates the structural conditions for divergence before a single domain file is produced.
How does controlled terminology drift cause validation failures across SENDIG versions?
Controlled terminology is one of the quieter sources of submission delays, precisely because the failures look minor on the surface but cascade through the validation layer.
The FDA expects you to use the controlled terminology version that matches your SENDIG version. A term that was acceptable under a previous terminology release may have been deprecated or replaced. Free-text entries or outdated terms where the standard expects a specific codelist value create validation failures. For non-extensible codelists, PMDA treats a value not found in the codelist as a Reject-level issue, meaning submission stops until correction.
The operational challenge is version mapping. The required SENDIG version depends on your study’s start date and type, not the date you submit. SENDIG v3.1.1 is the current baseline for general toxicology and carcinogenicity studies started after March 15, 2023. SENDIG-DART v1.1 covers embryo-fetal development studies, required for NDAs since March 2023 and for INDs since March 2024. SENDIG-Genetox v1.0, covering in vivo micronucleus and comet assay data, became required for studies starting after March 15, 2025.
Using the wrong version, or mixing versions across a submission, creates conformance findings that delay approval. Map each study to the correct SENDIG version before you begin dataset creation, and document this mapping in your nSDRG.
CDISC projects SENDIG v4.0 publication for Q4 2026, introducing domains for immunogenicity, cell phenotyping, and ophthalmology data. Because publication dates can shift during public review, confirm the active requirement against the FDA Data Standards Catalog before you lock your approach.
What does a validation workflow built for submission readiness actually look like?
Sponsors and CROs managing multiple studies need a repeatable validation process. Ad-hoc checking introduces inconsistency and leaves gaps that surface at the worst time.
A submission-ready workflow has three structural properties. First, it centralizes metadata governance so that your validation baseline stays stable across studies. PointCross Life Sciences’ Xbiom Metadata Repository (MDR) automates metadata management and enforces consistency across the data lifecycle, serving as the foundation for SDTM, ADaM, and SEND output generation.
Second, it defines clear checkpoints: after data lock, after dataset generation, and before final submission packaging. Validation runs at each stage rather than only at the end. The eDataValidator (eDV) from PointCross validates clinical SDTM and ADaM as well as nonclinical SEND datasets against FDA and PMDA rule sets in a single tool, providing a single solution for IND, NDA, and BLA preparation.
Third, it builds reconciliation into the generation process rather than treating it as a downstream QC step. When your study report and SEND datasets draw from the same data source and generate simultaneously, alignment happens by design rather than by manual comparison. PointCross Single Track Processing delivers both deliverables from one governed data model, eliminating the sequential handoff that creates divergence and cutting the post-data-lock timeline by two weeks or more.
For sponsors who receive SEND from an external vendor and need verification before filing, SEND-ASSURE provides an independent quality audit. It compares the submitted SEND dataset against the final study report across every domain, using independently regenerated reference files as the comparison baseline. Discrepancies have nowhere to hide because the comparison baseline is built independently rather than derived from the dataset under review.
How should regulatory operations teams prioritize their validation investments?
The FDA’s 2026 TCG and PMDA’s documentation requirements point in the same direction: the era of treating validation as a conformance checkbox is ending. Both agencies now expect sponsors to demonstrate that their submission data is not just structurally compliant but scientifically traceable and reviewer-ready.
For regulatory operations and data management leaders, three priorities emerge. First, assess whether your current process generates the study report and SEND dataset from a shared data source or from parallel, disconnected processes. The architecture of the workflow determines the probability of discrepancy before any QC step runs. Second, audit your controlled terminology governance. If your team is not tracking CT version alignment across studies, SENDIG version mapping, and define.xml consistency as part of the submission preparation process, you are absorbing risk that surfaces at the point of least recovery. Third, evaluate your reconciliation process. If reconciliation is a manual comparison step that happens after SEND generation is complete, you are spending time and cost fixing problems that a concurrent workflow would not have created.
PointCross Life Sciences has processed over 10,000 nonclinical studies for FDA and PMDA submission. The Xbiom platform, SEND-ASSURE, and eDataValidator together address the full lifecycle from data ingestion through validated, reconciled, submission-ready delivery. The operational question is not whether your data will be reviewed. It is whether your data will survive review without a request for correction that costs your program weeks it cannot afford.