Review by Exception for Batch Records: The Prerequisites Nobody Lists

What Review by Exception Actually Is

A batch record is a legal document. Under United States current good manufacturing practice regulations, a batch production and control record must include documentation of each significant step in the manufacture of the batch, and the quality control unit must review and approve those records to determine compliance with approved written procedures before a batch is released or distributed.² In the European Union, the same idea appears in Chapter 4 of the good manufacturing practice guidelines, which sets out what documentation must exist and how it must be controlled.⁸

None of that changes when the record becomes electronic. What changes is who performs the first pass of checking. In a paper world, a person compares each recorded value against a limit printed in the master record. In an electronic batch record with review by exception, the system performs that comparison as the value is captured, evaluates it against a machine-readable acceptance range, and either records it as conforming or raises an exception. The quality unit then reviews the exceptions and the surrounding context rather than reading the whole document line by line.

Vendors and advisers often illustrate the change by describing a 150-page batch record reduced to a three-page exception report.¹⁶ That illustration is a useful picture of the intent. It is not a benchmark, and no organization should put it in a business case as an expected outcome. The size of the exception report is entirely determined by how many exceptions your process actually generates, which is a function of your process, not your software.

What it is not

Review by exception is not a reduction in the quality unit’s obligations. It is not a decision to stop looking at data. It is not the same as real time release testing, which replaces some finished product testing with process data under an approved control strategy and requires prior authorization from the competent authority.¹² And it is not parametric release. Those are regulatory positions on what evidence supports a release decision. Review by exception is an operational position on how the evidence gets examined.

The distinction matters because it determines who has to approve what. Real time release testing changes your marketing authorization. Review by exception changes your internal procedure for production record review, and it needs to be defensible on its own terms during an inspection. A great deal of confusion in project charters comes from blending the two.

Why the Software Is Almost Never the Barrier

Every major manufacturing execution system on the market can evaluate a captured value against a configured range and raise a flag. That capability has been standard for a long time. The industry guidance on the topic is similarly mature: the GAMP Good Practice Guide on manufacturing execution systems takes a full lifecycle view of these deployments and was written for exactly this class of problem.¹⁴

So when a program stalls, it is worth being honest about where it stalled. In our experience the pattern is consistent. The system works. The organization cannot feed it the inputs it needs, and cannot articulate a defensible rationale for what it is choosing not to review.

The three inputs the system needs and rarely gets

Consider what happens when those inputs are missing. A site with weak parameter definitions and inconsistent equipment integration turns on review by exception. The system now flags every manually entered value that falls outside a range someone guessed at during configuration, every timestamp that arrives out of the expected sequence because two suites integrate differently, and every step where an operator entered a comment because the instruction did not fit what actually happened on the floor. The exception report is thirty pages. The quality unit reads the exception report and then, reasonably, reads the record too, because thirty exceptions on a batch means the reviewer has no basis for trusting the ones the system passed.

Where the real work sits

Nearly all of the effort in a successful program is upstream of the manufacturing execution system. It is in the master batch record rewrite that turns narrative instructions into parameterized steps. It is in the metrology and automation work that gets an instrument reading into the record without a keyboard in between. It is in the specification review that establishes where each limit came from and whether it is a registered specification, a validated operating range, or an internal alert level. And it is in the quality procedure that defines what a reviewer must still look at and why.

Industry commentary on manufacturing execution system payback makes a related point: the value realized depends heavily on the operational excellence maturity of the organization and on how well it can describe its own current state before the project starts.¹⁵ Sites that cannot describe the current state precisely tend to configure the new system to mirror the old ambiguity.

The Prerequisite List Nobody Puts in the Business Case

Here is the list in concrete terms. It is deliberately specific, because the generic version (“you need good data and a validated system”) is what allows a program to be approved without anyone confronting the actual work.

1. Every critical parameter defined with a machine-checkable acceptance range

For each parameter you intend the system to evaluate, you need a record that answers all of the following: what is the parameter called, what units is it in, what is the target, what are the upper and lower acceptance limits, what document approved those limits, is this a registered specification or an internal control limit, and what happens when the value falls outside the range. Anything the system cannot evaluate arithmetically stays in human review. That is fine. It just has to be stated.

This exercise usually reveals two uncomfortable things. First, a meaningful share of parameters in a legacy master batch record have no traceable source for their limits. They were carried forward from a technology transfer document or a supplier recommendation and nobody has revisited them. Second, some parameters that operators treat as critical are not in the specification at all, and some that are in the specification are not actually controlled.

2. In-line data capture from qualified instruments

The regulations already anticipate this distinction. Sampling and testing of in-process materials is required to be performed to assure batch uniformity and integrity, with control procedures established to monitor output and validate performance.³ The component charge-in requirements go further and call for a verification step on weights and measures.⁴ In a paper world that verification is a second person’s initials. In an electronic world it can be a scale reading that arrives directly from the instrument with its own identity, calibration status, and timestamp.

The 2025 draft revision of Annex 11 highlights the risk of manual data entry in place of electronic interfaces between systems, which is a clear signal about where inspector attention is heading.¹¹ If a value is important enough that you want a machine to check it, it is important enough to come from a machine.

3. Exception logic that is validated and under change control

The rules that decide what raises an exception are performing part of the production record review. Treat them accordingly. That means a written specification of each rule and its intent, test evidence that the rule fires when it should and does not fire when it should not, an identified owner, version identification on every rule set, and a change control path that requires quality approval before a rule is added, widened, narrowed, or retired.

The PIC/S guidance on computerised systems in regulated environments is explicit that regulated users remain responsible for ensuring systems are developed and maintained in a quality-assured way and that changes are controlled.⁹ A rule set that any superuser can edit from a configuration screen without a record of what changed and why is a finding waiting to happen, and it also destroys the evidentiary value of every previous release decision made using that rule set.

4. A documented rationale for what does not require review

This is the deliverable that separates a real program from a hopeful one. For each category of record content that a reviewer no longer reads, write down the reason. The reason is usually one of a small number of forms:

• The system performed the check and the check is validated. The value was captured from a qualified instrument, compared against an approved limit by a rule under change control, and recorded as conforming.
• The content is not risk-relevant to product quality. It exists for operational or business reasons and its absence or error would not affect a release decision. Say so, and say who decided.
• The content is covered by a different control. For example, an equipment cleaning status that is enforced by an interlock rather than by a record entry.
• It is reviewed, but on a sampling or periodic basis rather than every batch. Define the sampling plan and its statistical basis.

Write this as a controlled document, approve it through the quality system, and review it on a defined cycle. When an inspector asks why the reviewer signed a batch record without reading page 47, this document is the answer. Without it, the answer is that the site stopped reading pages because a project said it could.

5. Consistent equipment integration across the lines in scope

Sites frequently discover mid-project that the same unit operation is integrated differently on Line 1 than on Line 3, because the two lines were built eight years apart. One writes a temperature value every thirty seconds and one writes a summary at the end of the hold. The exception rules that work on one produce nonsense on the other. Either bring the integration to a common standard for the lines in scope, or accept a smaller scope and say so in the charter. A review by exception procedure that behaves differently by line is very hard to defend and very easy to get wrong.

6. A stable audit trail and a risk-based audit trail review procedure

Review by exception increases reliance on the audit trail, because the audit trail is now where a large part of the evidence lives. The draft Annex 11 revision devotes a substantially expanded section to audit trails, covering both the technical setup and the expectation of timely review.¹¹ If your audit trail is not queryable, not complete, or not reviewed on any defined basis, you are not ready. The audit trail review procedure and the review by exception procedure have to be designed together, because each is making assumptions about what the other covers.

The Exception Rate Problem

Here is the situation that quietly ends most programs. Twelve months after go-live, the system is raising exceptions on a large share of batches. Review time has not dropped. Somebody proposes widening the limits so fewer exceptions fire. The proposal is popular because it fixes the visible symptom immediately. It is also almost always the wrong answer.

A high exception rate is a signal with two very different possible sources, and the entire response depends on telling them apart:

1. The tolerances are wrong. The limits configured in the system are tighter than the approved specification, or tighter than the validated operating range, or set at a level that reflects an aspiration rather than the process’s demonstrated capability. In this case the process is fine and the rule is miscalibrated.
2. The process is genuinely not in control. The limits are correct, and the process really does drift outside them at the observed rate. In this case the exceptions are telling you the truth and widening the limits would suppress a real quality signal.

How to tell them apart

The diagnosis is not subtle, but it does require doing the work rather than debating it. Four questions resolve most cases.

Why widening limits is the wrong answer for the right symptom

Widening limits to reduce noise is attractive because it works instantly and nobody has to admit anything. It is the wrong answer for three reasons.

First, it may not be yours to do. If the limit derives from a registered specification or a validated range, changing it is a regulatory or validation activity, not a configuration change. Sites that quietly widen configured tolerances without recognizing the source of the limit create a gap between what the system enforces and what the filing says, which is a serious finding.

Second, it destroys the information content of the exception. The purpose of the rule is to distinguish batches that need attention from batches that do not. A rule widened until it almost never fires no longer does that. You have not achieved review by exception; you have achieved review by almost nothing, and the first time something goes wrong the investigation will ask why the system did not catch it.

Third, it treats a process problem as a documentation problem. If a process genuinely drifts outside its validated range on a large share of batches, that is a continued process verification issue. The FDA’s process validation guidance describes Stage 3 as providing ongoing assurance that the process remains in a state of control during routine production, with data collected, analyzed, and acted on.⁵ A high exception rate in an electronic batch record is one of the more direct pieces of Stage 3 evidence a site will ever generate. Suppressing it by widening the rule is deliberately discarding that evidence.

A metric set that keeps the program honest

That last one is worth stating deliberately. The FDA’s quality metrics work defines lot acceptance rate as a measure derived from specification-related rejected lots against lots attempted in the same period.⁶ If review effort falls and lot acceptance rate holds steady, the program is working. If review effort falls while lot acceptance rate slips, something has been switched off that should not have been.

What the Regulator Expects

There is a persistent misconception that review by exception is a regulatory concession that has to be granted. It is not. It is an approach to meeting an existing obligation, and the obligation itself does not change.

The quality unit still owns the release decision

Under 21 CFR 211.22, the quality control unit has the responsibility and authority to approve or reject components, in-process materials, and drug products, and the authority to review production records to assure that no errors have occurred, or that any errors that occurred have been fully investigated.¹ Section 211.192 requires that production and control records be reviewed and approved by the quality control unit before a batch is released, and that any unexplained discrepancy or specification failure be thoroughly investigated.²

Neither section says anything about how the review is performed. Neither prohibits a validated system from performing the comparison. But neither transfers the responsibility. The quality unit is answerable for the release decision whether it read 150 pages or three.

Recent enforcement makes the point directly. In a 2026 warning letter to a sterile injectable manufacturer, the FDA cited an inadequate investigation into severe environmental monitoring findings and noted that the quality unit approved the release of the affected lot despite a poorly supported root cause. The letter concluded that the firm’s quality unit “is not enabled to exercise proper authority and/or has insufficiently implemented its responsibilities.”¹⁷ The mechanism there was not review by exception. The principle is the same one: a release decision made on thin evidence is the quality unit’s decision, and calling the evidence a system output does not change that.

The same regulation appears repeatedly in current enforcement. A separate 2026 warning letter to a European sterile manufacturer cited the failure to thoroughly investigate unexplained discrepancies under 211.192 alongside findings on aseptic controls and laboratory records.¹⁸ Analysis of the MHRA’s published good manufacturing practice inspection deficiency reporting shows a similar concentration of findings in quality system and documentation categories.¹⁹ The FDA’s broader work on advancing product quality, including the voluntary quality metrics program, is aimed at the same underlying question of whether a site can demonstrate a sustained state of control rather than a compliant-looking record.²⁰ None of that changes because the record is electronic. It raises the standard for what the electronic record has to be able to show.

Annex 11 and the European position

EU GMP Annex 11 governs computerised systems used in regulated activities. The 2011 version established the core expectations on validation, data, accuracy checks, audit trails, and change control. The 2025 draft revision expands the document substantially, adding a dedicated section on alarms, a much larger treatment of audit trails including the expectation of timely review, and explicit attention to the risk of manual data entry where an electronic interface between systems would be more reliable.¹¹ Industry commentary submitted during the consultation reflects a broadly supportive but detailed engagement with these expectations.¹⁰

Two provisions bear most directly on review by exception. The expectation of accuracy checks on critical data entered manually is the reason in-line capture matters so much. And the audit trail expectations are the reason a review by exception procedure has to be designed alongside an audit trail review procedure rather than after it.

For European batch certification, Annex 16 sets out what the Qualified Person is confirming when they certify a batch, including that the batch complies with the marketing authorization and was manufactured in accordance with good manufacturing practice.⁷ A QP relying on a system-generated exception report is still personally certifying. That is a stronger form of the same principle as 211.22, and it tends to make European sites more careful about documenting the rationale for what they no longer read.

PIC/S and the inspector’s frame of reference

The PIC/S guidance on computerised systems in regulated environments was written to support inspectors and covers validation, lifecycle management, change control, electronic signatures, and security.⁹ It is a useful document to read from the inspector’s side rather than the vendor’s side. The questions it prompts are the questions you will be asked: how do you know the system does what you say it does, who can change it, how would you know if it stopped working, and what did you do about it.

The evidence an inspector will ask for

Evidence That the Exception Logic Is Trustworthy

The hardest question in a review by exception inspection is not whether the system is validated. Most sites can produce a validation package. The hard question is whether the specific rule that passed a specific value on a specific batch was working correctly on that date, and how you know.

Version the rule set, not just the system

System version alone is insufficient. Two batches made on the same system version can be evaluated by different rule sets if a configuration change happened between them. Every batch record should carry the identifier of the rule set version that evaluated it. This single practice resolves more inspection questions than any other, and it is often missing because rule configuration is treated as data rather than as code.

Test both directions

Validation of exception logic has to demonstrate two things, and most packages only demonstrate one. The first is that the rule fires when a value is out of range. That is the easy test and it is nearly always present. The second is that the rule does not fire when it should not, and more importantly that the rule is actually evaluating the value it claims to evaluate. A rule pointed at the wrong tag will pass everything silently. It will produce a clean exception report on every batch and it will be completely worthless. Negative testing and tag mapping verification are where this gets caught.

Regression test after every change, including infrastructure changes

Rule behavior can change without anyone editing a rule. A recipe change, an instrument replacement, a unit-of-measure change upstream, a system upgrade, or a change to how a historian aggregates data can all alter what a rule sees. Define a regression suite that runs after any change touching the data path, not only after changes to the rules themselves. The PIC/S guidance and Annex 11 both treat change control as a lifecycle obligation rather than a project activity for exactly this reason.⁹

Periodically prove the rules still work on real batches

Add a periodic verification to the procedure: on a defined cycle, take a sample of recently released batches and perform a full manual review of the record, comparing the result against what the exception report said. If the manual review finds nothing the system missed, that is evidence. If it finds something, you have an immediate quality issue and a rule defect, and you now know the scope of batches to assess. Sites that do this find issues early and small. Sites that do not find them during an inspection.

A Staged Adoption Path That Holds

The pattern is consistent enough to be predictive. Organizations that flip to full review by exception at go-live generally retreat within a year, because the first serious quality event produces an internal reaction that nobody wants to argue with: we should have been reading the record. Organizations that narrow the reviewed set progressively, with evidence at each step, tend to keep the ground they take.

The reason is not psychological. It is evidentiary. A staged path generates the parallel-run data that proves the rules work. A big-bang path asks the quality unit to trust rules that have never been compared against a human review of the same batch.

How long this takes

We are wary of giving a number, because the honest answer depends almost entirely on the state of the master batch records and the instrument integration at the start. What we can say is that the stages that consume the most calendar time are usually the ones with no software in them: rewriting master batch records into parameterized form, establishing traceability for limits that have none, and getting instrument data paths qualified. Sites that treat those as prerequisites finish faster than sites that treat them as parallel workstreams to be caught up later.

What Goes Wrong in Year Two

Programs that survive go-live can still fail slowly. Four patterns account for most of it.

Rule drift

Rules get widened one at a time, each with a locally reasonable justification, until the exception report is nearly always empty. Nobody made the decision to stop checking. It happened through twenty small approvals. The defense is the rule change metric described earlier: track changes per period with the reason for each, and review the pattern rather than the individual change.

Scope creep without rationale updates

A new product is introduced onto a line already running review by exception, and the existing procedure is applied by default. The rationale document was written for a different product with different critical parameters. This is one of the more common ways a site ends up unable to explain its own review scope. Make the rationale document a required input to product introduction.

The reviewer skill problem

Reading a full batch record teaches a reviewer what a normal batch looks like. Reading only exceptions does not. Over a few years, a quality organization can lose the tacit pattern recognition that lets an experienced reviewer notice that something is off even when every individual value is in range. This is a real loss and it is worth designing against: rotate reviewers through full manual reviews as part of the periodic verification, and treat that as training rather than as overhead.

Divergence between the record and reality

Over time, the way the process is actually run drifts from what the master batch record describes, and operators use comment fields to bridge the gap. Comment volume is a leading indicator worth trending. A step that consistently generates operator commentary is a step whose instruction no longer matches the work, and it is also a step where the exception logic is evaluating something other than what is happening.

Where continuous processes change the picture

For sites moving toward continuous manufacturing, the framing shifts. ICH Q13 addresses the scientific and regulatory considerations for continuous manufacturing of drug substances and drug products, including how batch is defined and how process monitoring and material traceability work in a continuous mode.¹³ In that setting, review by exception is not an efficiency option layered onto an existing paper process. It is closer to a requirement, because a human cannot review a continuous data stream line by line in any case. Sites planning continuous manufacturing should treat the prerequisite list in this article as foundational work rather than as a later optimization.

Similarly, sites pursuing real time release testing will find that the parameter definition and in-line capture work required for review by exception is largely the same work. The EMA guideline on real time release testing describes evaluating and ensuring quality based on process data through a valid combination of measured material attributes and process controls, which presumes exactly the data foundation described here.¹² The regulatory route is different and requires prior authorization, but the engineering and data work overlaps substantially. Organizations planning both should sequence them deliberately rather than running them as unrelated programs.

Conclusion

Review by exception is worth pursuing. Batch review is one of the few places in pharmaceutical operations where a large amount of skilled quality time is spent on an activity that adds very little judgment, and moving that time to the entries that actually need judgment is a genuine improvement in both efficiency and quality. The organizations that get there are not the ones with better software. They are the ones that did the unglamorous work first: defining every critical parameter with a limit that traces to an approved source, getting the data out of the instrument and into the record without a keyboard in between, treating the exception rules as controlled artifacts with owners and test evidence, and writing down why a reviewer is entitled to skip a page.

The exception rate is the honest measure of whether that work was done. A system generating exceptions on a large share of batches has not reduced review effort at all, and the response to it separates programs that hold from programs that retreat. Widening limits makes the number look better and makes the system worse. Diagnosing whether the tolerance was wrong or the process is not in control takes longer, produces uncomfortable answers, and is the only path that leaves you with both a shorter review and a defensible one. Throughout, the quality unit’s obligation under 21 CFR 211.22 does not move. What changes is what the reviewer spends their attention on, not who is answerable for the decision.

Sakara Digital works with pharma and biotech organizations on the data quality and process definition work that sits underneath programs like this. If you are running an electronic batch record that has not delivered review by exception, or you are scoping one and want an independent read on what has to be true before it will work, we are happy to have that conversation.

For Further Reading