BR-KSA-70Issue time is missingMutabiq 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-70.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
One entry for each way this rule can be reported.
Reported asissue_time_missingthe issue time is missing
The invoice has no cbc:IssueTime (KSA-25). ZATCA rejects the document under BR-KSA-70, which requires the issue time on every invoice, written as hh:mm:ss in local time or hh:mm:ssZ in UTC.
Map the time the invoice was issued into cbc:IssueTime, directly after cbc:IssueDate.
Reported asissue_time_bad_formatnot written as hh:mm:ss
cbc:IssueTime is present but is not a time of day written as hh:mm:ss (for example 19:20:30) or hh:mm:ssZ (19:20:30Z). ZATCA rejects the document under BR-KSA-70. Fractions of a second, a time zone offset such as +03:00, a missing seconds field and spaces around the value all fail this check, even where the XML schema would accept them.
Write the time with two digits each for hours, minutes and seconds, in 24-hour form, and nothing else. Timestamps copied from a database often carry milliseconds or an offset; strip them when the XML is written.
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.
not(exists(cbc:IssueTime) and (cbc:IssueTime) != '' and (matches(cbc:IssueTime, '^([01][0-9]|2[0-3]):([0-5][0-9]):([0-5][0-9])$') or matches(cbc:IssueTime, '^([01][0-9]|2[0-3]):([0-5][0-9]):([0-5][0-9])Z$')))exists(cbc:IssueTime) and (cbc:IssueTime) != '' and (matches(cbc:IssueTime, '^([01][0-9]|2[0-3]):([0-5][0-9]):([0-5][0-9])$') or matches(cbc:IssueTime, '^([01][0-9]|2[0-3]):([0-5][0-9]):([0-5][0-9])Z$'))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.
<cbc:UUID>3cf5ee18-ee25-44ea-a444-2c37ba7f28be</cbc:UUID><cbc:IssueDate>2026-09-01</cbc:IssueDate>This example: <cbc:IssueTime>10:00:00.0000000000000000000</cbc:IssueTime>A document that passed: <cbc:IssueTime>10:00:00</cbc:IssueTime><cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode><cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>Download this example (.xml)Check it in Mutabiq
This page's example, checked by the same rules your own upload goes through. No upload and no sign-in.
Rules evaluated against the same part of the document. One wrong value often reports several of them at once.
MTB-BR-CL-KSA-14QR code is longer than 1000 charactersMTB-BR-KSA-08Seller identification carries no scheme idMTB-BR-KSA-26Previous invoice hash attachment carries no payload elementMTB-BR-KSA-27Simplified invoice carries no QR code referenceMTB-BR-KSA-29Signature block does not carry the required signature idMTB-BR-KSA-30Signature block does not carry the required signature methodMTB-BR-KSA-33Invoice counter value is missingMTB-BR-KSA-34Invoice counter value contains something other than digits© 2026 Hayatiq AI Solutions F.Z.E. All rights reserved.