Electronic batch records: what actually changes when the paper goes
An electronic batch record captures the complete manufacturing history of one batch as it is produced: materials consumed, process steps, equipment, operators, results and signatures. Unlike a scanned paper record, it validates entries as they are made, which is what enables review by exception instead of reviewing every page.
The mistake worth avoiding first
The most common failed EBR project digitises the document rather than the process.
A batch record is filled in on paper, then scanned, then filed in a document system.
Retrieval is faster. Nothing else improves.
Whatever was wrong when it was written is still wrong, only now it is a PDF.
And the review burden, which is where most of the cost actually sits, is unchanged.
An EBR is not a document that gets digitised. It is a record that assembles itself while production runs.
The distinction is not semantic. It determines whether the project returns anything at all.
What an EBR contains
An electronic batch record is the complete manufacturing history of one batch, gathered as it happens.
| Content | Captured from |
|---|---|
| Materials | Every lot consumed, with quantity, timestamp, and the operator who dispensed it |
| Process steps | Each step performed, with equipment, start and end times, and parameters used |
| Equipment | Which units ran the batch, and their state and calibration status at the time |
| In-process results | Measurements and inspections, with their specification limits |
| Deviations | Anything out of specification, its investigation and its disposition |
| Signatures | Who performed, checked and approved each step that requires it |
Two properties separate this from a digitised document.
It is generated, not filled in.
Most content arrives as a by-product of executing the work. The operator consumes a lot, and the record gains a line.
Nobody transcribes anything.
It is validated at entry.
An out-of-range measurement is refused or flagged at the moment it is entered, not discovered during review.
A step cannot be signed as complete if a required check is missing.
Rules that used to be printed as instructions become behaviour of the system.
Review by exception is the actual return
The cost of paper batch records is rarely in filling them in.
It is in reviewing them.
In a regulated plant, someone reads every page of every batch record before release. Looking for missing entries, transcription errors, out-of-specification results and absent signatures.
It is slow. It is done by expensive people. And because it is repetitive, it is exactly the task humans are worst at doing reliably.
Review by exception inverts this.
Because the system enforced the rules during production, most entries are known to be within specification.
The reviewer’s attention goes to what deviated. Out-of-specification results, overridden defaults, timings outside normal, missing or late signatures.
This is where batch release time collapses. It is the return that justifies the project.
But it depends entirely on one precondition.
The system must actually have enforced the rules during production.
If entries were merely recorded rather than checked, exceptions cannot be trusted to be complete, and the reviewer is back to reading everything.
This is why data integrity comes first and review by exception second. Attempting them in the other order produces a system that is trusted for neither.
Where implementations go wrong
Recreating the paper form on screen.
Paper forms are shaped by the constraints of paper. Everything on one page because turning pages loses context, fields grouped by who fills them in.
A screen has different constraints. Reproducing the form faithfully usually produces something slower to use than the paper it replaced, and operator resistance follows quickly.
Requiring signatures at every step.
Each signature is an interruption.
When signatures are demanded where a regulation does not actually require one, the usual result is shared credentials at the terminal.
That destroys attributability for every record from that terminal, not merely the over-signed ones.
Ignoring the exception path.
Real production deviates. A material substitution, a step out of order, an unplanned hold.
If the system has no legitimate route for these, people find an illegitimate one.
The record then stops matching what happened, which is worse than the paper it replaced.
Treating retention as a later problem.
Records have to stay readable for their full retention period, across system upgrades and migrations.
A format that depends on the application that wrote it becomes a problem years later, when that version no longer exists.
Verification without trusting the system
One property is worth asking about specifically.
Can a batch record be verified by someone who does not have access to the system that produced it?
An auditor holding a printed record generally has to trust that the system it came from was not tampered with.
That is a weak position, and it is avoidable.
If each record carries a content hash, and signatures are chained so that each one covers the content it signed, then any later alteration breaks the chain visibly.
Made independently checkable, verification stops depending on trusting the issuing system. Paste the hash from a printed record and confirm it matches, without logging in.
For an auditor, that difference is substantial. The evidence stands on its own rather than on the credibility of the vendor.
Where VECHR MES fits
VECHR MES assembles the batch record as production runs, rather than as a document produced afterwards.
Material consumption is captured at the point of picking under enforced FEFO or FIFO rules.
Process steps carry their equipment, operator and timestamp.
In-process results are checked against their specification limits at entry, and an out-of-specification result can place an automatic hold rather than being noted for later.
Electronic signatures are hash-chained, so each signature covers the content it signed and any subsequent change breaks the chain.
Batch records export as documents that can be verified independently. A hash from a printed record can be checked without a login, so verification does not rest on trusting the system that issued it.
Because execution, quality, materials and equipment share one data model, the record does not have to be assembled from several systems at release time. It is a view of data that was already connected.
The regulatory frameworks around this are covered in 21 CFR Part 11 for manufacturers and CPOB and computerised systems.
Frequently Asked Questions
Is an EBR the same as a scanned paper batch record?
No, and the difference is the entire point. A scan is an image of a completed document, so the errors it contains are already in it. An EBR is generated as production happens and validates each entry at the moment it is made. Out-of-range values and missing steps are caught before the batch continues rather than found during review weeks later.
What is review by exception?
Instead of a reviewer reading every page of every batch record, the system flags only the entries that deviated. Out-of-specification results, overridden defaults, unusual timings, missing signatures. The reviewer examines those. It only works if the system reliably enforced the rules during production, which is why data integrity has to come first.
Does an EBR require an MES?
Not strictly, since standalone EBR products exist. But an EBR is assembled from material consumption, process execution, equipment state and quality results, which is exactly what an MES already records. Running them separately usually means entering the same data twice, or building integration to avoid it.
How long do electronic batch records have to be kept?
Retention periods depend on your regulator, product type and market, commonly a defined number of years past product expiry. What matters technically is that records stay readable for that whole period, including across system upgrades and migrations. That requirement catches many implementations by surprise.
What is the difference between an MBR and an EBR?
The MBR, or master batch record, is the approved template describing how a product should be made. The EBR is the record of one specific batch actually being made against that template. In ISA-88 terms, the MBR corresponds to the master recipe and the EBR to the executed control recipe.