Independent and not affiliated with the FDA, MHRA, ISPE, PDA, or any agency. Get the appgoutham@madhadi.com
madhadi.comData Integrity & GxP Quality
Browse all topics → Articles Templates & Procedures Learning paths GlossaryScenariosToolsRegulatory ReferencesLearning PathsTopics About Start here
SOP Plug-and-play starting point Manufacturing Automation

SOP: Review by Exception Design and Electronic Batch Record Review

A plug-and-play SOP for designing, validating, and operating review by exception on electronic batch records: how to define exception rules, the acceptance test that every failure a full review would catch is still surfaced, roles, and records, with a filled specimen.

Document type: SOP

Read and copy the template below into your own quality system. It is a generic starting point for your own internal use, provided as is, with no warranty; see the Terms and License. Adopting it does not by itself create compliance.

This is a ready-to-use SOP for review by exception (RBE) on electronic batch records. RBE only reduces oversight safely if the exception rules are designed to surface every failure a full manual review would catch; this procedure builds that guarantee in. Replace every <<FILL: ...>> placeholder, route it through your document control, and validate the exception logic before you rely on it. A filled specimen follows. Verify each cited regulation against the current source before you rely on it.

Document control header

FieldEntry
Document titleReview by Exception Design and Electronic Batch Record Review
Document number<<FILL: SOP-ID, e.g. SOP-MFG-021>>
Version<<FILL: version>>
Effective date<<FILL>>
Supersedes<<FILL: prior version or "New">>
Document owner<<FILL: role, e.g. Head of Manufacturing / MES owner>>
Applies to<<FILL: sites / lines / systems in scope>>

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> designs, validates, and operates review by exception for electronic batch records produced by <<FILL: MES / EBR system name>>, so that batch review focuses human effort on departures from expected values while still catching everything a full review would. It sets the standard that the exception logic is a GMP control with the same rigor as a manual review procedure.

2. Scope

Applies to EBRs reviewed by exception on the systems and products listed in the header. It does not replace the disposition decision itself, which is governed by <<FILL: SOP-ID for batch disposition>>, nor audit-trail review, governed by <<FILL: SOP-ID for audit trail review>>. Products or steps not yet approved for RBE are reviewed in full per <<FILL: SOP-ID for full batch record review>>.

3. Responsibilities

RoleResponsibility
MES / automation engineeringConfigures the exception rules and reports; maintains them under change control.
ValidationQualifies each exception rule against seeded failures during PQ; documents the design rationale.
Manufacturing reviewerPerforms the exception-based review of each batch; investigates every flagged exception.
Quality AssuranceApproves the exception-rule set and its risk justification; performs the independent quality review; owns periodic re-verification.
Process SMEDefines the failure modes a full review would catch and confirms each has a matching rule.

4. Definitions

  • Review by exception (RBE): a review method where validated rules surface only the entries that depart from expected values or defined conditions, so the reviewer examines exceptions rather than every data point.
  • Exception rule: a defined, testable condition that, when met, flags an entry for reviewer attention (for example a value outside its limit, a step completed outside its time window, an alarm on a critical parameter, an edited signed field).
  • Failure mode: something a full manual review is expected to catch. Every failure mode must map to at least one exception rule.
  • Coverage: the property that every identified failure mode is surfaced by at least one exception rule. Coverage is the load-bearing acceptance criterion for RBE.

5. Procedure

5.1 Build the failure-mode list first

Before writing any rule, list every failure a full manual review of this product’s EBR is expected to catch. Draw on the process SME, prior deviations, and the risk assessment. At minimum consider: out-of-range in-process values; steps completed outside their expected time window; alarms on critical process parameters; edits to signed fields or post-entry changes with a reason; yield or reconciliation outside limits; unreconciled material; skipped or out-of-sequence steps; missing signatures; and any parameter tied to a critical quality attribute.

5.2 Write one or more exception rules for each failure mode

For each failure mode, define the exception rule that surfaces it, expressed as a testable condition on the EBR data. Record the mapping in the coverage matrix (section 8). No failure mode may be left without a rule; if a failure mode genuinely cannot be surfaced by a rule, it stays in full review, and that decision is documented and risk-justified.

5.3 Risk-justify and approve the rule set

Document the risk basis for the exception criteria (see quality risk management). QA approves the rule set and the coverage matrix before RBE is used on production batches. Over-broad rules (which collapse RBE back into full review) and over-narrow rules (which hide real problems) are both design defects to resolve before approval.

5.4 Validate the rules against seeded failures

During PQ or a dedicated validation, seed each failure mode into a test batch and confirm the corresponding rule fires. A rule that does not fire on its seeded failure is a defect, not a pass. Keep the seeded-failure evidence with the validation record. Any change to a rule after go-live is a change (section 5.7) and requires re-validation of the affected rule.

5.5 Perform the exception-based review of each batch

  1. Confirm RBE is approved for this product and the rule set version in effect.
  2. Run the validated exception report for the batch.
  3. Investigate every flagged exception: confirm it is explained, authorized, and consistent with the record, and resolve or escalate any that are not.
  4. Confirm the report ran against the complete batch data set with no gaps (a partial or failed report is not a clean review).
  5. Record what was reviewed, what was flagged, and the disposition of each flag.

5.6 Independent quality review and disposition

QA performs the independent review of the exception outcomes and the resolution of each flag, then the batch proceeds to disposition per the disposition SOP. A batch with an unresolved exception is not dispositioned as released.

5.7 Change control and periodic re-verification

Any change to the exception rules, the report, or the product recipe that could affect coverage goes through change control for validated systems and re-validation of the affected rules. At a defined interval (<<FILL: e.g. annually>>), re-verify coverage against the current failure-mode list, because new failure modes surface from deviations and process changes over time.

6. Acceptance criteria

  • Every identified failure mode maps to at least one exception rule, or is documented as remaining in full review.
  • Each rule fired on its seeded failure during validation, with evidence retained.
  • The exception report for every reviewed batch ran against complete data with no gaps.
  • Every flagged exception was investigated and resolved before disposition.
  • The rule set is under change control and coverage is re-verified on schedule.

7. Records generated

Exception-rule set and version; coverage matrix; seeded-failure validation evidence; per-batch exception report and review record; change-control records for rule changes; periodic coverage re-verification record.

8. Coverage matrix (the core record)

Failure mode (what a full review would catch)Exception rule that surfaces itRule validated (seeded failure fired)In full review instead?
Out-of-range in-process value<<FILL: rule, e.g. value outside step limits>><<FILL: Yes / evidence ref>>No
Step completed outside time window<<FILL>><<FILL>>No
Alarm on a critical process parameter<<FILL>><<FILL>>No
Edited signed field / post-entry change<<FILL>><<FILL>>No
Yield / reconciliation outside limits<<FILL>><<FILL>>No
<<FILL: add product-specific failure modes>><<FILL>><<FILL>><<FILL>>

9. References

21 CFR 211.188 and 211.192 (batch record and its review). EU GMP Annex 11 (computerised systems, risk-based approach) and Chapter 6 (quality control review). ICH Q9 (quality risk management) for the risk-based exception criteria. Related reading: GxP manufacturing and laboratory systems, batch record review in GMP.

Confirm the current version and clause numbers of each reference before issue.

10. Revision history

VersionDateAuthorSummary of change
<<FILL: 1.0>><<FILL: date>><<FILL: author>>Initial issue.

11. Approvals

RoleNameSignatureDate
Author<<FILL>>
Reviewer (QA)<<FILL>>
Approver (Quality Head)<<FILL>>

Filled specimen

The following shows one row of a completed coverage matrix and its review outcome for an example batch, so you can see how the guarantee is demonstrated. The values are illustrative.

Failure modeException ruleRule validatedIn full review instead?
Bioreactor pH excursion outside 6.8 to 7.2 during productionRule R-07: flag any pH reading outside 6.8 to 7.2, or any pH alarm, in the production phaseYes; seeded pH of 7.4 in test batch T-118 fired R-07 (evidence VAL-RBE-031)No

For batch B-2026-0442 the exception report flagged one R-07 event: pH read 7.25 for four minutes during hour 3. The reviewer confirmed the deviation was already recorded (DEV-2026-0210), the impact assessed, and the batch dispositioned with that deviation open and then closed. The RBE review did not read every pH reading in the batch; it surfaced the one that mattered, and the reviewer could show the rule that would have caught it even if no one had noticed at the time. That is the whole point of the coverage matrix.

Common inspection findings this SOP prevents

  • RBE used with no documented mapping from failure modes to exception rules, so the firm cannot show what the review would still catch.
  • Exception rules never validated against seeded failures, so a rule may silently never fire.
  • A batch reviewed against an exception report that ran on incomplete data, mistaken for a clean review.
  • Rules changed after go-live with no re-validation of coverage.
  • RBE treated as a reduction in oversight rather than a redirection of it, with flags closed without real investigation.

How to adapt this SOP

  1. Set your document number, owner, and effective date in the header.
  2. Replace the failure-mode list in section 5.1 and the coverage matrix with your actual product and process failure modes.
  3. Name your real exception report and its validation record.
  4. Point the cross-references in section 2 and 5.6 to your real disposition, audit-trail-review, and full-review procedures.
  5. Confirm every regulation in section 9 against the current published version before issue.
Use madhadi.com as an app Full screen, works offline, one tap from your home screen.