The laboratory result is approved. Why is the batch still waiting?
For Quality managers and laboratory leads · Plan implementation
TL;DR — what you’ll learn
- Map ERP material and lot references to laboratory sample and test identities.
- Agree which result states can be exchanged and which system owns approval.
- Preserve units, methods, versions and corrected-result history.
- Separate successful transmission from the authorised inventory decision that uses the result.
The laboratory has approved the report, but production planning still sees the lot waiting for results. Someone downloads a PDF and emails a screenshot to the warehouse. That workaround may unblock today's conversation while leaving the ERP without a dependable record of the decision or the evidence behind it.
What should a LIMS-to-ERP integration exchange to support food batch decisions?
A LIMS-to-ERP interface needs a shared identity model and an agreed meaning for result states. It should transmit the approved information with its version and source reference, obtain an acknowledgement and expose rejected records. Sending a number between systems is only one part of the handover.
- 01Create the sample linkLot, test request and specification
- 02Receive result eventsVersion and laboratory status
- 03Validate the mappingUnits, methods and approvalIs the result accepted for this decision?YesUpdate the quality workflowNoKeep it pending and route the mapping or approval exception.
- 04Update the quality workflowRetain the source result
Illustrative information flow. The article explains the evidence, exceptions and responsible decisions. Diagram: NextEdge Labs.
Map the identities before mapping the fields
An ERP lot, laboratory sample and individual test are different entities. One lot may have several samples, and one sample may require several tests. Record those relationships explicitly. Using a single free-text batch number as the entire integration key can fail when suppliers, sites or product families reuse similar numbering patterns.
Start with a small identity map: company or site, material, ERP lot, sample reference, test reference and result version. Define which system creates each identifier. Where the source lacks a required reference, route the record for resolution rather than allowing the integration to guess the most recent open lot.
Define the state that is allowed to leave the laboratory
A recorded result, a reviewed result and an approved report can represent different stages. The integration contract should say which stage is eligible for exchange and what a later correction means. A draft result sent too early can be mistaken for final evidence if the ERP has only one result field.
The ERP's quality record and inventory decision remain distinct. Product documentation such as ERPNext's quality-inspection model illustrates how inspection information can be attached to operating records. Your design must specify which evidence enters that record and who is authorised to act on it.
Source: Frappe / ERPNext · Inspection records linked to incoming, outgoing and in-process activity. Reference details
Preserve the meaning around each value
Exchange the reported value or expression, unit, method reference where applicable, relevant dates and approval state. Keep qualifiers such as less-than expressions intact. If the systems use different test codes, maintain a reviewed mapping with an owner and effective version.
Do not treat a missing unit as permission to use the ERP's default. A record with incompatible or incomplete meaning should fail validation visibly. The laboratory and quality owners decide acceptable mappings and interpretations. Integration code should enforce those reviewed choices, not introduce scientific assumptions to make more records pass.
| Field group | Why it matters |
|---|---|
| Lot, sample and test references | Establish which material and observation the record describes |
| Result, unit and qualifier | Preserve the reported meaning |
| Approval state and version | Distinguish draft, approved and corrected evidence |
| Event ID and acknowledgement | Support reliable delivery and duplicate prevention |
A corrected result needs a correction event
Suppose result version 1 was approved and delivered, then a controlled laboratory correction produces version 2. Preserve both versions and the correction relationship. The receiving system should not silently overwrite the earlier result without indicating that the evidence changed.
Identify any decision that used version 1 and route the change through the site's quality process. The interface can flag the dependency and maintain status, but it should not independently decide the disposition of affected stock. Include a correction arriving after a downstream decision in acceptance testing; it reveals more than a successful first upload.
Design the recovery account
Every outbound event needs a stable identity, delivery status and receiving acknowledgement. A technical timeout can occur after the ERP accepted the record, so retrying should return or recognise the existing result. Keep rejected mappings separate from temporary connectivity failures; they require different owners and retry behaviour.
Give the laboratory and operations teams a readable queue: source reference, affected lot, reason, last attempt and next responsible action. Technical logs can support investigation, but they should not be the only place an operationally important failure is visible. Reconcile source approved records against accepted destination records for the pilot period.
Scope a first integration that can be proved
Choose one laboratory workflow, one material family and the result states already governed by an approved process. Collect redacted sample reports, identifier formats and examples of corrected or rejected records. Agree the destination fields and approval boundary before developing the interface.
A successful pilot demonstrates complete identity matching, retained result meaning, duplicate-safe delivery and a reviewed correction path. Measure unresolved handover age and manual re-entry effort. Do not promise faster scientific testing from an integration whose actual scope is moving approved information between applications.
Summary
LIMS and ERP integration needs agreement about identity, state and result meaning before it needs a connector. Acknowledged delivery and corrected-result handling complete the handover. That foundation lets the quality team use approved evidence while keeping authority over the decisions it supports.
What to do next
- Map one ERP lot to its laboratory samples, tests and approved result versions.
- Agree the state and field contract with laboratory, quality and ERP owners.
- Test a duplicate message, a rejected mapping and a corrected result after initial delivery.
Scope this automation around your operation
Tell us your current systems, transaction volume and the exception you need to resolve. We can discuss a bounded first release, its review controls and how to measure the result.
Sources and further reading
Sources checked 15 October 2026. The worked examples and software evaluation suggestions are NextEdge Labs’ editorial analysis.
- Quality InspectionFrappe / ERPNext · Online product documentation, accessed October 2026
Product examples of incoming, outgoing and in-process inspection records. Qualified quality staff determine the applicable tests and release rules.
Visual credits
AI-generated illustration created for NextEdge Labs; it does not depict a client facility. Workflow diagram by NextEdge Labs. Icons from Lucide (ISC licence).