Codul regulii este BR-RO-DT003.
Data scadenței se scrie exclusiv în format ISO 8601, adică an-luna-zi, cu patru cifre la an și câte două la lună și zi: 2024-07-05. Validatorul verifică două lucruri: lungimea șirului să fie exact 10 caractere și conținutul să poată fi citit ca dată calendaristică. Un format românesc obișnuit, cu puncte, sau o dată fără zerourile de completare (2024-7-5) cade pe ambele verificări.
În programul de facturare, setează formatul de afișare al datei scadenței pe ISO (yyyy-MM-dd), nu pe formatul local dd.MM.yyyy. Dacă data vine dintr-un import sau dintr-un câmp liber completat de operator, adaugă o conversie și zerourile de completare pentru lună și zi înainte de generarea XML-ului.
<ubl:Invoice> <cbc:DueDate>05.07.2024</cbc:DueDate> </ubl:Invoice>
<ubl:Invoice> <cbc:DueDate>2024-07-05</cbc:DueDate> </ubl:Invoice>
In practica nu ajungi sa vezi codul regulii: valoarea e respinsa mai devreme, de schema XML, iar mesajul arata cum scrie mai sus. Regula exista si ea, dar prinde doar cazurile pe care schema le lasa sa treaca.
ro16931-ubl-1.0.9. Factura cu fragmentul din stanga a fost respinsa cu mesajul de mai sus; cea cu fragmentul din dreapta a trecut fara nicio eroare. Verificarea s-a facut pe 14.09.2026.Un element de tip data (BT-9) trebuie sa respecte formatul YYYY-MM-DD
A date (BT-9) MUST be formatted YYYY-MM-DD. ({element} = '{valoare}')
cbc:DueDate
string-length(text()) = 10 and (string(.) castable as xs:date)
Nu am putut confirma din datele primite dacă validatorul ANAF acceptă și un format cu oră sau fus orar în BT-9; textul regulii și testul XPath cer doar lungime 10 și o dată ISO simplă, deci nu recomand altceva. De asemenea, BT-9 este opțional în EN 16931, dar nu am verificat dacă CIUS-RO îl impune în vreun scenariu concret.