Error in Simplified Invoice Report – Signed Properties Hashing Issue

Dear Zatca

We are currently working on generating a simplified invoice report and have encountered the following error in simulation mode:
json
{
“type”: “ERROR”,
“code”: “signed-properties-hashing”,
“category”: “CERTIFICATE_ERRORS”,
“message”: “Invalid signed properties hashing, SignedProperties with id=‘xadesSignedProperties’”,
“status”: “ERROR”
}

This error arises specifically for the simplified invoice, while the standard invoice report is functioning as expected without any issues. Could you kindly assist us in resolving the “Invalid signed properties hashing” error and advise if there is any configuration or certificate update required on our end to fix this issue?

Your prompt assistance is greatly appreciated.

Best regards,

Dear @mubarkoot

Thank you for reaching out.

Unlike standard invoice, simplified tax invoice & its associated notes must be signed with the taxpayer X.509 certificate (CSID), there are 2 returned X.509 certificates in the taxpayer’s EGS onboarding process.

First X.509 certificate: CCSID, which is returned after completing the first API (Compliance CSID), It’s returned as a security binary token which will be used as a username in the authorization, it’s also used as a signing certificate (X.509) after we decode it using base64 (we decode the binarysecurityToken) using base64 decoder and the output is the X.509 certificate, we use this certificate to sign the simplified tax invoices in the compliance invoice API (Compliance checks phase).

Second X.509 Certificate: PCSID, which is returned after completing the third API on the onboarding process (Production CSID), it’s also returned as a binary security token, and will be used as the username in te authorization for both reporting & clearance API, it’s also used as a signing certificate (X.509) after we decode it using base64 (we decode the binarysecurityToken) using base64 decoder and the output is the X.509 certificate, we use this certificate to sign the simplified tax invoices in the reporting API.

Please refer to the steps of manual signing using ZATCA’s JAVA SDK below:

After sending the CSR in the Compliance request CSID API, a Binarytoken & secret will be returned

Take the Binarytoken output, and decode it using base64 decoder, the decoded value is the x.509 certificate

Go to the SDK file to the following path: SDK/Data/Certificates/Cert.pem

Replace the value with your obtained x.509 certificate

Go to the SDK and use the command: fatoora -sign -invoice “invoice.xml”

Now the invoice will be signed & can be submitted successfully in the compliance checks phase (Compliance invoice API)

Redo the same steps above with the returned PCSID from the third API in the onboarding process and sign your simplified tax invoices with before sending to Reporting API

If you are implementing the signing process in your own code, please refer to This document:
SigningProcessUpdated.pdf

If you require any additional support other than the mentioned steps above, please do not hesitate to reach out.

Thank you.

Dear @halrashidy

We followed the steps as per the guideline attached in your post. However, we still get the issue.

Do you have any idea about the error message, shown in the screen below (we used SDK CLI)

We tried all possible scenarios.
Should we follow any specific format for Signed Properties Hashing?

Please let us know

Dear @mubarkoot

Thanks for collaboration,

Regarding to the error that you are facing, it seems that the issue is with the certificate itself, Can I kindly ask you to check and confirm that you are using the same certificate and private key that generated to the exact VAT number in the XML, If they are replaced successfully in the following path in the SDK “SDK\Java\zatca-einvoicing-sdk-Java-238-R3.3.9\Data\Certificates”?

If so, Please share all the details of your concern via below mail, to schedule one to one meeting with our technical team.

SP mail: sp_support@zatca.gov.sa

Thanks,
Ibrahem Daoud.

We followed the exact steps, still the same issue persists.

Regarding the certificate, we confirm that there is no issue, as we are using the same certificate and private key that generated to the exact VAT number.

We even tested this on Postman, as the below screenshot:

The following is the xml invoice. If you further need any information, please let us know.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"><ext:UBLExtensions><ext:UBLExtension><ext:ExtensionURI>urn:oasis:names:specification:ubl:dsig:enveloped:xades</ext:ExtensionURI><ext:ExtensionContent><sig:UBLDocumentSignatures xmlns:sac="urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2" xmlns:sbc="urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2" xmlns:sig="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2"><sac:SignatureInformation><cbc:ID>urn:oasis:names:specification:ubl:signature:1</cbc:ID><sbc:ReferencedSignatureID>urn:oasis:names:specification:ubl:signature:Invoice</sbc:ReferencedSignatureID><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="signature"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11"></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"></ds:SignatureMethod><ds:Reference Id="invoiceSignedData" URI=""><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"><ds:XPath>not(//ancestor-or-self::ext:UBLExtensions)</ds:XPath></ds:Transform><ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"><ds:XPath>not(//ancestor-or-self::cac:Signature)</ds:XPath></ds:Transform><ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"><ds:XPath>not(//ancestor-or-self::cac:AdditionalDocumentReference[cbc:ID='QR'])</ds:XPath></ds:Transform><ds:Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod><ds:DigestValue>6J/2DSKDqSV/a4r8ClecBishf4Pybppm0dCPX2oI7hc=</ds:DigestValue></ds:Reference><ds:Reference Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties" URI="#xadesSignedProperties"><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod><ds:DigestValue>51iizQHxieZ7MnUTUjZEUisCKmYg0bGjBZYvByuuu/A=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>MEUCIDhWab8dS4FBHeWEM8SHsLcDy2R4to004E3cNlaKaptIAiEA8j++wfqf/k/9QGh0m71qcF50oADrFFITpvGQubiP0Z0=</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIICQDCCAeigAwIBAgIGAZUeJgi4MAoGCCqGSM49BAMCMBUxEzARBgNVBAMMCmVJbnZvaWNpbmcwHhcNMjUwMjE5MTIxOTE4WhcNMzAwMjE4MjEwMDAwWjB/MSAwHgYDVQQDDBdQUk8tMTI2LTMxMDExMDgwODgwMDAwMzEsMCoGA1UECwwj2YHYsdi5INin2YTYsdmK2KfYtiB8IFJpeWFkaCBCcmFuY2gxIDAeBgNVBAoMF9iq2KfYrNixIHwgd2FuaSB0cmFkaW5nMQswCQYDVQQGEwJTQTBWMBAGByqGSM49AgEGBSuBBAAKA0IABAZw9ACShmtreRBpJsmC/y6IL3WZgHP3QF/OxL9wWDdr/0aUr36OkWtYRzX+7G8eMl3KYEKBi/6TeBPUvJJigx2jgbwwgbkwDAYDVR0TAQH/BAIwADCBqAYDVR0RBIGgMIGdpIGaMIGXMRowGAYDVQQEDBExLU5KVXwyLUdPTXwzLVhBUDEfMB0GCgmSJomT8ixkAQEMDzMxMDExMDgwODgwMDAwMzENMAsGA1UEDAwEMTEwMDEdMBsGA1UEGgwUMzU3MixUaGUga2hhZGVyLDY5MTIxKjAoBgNVBA8MIcOYwqfDmcKEw5jCrsOYwrbDmMKxIHwgVGhlIGtoYWRlcjAKBggqhkjOPQQDAgNGADBDAh84CuLXPCbJMTxlisEZ3OA3eDIU8yK/RyTaL7nPe88UAiA6iN53dTBoMpsv36EaO0epdogZkwiPhd+KBD58UP8pdg==</ds:X509Certificate></ds:X509Data></ds:KeyInfo><ds:Object><xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="signature"><xades:SignedProperties Id="xadesSignedProperties"><xades:SignedSignatureProperties><xades:SigningTime>2025-02-27T12:23:41</xades:SigningTime><xades:SigningCertificate><xades:Cert><xades:CertDigest><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod><ds:DigestValue>OWU1ZDFjM2MyNGFkYzkxODY3ZThkMDg0ZjUyMzdiOGI4NDg1ZmFhN2E2ZjQ5YTIyMzY3MTJmMzZjZjQ4NjU4MQ==</ds:DigestValue></xades:CertDigest><xades:IssuerSerial><ds:X509IssuerName>CN=eInvoicing</ds:X509IssuerName><ds:X509SerialNumber>1739967563960</ds:X509SerialNumber></xades:IssuerSerial></xades:Cert></xades:SigningCertificate></xades:SignedSignatureProperties></xades:SignedProperties></xades:QualifyingProperties></ds:Object></ds:Signature></sac:SignatureInformation></sig:UBLDocumentSignatures></ext:ExtensionContent></ext:UBLExtension></ext:UBLExtensions><cbc:ProfileID>reporting:1.0</cbc:ProfileID><cbc:ID>ORD-00013</cbc:ID><cbc:UUID>aa64a665-0f94-4930-87ad-f2a9e35bd77b</cbc:UUID><cbc:IssueDate>2025-02-27</cbc:IssueDate><cbc:IssueTime>12:23:41</cbc:IssueTime><cbc:InvoiceTypeCode name="0200000">388</cbc:InvoiceTypeCode><cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode><cbc:TaxCurrencyCode>SAR</cbc:TaxCurrencyCode><cac:AdditionalDocumentReference><cbc:ID>ICV</cbc:ID><cbc:UUID>54307</cbc:UUID></cac:AdditionalDocumentReference><cac:AdditionalDocumentReference><cbc:ID>PIH</cbc:ID><cac:Attachment><cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">X+zrZv/IbzjZUnhsbWlsecLbwjndTpG0ZynXOif7V+k=</cbc:EmbeddedDocumentBinaryObject></cac:Attachment></cac:AdditionalDocumentReference><cac:AdditionalDocumentReference><cbc:ID>QR</cbc:ID><cac:Attachment><cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">ARfYqtin2KzYsSB8IHdhbmkgdHJhZGluZwIPMzEwMTEwODA4ODAwMDAzAxMyMDI1LTAyLTI3VDEyOjIzOjQxBAQwLjUwBQQwLjA3Biw2Si8yRFNLRHFTVi9hNHI4Q2xlY0Jpc2hmNFB5YnBwbTBkQ1BYMm9JN2hjPQdgTUVVQ0lEaFdhYjhkUzRGQkhlV0VNOFNIc0xjRHkyUjR0bzAwNEUzY05sYUthcHRJQWlFQThqKyt3ZnFmL2svOVFHaDBtNzFxY0Y1MG9BRHJGRklUcHZHUXViaVAwWjA9CFgwVjAQBgcqhkjOPQIBBgUrgQQACgNCAAQGcPQAkoZra3kQaSbJgv8uiC91mYBz90BfzsS/cFg3a/9GlK9+jpFrWEc1/uxvHjJdymBCgYv+k3gT1LySYoMdCUUwQwIfOAri1zwmyTE8ZYrBGdzgN3gyFPMiv0ck2i+5z3vPFAIgOojed3UwaDKbL9+hGjtHqXaIGZMIj4XfigQ+fFD/KXY=</cbc:EmbeddedDocumentBinaryObject></cac:Attachment></cac:AdditionalDocumentReference><cac:Signature><cbc:ID>urn:oasis:names:specification:ubl:signature:Invoice</cbc:ID><cbc:SignatureMethod>urn:oasis:names:specification:ubl:dsig:enveloped:xades</cbc:SignatureMethod></cac:Signature><cac:AccountingSupplierParty><cac:Party><cac:PartyIdentification><cbc:ID schemeID="CRN">310110808800003</cbc:ID></cac:PartyIdentification><cac:PostalAddress><cbc:StreetName>The khader</cbc:StreetName><cbc:BuildingNumber>3572</cbc:BuildingNumber><cbc:CitySubdivisionName>الخضر | The khader</cbc:CitySubdivisionName><cbc:CityName>الخضر | The khader</cbc:CityName><cbc:PostalZone>12646</cbc:PostalZone><cac:Country><cbc:IdentificationCode>SA</cbc:IdentificationCode></cac:Country></cac:PostalAddress><cac:PartyTaxScheme><cbc:CompanyID>310110808800003</cbc:CompanyID><cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:PartyTaxScheme><cac:PartyLegalEntity><cbc:RegistrationName>تاجر | wani trading</cbc:RegistrationName></cac:PartyLegalEntity></cac:Party></cac:AccountingSupplierParty><cac:AccountingCustomerParty><cac:Party><cac:PostalAddress><cbc:StreetName>street</cbc:StreetName><cbc:BuildingNumber>1234</cbc:BuildingNumber><cbc:CitySubdivisionName>Riyadh Area</cbc:CitySubdivisionName><cbc:CityName>Riyadh</cbc:CityName><cbc:PostalZone>24263</cbc:PostalZone><cac:Country><cbc:IdentificationCode>SA</cbc:IdentificationCode></cac:Country></cac:PostalAddress><cac:PartyTaxScheme><cbc:CompanyID>323456789123453</cbc:CompanyID><cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:PartyTaxScheme><cac:PartyLegalEntity><cbc:RegistrationName>Walk-in Customer</cbc:RegistrationName></cac:PartyLegalEntity></cac:Party></cac:AccountingCustomerParty><cac:Delivery><cbc:ActualDeliveryDate>2025-02-27</cbc:ActualDeliveryDate></cac:Delivery><cac:PaymentMeans><cbc:PaymentMeansCode>10</cbc:PaymentMeansCode></cac:PaymentMeans><cac:AllowanceCharge><cbc:ChargeIndicator>false</cbc:ChargeIndicator><cbc:AllowanceChargeReason>discount</cbc:AllowanceChargeReason><cbc:Amount currencyID="SAR">0.00</cbc:Amount><cac:TaxCategory><cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5305">S</cbc:ID><cbc:Percent>15</cbc:Percent><cac:TaxScheme><cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5153">VAT</cbc:ID></cac:TaxScheme></cac:TaxCategory></cac:AllowanceCharge><cac:TaxTotal><cbc:TaxAmount currencyID="SAR">0.50</cbc:TaxAmount></cac:TaxTotal><cac:TaxTotal><cbc:TaxAmount currencyID="SAR">0.07</cbc:TaxAmount><cac:TaxSubtotal><cbc:TaxableAmount currencyID="SAR">0.43</cbc:TaxableAmount><cbc:TaxAmount currencyID="SAR">0.07</cbc:TaxAmount><cac:TaxCategory><cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5305">S</cbc:ID><cbc:Percent>15.00</cbc:Percent><cac:TaxScheme><cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5153">VAT</cbc:ID></cac:TaxScheme></cac:TaxCategory></cac:TaxSubtotal></cac:TaxTotal><cac:LegalMonetaryTotal><cbc:LineExtensionAmount currencyID="SAR">0.43</cbc:LineExtensionAmount><cbc:TaxExclusiveAmount currencyID="SAR">0.43</cbc:TaxExclusiveAmount><cbc:TaxInclusiveAmount currencyID="SAR">0.50</cbc:TaxInclusiveAmount><cbc:AllowanceTotalAmount currencyID="SAR">0</cbc:AllowanceTotalAmount><cbc:PrepaidAmount currencyID="SAR">0</cbc:PrepaidAmount><cbc:PayableAmount currencyID="SAR">0.50</cbc:PayableAmount></cac:LegalMonetaryTotal><cac:InvoiceLine><cbc:ID>105835</cbc:ID><cbc:InvoicedQuantity unitCode="PCE">1</cbc:InvoicedQuantity><cbc:LineExtensionAmount currencyID="SAR">0.43</cbc:LineExtensionAmount><cac:TaxTotal><cbc:TaxAmount currencyID="SAR">0.07</cbc:TaxAmount><cbc:RoundingAmount currencyID="SAR">0.50</cbc:RoundingAmount></cac:TaxTotal><cac:Item><cbc:Name>ماء</cbc:Name><cac:ClassifiedTaxCategory><cbc:ID>S</cbc:ID><cbc:Percent>15.00</cbc:Percent><cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:ClassifiedTaxCategory></cac:Item><cac:Price><cbc:PriceAmount currencyID="SAR">0.43</cbc:PriceAmount><cac:AllowanceCharge><cbc:ChargeIndicator>false</cbc:ChargeIndicator><cbc:AllowanceChargeReason>discount</cbc:AllowanceChargeReason><cbc:Amount currencyID="SAR">0.00</cbc:Amount></cac:AllowanceCharge></cac:Price></cac:InvoiceLine></Invoice>

Dear @mubarkoot

We tried your XML using our SDK and it’s worked fine in the reporting API, it seems that the issue in the signing process from your solution
Kindly review the file that my colleague Hager shared previously ensure that you understanding the exact functionality to implement your own solution.

Thanks,
Ibrahem Daoud.

Thanks for your answer! :slightly_smiling_face: I have another question: in the private key header and footer, should it start with -----BEGIN PRIVATE KEY----- or -----BEGIN EC PRIVATE KEY----- when generating a digital signature?