An MES is the system that turns a master recipe into a batch record, and that makes it the most consequential software in a plant. A LIMS can produce a wrong result. An MES can produce a wrong batch and then document it as correct.
PAS-X, Opcenter, Rockwell and Körber differ substantially in architecture, but MES validation goes wrong in the same places regardless of platform: recipe management, the electronic batch record, weigh and dispense, and the equipment interfaces that make all three real.
This is how we approach MES validation, and where the evidence has to be strongest.
Recipe management is the control point
Everything else in an MES is downstream of the recipe. If a master recipe can be changed by someone without the authority to change it, or changed without the change being approved and visible, then no amount of testing elsewhere in the system matters.
Test the lifecycle rather than the content. Who can create a recipe, who can approve one, whether the two can be the same person, whether an approved recipe can be edited in place or only superseded by a new version, and what happens to batches already in flight when a new version is approved. That last question is the one most often unanswered at go-live, and it has a real answer that should be a deliberate design decision rather than whatever the software happens to do. Recipe versioning is change control in all but name, and Change controls is how we keep the two joined.
Then test parameter boundaries. A set point with limits is only as good as its enforcement. Try the value above the limit, the value at the limit, the empty value and the value with the wrong unit.
The electronic batch record and review by exception
Review by exception is the main reason to buy an MES, and it is also the control that is most often weaker than it appears. The premise is that a reviewer examines deviations rather than reading every entry. That premise holds only if the system reliably identifies every exception.
So the validation question is not whether exceptions are displayed. It is whether anything can complete without being either compliant or flagged. The tests worth writing are the awkward ones: a step completed out of sequence, a step completed by a user whose training record has lapsed, a value entered late, a value corrected after the fact, a comment added after the batch is closed.
If any of those can pass through without surfacing, review by exception is not a control, and the batch record is a document that looks complete because nobody was told otherwise.
Weigh and dispense
This is the part of an MES where software errors become physical. The controls are straightforward to describe and easy to get subtly wrong: material identity, container identity, expiry and retest dates, scale selection and its calibration status, tolerance enforcement, and what happens on an over-dispense.
Test the rejection paths first. A material with an expired retest date. A container already consumed by another batch. A scale outside its calibration interval. A weight outside tolerance, both above and below. A second dispense against a quantity already satisfied. In each case the system should refuse and record the refusal, and the recording matters as much as the refusal.
Scale integration deserves its own tests rather than being bundled with the dispense workflow. A manual override of a captured weight should be possible only with a documented reason and a second signature, and that behaviour should be proven rather than assumed from a configuration screen.
Equipment interfaces and the Annex 15 boundary
An MES talks to equipment, and equipment is not software. The qualification of a vessel, a filler or an autoclave sits under Annex 15 of the EU GMP guide as installation, operational and performance qualification of the equipment itself. The MES interface to that equipment is software and is validated as software.
Conflating the two produces the same failure mode as in the laboratory: a package that proves the equipment was qualified and says little about whether the MES read it correctly. Keep the evidence sets separate and test the join. What happens when a piece of equipment reports a value outside its expected range, stops reporting mid-batch, or reports a status the MES does not recognise. The correct behaviour is usually to hold the batch and escalate, and that is a test case, not a design assumption.
Classification, honestly
MES implementations are configured heavily and extended frequently. The GAMP category therefore belongs to your implementation rather than to the product. Standard configuration of supplied functionality is category 4. Custom-built recipe logic, bespoke interfaces and reports written for you are category 5, and the validation depth follows.
Doing this classification after design rather than during procurement is the single change that most improves MES validation planning. Before design you are guessing; after design you can read what was actually built. GAMP 5 Second Edition consulting is where we do this work, and it usually reduces total test effort rather than increasing it, because it stops scripted testing being applied uniformly to functionality that does not need it.
A CSA-native test strategy for MES
MES is where unfocused scripted testing does the most damage, because the system is large and the temptation is to test it evenly. Testing evenly means under-testing the recipe lifecycle and over-testing the user interface.
Under the FDA's Computer Software Assurance guidance, finalised in September 2025 and reissued in February 2026, depth follows risk per requirement. For an MES that means scripted, boundary-focused testing on recipe approval, exception detection, dispense tolerance, electronic signature and equipment interface failure handling — and unscripted testing on the broad surface of navigation, dashboards and standard reporting.
Vendor evidence has a real place here too. Platform infrastructure, core database behaviour and standard supplied functionality that the vendor tests and will document are candidates for a vendor-evidence test path. The requirement is that you assess it and record the assessment, which supplier qualification covers properly.
Data integrity in a batch context
The ALCOA+ principles apply, and in an MES the one that breaks most often is contemporaneous. A step completed at the workstation an hour after the operation is a data integrity question, not a usability one. Decide whether late entry is permitted, how late, what it requires, and how a reviewer sees it.
The other recurring gap is audit trail review. The trail is complete and nobody reads it. For a batch system the review should be targeted: changes to approved recipes, overrides of dispense tolerances, late entries, and signature events outside expected shift patterns. Signatures themselves have to meet 21 CFR Part 11 on the same terms as anywhere else. data integrity (ALCOA+) is where we define this so it survives the first busy month after go-live.
Where to focus if the estate is already live
Most MES work is not greenfield. If you have inherited a validated MES and do not trust the documentation, three checks will tell you most of what you need. Does the configuration specification match the live configuration today. Can you produce a traceability matrix, and does it show any gaps at all — a matrix that has never shown a gap has not been stress-tested. How many changes has the system had since go-live, and how many have an impact assessment attached.
If any of those takes more than a few minutes to answer, that is the gap, and it was there before anyone looked. MES validation and audit readiness are the practices, and book a demo if you want a view on a specific estate.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.
