Recipe Version History: Who Changed What, and How to Undo It
Someone edits a recipe. The portion cost moves, or the allergen list changes, and nobody can say who did it or when. It is one of the most common frustrations in a growing food business, and one of the few that software genuinely solves outright. This guide covers why food businesses need a recipe audit trail more than most industries do, what good version history actually looks like, where restore stops being useful, and how FoodCore's field-level timeline and one-click undo work on Growth and Core plans.
The everyday disaster
It usually goes like this. On Monday the brownie recipe costs 84p a portion. On Thursday it costs 96p and nobody can say why. Or worse: the allergen list on a product quietly loses an entry, and the first anyone knows about it is a customer question you cannot answer with confidence.
Someone made a reasonable change. Maybe they corrected a yield that had always been wrong, or swapped a brand because the usual one was out of stock, or fixed a typo and fixed the wrong number. The change itself is rarely the problem. The problem is that it is invisible: no record of what the value used to be, no name attached, no timestamp, and therefore no way to decide whether to keep it or reverse it.
In a business with one person and ten recipes, memory covers this. In a business with three staff, a seasonal helper and eighty recipes, it does not — and the gap grows quietly until the first time it matters.
Why food businesses need this more than most
Plenty of software has version history because developers like it. Food businesses need it for reasons that are specific and unglamorous.
Traceability
If a batch is questioned — a complaint, a supplier recall, an internal check — the question is what the recipe said on the day that batch was made, not what it says now. A recipe with no history can only tell you its current state, which is the one piece of information you already have.
Allergen accountability
When an allergen declaration turns out to be wrong, two questions come immediately: when did it change, and who changed it. A timeline answers both in seconds. Reconstructing it from memory and email produces an answer nobody trusts, including you. This is closely tied to how allergens are stored in the first place — see our guide to allergen management for multi-ingredient recipes.
Inspections and due diligence
An environmental health officer asking how you control changes to recipes and allergen data is asking a process question. 'We're careful' is a weak answer. A dated, attributed timeline of every change to every recipe is a strong one, and it takes no preparation because it accumulates on its own.
Staff turnover
Kitchens turn over. The person who changed the sugar quantity in March may have left in May. Attribution is not about blame; it is about knowing who to ask, and about having an answer when there is no longer anyone to ask.
Attribution is also employee monitoring. A history screen that names colleagues is visible to anyone with access to the record. That is ordinary and reasonable in a food business, but if you have staff it belongs in your own staff privacy notice — tell people that edits are attributed and visible, rather than letting them discover it.
What good version history looks like
Not all audit trails are equally useful. Three features separate a history you actually use from one you ignore.
- Field-level diffs. An entry saying 'recipe updated' is close to worthless. An entry saying 'yield: 12 → 10, butter: 200g → 250g' tells you what happened and whether it was intentional.
- Who and when, on every entry. Named user and timestamp, with no gaps for changes made through imports or bulk edits.
- One-click restore. Reading the history is only half the value. Being able to put the record back to a known-good state without re-typing it is what turns the screen from a report into a tool — and the restore should itself appear in the timeline.
Six situations, and what a timeline gives you
The limits — stated plainly
It is worth being clear about what version history is not, because the gap between expectation and reality is where people get caught out.
Restore rewrites the record's own fields. It puts the values back. It does not reach outside the record and reconstruct things that have been removed elsewhere: if an ingredient has been deleted, restoring a recipe that referenced it will not bring that ingredient back.
It is not a backup. Version history protects against a bad edit to one record. A backup protects against losing the dataset. They cover different failure modes and you need both. It is also worth knowing what backups exclude — in FoodCore, uploaded images such as recipe photographs and label logos are not included in database backups and cannot be recovered from them.
It is not a route around a deletion request. If someone asks you to delete their data, an audit trail is not a place to keep a copy. Treat retained history as data you hold, subject to the same obligations as everything else.
Version history is evidence, not compliance. A timeline shows what changed and when. It does not check that the change was correct, that the resulting allergen declaration is accurate, or that the product is safe. Those remain the food business operator's responsibility. What the record does is make that responsibility far easier to discharge — and far easier to demonstrate afterwards.
How FoodCore does it
On Growth (£40/month inc. VAT, £400/year) and Core (£65/month inc. VAT, £650/year), every ingredient and every recipe carries a version history timeline. Each entry shows the field-level differences — what the value was, what it became — along with the person who made the change and the time they made it. Any past version can be restored in one click, and the restore is recorded as its own event so the history remains a complete account.
One honest note about how this came about, because it affects what you will find when you first open it. The feature needed no new data capture: FoodCore's audit log has recorded full row snapshots for recipes and ingredients since day one. Building the version history screen was a matter of surfacing what was already there. The practical consequence is that history exists for changes made before the screen was built — so on an established account you are likely to find a timeline stretching back well beyond the feature's release, rather than starting from zero.
Essentials (£25/month inc. VAT, £250/year) covers recipes, ingredients, allergens, labels and shelf life but does not include version history. If an audit trail is the reason you are looking at software at all, Growth is the entry point.
Compare what each plan includes →Habits that make the history worth having
- Give people their own logins. A shared account produces a timeline that attributes everything to 'the shop', which is no attribution at all.
- Check the history before you re-type. When a figure looks wrong, read the timeline first — the previous value is usually right there, and restoring beats reconstructing.
- Reprint labels after any allergen-affecting change. The history records the edit; it does not recall the labels already printed.
- Review the timeline after a busy period. A scan through a season's changes catches the well-meaning edit nobody mentioned.
For the wider question of keeping a recipe library organised in the first place, see how chefs keep track of recipes.
Start a 7-day free trial — no card required →Frequently asked questions
What is recipe version history?
Recipe version history is a running record of every change made to a recipe or ingredient: what changed, who changed it and when. Good version history shows field-level differences rather than a vague 'edited' entry, so you can see that the flour went from 500g to 450g on a particular date, by a particular person. It also lets you restore an earlier version. It is the difference between believing a recipe is correct and being able to show how it got that way.
How do I find out who changed my recipe?
In a system with an audit trail, you open the recipe's history and read the timeline. Each entry names the person, the timestamp and the fields that changed, with the old and new values side by side. Without an audit trail there is no reliable answer: you are reduced to asking around, and in a kitchen with shift workers and seasonal staff that rarely produces a confident conclusion. This is one of the strongest practical arguments for keeping recipes in software rather than a shared spreadsheet.
Why does a food business specifically need a recipe audit trail?
Four reasons. Traceability: if a batch is questioned, you need to know what the recipe said on the day it was made, not what it says now. Allergen accountability: when a declaration turns out to be wrong, the first questions are when it changed and who changed it. Inspections: an environmental health officer asking how you control recipe changes is far better answered with a timeline than with an assurance. Staff turnover: when the person who made a change has left, the record is all that remains.
Can I restore a previous version of a recipe?
In FoodCore, yes, on Growth and Core plans. Every ingredient and recipe carries a timeline, and any past version can be restored in one click, which writes those field values back onto the current record. The restore is itself an event in the timeline, so nothing is lost and the history stays honest. Restoring is the fastest fix when a well-meaning edit has changed a yield, a cost or an allergen and nobody can remember what the figure used to be.
What are the limits of restore?
Restore rewrites the record's own fields. It cannot recreate something that no longer exists: if an ingredient has been deleted outright, restoring a recipe that referenced it will not bring the ingredient back. It is also not a backup. A backup protects you against loss of the whole system; version history protects you against a bad edit to one record. And it is not a route around a deletion request, so it should not be treated as a way to retain data someone has asked you to remove.
Is version history the same as a backup?
No, and conflating the two is a common and expensive mistake. Version history is per-record and per-field: it answers 'what did this recipe look like last Tuesday'. A backup is a copy of the whole dataset at a point in time and answers 'what if we lose everything'. You need both, for different failure modes. It is also worth knowing what your backups exclude: in FoodCore, uploaded images such as recipe photographs and label logos are not included in database backups.
Which FoodCore plan includes version history?
Version history and one-click undo are included on Growth at £40/month inc. VAT (£400/year) and on Core at £65/month inc. VAT (£650/year). Essentials at £25/month inc. VAT covers recipes, ingredients, allergens, labels and shelf life, but not version history. Every plan starts with a 7-day free trial, and no card is required.
Further resources
FoodCore is kitchen management software built for small UK food businesses. We handle recipe costing, Natasha's Law labels, allergen matrices and order tracking.
Start free trial →