In this article
- What batch traceability must prove
- A worked example: a beverage co-packer
- Shelf life is a control, not a date typed onto a label
- The four dates food processors should separate
- Why FEFO matters more than FIFO for short-life stock
- A worked example: a chilled-food distributor
- Odoo configuration for a food processing operation
- 1. Define products, lots and shelf-life policies
- 2. Capture supplier lots at receipt
- 3. Consume lots in the production order
- 4. Apply quality release before sale
- 5. Use GS1 identifiers where interoperable scanning is needed
- Compliance across African sales markets
- The management reports that should be available
- Frequently Asked Questions
- Does Odoo provide food traceability by default?
- What is the difference between batch traceability and a recall process?
- Should food processors use FIFO or FEFO?
- Can an ERP-generated expiry date prove label compliance?
A production manager has just learned that a retailer found a packaging defect in a product on its shelf. The immediate question is not whether the factory has stock records. It is whether the team can identify the affected finished lot, the ingredients and packaging consumed, every warehouse holding stock, and every customer who received it.
That is the operating case for a food ERP for Africa. For food and beverage processors, Odoo must connect batch traceability, quality records, shelf-life dates, production and delivery in one auditable chain. A batch number printed on a label is useful. A batch number that cannot be traced back through receipts, production orders and customer deliveries is not enough when a withdrawal decision is due.
Africa does not have one food-ERP law, regulator, recall form or penalty schedule. The African Union Food Safety Strategy runs from 2022 to 2036, but it is a continental framework for national competent authorities and food businesses, not a replacement for domestic rules. Each processor must map its controls to the food-safety authority, labelling law and sector requirements in every market where it sells.
What batch traceability must prove
Codex defines a lot as a definitive quantity of food produced under essentially the same conditions. For packaged food, the practical baseline is a permanent lot code that identifies the producing factory and the lot. The current Codex pre-packaged-food labelling standard was revised in 2024.
For an ERP for food production in Africa, a finished-product lot should provide an unbroken record of:
1. Raw-material receipt and supplier lot.
2. Packaging-material lot where it affects the finished product or label.
3. Production order, work centre and production date.
4. Quality results and release decision.
5. Finished-product lot, date marks and storage rules.
6. Warehouse movements, deliveries and customer records.
This is the minimum operating model for a targeted withdrawal. Without it, a processor often has two poor choices: stop too little stock and accept avoidable exposure, or destroy far more stock than the incident requires.
The common failure is to assign one finished-goods batch after production while leaving ingredient lots outside the production record. That creates a forward trace, from factory to customer, but no dependable backward trace to the supplier receipt. During an investigation, the unanswered question is usually the costly one: which other products consumed the same ingredient or packaging lot?
A worked example: a beverage co-packer
Take a beverage co-packer producing the same drink for several brand owners. A quality hold is raised against one cap supplier lot after bottles have left the factory. If the production order records only the finished-drink lot, the operations team must review paper issue notes, warehouse sheets and dispatch records before it can determine the exposure.
In a properly configured Odoo implementation, the cap lot is reserved and consumed against each production order. The finished lots inherit a traceable relationship to that component lot, and each delivery identifies the customer and quantity shipped. The co-packer can isolate affected finished lots while unaffected batches continue through the supply chain. The team would still need to follow the relevant national regulator and customer procedures, because Codex guidance does not prescribe one recall process for all African markets.
Shelf life is a control, not a date typed onto a label
Food processors regularly treat best before and expiry as interchangeable. They are not.
Codex defines best before as the end of the period during which a product remains fully marketable under stated storage conditions. After a use-by or expiry date, the food should not be regarded as marketable. The difference matters to inventory policy, sales controls, labels and the decision to remove stock.
Date codes should be tied to validated shelf-life rules and required storage conditions. An ERP can calculate dates consistently from a production or receipt event, but it cannot validate the underlying shelf-life claim. That validation depends on the product, process, packaging, storage conditions and the local label review.
Where the validity of a date depends on storage conditions, Codex requires those conditions to be stated. For a processor selling across multiple markets, this means the master data and label approval process need local review. Do not configure one generic label rule and assume it meets every sales market’s requirement.
The four dates food processors should separate
| ERP date | Operational purpose | Why it matters | | Production date | Records when the lot was made | It anchors production traceability and supports date calculations where the product policy requires it. | | Best-before date | Signals the end of full marketability under stated storage conditions | It should not be treated as an expiry decision without considering the approved product and label rules. | | Expiry or use-by date | Marks the point after which food should not be regarded as marketable | Warehouse and POS controls must prevent sale after this date, not merely display a warning. | | Removal or alert date | Starts internal action before the critical date | It gives planners time to move, review or block stock before it reaches the customer. | In Odoo, Lots and Serial Numbers and Expiration Dates support expiry, best-before, removal and alert dates by lot. That configuration should be governed by approved product rules. If a shelf-life value changes, the change needs an auditable approval process, because a master-data adjustment can affect stock already in the network.
Why FEFO matters more than FIFO for short-life stock
FIFO sends the oldest received stock first. FEFO, first-expired-first-out, sends the stock closest to its removal date first. These methods can produce different picking decisions when goods arrive out of date sequence or when shelf-life changes between lots.
For short-life food and beverage stock, use FEFO where expiry or removal dates drive the risk. Odoo supports FEFO for picking stock closest to its removal date. This reduces the chance that a newer receipt is dispatched while an earlier-expiring lot remains in the warehouse.
FIFO can still be appropriate for products without meaningful expiry exposure or where the business policy requires it. The judgement call is practical: if a product can become non-marketable based on its lot date, do not rely on FIFO alone. Configure FEFO, test it in real picking scenarios and block expired lots from warehouse and point-of-sale flows.
A warning on a screen is not an expiry control. Staff can override warnings under delivery pressure. The relevant warehouse locations, sales orders, delivery orders and POS process need rules that stop release of expired lots unless an authorised exception process exists and is justified.
A worked example: a chilled-food distributor
Consider a chilled-food distributor receiving two lots of the same product. The later receipt has the nearer removal date because its remaining shelf life is shorter. A FIFO rule can select stock based on receipt sequence, leaving the nearer-dated lot behind.
With FEFO, the warehouse picker is directed to the lot nearest its removal date. The planner can see stock approaching the alert or removal date and decide whether to redistribute, promote, hold or dispose of it according to approved policy. The distributor should not treat this configuration as proof of food-law compliance, because storage conditions and market-specific label rules still require separate control.
Odoo configuration for a food processing operation
A food and beverage implementation starts with data discipline, not a dashboard. We configure the records that make each lot meaningful, then test the process from supplier receipt through customer delivery and, importantly, in reverse.
1. Define products, lots and shelf-life policies
Set each traceable ingredient, packaging component and finished product to use lots. Define whether the product uses best-before, expiry, removal and alert dates. The policy must reflect validated shelf-life rules and required storage conditions, not a number entered by a planner because it worked for a previous batch.
For multi-entity food groups, use a unified product and lot-governance model while preserving the legal entity, factory and warehouse records needed for accountability. A shared chart of product attributes helps reporting, but each entity’s approved labels and market obligations may differ.
2. Capture supplier lots at receipt
Receiving teams must record the supplier lot before material becomes available to production. Where supplier lot data is missing, the correct action is a hold or controlled internal identification process, not a blank field completed later from memory.
Quality checks can be linked to the receipt or lot, depending on the approved process. The result, release status and any hold decision should remain auditable. A quality result stored in an email folder does not help a warehouse user deciding whether to issue stock to production.
3. Consume lots in the production order
The production order must show what was consumed to create the finished lot. This includes ingredients and, where relevant, packaging material. The link is what enables a batch traceability ERP to answer both directions of the traceability question.
Production staff should record actual lot consumption, not only planned components. Planned consumption describes what should have happened. Actual consumption provides the record of what did happen.
4. Apply quality release before sale
Define the stage at which a finished lot becomes saleable. Some operations require checks during production, while others require laboratory or quality review after completion. The ERP should reflect that approved release point and prevent unrestricted stock movement before it is met.
This protects the business from shipping stock that is physically present but not yet approved. It also gives finance and operations real-time visibility of usable, held and expired inventory rather than one undifferentiated stock balance.
5. Use GS1 identifiers where interoperable scanning is needed
For interoperable labels and scanning, GS1 Application Identifier 10 identifies batch or lot, 15 identifies best before, 17 identifies expiry and 11 identifies production date. These identifiers help trading partners and warehouses interpret the encoded data consistently.
The barcode is only as reliable as the ERP record behind it. Before printing at scale, test scanning at goods receipt, production issue, finished-goods receipt, picking and dispatch. The step teams skip is testing a deliberately incorrect or expired lot, which is where control gaps become visible.
Compliance across African sales markets
A processor selling in more than one country should keep a market-control register outside of assumptions. It should identify the relevant food-safety authority, label requirements, approved date terminology, language needs, sector requirements and withdrawal or recall expectations for each market.
As of September 2026, there is no Africa-wide monetary threshold, licence form, recall deadline or penalty schedule that can be applied to all food processors. Confirm country-specific obligations with the national food regulator before publishing a claim, approving labels or setting a recall procedure. This matters because the African Union Food Safety Strategy is not domestic legislation.
Codex is also revising its 2006 traceability and product-tracing guidance. As of August 2026, the revised text remained at draft consultation stage. Do not configure a future draft requirement as if it is already in force. Use the current control baseline, then review the implementation when the final text and local adoption position are clear.
The management reports that should be available
A food ERP for Africa should make the following reports available without spreadsheet reconstruction:
● Lot genealogy from finished product to supplier receipt, and from supplier lot to all finished products and deliveries.
● Stock by lot, warehouse, best-before date, expiry date and release status.
● Inventory approaching alert or removal dates.
● Quality holds, results and release decisions by lot.
● Production consumption variance by actual lot.
● Customer deliveries by finished-product lot.
These reports serve different decisions. Operations needs expiry exposure before picking. Quality needs traceable release evidence. Finance needs a reliable view of inventory at risk. The board needs to know whether a targeted withdrawal can be executed with auditable evidence rather than broad assumptions.
Frequently Asked Questions
Does Odoo provide food traceability by default?
Odoo supports lot tracking, expiration dates and FEFO when the relevant features are enabled and configured. Food traceability depends on process discipline, because the system must capture supplier lots, actual production consumption, quality decisions and customer deliveries consistently.
What is the difference between batch traceability and a recall process?
Batch traceability provides the evidence to identify affected stock and customers. A recall or withdrawal process sets the decisions, communications and regulatory actions that follow. The latter is country and product specific, so it must be confirmed with the relevant national food regulator.
Should food processors use FIFO or FEFO?
Use FEFO for short-life products where the nearest expiry or removal date should drive picking. FIFO may suit products without meaningful expiry exposure, but it does not necessarily select the lot with the shortest remaining shelf life.
Can an ERP-generated expiry date prove label compliance?
No. The ERP can apply approved shelf-life rules consistently, but it does not validate shelf life, storage conditions or local label requirements. Those require product evidence and market-specific review.
Serpa implements Odoo ERP for food processing industry in Africa with batch traceability, quality controls, expiry management, FEFO and multi-entity visibility designed around your factory and sales-market requirements. Request a Consultation to scope your traceability controls, integration needs and auditable reporting requirements.