But they are mandatory!

This information is defined as mandatory in the documentation. It must appear in the invoice! Or not? This question has reached me more often lately. Often, most e-invoice documentation is not just a list of information, but structured data.

Hierarchical data structures

In hierarchical data structures, information is usually first grouped into logical units. For example, an address may consist of street, zip code, city and country. All these elements are then combined into a unit “address”. However, addresses are not on their own on invoices, but usually belong to a business partner who can be found at this address. A business partner is usually described by his name and address. Other possible information is, for example, its VAT number. The combination of these three pieces of information then forms the business partner. An invoice usually contains at least two business partners, the buyer and the seller. This is exactly how a tree-like structure of information emerges: a hierarchical data structure.

Cardinalities

Technical documentation and data models often define the repetition of the individual information, the so-called cardinality. It is often specified in the format x..y. Where x is the minimum frequency and y is the maximum frequency. This information refers to the technical documentation. For example, a data model or XML based syntax. Clearly defined business rules usually provide the basis for defining cardinalities. However, not every cardinality necessarily has a business rule. Typical values for cardinalities are

• 0..1 The information is optional. It may be omitted. If it is specified, it may be specified a maximum of 1 times. An example of this cardinality is the specification of the number of the associated order. If this does not exist, the information field does not need to be transmitted.
• 1..1 The information is mandatory. It must not be left out. If it is specified, it may be specified a maximum of 1 times. An example of this is the invoice number.
• 0..n or 0..unbounded The information is optional. It may be omitted. If specified, it may be specified as often as you like. Free text for an invoice is usually integrated in this way. There is no compulsion to specify free text. However, any amount of text may be transmitted.
• 1..n or 1..unbounded The information is mandatory. It must not be left out. If specified, it may be specified as often as you like. The item part of an invoice usually has this cardinality. An invoice requires the specification of at least one service or product to be invoiced.

Status declaration

Unlike technical cardinalities, additional status information is often added to documentations. This is used in particular in application recommendations. This defines the application of a technical standard for a specific group of recipients. For optimal processing of electronic invoices, certain information may be required, which is only optional in the technical standard. In practice, such information is often defined as a required indication that allows the unique assignment of an invoice in the recipient system. This could be, for example, the order number, a transaction number or a cash register. Typical information for a status in a documentation is

• R Required. The technical standard has an optional cardinality. (e.g., 0..1) The information is required for processing in the receiver system. Technically, this corresponds to a cardinality of 1..y.
• A Adviced. The technical standard has an optional cardinality. (e.g., 0..1) The information is needed by some recipients of the group. For easier implementation, this value should be included whenever possible.
• D Dependent. The technical standard has an optional cardinality. (e.g., 0..1) Whether the information is needed in the receiving system depends on a condition. This condition should be clearly defined in the application recommendation. An example is the possibility to enter a national tax number instead of a VAT number. The information depends on the type and place of delivery and service.
• O Optional. The technical standard has an optional cardinality. (e.g., 0..1) The recommendation for use makes no statement about this information. The cardinality is preserved.
• N Not used. The technical standard has an optional cardinality. (e.g., 0..1) The recommendation for use prohibits the transmission of this information. Technically, this would correspond to cardinality 0..0. In this status, it should be noted that this limits the interoperability of a standard. See also here.

Mandatory elements in hierarchical structures

Uff. That was a lot of information. Therefore, let us now deal with the question of why certain information can be omitted, even though they are defined as mandatory field 1..1.

In the picture for this post a tree is visible. This tree has branches and leaves on each branch. For the sake of simplicity, I assume that leaves only grow directly on the branches. The tree needs the leaves to live. The leaves of the tree are therefore necessary for its continued existence. So I defined a rule that every branch must have at least one leaf. However, I can also cut off all the branches. Then the rule does not work anymore.

 

An example in the invoice for this is the specification of a different delivery address. Not every invoice has a different delivery address. However, each address requires a minimum amount of information (e.g., country, city, and postal code if necessary) to ensure that the goods actually arrive. Similarly, EN16931 specifies the terms of payment. In the group BG-16 (Payment Instructions) the indication of the means of payment (credit card, bank transfer, etc …) is mandatory. However, the entire group can be omitted:

• BG-16 0..1 PAYMENTINSTRUCTIONS
  • BT-81 1..1 Payment means type code

Such situations often occur in hierarchical data structures. In the last example (method of payment) there are other connections in practice. Thus, the choice of a particular term of payment may entail the provision of further information. Thus, the specification of the SEPA direct debit payment method only makes sense if the required data such as mandate reference and creditor ID are also transmitted. This is where additional business rules come in, but which can be discussed elsewhere.

I am looking forward to further questions, suggestions or articles for this page!