BR-KSA-F-01A date on this simplified invoice is not written as ten characters
Mutabiq checks Saudi ZATCA Phase 2 e-invoice XML before you submit it: pre-validation against published ZATCA requirements, not an approval by the authority. This page explains one rule, BR-KSA-F-01.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-KSA-F-01]-A date MUST be formatted YYYY-MM-DD, in accordance to the "Calendar date complete representation" as specified by ISO 8601:2004, format YYYY-MM-DD.
What Mutabiq reports
One entry for each way this rule can be reported.
Reported as
What kind of value was found — empty, not_15_digits and the like — never the value itself.
A date on this simplified invoice is not written as ten characters
Reported asnot_10_charactersnot ten characters long
What is wrong
A date on this invoice is not exactly ten characters long. ZATCA requires every date on a simplified invoice to be written as YYYY-MM-DD and nothing else, under BR-KSA-F-01, and rejects anything longer or shorter. The commonest cause of a long one is a time zone offset appended to the date - 2026-09-01+03:00 is a perfectly valid date and is sixteen characters, so it is refused here. The check covers the issue date, the due date and the actual delivery date under cac:Delivery, wherever they appear in the document. This rule applies to simplified invoices only; a standard invoice's dates are not checked this way.
What to check in your ERP
Write dates as the date alone: 2026-09-01, with no time, no offset and no letter Z after it. This normally comes from a mapping that writes a full timestamp into a date field, or from a serialiser configured to emit time zone information on every date it writes. The time of issue belongs in cbc:IssueTime, which is a separate element - moving it there rather than trimming the string is the fix, because the offset is usually carrying real information.
A date on this simplified invoice is not a real calendar date
Reported asnot_a_datenot a real calendar date
What is wrong
A date on this invoice is ten characters long but is not a date that exists. ZATCA requires every date on a simplified invoice to be a real calendar date under BR-KSA-F-01, so 2026-02-30 and 2026-13-01 are both refused even though each is ten characters and looks like a date. The length is right; it is the value that is not. The check covers the issue date, the due date and the actual delivery date under cac:Delivery. This rule applies to simplified invoices only.
What to check in your ERP
Two causes account for most of these. The first is a day and month written the other way round - 2026-13-01 is the first of January written as 13-01 and then reassembled in the wrong order, so check whether a date is being reformatted between your system and the export. The second is a date arithmetic step that produced an impossible day, such as adding a month to 31 January and getting 31 February. Fix the value at its source; the format is already correct.
The clause that runs
Quoted from the validation-rule stylesheet ZATCA publishes, at the file and line named below. The executed guard is what the check runs; the reported test is what it prints when it fails, and the two are not always the same.
Executed guard
not(string-length(.) = 10 and matches( string(.), '[2-9][0-9]([0-9]{2}[\-]((0[13578]|1[02])[\-](0[1-9]|[12][0-9]|3[01])|(0[469]|11)[\-](0[1-9]|[12][0-9]|30)|(02)[\-](0[1-9]|1[0-9]|2[0-8]))|([02468][048]|[13579][26])[\-](02)[\-]29)') )
Reported test
(string-length(.) = 10 and (string(.) castable as xs:date))
As shipped in ZATCA SDK 3.4.8: the copy quoted here is, byte for byte, the file that release ships. The date in the file name is the name ZATCA gives the file; the rules in it are those of SDK 3.4.8.
A worked example
A synthetic document from the measured test corpus that trips this rule, shown where it differs from one that passed. Mutabiq's report names the class of the value, never the value itself.
Where it differs from a document that passed
− This example
+ A document that passed
</cac:AccountingCustomerParty><cac:Delivery>−This example: <cbc:ActualDeliveryDate>2026-09-01Z</cbc:ActualDeliveryDate>+A document that passed: <cbc:ActualDeliveryDate>2026-09-01</cbc:ActualDeliveryDate></cac:Delivery><cac:PaymentMeans>