Pharmacovigilance Reconciliation: What Should Be Reconciled, With Whom and How Often?

A pharmacovigilance (PV) organisation receives safety information through many routes. A patient may contact Medical Information. A healthcare professional may report an adverse reaction to an affiliate. A contractor may screen literature. A study team may maintain an event database. A product complaint may mention a patient injury. A report may pass through several systems before reaching the global safety database or a competent authority.

Reconciliation is one way to check that expected records and actual records agree. It can reveal a missing transfer, an unlinked report, an unexplained duplicate, an incorrect disposition or a broken interface. It does not mean that every operational database must contain identical records, and it does not replace sound intake, case processing, transmission acknowledgements or quality control.

The useful question is not simply “Do we reconcile?” It is: Which safety pathway is at risk of losing, delaying, duplicating or misrepresenting information, what evidence would reveal that failure, and how quickly must the organisation detect it?

This article sets out a programme-level framework for answering those questions. It complements the case-processing discussion in GVP Module VI: ICSR Data Quality, Follow-Up and Reconciliation. That article explains controls over the individual case lifecycle; this one focuses on the inventory, design, cadence and governance of reconciliations across PV interfaces.

1. What reconciliation is—and what it is not

Reconciliation is a controlled comparison of defined records from two or more sources to find and resolve differences that matter to a PV process. A comparison can be performed between systems, organisations, teams, queues, reports or source registers. It may be automated, manual, or a combination.

A reconciliation needs a defined purpose. For example, a medical-enquiry log may be compared with PV intake to test whether safety-bearing contacts reached PV. A vendor transmission file may be compared with the MAH's receipt records to confirm that expected reports arrived. A PV submission log may be checked against regulatory acknowledgements to identify rejected messages.

These controls are related but not interchangeable:

A successful file transfer can still omit a contact that was never flagged for transfer. A reconciliation limited to flagged contacts cannot detect that recognition failure unless the organisation also tests the completeness of the flagged population. Conversely, a successful reconciliation does not prove that every case was medically assessed correctly. Each control needs a stated objective and a defined boundary.

A useful mental model is a chain of custody for safety information: at each handoff, the organisation should know what information was expected, what arrived, what action was taken, and how exceptions were closed. Reconciliation tests selected links in that chain; it is not a substitute for the chain itself.

2. Regulatory foundation and practical interpretation

The EU framework does not prescribe one universal reconciliation catalogue or one calendar frequency for every PV interface. It does require an adequate pharmacovigilance quality system, proper handling and traceability of PV information, and compliance with the applicable safety-reporting duties. GVP guidance describes how to implement these responsibilities.

GVP Module VI, section VI.B.4, addresses data management and transfers. Where PV data are transferred within an organisation or between organisations with contractual arrangements, the mechanism should provide confidence that all notifications are received; a confirmation and/or reconciliation process should be undertaken. The statement is guidance expressed as “should.” It supports documented transfer controls; it is not a rule that every pair of systems must be reconciled monthly.

GVP Module VI, section VI.B.5, describes quality management across case documentation stages, including data collection and transfer. GVP Module I places PV quality systems within the wider system of responsibilities, records, compliance management and performance/effectiveness monitoring. The applicable legal foundation is Commission Implementing Regulation (EU) No 520/2012, as amended, including provisions on quality systems, compliance management and record management.

These sources lead to three practical conclusions:

1. The organisation must meet its binding legal and reporting duties. A local procedure or contract cannot reduce the MAH's applicable responsibilities.
2. GVP guidance informs implementation. Where the module recommends confirmation or reconciliation for a transfer, the organisation should either implement a suitable control or document a reasoned alternative that provides equivalent confidence.
3. The detailed design is risk-based. Source population, matching method, timing and evidence should reflect the pathway's volume, complexity, failure modes and possible impact.

Do not write “EU law requires monthly reconciliation” unless a specific applicable legal provision or binding agreement actually says that. A monthly review may be a reasonable local control for a particular pathway, but it remains a design choice unless some separate obligation fixes the interval.

Also distinguish a formal safety report transfer from other safety-related information. Some processes transmit validated ICSRs; others provide screening records, study events, medical enquiries or quality complaints that first need assessment. Reconciliation should compare like with like: a raw event count cannot automatically be expected to equal a count of valid ICSRs.

3. Start with the process and the failure risk

Reconciliation selection should begin with a process map, not a template copied from another company. Draw the pathway from the earliest relevant source to the point where PV action is complete. Record which role or system owns each step and what evidence is generated.

For each interface, ask:

• What information enters this pathway, and what is the authoritative source record?
• Which elements could be safety-relevant even if they are not yet an ICSR?
• Where can information be delayed, filtered, rejected, duplicated, altered or left unprocessed?
• Which handoffs occur within the MAH, between affiliates, or under a contract?
• What event or status shows that the receiving function accepted the transfer?
• What could happen to patients or regulatory compliance if a discrepancy remains undetected?
• Is the interface covered by a different control that provides equivalent confidence?

A process map may reveal that a reconciliation is not the right control. A validated interface with transaction-level acknowledgement, durable error queues and tested recovery may provide strong evidence for successful transfer. The organisation may still need a separate test of source completeness, because successful transfer only covers records that entered the interface.

Conversely, a manual spreadsheet emailed once a week may require a population comparison, an acknowledgement check, and a review of items held or rejected before transfer. If a vendor's log is the only source of what was received, the MAH should assess how it can independently verify completeness rather than accepting a summary statement.

Risk assessment should consider both likelihood and consequence. A rare failure may still merit a rapid control if it could cause a serious case to miss a deadline. A high-volume, low-risk administrative interface may be sampled or monitored differently. The goal is not to maximise the number of reconciliations; it is to ensure that important information cannot disappear without detection.

4. Build a reconciliation inventory

A reconciliation inventory is a controlled list of material PV interfaces and the checks used to monitor them. It helps prevent duplicated effort in one area while leaving a high-risk pathway untested.

The following catalogue is a starting point, not a mandatory EU checklist:

For each inventory row, record at least: owner; sending and receiving populations; safety purpose; source of truth; frequency; matching method; exception owner; escalation threshold; evidence location; applicable procedure or agreement; and the date the design was last reviewed.

Not every source needs a periodic comparison. Some require event-level confirmation for each transfer. Others may be checked by sampling or by reviewing a complete population at a defined interval. Some may not produce a one-to-one PV case at all; their reconciliation may verify that each item received a documented disposition rather than a case number.

The inventory should include a clear exclusion rationale where an interface is not reconciled. “No reconciliation required” is not enough by itself. State what control provides confidence, what risks remain, and how the organisation will know if that control stops working.

5. Define the population before matching

A comparison is only as reliable as its population. The sending system and receiving system should use compatible reporting periods, scope, status definitions and inclusion rules.

Before extraction, define:

• products, territories, channels and business units covered;
• whether the population includes all records or only records in selected statuses;
• the event date, receipt date, transfer date or processing period that determines inclusion;
• treatment of records received near a period boundary;
• time zone and daylight-saving conventions where timestamps are relevant;
• treatment of reopened, amended, cancelled or duplicate records;
• exclusions, such as test records or records outside the agreed safety scope;
• and who may approve a change to the population definition.

A common defect is to compare a vendor's “cases sent” report with the MAH's “cases entered” report when the two use different cut-off dates or include different statuses. The resulting difference may be an artefact of the extraction rather than a missing report—or a genuine missing item may be hidden by compensating differences.

Population completeness is especially important when only flagged records are reconciled. If the process begins with staff selecting “safety-related,” the reconciliation can show that selected contacts reached PV while saying nothing about contacts incorrectly left unflagged. For high-risk channels, supplement the transfer check with review of unflagged records, keyword search, random sampling, abandoned submissions or source logs, as permitted by system design and applicable privacy rules.

Keep an immutable or reproducible record of each extraction: system name and version, query or filter, date run, period covered, row count, preparer, and any transformation applied. Re-running the query should produce the same population or an explainable result. This makes the comparison auditable and helps distinguish a data-extraction problem from a genuine process discrepancy.

Do not force all source records into the same data model. A literature result, complaint, support-programme contact and valid ICSR have different meanings. The reconciliation should preserve source identity and disposition rather than converting every row into a “case” for counting convenience.

6. Select the right comparison level and matching rules

Reconciliations can compare counts, individual records, events, acknowledgements or process statuses. Aggregate counts are easy to review but often weak at identifying what was lost. A one-to-one record comparison is more specific, but it requires stable identifiers and defined handling for legitimate one-to-many or many-to-one relationships.

Use the strongest available match key first, such as a unique source reference carried into PV intake. Where no common identifier exists, use a controlled combination of fields—such as receipt date and time, reporter, patient, product, event description, source country and contact channel. Review ambiguous candidates rather than automatically closing them as matches.

The comparison logic should account for legitimate differences:

• one source contact may report more than one patient;
• multiple contacts may update a single continuing case;
• one publication may create several patient cases;
• a literature article may be documented as a duplicate of an existing report;
• a quality complaint and a PV case may share a source reference but have separate investigation records;
• and a study may contain many events while only some meet the applicable criteria for individual case reporting.

An effective match rule documents which fields are exact, which allow controlled variation, which require human review, and when a reviewer must not infer that two records are the same. A product name and a nearby date alone are usually insufficient to establish identity.

Where information flows both ways, define both directions. A source-to-PV check tests whether source records reached PV. A PV-to-source check can reveal missing source references, incorrect source classifications, or PV records attributed to an interface without a corresponding source record. Bidirectional comparison is useful when each system should hold a traceable reference to the other, but it should not be imposed if the process does not logically require symmetry.

6.1 Disposition states

Every comparison result should end in a controlled status with an owner and evidence. A practical status model might include:

These labels are examples for procedure design. The organisation should use terms consistent with its quality system and ensure that “closed” means the discrepancy was resolved or formally accepted by an authorised reviewer—not merely removed from the worklist.

7. Resolve discrepancies according to potential impact

A discrepancy is a difference that needs explanation; it is not automatically an error. The reviewer should establish what happened, whether safety information is affected, whether regulatory obligations may be affected, and what correction or escalation is necessary. If a transfer delay may have changed or obscured when the MAH first became aware of a reportable case, assess that under the applicable awareness-date rules; reconciliation does not move the date. See the Day Zero guide.

A useful investigation sequence is:

1. Protect the information. If an unmatched item could contain a suspected adverse reaction or another urgent safety concern, route it to PV immediately while the investigation continues.
2. Confirm the source population. Check filters, cut-off times, status definitions, time zones, missing pages and extraction errors.
3. Search for the counterpart. Use the unique reference, matching fields, alternate queues and controlled duplicate logic.
4. Reconstruct the path. Review transmission logs, interface messages, email receipts, work queues, acknowledgements, audit trails and vendor records.
5. Determine impact. Assess whether a report was delayed, a case omitted, a submission rejected, a safety issue unassessed, or only an administrative reference missing.
6. Correct and document. Create or update the PV record, restore the link, resubmit when applicable, and record the rationale and evidence.
7. Assess systemic cause. Check whether the same defect could affect other periods, products, channels or cases.
8. Close with authority. A designated reviewer approves closure and assigns any deviation, corrective action or further review.

The response time should reflect the possible consequence. A missing valid case or a failed urgent safety escalation should not wait until the next routine reconciliation meeting. An administrative discrepancy with no effect on safety or compliance may be handled under a normal due date. Procedures should distinguish immediate escalation triggers from standard exception handling.

Avoid using a generic threshold such as “investigate if more than five records differ.” One omitted report may be significant; five differences may all be explainable status timing. Thresholds are useful for trends and workload planning, but they should not override item-level triage where safety information may be missing.

If a defect may have affected regulatory timelines, PV compliance management should assess the affected cases, determine required reporting or notifications under the applicable rules, and document the impact assessment. Reconciliation closure does not erase the history of a late or failed process. The underlying event should be handled under deviation and corrective/preventive action procedures where appropriate.

A discrepancy log should show the source and receiving records, detection date, first known receipt where relevant, responsible owner, potential impact, investigation, correction, escalation, root cause, approval and closure evidence. Store detailed personal or medical data in the appropriate controlled system; a general reconciliation tracker usually needs references, not duplicate narratives.

8. Set frequency by risk and control design

There is no single reconciliation frequency that fits every PV interface. A frequency should be justified by the time in which a failure must be detected, the reliability of other controls, the volume and variability of the source, and the likely impact of an undetected omission.

Consider at least these factors:

Examples of possible approaches include transaction-level acknowledgement for each safety transfer, daily review of an urgent queue, weekly or monthly population comparison for a manual interface, periodic risk-based sampling of a stable process, or event-triggered reconciliation after a system change. These are design examples, not EU-mandated schedules.

A layered model is often stronger than a single monthly reconciliation:

• at transfer: acknowledge receipt or capture a technical response;
• during operations: monitor open, rejected and aged items;
• periodically: compare source and destination populations;
• after change or failure: perform targeted review of affected records;
• in oversight: trend exceptions and test that corrective actions worked.

The procedure should state what begins, ends or changes a reconciliation interval. For instance, a new vendor may be subject to more frequent checks during implementation, with a later reduction only after performance evidence and governance approval. A reduction should not be based only on a short period with no recorded exceptions if the sampling method could miss recognition failures.

Review frequency should also be practical: a monthly list that is so large no one can resolve exceptions promptly is not an effective control. Improve automation, stratify by risk, assign adequate resources, or change the control design. Completion time and unresolved backlog are themselves useful indicators.

9. Reconciliation across common PV interfaces

The nature of the comparison should follow the source process. The table below describes typical objectives and cautions; it does not mean that every organisation must operate every row.

For studies, separate the study's event collection from individual safety reporting. A study database may intentionally capture a broad set of events for analysis, while individual suspected adverse reactions are managed under applicable PV criteria and reporting rules. The reconciliation should test that the agreed reportable population has been transferred and documented, not demand a one-to-one match between all study events and PV cases.

For literature and digital channels, the disposition is part of the control. It should be possible to follow a source item through screening, PV referral, duplicate review or a reasoned non-case decision. An aggregate count of “articles screened” or “posts reviewed” is not enough if the organisation cannot trace safety-relevant items to their outcomes.

For regulatory submission, reconciliation often complements system acknowledgements. The organisation should be able to identify the cases expected to be submitted, the messages sent, the responses received, and the action on rejects or technical errors. The detailed ICSR reconciliation and data-quality practices are covered in the Module VI companion article.

10. Third parties, agreements and organisational boundaries

Reconciliation becomes more difficult when records cross legal entities, vendors, affiliates, shared service centres or technology platforms. The organisation should define the reporting boundary: which party first receives the information, which party processes it, who transmits it onward, and who has access to the evidence needed to verify the exchange.

A written safety data exchange agreement or service agreement should describe, as applicable:

• safety information in scope and how it is identified;
• sender and recipient responsibilities;
• required content, format and source identifiers;
• transfer routes and time expectations;
• acknowledgement and rejected-message handling;
• urgent escalation and business continuity;
• record access, retention and audit trail;
• reconciliation responsibilities and evidence;
• deviation notification and corrective action;
• and change control for systems, subprocessors or operating models.

A contract should not be treated as proof that an exchange is operating effectively. The organisation needs evidence such as actual transmission logs, sample comparison results, open exception lists, timeliness trends, system tests, audit outputs or other controls proportionate to the service.

If the counterparty cannot provide a complete source population, document that limitation and consider alternative evidence: independent logs, transaction-level acknowledgements, sampling at source, direct interface monitoring, or an audit right. If there is no feasible way to obtain evidence, escalate the residual risk and address it through vendor governance. A reconciliation that compares two incomplete reports can produce a reassuring but false result.

For affiliates, a global safety database may be the destination, but local intake records remain important where they contain earlier receipt dates, local reporter details, language-specific source material or a required local disposition. Define how local records connect to the global case number and what happens when the global record is created after the local reporting process has begun.

The MAH retains oversight of its pharmacovigilance system when tasks are outsourced. The exact legal allocation can depend on the activity and applicable agreements, but operational delegation does not make it safe to rely solely on a vendor's summary of its own performance. A risk-based oversight plan should identify which services need routine reconciliation, which can be supported by reliable transaction evidence, and which require audit, sampling or another control.

After a contract or vendor change, reconcile the transition population: open items, transfers in flight, rejected messages, duplicate identifiers and records still awaiting PV disposition. Agree a final data cut-off, preserve access to historical records, and assign ownership of exceptions that surface after the service changes.

11. Reporting results and governing the programme

A reconciliation result should be usable by the team that must fix an item and by the manager who must judge whether the process is reliable. A concise report should include:

• scope and period;
• source and destination systems;
• population definitions and extraction details;
• number of expected and matched records;
• exceptions by status and potential impact;
• aged items and immediate escalations;
• decisions and evidence supporting closure;
• trends, repeat causes and affected interfaces;
• and actions, owners and due dates.

Counts need context. A match rate is not interpretable without knowing its denominator, exclusions, population completeness and whether some rows legitimately map to one case or several. A falling discrepancy count could mean that controls improved—or that fewer source records were included. A “zero discrepancy” result is meaningful only when the source population and the comparison logic are trusted.

Metrics should support decisions rather than reward superficial closure. Useful measures may include unmatched safety-relevant items, time to detect and resolve, rejected or unacknowledged transfers, overdue exceptions, recurring causes, source-reference completeness, reconciliation completion against schedule, and corrective-action effectiveness. Define each measure and its data source before trending it.

Senior PV management and the QPPV should receive significant or recurring issues through the established escalation route. A single discrepancy may require immediate escalation if it could affect a serious or time-critical report. A pattern of low-level mismatches may also signal an interface or governance weakness. The escalation threshold should consider potential impact and recurrence, not only volume.

A closed item should show a reasoned disposition and adequate evidence. If the discrepancy is accepted as a legitimate difference, state why. If the case is corrected, retain the link to the correction. If a deviation or corrective action is opened, cross-reference it. If an action changes the procedure, system or vendor control, confirm implementation and evaluate effectiveness before returning to the normal monitoring level.

12. Common failure modes and illustrative examples

The following scenarios are hypothetical and are included to show how a reconciliation programme can reveal different types of weakness.

Example 1: matching only on totals

An affiliate reports 42 safety transfers for the month and the global team records 42 new cases. The monthly totals match, but one source report was sent twice and another was never received.

Lesson: equal counts do not prove record-level completeness. Use identifiers or sufficiently reliable matching fields and investigate unmatched records.

Example 2: reconciling only the vendor's flagged records

A call-centre vendor forwards every contact marked “possible AE.” The MAH compares only that list with PV intake and finds no discrepancy. A sample of unflagged calls reveals that staff sometimes interpret “the medicine stopped working” as a product question.

Lesson: a transfer reconciliation tests only the population it receives. If recognition is at risk, test the screening control and source population as well.

Example 3: studies with different populations

A registry contains 300 adverse events, while the PV system contains 18 individual cases. The teams assume 282 cases are missing.

Lesson: first align definitions. The registry may collect events for a study purpose, while individual case reporting follows separate criteria and protocol obligations. Reconcile the reportable/disposition population, not raw totals.

Example 4: accepted transmission is confused with successful reporting

A submission dashboard shows 100% of messages as sent. Several regulatory acknowledgements show errors, but rejected messages remain in an unmonitored queue.

Lesson: distinguish dispatch from acceptance and have a named owner for acknowledgement failures and resubmissions.

Example 5: unexplained “no case” closures

The literature team sends a list of screened references. PV receives only records already judged to be cases, with no disposition for excluded items.

Lesson: where the process requires screening decisions to be traceable, reconcile both case referrals and a reviewable disposition record for the full defined population.

A useful tabletop exercise is to inject one missing record at each handoff—source capture, vendor transfer, affiliate intake, global case entry and regulatory acknowledgement—and ask how the control detects it, how soon, who acts, and what evidence remains.

13. Practical implementation checklist

Use this checklist when establishing or reviewing the programme.

Scope and ownership

• Have material sources, systems, organisations and PV handoffs been inventoried?
• Is each reconciliation linked to a defined failure risk and process owner?
• Are non-reconciled interfaces supported by a documented alternative control and rationale?
• Do agreements define responsibilities and evidence access where information crosses organisations?

Population and method

• Are source and destination populations, periods, cut-offs, status definitions and exclusions explicit?
• Is the source population complete, including records not flagged as safety-relevant where that is a known risk?
• Are stable identifiers carried across systems where feasible?
• Are one-to-many, many-to-one, duplicate, update and non-case dispositions covered by the matching rules?
• Can an independent reviewer recreate the extraction and comparison?

Frequency and exception handling

• Is the frequency based on consequence, volume, transfer design, prior failures and alternative controls?
• Do transaction acknowledgements, queue monitoring and periodic population comparisons complement one another?
• Are urgent unmatched safety items escalated immediately?
• Are each exception, owner, due date, investigation, correction, impact assessment and approval recorded?
• Do deviations, corrective actions and change controls connect back to the reconciliation record?

Effectiveness and oversight

• Are metrics defined with clear denominators and limitations?
• Are source populations sampled where flagging or screening could miss safety information?
• Are recurring causes and overdue exceptions reviewed by the appropriate governance forum?
• Is control frequency increased when the system, provider, volume or risk changes?
• Is effectiveness demonstrated before returning to the routine monitoring model?

14. Key takeaways

• Reconciliation is a controlled comparison of defined populations; it is not a blanket requirement that all PV systems contain the same records.
• Start with the process, source population and failure risk. Then choose the comparison, matching logic and evidence.
• GVP Module VI recommends confirmation and/or reconciliation for certain internal or contracted data transfers to provide confidence that notifications are received; it does not set one universal calendar frequency for every interface.
• Reconcile dispositions as well as cases where a source can lead to a new case, update, duplicate or reasoned non-case decision.
• Matching totals alone can conceal a missing item. Use traceable identifiers and investigate ambiguity.
• Set frequency according to consequence, source volume, transfer design, known defects and other functioning controls.
• Outsourcing does not remove the need for MAH oversight and evidence of performance.
• A reconciliation is complete when discrepancies have a documented, authorised disposition and systemic issues are addressed—not when a spreadsheet is marked complete.

References

1. European Commission. Commission Implementing Regulation (EU) No 520/2012 on the performance of pharmacovigilance activities, consolidated text applicable from 12 February 2026.
2. European Commission. Commission Implementing Regulation (EU) 2025/1466 amending Regulation 520/2012.
3. European Medicines Agency. Good pharmacovigilance practices (GVP), Module VI, Revision 2, especially VI.B.4 and VI.B.5.
4. European Medicines Agency. Good pharmacovigilance practices (GVP), Module I, especially I.B.9–I.B.12.
5. European Medicines Agency. Good pharmacovigilance practices (GVP), Module VIII, Revision 3, especially VIII.B.4.2 on adverse events and reactions in post-authorisation safety studies.
6. European Medicines Agency. Current GVP modules and revisions.

Regulatory Note

This article is an operational guide to reconciliation in the EU pharmacovigilance context, reviewed on 3 October 2026. Binding obligations arise from the applicable legislation, product-specific requirements, national rules and enforceable agreements. GVP provides regulatory guidance; the inventory, matching methods, frequency examples and oversight practices described here are implementation approaches that should be justified, documented and adapted to the organisation's actual processes. Confirm the current consolidated law and guidance before applying the article to a specific system.