BR-TMP-7Datumsangaben in UNCEFACT/CII müssen das Attribut format="102" tragen und im Format JJJJMMTT (YYYYMMDD) übermittelt werden.

Official rule text

Dates in CII are written differently from UBL: as YYYYMMDD with no separators, for example 20260826, and the surrounding element must carry the attribute format="102", which announces exactly that pattern.

Severity
Warning
Applies to
CII
Rule set
v2026-08-31
Checked on

Written and checked against the official KoSIT rule set by Dmytro Yalanskyi, NormAPI.

Why does BR-TMP-7 happen?

Almost always the attribute is missing or set to 610 or 616 while the value stays eight digits. Just as often the ISO format is carried over from the UBL output, where hyphens are correct — in CII they are not. Three elements are checked: udt:DateTimeString, qdt:DateTimeString and udt:DateString. And a wrong attribute rarely stops at this warning: BR-03 looks for the invoice date in CII as a udt:DateTimeString with format 102, so a missing or wrong attribute makes the date disappear as far as BR-03 is concerned — and that is an error, not a warning.

What the validator checks

The expression the official KoSIT rule set evaluates — not paraphrased, but read from the Schematron file it ships.

CII
normalize-space(@format) = '102' and matches(normalize-space(text()), '^\d{8}$')

Source: rule set v2026-08-31

How do you fix BR-TMP-7?

Write the date as a udt:DateTimeString with format="102" and eight digits. If you emit both syntaxes, keep date formatting in exactly one place per syntax; otherwise one spelling eventually leaks into the other output — see BR-TMP-6.

In the XML

A CII fragment — the rule applies to that syntax only.

Fails
<ram:IssueDateTime>
  <udt:DateTimeString format="610">2026-08-26</udt:DateTimeString>
</ram:IssueDateTime>
Fixed
<ram:IssueDateTime>
  <udt:DateTimeString format="102">20260826</udt:DateTimeString>
</ram:IssueDateTime>

Related rules

NormAPI provides technical validation, not tax or legal advice.