Three weeks before a planned database lock, someone finally runs the comparison listing.
The clinical database shows 47 serious adverse events. The safety database shows 44. Two of the gaps are events a site downgraded to non-serious months ago without telling pharmacovigilance. The third is a hospitalization that was emailed to the safety desk and never entered in the eCRF. Each one now needs a query, a site response and a medical monitor review. The lock date starts to slide.
If that sounds familiar, the problem is rarely the software. SAE reconciliation fails because two teams keep two versions of the same event on two different clocks, and the comparison between them gets scheduled for the one moment when there’s no slack left to absorb what it finds. This guide covers why that happens, the discrepancies that keep coming back, and how to fix your SAE reconciliation process well before lock.
What Is SAE Reconciliation in Clinical Trials?
Serious adverse event reconciliation is the systematic comparison of SAE data in the clinical trial database (usually the EDC) against the same events in the sponsor’s safety or pharmacovigilance database. Every SAE should exist in both systems, and the key facts should either agree or differ for a documented reason.
The two systems serve different purposes. The clinical database feeds the statistical analysis and the CDISC SDTM AE domain that goes to regulators. The safety database feeds expedited reports, aggregate safety reviews and signal detection. When they disagree, one of your regulatory outputs is wrong, which is why SAE data quality is treated as a safety issue and not just a data cleaning task.
| Data point | Clinical database (EDC) | Safety database | Where mismatches usually start |
| Subject / case identifier | Subject ID | Case number, often without subject ID | Matching keys were never agreed at setup |
| Event term | Investigator verbatim on the eCRF | Narrative-derived term | Site enters a symptom; safety records a diagnosis |
| MedDRA coding | Coded by data management | Coded by safety | Different dictionary versions or LLT choices |
| Onset date | Date of first symptom | Date the event became serious | No shared definition |
| Seriousness criteria | Checkbox on the AE page | Full SAE form | Updated in one system only |
| Causality | Investigator assessment | Investigator and sponsor assessments | Comparing the wrong assessment |
| Outcome and end date | Last eCRF update | Last follow-up report | Follow-up sent to safety only |
Every row in that table is a place where two honest teams can hold two different truths.
Why SAE Reconciliation Usually Lands Right Before Database Lock
The short answer: the safety database runs on regulatory deadlines, and the clinical database runs on monitoring cycles.
Safety teams move fast because regulation requires it. Under 21 CFR 312.64(b), an investigator must immediately report any serious adverse event to the sponsor, whether or not it’s considered drug-related. The sponsor then has fixed windows to assess and report onward.
| Jurisdiction | Investigator to sponsor | Sponsor expedited reporting |
| United States (FDA) | Immediately, per 21 CFR 312.64(b) | No later than 15 calendar days for qualifying IND safety reports; 7 days for unexpected fatal or life-threatening suspected adverse reactions (21 CFR 312.32) |
| European Union (CTR) | Without undue delay, no later than 24 hours, unless the protocol exempts certain SAEs (Regulation (EU) No 536/2014, Art. 41) | SUSARs to EudraVigilance within 7 days (fatal or life-threatening) or 15 days (others), Art. 42 |
| India (CDSCO) | Initial report within 24 hours | Analysed report within 14 days under the New Drugs and Clinical Trials Rules, 2019 |
Nothing comparable forces the eCRF to keep pace. A site can send an SAE form to the safety desk on day one and complete the EDC page three weeks later, after the monitor’s next visit. Follow-up travels the same way: the discharge summary goes to safety, where the clock is ticking, and the eCRF waits. So the two databases drift, slowly and predictably.
Three structural habits make it worse:
- Reconciliation is written into the data management plan as a closeout activity. If the only scheduled comparison is “prior to database lock,” that’s when the backlog appears.
- Ownership sits between departments. Data management owns the EDC, pharmacovigilance owns the safety database, and the medical monitor owns the judgment calls. Without a named owner for the comparison, each team assumes another is watching.
- Vendors are split. When one party runs the EDC and another runs the safety system, SAE data reconciliation between CRO and sponsor depends on file transfers that someone has to remember to request.
SAE Reconciliation Challenges in Clinical Trials: Discrepancies That Keep Coming Back
Every study produces its own mix of clinical and safety database discrepancies, but the categories barely change.
| Discrepancy | Most common cause | Who usually resolves it |
| SAE in safety database, missing in EDC | Paper or email SAE form sent; eCRF never completed | Site, via CRA follow-up |
| SAE in EDC, missing in safety database | Seriousness box ticked on the eCRF but no SAE form submitted | Site and pharmacovigilance |
| Seriousness differs | Site downgraded or upgraded after new information and updated one system | Medical monitor with site |
| Onset date differs | Symptom date in one system, hospitalization date in the other | Data management, per agreed convention |
| Event term or coding differs | Different verbatims or MedDRA versions | Coders from both teams |
| Outcome or resolution date differs | Follow-up report sent only to safety | Site, via eCRF update |
Causality is the one teams most often “fix” when they shouldn’t. The sponsor makes its own causality assessment, and it can legitimately differ from the investigator’s. Reconciliation should compare the investigator’s assessment in the EDC against the investigator’s assessment in the safety case. Comparing it against the sponsor’s creates false discrepancies, and pressuring sites to change their opinion to match creates a data integrity problem of its own.
Onset date conflicts are almost always a definitions problem. If your conventions document doesn’t say whether onset means the first symptom or the date the event met seriousness criteria, two careful people will pick differently every time.
AE/SAE Coding Discrepancies
MedDRA, the ICH medical terminology used for adverse event coding, is released in updated versions twice a year. When the safety database upversions on one schedule and clinical coding follows another, the same verbatim can map to different preferred terms, sometimes under different system organ classes.
The fix is administrative. Agree on the study’s MedDRA version or upversioning rule, write it into both teams’ conventions, and compare at the preferred-term level, where legitimate coder variation is narrower.
Why Manual SAE Data Reconciliation Doesn’t Scale
On a small Phase I study, a spreadsheet comparison works. Export both listings, sort by subject and date, and read down the columns. It stops working as volume grows, and it stops quietly.
- Safety case numbers and EDC subject IDs don’t join cleanly, so matching depends on judgment.
- Free-text event terms rarely match character for character.
- Each export is a snapshot. By the time discrepancies are resolved, new SAEs have arrived.
- The spreadsheet becomes the reconciliation record, usually without an audit trail.
That last point matters more now. ICH E6(R3), published by FDA as final guidance in September 2025, puts weight on data governance, traceability and focusing quality effort on data that’s critical to participant safety. SAE data sits at the center of that. A reconciliation you can’t reconstruct is hard to defend at inspection.
SAE Reconciliation Best Practices: How to Fix It Before Database Lock
The goal is to make the final pre-lock reconciliation boring. That means moving the real work upstream.
1. Write one reconciliation specification that both teams use
The data management plan and the safety management plan should describe the same process in the same words: compared fields, matching keys, cadence, acceptable differences and the named owner. If the two documents disagree, the teams will too.
Add the safety case number to the eCRF SAE page at database build. It costs almost nothing and removes the most common matching headache.
2. Set an SAE reconciliation timeline that starts at first patient in
| Study stage | Suggested cadence | Scope |
| Enrollment, low SAE volume | Monthly | All SAEs received to date |
| Enrollment, high SAE volume | Every two weeks | New and updated cases |
| Before any DSMB or interim data cut | Full reconciliation | All cases, all compared fields |
| Last patient last visit | Full reconciliation | All cases, plus outstanding queries |
| Pre-lock | Confirmation pass | Should find nothing new |
Adjust this to your study. The principle holds either way: no discrepancy should be older than one cycle.
3. Define acceptable differences in advance
Some mismatches are correct: sponsor-upgraded seriousness, sponsor causality, and safety-only follow-up that isn’t collected on the eCRF. List them so reviewers stop raising them as findings.
4. Run reconciliation queries through one channel
Route site queries through the EDC, not email, so the question, the response and the data change sit in one audited place. Track query aging. Close a discrepancy only when source documents support it, and record which system changed and why. Discrepancies that sit in inboxes are how a three-week closeout turns into a six-week one.
On a new study, this specification belongs in the data management plan, which Weltrix’s data management team builds with sponsors before the first SAE arrives. You can see how that fits into the wider clinical data management services we provide, and how EDC data management services handle query management from setup to lock.
Can SAE Reconciliation Be Automated?
Partly. The split is fairly clear.
| Task | Automation fit | Why |
| Pulling listings from both systems on schedule | Strong | Pure data movement |
| Matching records on agreed keys | Strong, if keys exist | Fails without a shared identifier |
| Field-by-field comparison and flagging | Strong | Rules are explicit |
| Query generation and aging reports | Strong | Workflow, not judgment |
| Deciding which system holds the correct value | Weak | Needs source review and medical judgment |
| Judging whether a difference is acceptable | Weak | Depends on context and the specification |
Validated SAS or R programs, EDC-native tools and safety system integrations remove the eyeballing that makes manual reconciliation slow. Teams are also starting to look at AI-informed clinical data management for discrepancy flagging, though the same limit applies. A medical monitor and a data manager still have to agree on the right answer. At the point of resolution, pharmacovigilance reconciliation remains a clinical decision.
Automation also exposes weak setup. A program can’t match what was never designed to match. And since the clinical side of the comparison ends up in your submission, it helps to have programmers who understand how AE data flows into SDTM datasets involved when the matching rules are written.
How Weltrix Supports SAE Reconciliation
At Weltrix, SAE reconciliation is set up alongside EDC build, data validation specifications and MedDRA coding, so database lock is a milestone and not a crisis. That means the matching keys, compared fields, cadence and owner are agreed before the first SAE comes in, not negotiated in the last month. If you’re weighing up SAE reconciliation services for a study, or you’re inheriting a study where the two databases have already drifted, our biometrics CRO team can review your current process and tell you where the gaps are.
Frequently Asked Questions
Q. What is SAE reconciliation in clinical trials?
SAE reconciliation in clinical trials is the comparison of serious adverse event data in the clinical database against the sponsor’s safety database. It confirms that every SAE appears in both, and that event term, onset date, seriousness, investigator causality and outcome agree. Differences are corrected or documented as acceptable.
Q. What is the SAE reconciliation process?
In practice, the SAE reconciliation process has four parts: extract listings from both databases, match records on agreed keys, compare the agreed fields, then raise and close queries for anything that doesn’t agree. It’s repeated on a fixed schedule through the study, ending with a confirmation pass before lock.
Q. Why does SAE reconciliation usually happen so close to database lock?
Because many data management plans schedule it as a closeout task. The safety database updates quickly under regulatory reporting deadlines, while eCRF entry follows monitoring cycles. The two drift apart all through the study, and the gap only gets measured at the end.
Q. What are the most common causes of SAE reconciliation discrepancies?
The most common causes are SAEs reported to safety but never entered in the eCRF, seriousness changes recorded in only one system, inconsistent onset date definitions, and follow-up information sent only to the safety team. MedDRA version differences cause coding mismatches. Causality mismatches are often false alarms from comparing the investigator’s assessment against the sponsor’s.
Q. Who is responsible for SAE reconciliation?
Data management usually runs the comparison and pharmacovigilance supplies the safety data, with the medical monitor making judgment calls on what’s correct. The important part is that one named person owns the process. When ownership is shared between teams, nobody tracks it.
Q. How can sponsors avoid last-minute SAE reconciliation delays?
Reconcile on a fixed schedule starting at first patient in. Share one reconciliation specification between data management and pharmacovigilance, capture the safety case number in the EDC, fix the MedDRA versioning and onset date conventions at study start, and route discrepancy queries through the EDC.
Q. Can SAE reconciliation be automated?
Yes, in part. Extraction, record matching, field comparison and query tracking can be automated reliably once matching keys are defined. Resolving a discrepancy still needs human review of source documents and medical judgment.
Conclusion
SAE reconciliation breaks down before database lock for one reason more than any other: it gets deferred to the only point in the study where a discrepancy can delay everything else. Two databases on two clocks will always drift. Measure that drift monthly, with shared rules and a named owner, so the last comparison before lock returns an empty listing and a signature.
Key Takeaways
- SAE reconciliation compares serious adverse event data between the clinical and safety databases. Both feed regulatory outputs, so if they disagree, one of them is wrong.
- The two databases drift because safety reporting runs on legal deadlines (15 days under 21 CFR 312.32; 24 hours investigator-to-sponsor under EU CTR Article 41) while eCRF entry follows monitoring visits.
- Compare the investigator’s causality against the investigator’s causality. Sponsor assessments can legitimately differ.
- Agree on MedDRA version, onset date definition and matching keys before the first SAE is reported.
- Recurring reconciliation from first patient in turns the pre-lock pass into a confirmation.
- Automation handles extraction, matching and query tracking. Resolution still needs human judgment.


Leave A Comment