Business Terms and Business Groups in EN 16931

A business term identifies an individual invoice fact with a defined meaning. A business group organises related facts into a defined relationship. For mapping work, both matter: knowing a value’s label is insufficient if it is assigned to the wrong party, line or document context.

The EN 16931 mapping preparation workflow uses those definitions before choosing target elements. The current creator has its own fields and visual sections; those are not automatically a complete implementation of the standard’s terms or groups.

Start with a single fact

Consider the seller’s name. Its intended meaning is more specific than whichever brand text appears largest in a header. The Commission’s binding example shows how a defined seller-name business term is represented in different message syntaxes.

That example illustrates why the term’s definition controls the mapping. A source value must be the right fact, not merely a string that fits a target text type. Copying a trading slogan or an unrelated payee name would preserve characters while changing meaning.

Record the confirmed source and the intended term in your mapping sheet. If the source is ambiguous, resolve it before choosing a target element. A mapper cannot responsibly decide which company name is authoritative solely from its position in a page layout.

Understand the group context

Seller facts belong with the seller role; buyer facts belong with the buyer role. Related addresses and identifiers should remain attached to the intended party. A group provides context that a bare value cannot supply on its own.

Similarly, an invoice line groups facts about a particular billed supply. Quantity, unit, price and description must describe the same line. Moving a valid quantity to another line can produce a structurally plausible but commercially wrong invoice.

Do not equate groups with form panels. One panel may combine several semantic roles, while a target group may require components that the current editor does not collect separately. Use the definitions and required relationships rather than the screen’s visual arrangement.

Record repetition and conditions

A model can specify whether a fact or group may occur once, several times or under a condition. Check the applicable edition and profile rather than assuming every input box is a universal required field. Profiles may constrain the broader model further.

If a group is present, related rules can require particular facts inside it. A blank optional section and a partly completed required group are different cases. The final implementation needs the actual applicable rules, not a generic rule that every field is optional unless visible.

Use the mandatory and conditional field review to identify those dependencies. Preserve the transaction condition and its evidence so a later reviewer can understand why the mapping included or required the group.

Keep terminology tied to a version

Record which standard edition, syntax binding and profile your definitions come from. Similar names across documentation do not prove identical scope. A future or superseded publication should not silently become the production target.

OpenPeppol’s billing documentation provides a concrete profile example with identified business terms and groups. Use it in its own stated context. Do not present a Peppol-specific condition as an automatic requirement for every EN 16931 implementation.

The current creator does not implement those formal group structures. Its JSON has application-owned fields and limited supported relationships. Educational discussion of terms does not change the exported schema or establish conformance.

Use a practical mapping test

Create fictional seller and buyer records with clearly different names and identifiers. Map them through the proposed final system, then trace each target value back to its source role. A passing schema check alone may not expose a semantic exchange between parties.

Next, use two lines with different quantities and references. Verify that their grouped facts remain together rather than only checking the document total. Matching sums can conceal swapped line information.

Keep a mapping entry for each reviewed fact, including source, intended meaning, group context, target path and test evidence. Mark unsupported facts explicitly. A clear gap is more useful than forcing an unrelated source field into the target.

Before delivery, use software that genuinely implements the required model and validation. The creator can support source preparation, but its printable output, application JSON and CSV do not provide formal business-term mapping. The practical aim is to preserve meaning and relationships so the final implementation can be checked accurately, not to make the interface resemble the terminology of a standard.

A practical worksheet can use separate columns for fact, group context and target. For a fictional quantity of three, record which line it belongs to and which unit it measures. The number alone is not enough. For a fictional identifier, record the party role and identifier type. This prevents a mapping review from approving values in isolation while losing the relationships that make them meaningful. Use the worksheet to test a changed group order as well, so the implementation does not depend on the original screen arrangement.

Record the group definition used by the mapper.