Batch records that run your process.

1An electronic batch record is a controlled system of execution.

Electronic batch record software should change how manufacturing runs, not only where operators type. A PDF displayed on a tablet is still a document-driven process. People interpret the instructions, transcribe and calculate values, and the missing evidence and unreconciled materials surface in QA review after the batch has finished.

The batch record must show that the approved process was followed and that departures were visible, assessed and resolved.¹ Seal turns the approved master record into an executable workflow. The live record knows which process version, materials, equipment, people, limits, samples and signatures apply, checks evidence as it is created, and begins review while the batch is still running.

1.1Why teams choose Seal for electronic batch records

The master batch record is executable configuration in Seal: instructions, required fields, calculations and review steps on the same platform as materials, equipment, QC and quality. Neil builds proposed workflows from your procedures and prepares improvements from recorded exceptions and results. Your team tests and approves each new version. Batches in progress keep the version they started with; new batches run the released improvement.

Electronic signatures do not replace the underlying manufacturing requirements. FDA’s Part 11 guidance treats electronic-record controls as operating alongside the predicate rules, so the system must first create and retain the record the operation requires.²

2Master records define behaviour, and effectivity decides what runs.

A master manufacturing record contains approved process knowledge.³ Seal represents it as reusable stages and steps with explicit behaviour rather than page layout.

Authors reuse approved patterns for dispensing, line clearance, sampling or reconciliation without copying uncontrolled text between records. The displayed instruction is generated from the structured requirements, so the readable record is derived from the same definition as the executable logic rather than maintained separately. Authoring is itself controlled: draft, review, approval, effective and superseded states have defined permissions, and comparisons, signatures and validation evidence stay with the version.

The latest version is not always the correct one. Seal resolves effectivity for the product, site, market and start date when the batch is created, and records the versions selected. A later change does not rewrite work in progress. If an urgent change must apply to live work, authorised users define the transition point and approve the additional instructions, and both the original and changed course remain visible.

The batch instance then accumulates what actually happened, from the containers consumed and units created to the values recorded, the deviations raised and the final reconciliation. It is the as-executed state of the physical batch, not a filled-in copy of a document.

3Materials, equipment and people are checked at the point of use.

When an operator scans a container, Seal checks it against the effective process: identity and lot, status, expiry or retest date, reservation, quantity and eligibility for this batch. Dispensing can use connected balances and label printers, and the record keeps the balance, gross, tare and net weights, tolerance, source and destination containers, operator and verifier. Partial use updates the source container rather than creating an unexplained inventory adjustment.

A wrong material, rejected lot or quantity outside tolerance does not become a note discovered later. The normal transition is blocked and the approved resolution path begins. Substitutions, overages and returned material each follow their own accountable rule.

The instruction requests an equipment class; execution selects a physical asset. Seal checks its qualification, calibration, maintenance, cleaning and allocation status before the step can begin. People are checked the same way: a user account alone does not establish eligibility, so effective training, role and verifier rules are evaluated at the action. The record stores the state that allowed the work at that time. If a calibration or qualification is later found invalid, impact assessment can identify every affected batch action without reconstructing schedules and sign-in sheets.

4Data keeps its source, and limits control the next step.

Not every value should be typed, and not every automation signal belongs in the batch record. The design question is which evidence supports the accountable manufacturing action. Manual entries retain user, time, unit and correction history. Calculated values retain the formula version, inputs, rounding and result. Readings from balances, scanners and equipment interfaces retain their physical source, while DCS, PLC and historian systems remain authoritative for process control and supply the events, critical values or alarms the record needs.

Every interface defines ownership and failure behaviour. Seal records message identity, acknowledgement and retry, so a message delivered twice or not at all is visible rather than silently duplicated or lost. Operators can see when expected data is pending, and an integration fault is recorded as a fault rather than as a completed step.

A red border on a field is not an exception strategy. Each controlled value has a range and a configured response: continue, require verification, repeat the observation, create a sample, place the batch on hold or open a deviation. The original value and the system’s evaluation stay visible even when the authorised process continues. Calculations such as yield, potency adjustment or material balance are versioned process logic, so a changed formula is a controlled revision tested against representative cases before it takes effect.

5Exceptions and signatures stay inside the execution history.

Paper encourages people to write around problems. Seal makes abnormal paths part of the process: correction, variance, alarm, intervention, deviation, rework, repeat, abort and not-applicable work each have their own permissions, rationale, evidence and approval rules, and the planned path remains visible.

A deviation opened from a step inherits the batch, process version, materials, equipment, values, people and time window, so containment and impact assessment start with a defined population. Authorised rework creates additional executable work without altering the original course. The record answers both what happened and how the quality system responded.

A signature identifies the record, signer, time and meaning of the act; performing, verifying, reviewing and approving are different decisions. Seal binds each signature to its record,⁴ can require the verifier to be different from the performer and reauthentication for critical actions, and applies the configured behaviour when a signed entry changes. The audit history preserves original and changed values, reasons, users and times, and covers administrative configuration as well as operator fields. FDA’s data-integrity guidance frames the goal as complete, consistent and accurate data across the lifecycle;⁵ a well-designed batch record produces that as the normal output of execution.

6Review begins during the batch, and release uses the live record.

Traditional review starts when the packet reaches QA, and reviewers search every page for missing entries, arithmetic errors, late signatures and unexplained changes. Seal evaluates completeness and exceptions continuously. Reviewers can see completed stages and focus on what needs judgement: values outside limits, corrections and overrides, alarms and interface failures, material or training exceptions, reconciliation outside expected limits and open samples or deviations. Every instruction, value and signature remains available; review by exception directs attention without hiding the batch.

QA can disposition the batch only when the effective release requirements are resolved. Approved, rejected, restricted and pending states remain distinct, and the decision updates the eligible containers and inventory without a second manual status change. The human-readable batch record is generated from the governed data for inspection and archive, while the underlying records stay searchable for investigations, product reviews, continued process verification, complaints and recalls. See batch release for the disposition workflow.

7Plan continuity and migration before go-live.

Electronic execution changes the failure model. Define what happens during an application, network, device, identity-provider, interface or printer outage: the critical steps, safe hold points, queued interfaces and approved contingency records. When service returns, reconciliation establishes which actions occurred and which data arrived, so the official record is completed without duplication or silent transcription. Contingency is a tested procedure for a defined failure, not permission to run a shadow paper system.

Copying every line of a legacy paper record into fields reproduces its ambiguity and review burden. Classify each element instead: instruction, verification, observation, calculated or automated value, laboratory decision, signature, exception path or output that can be derived from data already held. Redesign duplicate prompts, retrospective entries and manual calculations. Migrate active master data, open batches, current inventory and equipment state with controlled reconciliation; closed paper packets can often stay in a validated archive rather than being re-keyed.

8Validate one representative record with failure paths.

Validation should demonstrate intended use and risk controls, not only that the buttons work. Annex 11 expects the application to be validated.⁶ Replacing a manual operation should not reduce product quality, process control or quality assurance. Start with one representative product and exercise:

1. authoring, approval and effectivity, including correct version resolution for a new order;
2. valid and invalid material and equipment scans;
3. manual, calculated and integrated data capture;
4. limits, holds, corrections, deviations and rework;
5. signatures, verifier rules and changed-record behaviour;
6. interface failure, service interruption and recovery;
7. concurrent review, disposition, retrieval and genealogy from the released batch.

The batch record is ready when operators can run the real process, QA can understand abnormal execution without reconstructing it, and the organisation can recover from failure without losing the authoritative record.