Mandatory vs Conditional Fields in an Invoice Profile

A mandatory field is required in the relevant model context. A conditional requirement depends on a defined circumstance or relationship. A field that appears optional in a general structure can still be required when a condition applies. Read the actual profile rules instead of deciding from whether an input box is visible.

The mapping preparation workflow records these rules before implementation. The creator’s application validation is limited to its supported fields; it does not determine the mandatory or conditional requirements of every recognised invoice profile.

Read occurrence rules in context

A specification may state how often a value or group can occur. Those occurrence rules concern the defined structure and role, not simply whether a human can find similar text somewhere on the page. A note containing a date does not automatically fill the intended typed date field.

Check the parent group and applicable profile. A field can have one occurrence within each repeated line while the invoice contains many lines. Ignoring the group context can lead to an incorrect assumption that the whole document accepts only one value.

Record the exact edition and profile used. Similar field names in another publication may have different constraints. Do not combine a general schema’s broad allowance with a receiver-specific rule from an unrelated workflow.

Identify the condition explicitly

Write down what makes the requirement apply and which source fact establishes it. A condition may depend on an amount, a selected method or another value. The implementation needs that dependency, not a generic instruction to require the field whenever convenient.

OpenPeppol’s published invoice binding provides examples of relationships between payment information and other invoice values. Treat such examples as rules of that specific profile and release, not a universal law for every invoice format or jurisdiction.

If the determining fact is unknown, mark the condition unresolved. Do not choose a convenient default merely to avoid collecting the information. A missing decision can be hidden by a completed but incorrectly classified field.

Distinguish absence from incomplete content

An absent optional group and a present group lacking required child values are different structural cases. A final mapper must know whether to omit the group or populate its required contents under the actual rules. Empty placeholders are not automatically equivalent to omission.

Do not generate every possible element with an empty string because the source form has unused fields. That may produce invalid or misleading output. Conversely, omitting an entire group cannot be used to evade a condition that requires it.

Use the semantic-versus-schema review to identify which validation layer can detect each issue. A schema rule may catch a missing child, while a business rule tests the circumstance requiring the group. The underlying source fact still needs accurate review.

Compare source capability with requirements

For each mandatory or conditionally required fact, identify a supported source field or a separate confirmed record. Typed endpoints, codes, line periods and certain financial structures may exceed the current creator’s model.

Do not put a required value into an unrelated source field just to preserve it somewhere. The final adapter needs its intended meaning. Keep a clear gap record and use final software that can represent the fact correctly.

A note explaining the requirement can help a person continue the work, but it is not implementation. The current application JSON remains its own schema, and application field success does not establish completion of the formal model.

Build positive and negative tests

Use fictional data where the condition applies and confirm the required field is generated and checked. Then remove the field and inspect the failure. This demonstrates the implementation responds to the actual dependency, not merely to a permanently required input.

Create another case where the condition does not apply and verify the intended representation. Check that the software does not invent irrelevant data or generate forbidden combinations. Both directions matter when reviewing conditional behaviour.

Keep the input facts, expected result, actual file and validator configuration with the test. A report from a simpler example does not establish that this condition is covered. Repeat the relevant cases when the profile or implementation changes.

Record the remaining review responsibilities

Technical rules cannot establish every business fact behind a condition. A correctly represented identifier may still belong to the wrong party, and a tax category may still reflect an incorrect determination. Preserve factual review alongside automated checks.

Before delivery, resolve missing source facts, run the required validation and retain the exact final version. Do not describe a completed form as formal conformance. The creator supports local preparation and field checks, while an implemented mapper and appropriate review must satisfy the destination’s actual mandatory and conditional requirements.

Keep a condition table beside the mapping: source trigger, required target fact, expected positive result and expected negative result. When the trigger changes, the test should demonstrate the intended behaviour in both directions. This is more useful than a single successful example containing every possible value, which cannot show whether conditional logic was implemented or merely bypassed by a fully populated sample.