Custom software for BRCGS traceability and mass balance
BRCGS requires a traceability test demonstrating that you can trace forwards and backwards, including mass balance, and do so within four hours. Most companies manage it, but with two people, a stack of printouts and an afternoon. Four hours is not a performance target; it is a test of whether the data is all in one place.
Where the four hours go wrong
BRCGS Food Safety is at Issue 9, mandatory for audits since early 2023. That version has a limited set of fundamental requirements, and traceability is one of them. A major non-conformity against a fundamental requirement is a different kind of problem from an ordinary deviation: it affects the certification itself, not just the grading.
The test has two halves that fail in different ways. Tracing forwards and backwards is a search: which raw material lots went into this finished product, and where did that finished product go. That usually works, provided everything was recorded. The mass balance is the arithmetic around it: does what came out match what went in, including losses and reprocessing. That is where it more often falls apart, because reprocessing and residual lots are precisely the things nobody records.
What the four hours really measure is whether the link between parties was recorded at the moment it was created. If that relationship is in place, the trace is a lookup that takes seconds. If it isn't, it becomes a reconstruction from production lists, weighbridge tickets and a shift supervisor's memory, and four hours is tight. No reporting package can fix that after the fact.
How we build this
The link between incoming and outgoing parties is the core of the work. Once that is in place, the trace is simply a lookup.
Every step where a lot is combined or split must record that relationship. One missing link makes the entire chain unusable, even if everything else is perfect.
Residual lots returned to the line are the most common break. We start there, because that is where a mass balance in practice fails to close.
Not once a year during the test, but per production order. That way a discrepancy surfaces on the day itself, when someone still remembers what happened.
We run the traceability test on random batches from the past and measure how long it takes. Whatever gets stuck there will still be stuck when the auditor arrives.
What the software actually does
The batch register with its mutual relationships carries everything. What else you need depends on your process and on what is already being recorded.
Party link recorded at the point of action
Which incoming batch ends up in which outgoing batch is recorded the moment it happens. Reconstructing it afterwards is why the test takes four hours.
Forward and backward traceability
From finished product to every raw material batch, and from raw material batch to every customer, in a single query. That is half the test, and it works without a gap.
Mass balance per order
What went in against what came out, including losses and rework. Continuous calculation shows a discrepancy on the day itself rather than at the annual test.
Root cause analysis with preventive action
After an audit, short deadlines apply for correction, root cause analysis and a preventive plan. A correction without a root cause is not accepted as closed under BRCGS.
Monitoring the deadline after the audit
From the end of the audit, there is a short period in which everything must be submitted. That deadline belongs in the system, not in someone's diary.
Connecting to production and stock
Parties originate in your production system or your connected systems. We pull them from there, because a second entry creates a second version of the truth.
Who we build for
Where the chain breaks depends on the process. Four situations.
Production and processing
Blending, rework and residual batches make the balance difficult. The gain lies in recording what goes back onto the line.
Storage, repackaging and distribution
Batches split into smaller units and go to many customers. The challenge is keeping the outgoing side complete, not the incoming side.
Private label for retail
Your customer sets their own traceability requirements on top of the standard and tests independently too. Two frameworks on one record is the difference between work and duplicate work.
Sites with multiple production lines
A party that moves between lines or locations is where the chain usually breaks. Floor checks run through the batch linking app.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology and integrations
Standards are revised and clause numbers shift accordingly. Everything related to requirements, deadlines and tolerances should be configurable and kept per version.
Why Appfront
The trace is created while the work is done
We build the recording of the link at the moment it happens. A reporting package cannot invent a missing link after the fact.
The mass balance is where things go wrong
We have it calculate continuously rather than once a year. A discrepancy from last week can still be investigated; one from last quarter often cannot.
The cause belongs with the correction
We build root cause analysis and preventive action into the workflow, because a correction without a cause does not count as closed.
We rehearse the test
We run the trace on random batches and time it. That is the only way to know whether four hours is achievable.
Security and privacy
A batch register exposes your recipes and your suppliers: whoever can see which raw material batches went into which finished product knows your formulation. We restrict access by role, give a customer in a portal only their own shipments, and log every access.
For traceability, the record itself is the evidence. A party link that can be altered after the fact undermines the entire chain, and in a product recall it is the first thing an inspector examines. We therefore record party links immutably, with timestamp and person, and any correction is shown as a visible correction alongside the original value. How we handle security ourselves is set out in our information security policy; reports from outside go through our vulnerability disclosure policy.
Frequently asked questions about BRCGS and traceability
From the BRCGS standard itself. The traceability test must demonstrate that full forward and backward traceability, including mass balance, can be completed within four hours, and that test should be carried out at least annually. The precise wording is in the current version of the standard; please check it against your own situation.
The IFS page covers the KO requirements and the unannounced audit: the two mechanisms that can cost you the certificate. This page covers traceability and mass balance, where BRCGS is particularly strict. If you hold both standards, you can build them on a single record.
An audit file with nonconformity management collects evidence and tracks findings. This page is about one specific requirement that depends on your production data rather than your document management. That is a different kind of problem with a different solution.
Usually because of reprocessing and residual batches. Material that goes back onto the line is often not recorded as a batch, so more appears on the outgoing side than was registered coming in. Losses and sampling also fall outside the picture. These are not calculation errors but missing records.
A short period follows in which you must supply corrections, a root cause analysis and a preventive action plan for the nonconformities found. With BRCGS, root cause analysis is an explicit requirement: a correction without a substantiated cause is not accepted as closed. That deadline needs to be monitored.
There has been a public consultation for the next edition and work is ongoing, but there is no publication date yet. With a new edition, clause numbers and sometimes requirements shift. We therefore keep the requirements list as a reference and store, for each piece of evidence, the version it was recorded against.
Usually yes, and that is the best route. Parties already originate there: on receipt, on a production order and on dispatch. We pull that data and fill in what is missing, usually the link between parties and the recording of rework.
That depends on how many steps your process has, whether batches are already being recorded and whether there is a production system to connect to. The batch register with its trace is usually quick to put to use; the mass balance with reprocessing takes more effort. We give a reasoned estimate after the scoping exercise.
Want to measure the four hours for real?
Pick a finished product from last month and find out which raw material batches went into it and where it went. Start a stopwatch. That figure is what the auditor will measure. We build this as a standalone application and as part of a broader custom software development project.