BR-KSA-60Simplified invoice carries no signature block
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-60.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-KSA-60]-Cryptographic stamp (KSA-15) must exist in simplified tax invoices and associated credit notes and debit notes (KSA-2, position 1 and 2 = 02).
Also cited in this report
BR-KSA-28
[BR-KSA-28]-If the cryptographic stamp (KSA-15) exists in the invoice, this cryptographic stamp (KSA-15) must contain the exact "urn:oasis:names:specification:ubl:signature:1" value for signature information ID.
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.
Simplified invoice carries no signature block
Reported assignature_missingthe signature block is missing
What is wrong
The document is a simplified invoice and carries no cac:Signature element anywhere in it. SDK 3.4.8 flags it under BR-KSA-60 as a warning, not a rejection: the finding is reported without failing the document by itself. Read what this rule does and does not establish. ZATCA's message calls the requirement the cryptographic stamp (KSA-15), and the check behind it does not test a stamp: cac:Signature in UBL is a reference block - an id and a signature method - and the check asks only that one exists somewhere in the document and is not empty. The check is what decides, and the consequence is that an unsigned invoice carrying that reference block satisfies BR-KSA-60. So a silent result here is not evidence that this document is stamped. The stamp itself is checked by BR-KSA-28, inside ext:UBLExtensions, and Mutabiq does not check it and never handles certificates or private keys. This rule applies to simplified invoices and their credit and debit notes - the invoice transaction code KSA-2 beginning 02 - and the block is looked for anywhere in the document, including one attached to a line item's certificate.
What to check in your ERP
The block is a constant, not a computed value: ZATCA's own sample simplified invoices carry cac:Signature with cbc:ID set to urn:oasis:names:specification:ubl:signature:Invoice and cbc:SignatureMethod set to urn:oasis:names:specification:ubl:dsig:enveloped:xades. An export missing it entirely is almost always a template built from a pre-Phase-2 UBL sample, or one built for standard invoices - where this rule does not apply - and reused for simplified ones. Add the block to the template in its UBL position; it does not need the signing step to have run.
Simplified invoice's signature block is empty
Reported assignature_emptythe signature block is empty
What is wrong
The document is a simplified invoice and carries at least one cac:Signature element, but every one of them is empty - no text in it or anywhere below it, which UBL permits because every child of the element is optional. ZATCA flags the document under BR-KSA-60 exactly as it does a missing block: as a warning, which does not by itself reject the document. Read what this rule does and does not establish. ZATCA's message calls the requirement the cryptographic stamp (KSA-15), and the check behind it does not test a stamp: cac:Signature in UBL is a reference block - an id and a signature method - and the check asks only that one exists somewhere in the document and is not empty. The check is what decides, and the consequence is that an unsigned invoice carrying that reference block satisfies BR-KSA-60. So a silent result here is not evidence that this document is stamped. The stamp itself is checked by BR-KSA-28, inside ext:UBLExtensions, and Mutabiq does not check it and never handles certificates or private keys. This rule applies to simplified invoices and their credit and debit notes - the invoice transaction code KSA-2 beginning 02 - and the block is looked for anywhere in the document, including one attached to a line item's certificate.
What to check in your ERP
The element is being emitted and its children are not, which normally means a template writes the container and fills it from the signing step's output, and the signing step did not run or returned nothing. The two children ZATCA's samples carry are constants and can be written unconditionally: cbc:ID as urn:oasis:names:specification:ubl:signature:Invoice and cbc:SignatureMethod as urn:oasis:names:specification:ubl:dsig:enveloped:xades. Writing them satisfies this rule; it does not stamp the invoice, which is a separate step in your e-invoicing module.
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(exists(//cac:Signature) and (//cac:Signature) != '')
Reported test
exists(//cac:Signature) and (//cac:Signature) != ''
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:Attachment></cac:AdditionalDocumentReference>+A document that passed: <cac:Signature>+A document that passed: <cbc:ID>urn:oasis:names:specification:ubl:signature:Invoice</cbc:ID>+A document that passed: <cbc:SignatureMethod>urn:oasis:names:specification:ubl:dsig:enveloped:xades</cbc:SignatureMethod>+A document that passed: </cac:Signature><cac:AccountingSupplierParty> <cac:Party>