Electronic Batch Record: Understanding the Executed Batch Record

An Electronic Batch Record documents the batch that was actually executed

Electronic Batch Record is often reduced to the idea of a “digital batch record”. That is useful only if “digital” is not confused with “scanned” or “stored electronically”.

An EBR is not merely an empty template or an electronic form. It is the electronic record of the batch that was actually executed. Its content therefore comes from real activities: an executed step, a material issue, a captured measurement, a test result, a confirmation, a deviation or a release decision.

EU GMP Chapter 4 treats records as part of the documentation system that should, among other things, provide a history of each manufactured batch, including its distribution. The chapter also states that regulated users should define which data are to be used as raw data.^[1] The record question therefore does not begin at archiving. It begins with deciding which information represents the actual process.

For batch documentation, one distinction is fundamental: approved instructions describe the intended process. The batch record documents the batch that was actually executed.

The master record and the executed batch record are different layers

EU GMP places these layers next to one another. Chapter 4 first describes the Manufacturing Formula, Processing Instructions and Packaging Instructions. Only after those approved instructions does it define the Batch Processing Record and the Batch Packaging Record.

The two layers therefore serve different purposes:

Master instructions: What is intended to happen for a given product or process under the approved version?

Executed batch record: What actually happened for a specific batch?

US CGMP makes the same structural distinction. 21 CFR 211.186 governs Master Production and Control Records. 21 CFR 211.188 requires a Batch Production and Control Record for each batch containing complete information on actual production and control.^[2][3]

This distinction is central to an EBR system. A new batch should not simply start from an arbitrary copy of an old record. Execution must be based on the approved and applicable master instructions. The resulting record then captures the actual execution of that specific batch.

It also resolves a common terminology problem: an Electronic Master Batch Record and an Electronic Batch Record are not the same thing. The master defines the approved intended state. The executed record documents batch reality. “Master instruction” is used here as an editorial umbrella term: EU GMP Chapter 4 does not use the US term “Master Batch Record”; it refers in particular to the Manufacturing Formula and Processing Instructions, and to Packaging Instructions for packaging. Functionally, these approved instructions form the intended layer from which the Batch Processing or Batch Packaging Record is created.^[1]

The record is created during batch execution

A robust EBR is not strongest when information is copied from multiple systems after production has ended. Its strongest form is created during execution.

When a material is assigned to a step, that relationship can become part of the batch context immediately. When a process parameter is captured from connected equipment, the value can remain linked to batch, step and time. When one person confirms a step or another role checks a significant activity, that relationship belongs in the record as well.

Not every item needs to be entered manually. One of the strengths of an electronic record is that known context can be reused and technical data can be captured where they arise. What matters is that the information remains linked to the correct batch activity.

A complete EBR can provide the basis for automated compliance evidence. A specific, verifiable statement is derived from recorded activities, while the EBR preserves the complete batch-specific record beyond that statement.

An EBR connects execution with its data sources

A batch record rarely originates in only one technical system. Material and inventory information may come from ERP or inventory systems, laboratory and test results from LIMS or QMS environments, and process parameters from machines, scales or sensors. An MES may coordinate operational manufacturing execution, while specialised equipment can provide its values directly. For batch traceability across processing stages, the incoming batches actually used and the output batches produced must also remain connected across the individual records.

For the EBR, the number of interfaces is not the decisive point. What matters is whether imported information remains unambiguously linked to the correct batch, execution step and time. Automated transfer can reduce manual transcription, but it does not make an incorrect object assignment correct.

An EBR system should therefore do more than import data. It should make it possible to understand where information originated, how it entered the batch context and what role it plays in the executed record. Regulated users must also define which data are treated as raw data.^[1]

Example: Batch PB-2041

A fictional batch example shows the difference between approved instructions and the executed record. Batch PB-2041 is started from the approved master instruction MV-17, version 4. At the third execution step, material from batch RM-506 is weighed and the actual quantity used is captured in the batch record. Connected equipment MX-3 provides the relevant process parameter directly to the associated execution step.

At step 7, an in-process result falls outside the target range defined for this example. The process is therefore not simply advanced as “completed”. Deviation DV-2041-01 is created within the record and linked to PB-2041 and the affected process step. Assessment and approval of the deviation are recorded with the responsible role before execution continues.

At completion, the record therefore contains more than a final status for PB-2041. It preserves the applicable master version, the material batch and actual quantity used, relevant equipment data and process parameters, the in-process result, the deviation and its approval, and the subsequent review and release in the context of the executed batch. That context is what distinguishes an EBR from a collection of separate documents assembled after the fact.

Regulations shape the information that must be available in the batch record

EU GMP Chapter 4.20 provides a particularly concrete content structure.^[1] For each processed batch, a Batch Processing Record should be kept, based on the currently approved Manufacturing Formula and Processing Instructions.

The record should make available, among other things:

• the name of the product and the batch number;
• dates and times of commencement, significant intermediate stages and completion;
• identification of the persons performing significant process steps and, where appropriate, the persons checking those activities;
• the actual quantities of materials used together with relevant batch identification;
• significant processing operations and major equipment;
• in-process controls and the results obtained;
• yields obtained;
• deviations from approved instructions together with documented authorisation;
• approval by the responsible person.

The recorded material quantities and yields also provide the basis for quantity reconciliation. A documented connection between input and output batches does not, by itself, explain a quantity difference.

Chapter 4.21 provides a corresponding batch-specific record requirement for packaging operations.

21 CFR 211.188 follows the same underlying idea within a different regulatory structure.^[3] A Batch Production and Control Record must be prepared for each batch and contain complete information relating to production and control. That includes the applicable master record, significant processing steps, major equipment, materials and components, in-process and laboratory results, and identification of persons performing or checking significant steps.

The two rule sets are not identical. But both draw the same line against a simple digital checklist: an Electronic Batch Record must be capable of representing the actually executed batch as a coherent record.

Deviations and corrections belong to the record and must not overwrite its history

Real batches do not always follow the planned path exactly. A measurement may fall outside an expected range. A step may have to be repeated. An entry may require correction. A deviation may need assessment and approval.

Those events are not disturbances outside the record. If they are relevant to the batch, they belong to the record.

For an EBR, that means a deviation should remain linked to the affected step and batch. A correction should not replace the earlier state as if it had never existed. The record should be able to show what was originally documented, what was later changed or supplemented, and how that change was handled.

A correction event extends the history with the controlled correction and its reference to the original entry. The earlier state remains traceable.

The Audit Trail then makes it traceable which changes were made and how they can be reconstructed.

At EBR level, the consequence is simpler: a complete batch record contains not only the final state but the relevant history of execution.

Review by Exception must be separated from audit-trail review

The term Review by Exception is used in more than one context. A careful EBR article therefore needs to separate those uses.

PIC/S PI 041-1 uses the term in the context of audit-trail review.^[6] Systems may identify exceptions, anomalous activity or unauthorised activity so that reviewers can focus their attention on those events. That is a statement about reviewing audit trails — not automatically a definition of the entire EBR batch-review process.

EU GMP Chapter 4 contains a separate note that is highly relevant to the batch record.^[1] Where a validated process is continuously monitored and controlled, automatically generated reports may be limited to compliance summaries and exception/OOS data reports.

That is a different reference point. It does not mean that the underlying batch record can omit required information. Rather, a controlled and validated process may structure the review presentation so that compliant execution is summarised and relevant exceptions are highlighted.

For an EBR, that distinction matters: the complete record and the efficient review view are not the same thing. The record remains complete; the review interface may focus attention on what actually requires review.

PIC/S section 9.8 links the scope of electronic data review to data criticality. Summaries used for reporting need evidence of verification against the raw data. For the EBR, a concise review view must therefore remain connected to the relevant source data and changes; it must not conceal information needed for the batch decision.^[6]

Electronic signatures and audit trails do not by themselves make a system an EBR

An electronic batch record needs controls for electronic records. But a system does not become an EBR merely because it has an audit trail and electronic signatures.

21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails for actions that create, modify or delete electronic records. Record changes must not obscure previously recorded information.

21 CFR 11.50 requires signed electronic records to display, among other things, the printed name of the signer, the date and time, and the meaning associated with the signature — for example review, approval or responsibility.

EU GMP Annex 11 likewise addresses audit trails and electronic signatures.^[4][5] Both controls are important for a credible electronic record. They solve a different problem from the substantive completeness of the batch record itself.

A system can have an excellent electronic signature and still fail to maintain a complete batch record. Conversely, a data-rich record is not enough if relevant changes cannot be reconstructed or an electronic release cannot be attributed clearly.

Record completeness, audit trail and signature meaning must work together.

An EBR system must do more than store batch data

For procurement and system assessment, one practical question is especially useful: Can the software create and preserve a complete, controlled execution record for each batch? A database containing batch numbers or an electronic form does not automatically satisfy that task.

A credible EBR system should be able to demonstrate at least that:

1. approved and versioned master instructions govern the concrete batch execution;
2. significant steps, times and responsible persons or roles remain part of the executed record;
3. materials, equipment, process parameters and test results are unambiguously linked to the batch and relevant steps;
4. deviations and corrections remain visible in batch context without obscuring earlier information;
5. review and release are documented with a clear person or role and the meaning of the approval;
6. audit trails and electronic signatures support the electronic record without replacing its substantive content;
7. the complete batch record remains exportable and reviewable, including the information required to understand its history.

These points are not an additional regulatory checklist beside EU GMP or US CGMP. They translate record requirements into questions that can be tested during a product demonstration or system assessment.

PIC/S section 9.9 permits true copies of dynamic electronic records provided that their entire content and meaning are preserved, including all data and relevant metadata. Storage also needs to include audit trails and maintain readability and access.^[6] A clear PDF summary is therefore not automatically a true copy of the complete batch record. For PB-2041, it must remain possible to reconstruct the relationship between the measurement, deviation DV-2041-01, and subsequent approval.

The required format depends on what must remain verifiable. PIC/S sections 7.7.2–7.7.3 allow static retention where preservation of the original data’s integrity is justified and accurate representation is verified through a documented process. A dynamic format must be retained where it is critical to integrity or later verification; whether and for how long it is needed must be justified through risk management.^[6] This is not a general requirement for every EBR export to be dynamic. A static review export may be suitable if the complete record and any necessary dynamic source data remain controlled and accessible. The export’s purpose and scope must be clear.

EBR, MES and workflow software describe different layers

Electronic Batch Record, Manufacturing Execution System and workflow software are often discussed together in procurement projects. They describe different capabilities and layers of a system and are not mutually exclusive categories.

An Electronic Batch Record describes the batch-specific record capability: the ability to represent the actual execution of a batch electronically and preserve it as a controlled record.

A Manufacturing Execution System (MES) is typically a broader framework for operational manufacturing execution. An MES may include EBR functionality and workflow control, but it is not limited to the batch record itself.

Workflow software structures tasks, hand-offs, decisions and process steps. A system can therefore be workflow software while also providing EBR functionality. What matters is which substantive capabilities are actually implemented.

The better procurement question is therefore not which label a system carries. One key question is: Can it create and preserve a complete executed record for each batch, including relevant deviations, review and release?

Moving from paper to EBR is not a form-digitization project

One of the weakest digitization strategies is to reproduce the existing paper logic on a screen as closely as possible.

A paper form may contain fields only because information had to be copied manually from another source. It may require signatures at points where an electronic system already has clear role and state information. And it may record the same information several times because relationships between separate documents would otherwise be difficult to reconstruct.

An EBR project should therefore not begin with the question of how to reproduce the existing paper form pixel by pixel. More useful questions are:

• Which approved master instructions govern execution?
• Which data are raw data and where do they originate?
• Which information can be captured from systems or equipment?
• Which observations or assessments require human input?
• Which deviations must become visible during execution?
• Which roles may execute, review and release?
• Which information must the complete batch record carry at the end?

Those answers define the electronic record logic. An electronic form may be part of that logic. It is not the definition of the EBR.

Before defining a complete EBR project, an organization can first select a single handover as a digitization use case. This requires describing the operational problem and available information. Such a limited improvement does not yet implement a complete EBR.

Limits of an Electronic Batch Record

A complete electronic record does not automatically make the underlying process correct.

If the wrong master instruction has been approved, an EBR can document the wrong instruction very reliably. If equipment is assigned incorrectly, an automatically captured reading can still be attributed to the wrong batch. If a deviation remains unresolved, electronic storage does not make it acceptable. And if roles or permissions are configured incorrectly, a clean audit trail does not create correct domain responsibility.

The definition of raw data also remains critical. If an organization does not define which data constitute the authoritative original information for a process, a later electronic summary can look complete while still omitting essential source information.

An EBR is therefore not a substitute for process design, data integrity or governance. It is the electronic form in which the actually executed batch can be assembled and preserved as a controlled record.

Frequently asked questions about Electronic Batch Records

Is an Electronic Batch Record the same as a Master Batch Record?

No. The master layer defines the approved intended process; the Electronic Batch Record documents the batch that was actually executed. US CGMP makes this separation explicit in 21 CFR 211.186 and 211.188. In EU GMP, the Manufacturing Formula and Processing Instructions form the approved instruction layer, followed by the executed Batch Processing Record in Chapter 4.20.^[1][2][3]

Does an Electronic Batch Record have to comply with 21 CFR Part 11?

Where an EBR is used as an electronic record within the scope of FDA requirements in place of required paper records, the applicable Part 11 requirements need to be considered. Part 11 does not, however, define the substantive content of the batch record. That content is shaped by the applicable CGMP record requirements. For an EBR, 11.10(e) on audit trails and 11.50 on signature manifestations are particularly relevant.^[2][3][4]

Is an EBR the same as an MES?

No. An EBR is the batch-specific record or system capability. An MES typically provides a broader framework for manufacturing execution and may include EBR functionality.

What should an Electronic Batch Record contain?

The exact content depends on the applicable regulatory framework and process. EU GMP Chapter 4.20 lists, among other things, product and batch identification, relevant times, operators and checkers, materials used, significant operations and equipment, in-process controls and results, yields, deviations and responsible approval. 21 CFR 211.188 provides its own US CGMP structure for the Batch Production and Control Record.^[1][3]