Digital food passport: from field, through batch, to ESG

What is a digital food passport?

A digital food passport is a data layer that describes the identity, origin and subsequent events relating to a raw material or batch. It answers the following questions: where does the product come from, what happened to it along the way, who confirmed the data, what documents are available and where did the batch go?

The passport may draw on FarmPortal, FoodPass, ERP, weighbridge systems, WMS, QMS, laboratories and IoT, provided that all sources use shared identifiers. Without a master-data rule, several versions of the same delivery emerge.

Traceability enables movement backwards and forwards through the chain. A passport adds production context, quality, documents, environmental data and the history of changes. For that reason, a digital product passport should be designed around events and responsibility for data, not around a screen with a code.

Why does a digital food passport begin in the field?

The passport begins in the field because that is where data is created that a plant cannot reliably recreate once the raw material has been received: the specific plot, variety, treatment date, fertiliser dose, pre-harvest interval, harvest date and production conditions. A supplier number on a weighbridge ticket is not a substitute for that history.

During the harvest peak, the gap appears quickly. A lorry is waiting on the weighbridge, the procurement team wants to unload the material, and information about the field is expected to “arrive later”. The operator chooses a general supplier profile. Once several deliveries have been combined in a silo or on a production line, the missing link cannot be repaired with Excel alone.

Many companies declare full traceability, yet their data is scattered across paper records, spreadsheets, emails, certificates, the weighbridge system, ERP and agronomists’ notes. The problem is not only the number of applications. What is missing is a single model that connects the field, supplier, harvest, delivery, quality, storage, production and customer.

A broader explanation of the “one step back, one step forward” requirement is available in the guide to traceability in agriculture.

How does data move from field to customer?

Data moves through the chain as a sequence of events, not as a single form filled in at the end. Each event should identify the object, time, place, operator, status and link to an earlier or later batch. This preserves continuity even when raw material is split, combined or repacked.

1. Production registration: the farm creates fields, plots, crops, varieties and the production season.
2. Treatments and inputs: fields receive dates, doses, plant protection products, fertilisers, fuel, machinery and operators.
3. Harvest: a harvest batch is created with the date, quantity, field, container or transport.
4. Delivery: the weighbridge, delivery notice and receipt process connect the supplier, vehicle, weight, documents and batch identifier.
5. Quality control: samples, results, photos, decisions and any blocking actions remain attached to the delivery.
6. Production and storage: the system records raw material consumption, mixing, yield, packaging and finished product batches.
7. Dispatch: the product batch is assigned to an order, customer, transport and export documents.

Splitting and combining are the most difficult operations. One delivery may feed three production batches, while one finished product batch may contain raw material from several fields. The system must store many-to-many relationships, preferably also with the quantity assigned to each transition.

QR, DataMatrix, NFC or UHF RFID are carriers of the identifier. The choice should be driven by process speed and working conditions, as described in the article on choosing QR, NFC and RFID for batch identification.

What data should the passport contain?

The passport should contain only the data needed for decisions, compliance, quality or reporting. More fields do not create better traceability. They create backlogs, workarounds and records completed after the season, when nobody remembers the details.

Each field needs an owner and a correction rule. Net weight should come from the weighbridge, quality status from QMS or FoodPass, and the invoice from ERP. Manually re-entering the same value into three systems creates discrepancies, not control.

What really follows from traceability, EUDR and ESG?

Law and the market require different types of data. As of June 2026, a digital food passport is primarily an operational architecture supporting separate obligations and customer requirements, not one mandatory EU document.

Does the EU digital product passport cover food?

Not under the ESPR. Regulation (EU) 2024/1781 establishes the framework for a digital product passport, but Article 1(2) excludes food and feed. In this article, the term “food passport” describes an agri-food data model, not a declaration of compliance with DPP requirements for products covered by the ESPR.

What remains a traceability obligation?

Article 18 of Regulation (EC) No 178/2002 requires traceability of food, feed and ingredients at the stages of production, processing and distribution. The legal minimum is often described as “one step back, one step forward”. Full internal batch genealogy, however, gives far greater precision during complaints, blocking and withdrawals.

When does EUDR apply to the food chain?

EUDR covers, among other commodities, cattle, cocoa, coffee, oil palm, rubber, soya and wood, not all fruit, vegetables or cereals. According to the European Commission, the rules will apply from 30 December 2026 for large and medium-sized operators, and from 30 June 2027 for most micro and small operators. Companies within the regulation’s scope need data on geolocation, origin, suppliers and due diligence. The current scope is provided on the European Commission page on EUDR.

How does the passport connect with ESG and carbon footprinting?

ESG in agriculture needs source data: nitrogen quantities, fertiliser type, fuel, energy, yield, storage and transport. These data points feed monitoring, reporting and verification (MRV) and emissions calculations, but they are not yet a verified food carbon footprint. Calculation boundaries, emission factors, allocation and missing-data rules are still required.

The scope of CSRD and ESRS was being modified in 2026, so the data model should remain flexible. It is not worth building the whole process around one customer spreadsheet.

Regulatory status as of 24 June 2026. This material is for information only and does not constitute legal advice or a declaration of compliance.

Who benefits from a shared batch history?

Value is created before a code is shown to the consumer: the farmer, processor, quality team and customer work on connected data, while each group sees only the scope it needs.

Large farms and producer groups

The farm records a treatment once, against the field and crop, and the same record feeds documentation, pre-harvest interval control, costs and customer requirements. A producer group receives comparable data without consolidating dozens of spreadsheets.

Fruit, vegetable and agricultural raw material processors

The processor checks completeness before delivery, connects quality with the batch and moves from the finished product back to the source fields. In a complaint, minutes matter; broad blocking of an entire shift often results from the lack of precise genealogy.

Procurement companies, distributors and exporters

The procurement company gains consistent identifiers, the distributor gains more efficient trace-forward, and the exporter gains data required by a contract or market. The customer can receive a controlled history without access to the farm’s full documentation.

Advisers, auditors and ESG teams

The adviser sees gaps before the audit. The ESG team receives data assigned to area, crop and volume, while the auditor can move from a certificate to source events if the system stores a change history.

How do FarmPortal and FoodPass support passportisation?

FarmPortal and FoodPass cover two sides of the process. FarmPortal creates data at source: fields, crops, treatments, fertilisation, plant protection, harvests, input use and documents. Alerts help identify gaps before delivery; the scope is described in the FarmPortal modules and functions.

FoodPass links the supplier with the contract, delivery, quality, audits, certificates, complaints and production batches. The grower portal provides data to the processor, but the scope of sharing must follow role, consent and purpose.

The shared FarmCloud model makes it possible to build a history from field to customer: FarmPortal is responsible for production data, while FoodPass covers supplier–delivery–quality–batch relationships. A public description of the solution is available on the FoodPass supply chain management page.

CO₂, nitrogen and production-input reporting draws on the same events, but it requires a separate calculation layer. This distinction matters. Good records are input evidence, not a certificate of the result.

How can ERP, WMS, QMS and weighbridge data be connected?

Integration is based on stable identifiers for the supplier, field, harvest batch, delivery and production batch, not on copying tables. Every data field must have a designated source system.

ERP holds contracts and settlements, WMS handles warehouse movements, QMS stores quality, the weighbridge records weight and time, and the production system records raw material consumption. FarmPortal contributes the field context. Connections may use APIs, files and IoT events; satellite data adds evidence, but it does not replace the batch identifier.

At a larger scale, identifiers should be designed in line with GS1 standards, and events in a way that can be mapped to the EPCIS model. This does not mean every company has to implement the full standard on day one. It means the structure should not block later data exchange with a customer.

What might implementation look like at a vegetable processor?

A model processor of frozen vegetables works with 42 farms. Contracting covers 1,120 ha, around 7,400 t of raw material, 620 deliveries and 124 production batches. The company uses ERP, a weighbridge system and a separate quality spreadsheet.

Model example prepared for this article. The data is used to illustrate the process and requires verification before being used as the result of a real implementation.

Problem

ERP knew the supplier, the weighbridge knew the weight, and the spreadsheet held the quality result. Field and harvest data arrived as scans and various files, so reconstructing a batch involved procurement, quality, production and an agronomist.

Solution

FarmPortal registered fields, treatments and harvest batches, while FoodPass managed suppliers, certificates, deliveries and quality. The weighbridge added time and weight, and the production system connected raw material with the finished product.

The pilot covered one crop and eight farms. A trial withdrawal revealed gaps during raw material mixing; the process was expanded only after those gaps had been removed.

Source: FarmPortal editorial model benchmark. Values are indicative and do not describe a real customer or a guaranteed effect.

Interpretation limits

The result depends on identification, integration and data quality. If mixing is recorded without quantities, the system will show possible sources but will not calculate reliable shares. Digitisation does not recreate an event that nobody recorded.

How to implement a digital batch history step by step

Implementation should start with the decisions the company needs to make faster or with greater certainty. Not with a list of every possible data point. The best test is a specific question: can we identify the source fields and customers of one batch within 60 minutes?

1. Draw the physical flow. Mark fields, harvests, containers, deliveries, warehouses, mixing, production and dispatch.
2. Define the batch level. Decide when a harvest batch is created and when its identity changes inside the plant.
3. Define the minimum data set. Select the fields that block receipt and the data that may be completed later.
4. Assign the source system. One value should have one owner, even if it is visible in several applications.
5. Run a pilot. Start with one crop, 5–10 suppliers and a process with real commercial importance.
6. Perform a trace-back and trace-forward test. Measure time, gaps, number of exceptions and the level of manual work.
7. Add ESG and automation only afterwards. A CO₂ report based on poor batch genealogy produces a precisely calculated but wrongly assigned result.

A good pilot ends with an exception protocol. It should describe delivery without internet access, a field correction after receipt, batch mixing, returns, a damaged label and a supplier who has not completed a document. Production works through exceptions more often than a sales presentation suggests.

When does the solution not make sense, and where do implementations fail?

Full enterprise integration is not suitable for every process. A farm selling a few homogeneous batches each week can start with records, a batch number and QR. RFID and a broad EPCIS implementation will be a cost without a return until manual scanning starts blocking work.

A passport will not fix chaos. If the company cannot define what a batch is, who may change it and when raw material loses its original identity, software will only replicate ambiguity faster.

• An overlong form for farmers: data is completed after the event or copied between fields.
• No shared identifier: the same supplier has different numbers in ERP, the weighbridge system and the grower portal.
• Mixing and repacking are ignored: the history looks good up to the plant gate and then breaks inside production.
• False automation: integration sends a file once a day, but nobody handles faulty records.
• No access rights: the customer sees too much, or the farmer does not know who is using their data.
• Confusing data with a declaration: a CO₂ calculation without a described methodology is a number, not evidence.

We recommend a simple rule: batch continuity first, additional indicators later. Without it, ESG, EUDR or quality reporting rests on assumptions that cannot be defended in an audit.

Frequently asked questions about the digital food passport

Glossary

Traceability

The ability to track a product, raw material or ingredient backwards and forwards. In practice, it connects the supplier, batch, process and customer.

Food passportisation

The process of building a digital history of a product or batch using data on origin, production, quality, flow and documents.

Raw material batch

A clearly identified quantity of raw material with a shared origin or production event, such as a harvest from a defined plot.

Trace-back

Moving from a product or delivery back to earlier events, suppliers, fields and materials used.

Trace-forward

Moving from a raw material or event to all batches, warehouses and customers that may have been affected by it.

FMS

Farm Management System. FarmPortal fulfils this role for fields, crops, tasks, resources and documentation.

FoodPass

An Agri Solutions product for supplier collaboration, traceability, quality, audits and data in the supply chain.

FarmCloud

An ecosystem integrating Agri Solutions applications and data, including FarmPortal and FoodPass, on both the farming and processing sides.

MRV

Monitoring, reporting and verification of data, for example concerning emissions or resource use.

EUDR

The EU regulation on deforestation-free products. It covers specified commodities and requires origin data and due diligence.

Summary and practical next step

A digital food passport does not begin in the production plant. It begins when the field, crop, treatment and harvest receive identifiers that can be linked with a delivery. Without that, traceability on the processor side remains a partial reconstruction.

FarmPortal organises data at source, FoodPass links suppliers, quality and batches, and FarmCloud creates the cooperation and integration layer. The most sensible next step is to select one crop and run a test: from a product batch back to the field, and then from the field forward to all customers.

Explore the FarmPortal functions that help structure farm data and plan a pilot with the Agri Solutions team.