Build an EUDR evidence ledger that survives the next shipment
A practical evidence-register structure for product coverage, source files, versions, review status, exceptions and repeat shipments.
A ledger records relationships as well as files
An evidence ledger is a structured register of what you received, where it came from, what it supports and how it was reviewed. It is an operating method, not a term that requires a particular software product.
The EUDR’s information, assessment and record-keeping provisions provide the regulatory context. A useful ledger helps make those records understandable over time.
Use stable identifiers
Assign stable identifiers to the importing entity, supplier, manufacturer, product family, batch or flow, and evidence item. Keep the supplier’s original references too. An internal identifier helps join records; it should not erase the reference someone upstream uses.
A filename alone is a weak identifier because files are often renamed, duplicated or replaced. Record the original filename, received date and source alongside your internal evidence reference.
A minimum useful structure
| Field | Why it matters |
|---|---|
| Evidence ID and version | Distinguishes the exact record used |
| Source organisation and contact role | Shows who supplied or asserted the information |
| Received date and covered period | Separates file receipt from factual coverage |
| Product, batch and origin relationships | Explains which flow the evidence supports |
| Evidence type and original location | Makes the source retrievable |
| Review status and reviewer | Distinguishes receipt from assessment |
| Limitations and open actions | Keeps unresolved issues visible |
| Decision and statement references | Connects evidence to the approved outcome |
Use separate record types
| Record | Useful fields | Fictional relationship |
|---|---|---|
| Flow | Entity, role, goods, quantity, commercial references, output | SH-EX41 → B-A17 |
| Evidence | ID/version, source/contact, received date, factual period, original, limits | E-05 v1 = PS-07 |
| Relationship | From/to IDs, supporting record, explanation, reviewer/status | B-A17 → NR-11: unresolved |
| Action | Issue, affected flow, owner, request, response, closure criteria | F-01: obtain input allocation |
| Decision | Scope, evidence versions, material concerns/mitigation, rationale, date, reference | DEC-EX41: pending |
| Change | Old/new version, reason, affected flows, reassessment owner | CH-02: PS-07 v2 arrives |
This is a practical design, not a mandated schema. Start with clear identifiers and a controlled register. A more sophisticated platform cannot repair an undefined relationship model.
E-05 v1 is received from Manufacturer A, but its plot coverage is unresolved. F-01 requests the output-to-input reconciliation. The task status can become “response received” while DEC-EX41 remains pending; only a reviewed answer can close the evidence issue.
Coverage belongs beside every file
Record which product, lot, sourcing set and factual period a document supports. A receipt timestamp is not a coverage period. Distinguish the person forwarding a file from the organisation making its underlying assertion.
Retain originals and identify derived records, translations and format conversions. A concise internal summary should not silently replace conditions or exclusions in the supplier’s original wording.
Version changes need an affected-flow review
When PS-07 v2 arrives, retain v1 and ask whether the change corrects geometry, adds or removes plots, changes a period or revises an origin assertion. Find every review that used v1. A filename containing “final” is insufficient, and replacing an old file should not leave an unexplained old approval intact.
Closure requires the reviewer, evidence version, remaining limitations and rationale. A supplier reply or completed task is separate from the material issue being resolved. Escalate contradictions to the responsible operator reviewer rather than treating every exception as a document chase.
Retention is category-specific
Articles 4, 9 and 12 and amended Article 5 provide information/record duties with at least five-year periods under the applicable provisions. Match record categories and start events to actor duties; do not set an unexplained universal deletion date.
A public CRM enquiry is a different record from an EUDR evidence pack. Its purpose and privacy arrangements should govern its retention. Plan permissions and exports for staff departures, expiring supplier portals and the end of a provider contract. A stored URL is not a retained original if access disappears.
The reconstruction test
- Which importing entity and goods were assessed?
- Which relevant input and origin set support the flow?
- Which exact versions were reviewed?
- What remained unresolved, and how were concerns handled?
- Who reached the decision, why, and which applicable reference belongs to it?
Run the test with a colleague who did not prepare the file. It measures internal clarity, not certification. The illustrative diagnostic report shows the flow, inventory, action register and conditional management recommendation as one readable deliverable.
Know what is ready.
Know what is missing.
A focused diagnostic before you commit to a recurring operating model.
