Reconciliation is the quality control activity that confirms data held in two different systems agrees before a clinical trial database is locked. Throughout a trial, data about the same participant is collected and stored in more than one place — the clinical database, a separate safety database, a central laboratory system, and various external vendor systems. Reconciliation is the disciplined comparison that makes sure these independent records tell the same story.
It is one of the most important safeguards against a locked database that looks complete but contains contradictions. This guide explains what reconciliation involves, why it matters, and how the three most common types — serious adverse event (SAE), laboratory, and external vendor reconciliation — are carried out in practice.
What is reconciliation in Clinical Data Management?
Reconciliation is the process of comparing two datasets that should contain the same information and identifying, investigating, and resolving any differences between them. In clinical data management it almost always means comparing data in the clinical database — the electronic data capture (EDC) system where site-entered data lives — against data held in another system that received or generated the same information independently.
The reason this is necessary is structural. A serious adverse event, for example, is recorded by the site in the clinical database and also reported into a separate pharmacovigilance safety database, often through different routes and by different people. Both records describe the same event, but nothing guarantees they match. Reconciliation closes that gap before the data is used for analysis.
The three most common types of reconciliation in clinical data management compare different systems but follow the same logic:
| Type | What is compared | Key fields | How discrepancies are resolved |
|---|---|---|---|
| SAE reconciliation | Clinical database (EDC) and safety (pharmacovigilance) database | Subject ID, event term, onset date, seriousness, outcome, causality | Query to the site, or an update to the safety case by drug safety |
| Lab data reconciliation | Clinical database and central or other third-party laboratory data | Subject ID, visit, sample collection date and time, accession number | Query to the site, or a correction request to the laboratory |
| External vendor (third-party) data reconciliation | Clinical database and vendor data such as IRT, ePRO/eCOA, ECG or imaging | Subject ID, visit, dates and the shared variables named in the data transfer specification | Query to the site, or a data change request to the vendor |
Why reconciliation matters
The integrity of a trial's conclusions depends on internal consistency. If the safety database lists an event as fatal while the clinical database records the participant as recovered, that contradiction must be found and resolved — not discovered by a regulator after submission. Reconciliation directly supports the ALCOA+ principles of accurate and consistent data, and unresolved discrepancies between systems are a recurring source of inspection findings.
Reconciliation is also a prerequisite for database lock. Declaring a clean file means confirming that data collection, cleaning, consolidation, and reconciliation are complete and that any residual issues are documented and accounted for. A database cannot be credibly locked while known cross-system discrepancies remain open.
What is SAE reconciliation in Clinical Data Management?
SAE reconciliation takes place between two databases: the clinical database, where the site records the serious adverse event on the eCRF in the EDC system, and the safety (pharmacovigilance) database, where drug safety processes the same event as a case for regulatory reporting. Data management and drug safety compare the two and resolve every difference, so that both describe each SAE the same way before database lock.
SAE reconciliation compares serious adverse event data recorded in the clinical database against the same events in the safety (pharmacovigilance) database. Because the two databases are populated independently — the clinical side through the eCRF, the safety side through expedited reporting workflows — differences are common and expected.
The comparison focuses on the fields that define the event and its clinical significance: the event term, onset and resolution dates, seriousness criteria, severity, outcome, causality assessment, and the action taken with the study drug. A reconciliation listing pairs the records and highlights where they disagree. Each discrepancy is then investigated with the data management, safety, and medical teams, and corrected in whichever system holds the error — though, because the investigator owns the trial data, any correction on the clinical side is raised as a query for the site rather than made by the sponsor directly. SAE reconciliation runs periodically through the trial and is completed in full before database lock, because safety data carries the highest consequence of any data in the study.
Adverse event (AE) reconciliation and safety data reconciliation are often used as names for the same activity. In most trials, only serious adverse events and other reports the protocol requires to be sent to drug safety, such as adverse events of special interest or pregnancy reports, reach the safety database, so those are the records that are reconciled. Non-serious adverse events usually exist only in the clinical database and are cleaned through normal data validation instead.
Which fields are compared in SAE reconciliation?
The fields are agreed in advance in the data management plan or a separate SAE reconciliation plan. A typical set:
| Field | What is checked |
|---|---|
| Subject ID and site | The event belongs to the same participant in both databases |
| Event term | The verbatim term reported by the investigator, and its MedDRA coding, describe the same event |
| Onset and resolution dates | The dates are the same in both databases |
| Seriousness criteria | The same criteria are recorded: death, life-threatening, hospitalisation or prolonged hospitalisation, persistent or significant disability, congenital anomaly, or other medically important event |
| Severity | The intensity grade matches, for example mild, moderate or severe, or a CTCAE grade in oncology trials |
| Outcome | For example recovered, recovering, not recovered, recovered with sequelae or fatal |
| Causality | The investigator's assessment of the relationship to the study drug is the same in both databases |
| Action taken with study drug | For example dose not changed, interrupted or withdrawn |
SAE reconciliation process step by step
- Plan. Define the scope, the fields, the matching rules and the frequency before the first cycle.
- Extract. Pull SAE data from both databases at the same cut-off date, so that reports still in transit do not show up as false discrepancies.
- Match. Pair the records, usually by subject ID, event term and onset date, with a programmed comparison or a side-by-side listing.
- Review. Data management and drug safety go through the discrepancy listing together, with the medical monitor where clinical judgement is needed.
- Resolve. Errors in the clinical database go to the site as a query. Errors in the safety database are corrected by drug safety, often as a follow-up version of the case.
- Document. Record each discrepancy, its resolution and the date, then sign off the cycle. The final cycle is signed off before database lock.
How often SAE reconciliation is done and who is involved
SAE reconciliation runs at a fixed interval set in the plan, such as monthly, and before each major data cut: interim analyses, data monitoring committee reviews and database lock. The data manager produces the listings and raises site queries. The drug safety (pharmacovigilance) associate owns the safety database side. The medical monitor advises on clinical questions, such as whether two differently worded terms describe the same event. The investigator site confirms or corrects the data against source documents.
Typical SAE discrepancies and how they are resolved
| Discrepancy | Typical resolution |
|---|---|
| SAE in the safety database but not in the clinical database | Query to the site to enter the event on the adverse event eCRF |
| SAE in the clinical database but not in the safety database | Drug safety checks whether a report was received; if not, the site is asked to submit an SAE report |
| Event recorded as serious in one database and non-serious in the other | Query to the site to confirm seriousness; the database in error is updated |
| Different event terms, for example "chest pain" in one database and "myocardial infarction" in the other | Medical review, then a query to the site to confirm the diagnosis; the MedDRA coding is aligned once the term is agreed |
| Onset date, outcome or causality differs | Query to the site to confirm against source; drug safety updates the case if the clinical database is correct |
What is lab reconciliation in Clinical Data Management?
Lab reconciliation, or lab data reconciliation, compares the sample information recorded in the clinical database with the data received from the laboratory, usually a central or other third-party lab. It confirms that every sample the site collected has matching lab data under the same subject, visit and collection date, and that nothing is missing, duplicated or assigned to the wrong participant.
Most trials use a central laboratory that transfers results electronically into the clinical data environment on an agreed schedule. Laboratory reconciliation confirms that what the lab sent and what the clinical database holds are aligned — that every expected sample is present, that none are duplicated, and that key identifiers match.
The comparison typically checks participant and visit identifiers, sample collection dates, the presence of expected results, and units of measure. A frequent issue is a mismatch between the sample date or visit recorded at the site and the one supplied by the lab, which must be investigated rather than assumed away. Where a trial also uses local laboratories whose results are entered at the site, those entries are checked against source documentation as part of the same quality effort.
Because a central laboratory is an external vendor, third-party lab data reconciliation follows the same rules as other vendor data: the data transfer agreement and specification described in the next section define what the lab sends, in what format and how often.
Fields compared in lab data reconciliation
- Subject ID and site number, as written on the lab requisition and as recorded in the EDC system
- Visit, including unscheduled visits and repeat samples
- Sample collection date and time
- Accession or requisition number, the identifier that links a sample kit to its results
- Demographics held by the lab, such as sex and date of birth, because they determine which reference ranges are applied
- Expected tests, so that a sample recorded as collected has results for the tests the protocol requires at that visit
How often lab reconciliation is done and who is involved
Lab data is usually reconciled with every scheduled data transfer, so the frequency follows the transfer schedule agreed with the lab. A final reconciliation is run on the last transfer before database lock. The data manager runs the comparison and raises queries. The laboratory's project or data team investigates issues on the lab side. The site confirms collection details against source, and the monitor (CRA) may help with recurring labelling problems at a site.
Typical lab data discrepancies and how they are resolved
| Discrepancy | Typical resolution |
|---|---|
| Lab results with no matching visit or sample record in the clinical database | Query to the site to confirm the sample was taken and complete the eCRF |
| Sample recorded as collected in the EDC system, but no results from the lab | Check with the lab whether the sample was received, cancelled or could not be analysed, for example a haemolysed or leaking sample; record the reason if no result will follow |
| Collection date, time or visit differs | Query to the site to confirm against source; if the site is correct, the lab corrects its data in the next transfer |
| Wrong subject ID on the requisition | The site confirms the correct participant; the lab re-assigns the results and sends corrected data |
| Sex or date of birth differs between the lab and the EDC system | Query to the site to confirm; the lab updates its demographics so the correct reference ranges are applied |
| Duplicate records | The lab removes the duplicate in the next transfer |
External vendor and third-party data reconciliation in Clinical Data Management
Vendor reconciliation, also called external data reconciliation or third-party reconciliation, is the comparison of data delivered by an external vendor with the corresponding data in the clinical database. It covers non-eCRF data that arrives as electronic transfers, such as randomisation data from IRT, ePRO and eCOA questionnaires, ECG and imaging reads, and specialist laboratory results, checked against the data transfer specification agreed with each vendor.
Modern trials draw data from a growing number of external vendors: ePRO and eCOA providers, interactive response technology (IRT/RTSM) for randomisation and drug supply, imaging and ECG core labs, and specialist biomarker providers. Each delivers a dataset that must agree with the clinical database on the data points they share.
External data reconciliation confirms that these independent datasets line up — that the participants, visits, and key shared variables match across systems, and that no records are missing, duplicated, or orphaned. The foundation for this is laid during set-up: a data transfer agreement and transfer specification define exactly what each vendor will send, in what format, and how often. Reconciliation then verifies, throughout the trial, that the data actually received conforms to that specification and agrees with the clinical record.
The data transfer agreement (DTA) sets out responsibilities, the transfer method, file format, frequency and timelines. The data transfer specification (DTS) describes the content of each file: the variables, their formats and code lists, and the key variables used to match vendor records to the clinical database, typically subject ID, visit and date. A test transfer is normally checked before the first live transfer, so that structural problems are found before real data flows.
What is compared for each type of vendor data
| Vendor data | Typical reconciliation checks |
|---|---|
| IRT/RTSM (randomisation and drug supply) | Subject ID, randomisation number and date, stratification factors, and kit numbers dispensed against drug dispensing recorded in the EDC system. In a blinded trial, treatment assignment stays out of the comparison so that the data management team remains blinded. |
| ePRO and eCOA | Subject ID, questionnaire dates against visit dates, and expected questionnaires against those received |
| ECG and imaging core labs | Subject ID, visit, and assessment date and time against the procedure recorded on the eCRF |
| PK and biomarker laboratories | Sample ID, collection date and time, and planned time point against the sampling page in the EDC system |
How often vendor data is reconciled and who is involved
Reconciliation follows the transfer schedule in the DTA. Each incoming transfer is checked first against the specification (file structure, variables and formats) and then against the clinical database. A final reconciliation is run on the last transfer before database lock. The data manager, sometimes a dedicated external or vendor data manager, owns the process. The vendor's data team corrects issues on their side, the site resolves queries on the EDC side, and statistical programmers often build the reconciliation listings.
Typical vendor data discrepancies and how they are resolved
- Orphan records: vendor data for a subject or visit that does not exist in the clinical database. Resolved by a query to the site, or by the vendor if the ID was entered wrongly in their system.
- Missing records: an assessment recorded in the EDC system with no vendor data. The vendor confirms whether it was received and sends it in the next transfer, or the reason it is missing is documented.
- Mismatched IDs or dates: the source is checked, then the site corrects the eCRF through a query or the vendor corrects its data through a data change request. ePRO data in particular is changed only by the vendor, because sites cannot edit patient-entered data directly.
- Specification deviations: wrong formats, unexpected code list values or missing variables. These are raised with the vendor and fixed in the next transfer; if the specification itself needs to change, the DTS is updated under version control.
- Stratification differences between IRT and the EDC system: documented and reported to the study statistician, because a completed randomisation is not normally repeated.
How reconciliation works in practice
Although the systems differ, the method is consistent across all three types. The expected datasets and the fields to be compared are defined in advance, usually in the data management plan or a dedicated reconciliation plan. The two datasets are then compared, most often programmatically, to produce a listing of matches and discrepancies. Each discrepancy is investigated to find its cause, resolved through a correction or a documented explanation — raising a query to the site where site data is the source of the error — and the resolution is recorded.
Two principles separate reconciliation that works from reconciliation that creates a last-minute crisis. First, it is continuous: running comparisons at regular intervals throughout the trial keeps the discrepancy count manageable, whereas leaving it all until close-out guarantees a bottleneck. Second, it is documented: the comparison, the discrepancies found, and how each was resolved form part of the evidence that the database was clean at lock.
Frequently asked questions
What is reconciliation in clinical data management?
Reconciliation is the comparison of two datasets that should contain the same information — typically the clinical database against a safety, laboratory, or vendor system — to identify and resolve any differences between them. It confirms that independently held records of the same data agree, and it is completed before database lock as part of declaring a clean file.
What is SAE reconciliation?
SAE reconciliation compares serious adverse event data in the clinical database against the same events in the safety (pharmacovigilance) database. It checks fields such as event term, dates, seriousness, outcome, and causality, because the two databases are populated independently. Discrepancies are investigated with the data management, safety, and medical teams and resolved before lock, given the high consequence of safety data.
Which two databases are compared in SAE reconciliation?
SAE reconciliation is performed between the clinical database and the safety (pharmacovigilance) database. The clinical database, usually an EDC system, holds the event as the site entered it on the eCRF. The safety database holds the same event as a case processed by drug safety for regulatory reporting. Both must agree before database lock.
What is lab reconciliation in clinical data management?
Lab reconciliation compares the sample information in the clinical database with the data transferred by a central or other third-party laboratory. It checks subject ID, visit, sample collection date and time, accession number and the demographics used for reference ranges, so that every sample collected has matching lab data and no result sits under the wrong participant or visit.
What is vendor or third-party reconciliation in clinical data management?
Vendor or third-party reconciliation, also called external data reconciliation, compares data delivered by external vendors, such as IRT, ePRO, ECG, imaging or specialist laboratories, with the clinical database. It checks the records and key variables defined in the data transfer specification, and resolves differences through queries to the site or data change requests to the vendor.
What is the difference between lab and vendor reconciliation?
Laboratory reconciliation confirms that data from a central or local laboratory agrees with the clinical database, checking identifiers, sample dates, results, and units. Vendor reconciliation applies the same logic to other external providers — ePRO, IRT, imaging, ECG, or biomarker vendors — confirming that each external dataset matches the clinical record on the variables they share.
When does reconciliation happen in a trial?
Reconciliation is an ongoing activity during the conduct stage rather than a single task at the end. Running comparisons at regular intervals keeps the number of open discrepancies manageable. A final, complete reconciliation is then performed before database lock, because no database can be credibly locked while known cross-system discrepancies remain unresolved.
Why is reconciliation important?
Reconciliation prevents a locked database that appears complete but contains contradictions between systems — for example a safety database and clinical database that disagree on an event outcome. It supports the ALCOA principles of accurate and consistent data, and unresolved cross-system discrepancies are a recurring source of regulatory inspection findings.
Build the full picture with TriTiCon
Reconciliation sits within the wider conduct and close-out stages of clinical data management, alongside data cleaning, consolidation, and the declaration of a clean file. TriTiCon's training covers it in that context: The Clinical Data Management Conduct Process covers data cleaning and consolidation, and The Clinical Data Management Close-out Process covers completing data handling and declaring the clean file. Each module defines the key concepts, highlights regulatory requirements, and shows you how to apply the fundamentals across different trial and company settings.
