EUDR DDS Preflight Checker for Technical Submission Gaps
Run deterministic required-field and consistency checks against confirmed case facts before an authorised person transfers the prepared values. Every issue points to its evidence and mapping version.
A bounded, attributable workflow.
Inputs, results, versions, and user decisions stay separate so each output can be reproduced and reviewed.
Run a versioned field mapping
Resolve issues and rerun
Checks remain explainable
What the workflow keeps visible
- Required field presence
- Conflicting confirmed values
- Product-code confirmation needs
- Source and mapping versions
DDS Preflight does not submit to the EU Information System or guarantee acceptance by a regulator.
What does EUDR DDS Preflight check?
Filovara DDS Preflight checks whether the latest Scope result and confirmed case facts can populate a versioned technical mapping for ten DDS preparation fields. It surfaces missing, conflicting, unavailable, or confirmation-required values and preserves the source and mapping versions used. It does not submit a declaration to the EU Information System.
Reviewed 2026-08-09
Which DDS preparation fields are checked?
The published technical mapping evaluates ten fields that must come from the latest Scope result or confirmed case facts. Each mapped value retains its source kind and, where applicable, the exact confirmed fact versions that support it.
- Commodity category and commodity code
- Product description, operator role, and activity date
- Country of origin
- Quantity and unit
- Supplier name and batch reference
How missing and conflicting values become reviewable issues
A required value is never silently invented. Preflight records whether a field is mapped, missing, conflicting, awaiting confirmation, or unavailable. The resulting issue identifies the affected field, severity, responsible party, suggested action, and supporting fact versions so a case team can correct the source, confirm a fact, or request one specific item from a supplier before rerunning the check.
Why the Scope result and mapping version matter
The run binds the latest Scope outcome, rule version, source versions, mapping definition, confirmed fact versions, and input snapshot hash. If upstream facts, Scope results, or the mapping change, the earlier output remains historical evidence and the affected check must be run again against the new inputs.
What technical readiness does not mean
A clear preflight means the described technical mapping found no unresolved issue in the selected inputs. It does not verify supplier truthfulness, make a legal scope or risk decision, prove compliance, guarantee acceptance, or replace the authorised person’s review and manual DDS submission.
Questions about EUDR DDS Preflight
Does DDS Preflight submit to the EU Information System?
No. It prepares and checks a reviewable technical draft. An authorised user reviews the materials, signs in with their own EU Login, submits manually, and records the official receipt.
What happens when required DDS data is missing?
The field remains missing and an explicit issue and data requirement identify what is needed, who is responsible, and the next action. The value is not guessed or filled from an unrelated source.
Does DDS Preflight check conflicting confirmed facts?
Yes. When more than one confirmed value cannot be mapped safely to the same DDS field, the run records a conflict that must be resolved before the affected output can be treated as technically ready.
Should I rerun Preflight after changing evidence?
Yes. Changes to confirmed facts, the Scope result, source availability, or the published mapping can make an earlier run stale. Preserve the historical run and create a new versioned result.