ERP and expiry date management in food distribution: what to configure

A food distributor with 50 employees and 12,000 SKUs loses 3-4% of stock annually to expiry — not through negligence, but because the ERP doesn't warn in time and the warehouse has no visibility of batches. This guide configures your ERP in 8 weeks to eliminate that loss.

Retail in Portugal generated €201.8 billion in 2024, with 218,800 companies and 860,600 workers. The overall trade margin in wholesale was just 4.6% — logistics and stock efficiency determine profitability. Every percentage point of expiry loss is revenue that won't come back.

What you need before you start

Five items are non-negotiable. Administrator access to the ERP (or permission to configure master tables). A list of all products with a mandatory expiry date: food, pharmacy, cosmetics — don't improvise. A clear definition of the reference date: is it manufacture, expiry, or removal from sale? The warehouse and accounting have to agree. The warehouse manager available for 2 hours of alignment on the process — this isn't training, it's alignment. 6 months of historical stock movement data (inbound, outbound, returns) to validate the rules you're going to configure.

Access to current stock and ageing reports — or the willingness to generate them from scratch. A decision on the FIFO strategy: is it mandatory or merely recommended by category? In food, it's mandatory. Full stop.

Step 1: Configure the batch and date structure in the ERP

The ERP has to know that each stock unit is a batch with a date. This isn't optional — it's the foundation of everything.

Enable batch management in the inventory module. Mark it as mandatory for all families: food, drinks, frozen, hygiene products. Set the expiry date field as the batch's key field (not as a free-text note). The ERP has to be able to sort by expiry — if it can't, picking will get it wrong. Configure the manufacture date field (or inbound date) — needed to calculate the age of the batch and forecast expiries. Test the entry of a real batch: supplier, batch number, quantity, manufacture date, expiry date. Confirm that the ERP blocks outbound movements without a batch specified. Document the batch naming standard (e.g. "202501-A1", "LOTE-2025-001"). Communicate it to the warehouse and suppliers — if each uses a different format, the ERP can't sort.

Check: Can you view stock by batch and see the expiry date? Does the ERP prevent picking of a product without specifying the batch? Can you generate a "stock by expiry" report (sorted from nearest to furthest from expiry)?

Step 2: Define expiry alert and block rules

Timely alerts prevent emergency decisions on the floor. Blocks prevent the sale of out-of-date products.

Configure an automatic alert: when a batch has 30 days to expiry, the ERP flags it as "attention" at picking. It doesn't block — it just warns. Configure a second alert at 7 days: it flags it as "critical" and sends a notification to the warehouse manager (by email, SMS, or push on the terminal). Configure an automatic block: 1 day before expiry, the ERP prevents any outbound movement of that batch — except return to supplier or authorised destruction. Set a block rule too for already-expired batches: no outbound movement, full stop. Test the flow: create a batch with an expiry date of today + 5 days. Confirm that the ERP flags it as critical and blocks the sale tomorrow.

Check: Does the ERP send an email or notification when a batch enters "alert"? Does picking refuse an expired batch or one with 1 day to expiry? Can you see on a dashboard how many batches are in each stage (normal, attention, critical, blocked)?

Step 3: Implement the FIFO strategy at picking

FIFO isn't a suggestion — it's the law of food distribution. The ERP has to enforce it, because the warehouse won't.

Configure automatic picking: when a customer orders a product, the ERP proposes the batch with the nearest expiry date (the oldest). If your ERP allows it, create a conditional block rule: it doesn't permit picking of a newer batch if there's an older batch of the same product with stock available. Test with a real example: you have 100 units of milk expiring on 15 February and 80 units expiring on 28 February. An order of 50 units has to come from the 15 February batch, not the 28 February one. Communicate it to the warehouse: picking will appear with the batch pre-selected. They can't ignore it. If they do ignore it, the system has to warn and record who ignored it. Audit picking twice a week during the first month. If you find out-of-FIFO movements, investigate the cause — is it operator error, lack of training, or an ERP fault?

Check: Does picking always propose the oldest batch? If the warehouse tries to pick a newer batch, does the ERP warn or block? Can you generate a "FIFO compliance" report (% of outbound movements in the correct order)?

Step 4: Configure cyclical expiry counting

Cycle counting is the most efficient method for validating batch integrity. Don't wait for the annual stocktake — by the time it comes, it's too late.

Configure a weekly cycle count in the ERP: each week, the system automatically selects 10-15% of food SKUs for physical counting. Prioritise: start with the products with the highest turnover and highest risk of expiry (milk, yoghurt, meat, fish, frozen). Create a counting form that includes: SKU, batch, expiry date, physical quantity, ERP quantity, counter's signature, date. Set the counting frequency by category: high-turnover products (weekly), medium turnover (fortnightly), low turnover (monthly). Configure the ERP to automatically generate a discrepancy report (difference between physical and ERP). Investigate every discrepancy > 5 units or > 2% of stock — it's a symptom of an error in the batch, in picking, or in supplier intake.

Check: Does the ERP automatically generate a cycle-count list every Monday? Does the count include the batch and the expiry date? Can you consult the counting history (when it was counted, who counted, result)?

Step 5: Create stock movement rules by expiry

Not all stock that goes out is a sale. Returns, adjustments, promotions — every movement has to be traceable, because the AT and the IGAE will ask.

Configure movement types: "normal sale", "sale with discount for proximity to expiry", "return to supplier", "destruction", "sample". For "sale with discount for proximity": automatically set a discount of 10-15% for batches with 14 days to expiry, and 20-25% for batches with 7 days — the ERP calculates it, it's not manual. Configure destruction: when a batch expires, the ERP allows recording "destruction" (not sale, not return). Require a photo or destruction certificate (for compliance with the IGAE). Test the flow: a batch with 10 days to expiry is sold at a discount. The ERP records the sale, reduces the stock, and generates an "expiry discount" movement for later analysis. Create an "expiry movements" report: how many units were sold at a discount, how many returned, how many destroyed, per period — this is the metric that will show whether the configuration is working.

Check: Does the ERP automatically apply a discount to batches near expiry? Can you trace every stock movement (origin, destination, reason, date, user)? Can you generate an "expiry losses" report (how many units were destroyed, what the value was)?

Step 6: Integrate expiry with invoicing and the SAF-T

Tax compliance requires batch traceability. The SAF-T has to include the expiry date.

Configure the ERP to include in the SAF-T (tax audit file) the batch number and the expiry date of each stock outbound movement. Check with your tax consultant: in Portugal, the Tax Authority (AT) doesn't formally require a batch in the SAF-T for food, but the General Inspectorate of Economic Activities (IGAE) may audit. Document your policy — if you have to prove that a product was destroyed, the SAF-T has to show it. Configure the invoice: when a customer receives a product, the invoice has to include the batch number and the expiry date (mandatory for traceability, especially if the customer is a restaurant or hospital). Test a complete invoice: product, quantity, batch, expiry date, price with discount (if applicable), and confirm that the SAF-T records it correctly. Export the SAF-T for one month and validate it: can you trace every batch of every product sold? If you can't, the configuration isn't complete.

Check: Does the invoice include the batch number and the expiry date? Does the SAF-T record the batch and the expiry date? Can you trace a specific batch: from when it came in, how many units went out, to whom, on what date?

Step 7: Configure real-time visibility dashboards

Data in the ERP is useless if no one sees it. A dashboard is the difference between reaction (Monday, when you discover you've lost 200 units) and proaction (the previous Friday, when there's still time to sell at a discount).

Create a dashboard for the warehouse manager: total stock by product, stock by expiry (normal, attention, critical, blocked), number of batches at risk in the next 7 days. Create a dashboard for the sales manager: products with a proximity-to-expiry discount, volume of discounted sales, revenue lost to destruction (this is the metric that will make them act). Create a dashboard for management: expiry loss rate (% of stock destroyed vs. total stock), monthly cost of losses, trend (improving or worsening). Configure alerts: when the loss rate exceeds 2%, the ERP sends an email to the operations director — 2% is the acceptable threshold, above that something is wrong. Update the dashboards in real time (or at least every 4 hours). Yesterday's data is useless for today's decisions.

Check: Does the dashboard show stock by expiry (normal, attention, critical)? Can you see how many units are at risk of expiry in the next 7 days? Does the dashboard update automatically?

Decision table: configurations by product category

Most expiry losses aren't the warehouse's fault — they're the fault of an ERP that doesn't warn in time. Configure the alert 30 days in advance, not 3 days.

Common mistakes and how to avoid them

Mistake 1: configuring alerts too close to expiry. If you configure the alert at 3 days to expiry, the warehouse hasn't got time to sell at a discount. Configure it at 30 days — that gives time to react. Yes, some products will last another 30 days. It doesn't matter. The goal is zero expiries, not zero alerts.

Mistake 2: not testing FIFO with real data. Many ERPs have the "FIFO" option switched on, but picking still proposes the wrong batch. Reason: the expiry date field isn't mapped properly, or picking is using a different field to sort (e.g. inbound date vs. expiry date). Test with a real product, with two different batches, and confirm that picking proposes the oldest.

Mistake 3: not communicating to the warehouse that picking is mandatory. If the warehouse thinks it can ignore the batch proposed by the ERP, it will ignore it. Communicate clearly: "Picking is mandatory. If you try to pick a different batch, the system blocks it. There are no exceptions." Then, audit twice a week during the first month.

Mistake 4: destroying stock without documentation. If the IGAE audits and asks "where are the 500 units that disappeared?", the answer "they were destroyed" without a photo or certificate is insufficient. Configure the ERP to require a photo (upload) or a destruction certificate number. Without it, the movement isn't recorded.

Mistake 5: not integrating the automatic discount with the invoice. If the ERP applies a 15% discount at picking, but the invoice goes out at full price, the customer will complain. Configure the discount at picking, confirm that the invoice reflects it, and test with a real sale.

Mistake 6: cycle counting without a defined frequency. If the count is "whenever there's time", there's never time. Set a fixed frequency: Monday, 10% of SKUs. Tuesday, 10%. And so on. The ERP has to generate the list automatically.

Mistake 7: dashboards that no one sees. If the dashboard is on a server that no one accesses, it's useless. Put it on a screen in the operations room, or send it by email every morning. The goal is that the sales manager sees, every Monday, how many euros they lost to expiry in the previous week.

Implementation timeline: 8 weeks

Weeks 1-2: Configure batches and dates (Step 1). Test with a pilot product. Communicate the naming standard to the warehouse and suppliers.

Week 3: Configure alerts and blocks (Step 2). Test with real batches. Audit picking.

Week 4: Implement FIFO (Step 3). Audit twice a week. If you find errors, investigate.

Week 5: Configure cycle counting (Step 4). Start with 10% of SKUs. Increase gradually.

Week 6: Create movement rules (Step 5). Configure automatic discount and destruction.

Week 7: Integrate with invoicing and the SAF-T (Step 6). Test a complete invoice. Validate the SAF-T.

Week 8: Configure dashboards (Step 7). Put it on a screen. Send it by email. Train the team.

After week 8, monitor the loss rate for 4 weeks. If it's below 2%, the configuration is correct. If it's above, review the alerts, the blocks, and the FIFO.

Frequently asked questions

What happens if my ERP can't sort stock by expiry date?

Picking will go wrong systematically. Without sorting by expiry, the warehouse can't apply FIFO, and products near expiry go out after the newer ones. This causes expiry losses and loss of stock. Sorting by date is non-negotiable — if the ERP doesn't do it, it has to be reconfigured or replaced.

What's the difference between an expiry alert and an expiry block?

An alert warns the warehouse manager (by email or notification) when a batch approaches expiry, but still allows the sale. A block prevents any outbound movement of the product — the ERP refuses picking. Alerts give time for action; blocks prevent the sale of out-of-date products.

Do I need complete warehouse training to implement this?

No. You need 2 hours of alignment with the warehouse manager on the new process — it's not formal training. The ERP will enforce the rules (automatic FIFO, expiry blocks), so the operator follows what the system proposes. Clear documentation and weekly auditing in the first month are more important than prior training.

How do I know if FIFO is working correctly?

Configure a "FIFO compliance" report that shows the percentage of outbound movements in the correct order. Audit picking twice a week during the first month. If you find out-of-FIFO movements, investigate whether it's operator error, lack of understanding, or an ERP fault. The system's conditional block should prevent picking of newer batches if older batches are available.

What's the ideal frequency for cyclical expiry counting?

Configure a weekly cycle count covering 10-15% of food SKUs. Prioritise high-turnover products (milk, yoghurt, meat, fish, frozen) weekly. Medium-turnover products, fortnightly. Low turnover, monthly. This lets you validate batch integrity without waiting for the annual stocktake, when it's too late.

What should I do if I find discrepancies between physical stock and the ERP?

Investigate every discrepancy greater than 5 units or 2% of stock. It's a symptom of an error in the batch, in picking, or in supplier intake. The ERP should automatically generate a discrepancy report. Document the cause (operator error, damage, incorrect intake) and correct the record. This helps identify error patterns in the process.

How long does it take to configure the ERP for expiry management?

The guide proposes 8 weeks for a distributor with 12,000 SKUs and 50 employees. This includes: enabling batch management, configuring alerts and blocks, implementing FIFO, establishing cycle counting, and auditing the process. The time varies depending on the complexity of the ERP and the quality of the historical data available.

Sources

• Statistics Portugal (INE) — Trade Statistics in Portugal 2024 (data on turnover, number of companies and workers in the trade sector)
• Regulation (EC) No 178/2002 — Base legislation on food safety and traceability of food products in the EU
• ISO/IEC 27001:2022 standard — Information security management in information systems (ERP and stock data)
• Decree-Law No 67/2018 — Transposition of Directive (EU) 2015/2436 on date marking and expiry periods on food products in Portugal
• ENISA (European Union Agency for Cybersecurity) — Security Guide for Enterprise Management Systems (ERP) — Recommendations for access control and auditing