Error Code 1006: Invalid Cryptographic Stamp

When you submit your electronic invoice to the Fatoora platform in the second phase of e-invoicing, the response may come back with error code 1006 and a message stating that the “cryptographic stamp is invalid.” This error means one thing precisely: the digital signature attached to the invoice did not pass validation — that is, the platform computed the expected signature and compared it against the signature present in the invoice, and the two did not match. The result is that the invoice is rejected and not cleared, and your transaction stalls until you fix the cause.

This guide focuses on error code 1006 alone. We will not discuss invoice field errors, nor tax registration number errors, nor value-added tax problems. Our goal is to take you from a vague rejection message to a specific, fixable diagnosis within minutes. We will show how the error appears in the rejection response, then break down its four root causes one by one, along with how to detect each cause, fix it, and prevent it from recurring.

Why does a single error code deserve a standalone guide? Because the cryptographic stamp is the cornerstone of the second phase. A tax invoice in business (B2B) transactions must be cleared by the Fatoora platform before it is delivered to the buyer. If its stamp is rejected with code 1006, you have no valid invoice, and the entire transaction may stall. As for consumer (B2C) invoices, reporting is required within twenty-four hours, and a rejected stamp means a buildup of unreported invoices and exposure to violations. Understanding this error is therefore not a technical luxury but a direct operational necessity.

If you use a compliant accounting platform such as Qoyod, the stamping layer is managed automatically behind the scenes, and you will most often not see this error at all. But understanding its mechanism remains useful for direct integration, or when diagnosing a sudden rejection from the Authority’s system. For a broader picture of all signature errors, see the guide on electronic invoice signature errors, and for the wider family of integration errors, see ZATCA e-invoicing errors.

What error code 1006 means exactly

Before diagnosis, you must understand what the Authority’s system checks when validating the stamp. A second-phase electronic invoice is not a signed PDF file. It is an XML file in UBL 2.1 format that is digitally signed, and the signature is computed as a cryptographic hash of the invoice content. This hash is encrypted with the issuer’s private key, and the signature is attached to the invoice along with its accompanying public key.

On receipt, the Fatoora platform repeats the same calculation. It takes the invoice content, computes the cryptographic hash over it, then verifies that the attached signature matches this hash using the public key. If they match, the invoice is valid and has not been altered after signing. If they do not match, the stamp is rejected and error code 1006 is returned. The accompanying message usually reads something like “the signature value does not match the invoice hash.”

The important thing to grasp is that 1006 does not tell you the root cause — only the symptom. It says “validation failed,” but it does not say “why.” The task of this guide is to translate this single symptom into one of its four known causes, because each cause has a completely different fix. Anyone who tries random fixes without pinpointing the cause wastes hours. Anyone who starts from the correct diagnosis reaches the fix directly.

It is also important to distinguish code 1006 from errors that concern the invoice data. When the fault is in one of the invoice fields — such as a tax registration number written in the wrong format, or a total that does not match the sum of the line items — the category returned is different from the stamping layer. Code 1006, by contrast, occurs after the invoice passes its data checks, specifically at the signature validation stage. This means that reaching 1006 is an implicit signal that your invoice content may be sound, and that the problem is confined to how it was stamped rather than what it contains.

This distinction saves you a great deal of effort. Many users, on seeing any rejection, begin reviewing every field in the invoice line by line — a waste of time when the code is 1006. The right question is not “which field did I get wrong?” but “which element in the signing chain broke?” The chain starts with generating the certificate request, then registering it with the Authority, then signing with the private key, and finally validation on the canonical form. A fault in any link of this chain produces the same code.

Remember too that the signing algorithm approved by the Authority is precisely specified: ECDSA on the elliptic curve secp256k1 with the SHA-256 hash function. And any digital certificate you use in signing is issued by the Authority, named the Cryptographic Stamp Identifier (CSID). These two elements — the algorithm and the certificate — are the key to understanding every one of the four causes.

How to read error code 1006 in the rejection response

When the stamp is rejected, the Authority’s system returns a JSON response containing a list of errors, each with a code, a message, and a category. Learn to read this response before anything else, because it tells you clearly that the problem is in the stamping layer and not in the invoice data. Here is a simplified sample of a rejection response caused by error code 1006:

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "code": "1006",
        "type": "ERROR",
        "category": "CRYPTOGRAPHIC_STAMP",
        "message": "Invalid cryptographic stamp: the signature value does not match the invoice hash."
      }
    ]
  },
  "clearanceStatus": "NOT_CLEARED"
}

Note three elements in this response. The field code carries the value 1006, which precisely identifies the error type. The field category equals CRYPTOGRAPHIC_STAMP, which confirms that the error is in the stamping layer and not in one of the invoice fields. And the field clearanceStatus equals NOT_CLEARED, meaning the invoice was not cleared and may not be delivered to the buyer.

The practical rule here is clear. Whenever you see the category CRYPTOGRAPHIC_STAMP with code 1006, stop inspecting the invoice data. Neither the quantities nor the prices nor the tax registration number are the cause. The problem is in how the invoice was signed or in the certificate used. Direct all your diagnostic effort to the four causes that follow.

The four causes of error code 1006

Error code 1006 looks like one thing, but it is a window onto four fundamentally different faults. Three of them concern the certificate and keys, and one concerns the way the signature itself is computed. Once you know which one is responsible for your rejection, you know where to look for the fix. We will take them ordered from the most common to the most technically subtle.

Cause one: using the wrong CSID certificate (confusing compliance with production)

This is the most common cause, and the most deceptive, because invoices may pass in testing then suddenly be rejected in production. The Authority issues two types of Cryptographic Stamp Identifier certificate: a compliance certificate used in the simulation environment to test the integration, and a production certificate used in the live environment. The two certificates are different, and each environment has its own certificate.

The error occurs when the system signs production invoices with the compliance certificate, or sends an invoice signed with the production certificate to the simulation environment. In both cases, the Authority’s system tries to verify the signature with the public key of the certificate correct for that environment, and the signature computed with a different certificate does not match. The result is error code 1006.

How to detect it: Check the environment you are sending to and the certificate used in signing. If the rejection began right after you moved from simulation to production, this cause is by far the leading candidate. Review the integration settings and make sure each environment uses its own certificate, not the other environment’s certificate.

How to fix it: Regenerate the certificate request (CSR) appropriate for the live environment, register it with the Authority, obtain the correct production certificate, then bind it to the production environment alone. Keep a clear separation between the compliance certificate and the production certificate in your settings, and never mix them. This separation alone prevents half the rejection cases tied to this cause.

The reason this error is so common is precisely that the simulation environment is designed to closely resemble production, so the team is deceived by a successful test and thinks the integration is ready. But the moment the certificate changes on the move to production is the moment the fault appears. So make it your rule that any configuration succeeding in simulation is not considered proven until it passes through the real production certificate in the live environment. Document in your settings the identifier of each certificate and its assigned environment explicitly, so that no mix-up occurs on any later update or handover between team members.

Cause two: certificate expiry

The Cryptographic Stamp Identifier certificate is not permanent. It has an expiry date, and once it is passed the certificate becomes invalid for signing. The system may keep producing a signature with the private key of the expired certificate, but the Fatoora platform refuses to verify it because the accompanying certificate is no longer valid. The result is error code 1006, often with a message indicating that the certificate is expired or unknown.

The danger in this cause is that it arrives suddenly. The integration runs smoothly for months, then all invoices stop being cleared on a single day without any change in the code. The reason is that the certificate reached its expiry date silently. Many teams do not monitor certificate expiry dates, so they are caught off guard by the stoppage at the worst possible time.

How to detect it: Check the expiry date of the certificate used in signing. If the rejection covers all invoices at once and without any change in the system, the expired certificate is the strongest candidate. Record the expiry date of every certificate you have in a clear place and monitor it.

How to fix it: Renew the certificate with the Authority well before its expiry, bind the new certificate to the system, and make sure signing uses it and not the old certificate. It is best to set an alert weeks before the expiry date so you renew without interruption of service. Proactive renewal is far cheaper than handling a sudden stoppage in invoicing.

Cause three: using a private key that does not match the certificate

A digital signature relies on a pair of keys: a private key that signs, and a public key that verifies. The certificate issued by the Authority carries the public key associated with a specific private key generated when the certificate request was created. For verification to succeed, the private key used in signing must be the correct pair of the public key in the certificate.

The error occurs when the system signs with a private key that does not belong to the certificate sent. This happens when a new key pair is regenerated without updating the accompanying certificate, or when keys from different certificate requests are mixed, or when a backup is restored that contains an old key alongside a new certificate. The Fatoora platform decrypts the signature with the public key in the certificate, and it does not match what the wrong private key signed. The result is error code 1006.

How to detect it: Make sure the private key used in signing is the one generated with the certificate request that produced the current certificate. If you have recently regenerated the keys or restored a backup, this cause is likely. The match between the private key and the public key in the certificate is what you must verify.

How to fix it: Bind the certificate to the correct private key generated with it. If you have lost the original private key, there is no way to use the existing certificate, and you must generate a new certificate request with a new key pair and obtain a new certificate from the Authority. Keep the private key and its certificate together as a single unit, never separating them — this prevents the problem from recurring.

Cause four: signing the wrong canonical form of the invoice

This is the most technically subtle cause, and the one most likely to appear in manual integrations. The signature is not computed over the XML file as is, but over its canonical form. Canonicalization is the process of converting XML into a fixed, unified format, so that the same content always produces the same cryptographic hash regardless of differences in whitespace, attribute order, or encoding.

The Authority mandates a precisely specified canonicalization method, and any deviation from it makes the issuer compute the hash over one form while the Fatoora platform computes it over another. The signature is arithmetically correct for the form the issuer signed, but it does not match the hash the platform computes over the correct canonical form. The result is error code 1006 despite a sound certificate and keys.

How to detect it: If you have confirmed that the certificate is correct and valid and that the keys match, yet the rejection persists, the problem is most likely in canonicalization. This cause appears specifically when an in-house team builds the XML generation and signing themselves without following the canonicalization specification to the letter. See the technical specification for the cryptographic stamp for the details of the required canonical form.

How to fix it: Apply the canonicalization method mandated by the Authority precisely before computing the hash and signing. Make sure the elements excluded from the signature (such as the signature elements themselves and the QR code) are handled correctly. Test your output against the Authority’s reference samples until the hash you compute matches what the platform expects. This fix requires precision, which is why certified platforms avoid it by taking over the entire canonicalization layer.

The trick with this cause is that it does not always appear. Signing over a wrong canonical form may pass in some invoices and be rejected in others, depending on a minor difference in each invoice’s content that exposes or hides the deviation in canonicalization. This fluctuation makes diagnosis harder, because the team thinks the problem is random when it is in fact deterministic in the calculation method. Whenever you notice that some invoices are cleared and others are rejected with code 1006 despite matching certificate and keys, head straight to canonicalization as the prime suspect.

How to isolate the right cause quickly

If you face code 1006 and do not know which of the four causes is responsible, follow one order that shortens your path. Start with the environment: are you in production with a production certificate, or did you mix it up with compliance? Then move to validity: is the certificate valid or has it expired? Then to matching: is the private key the pair of the public key in the certificate? And finally to canonicalization: are you computing the signature over the correct canonical form?

This order is not arbitrary. It is arranged from the most common and easiest to check to the most technically subtle. Three of the four causes relate to the certificate and can be checked in minutes without diving into the code. Canonicalization, however, requires deeper inspection, so leave it to last after ruling out what precedes it. Sticking to this order turns a vague rejection message into a specific diagnosis in a very short time.

How to prevent error code 1006 from the start

Diagnosis after a rejection is useful, but prevention is cheaper. Most cases of 1006 can be avoided with four simple habits. First, clearly separate the compliance environment from the production environment and the certificate of each, and never mix the certificates between them under any circumstances. Second, monitor certificate expiry dates and set a renewal alert well before expiry.

Third, keep every private key paired with its certificate as a single unit, and document any key regeneration immediately by updating the accompanying certificate. Fourth, if you are building the integration manually, test the signing and canonicalization output against the Authority’s reference samples before moving to production, not after. These four habits cut the roots of the four causes before they turn into rejected invoices.

The deeper lesson is that half the causes of error code 1006 go back to certificate management — its validity and its environment — not to the arithmetic of signing. Many teams focus their effort on the signing algorithm while the real problem is in the certificate. So always start your diagnosis from the certificate: is it for the correct environment? Is it valid? Is its private key the right one? Then move on to canonicalization if necessary.

How Qoyod helps you avoid error code 1006

When you use a certified accounting platform such as Qoyod, all these fine decisions move off your team’s shoulders and onto a system tested with thousands of establishments. Qoyod manages the Cryptographic Stamp Identifier (CSID) automatically and is compliant with the second phase of e-invoicing, so it signs and stamps every invoice and includes its Universally Unique Identifier (UUID) and QR code without any intervention from you.

This means you do not choose a certificate between compliance and production, you do not monitor expiry dates yourself, you do not bind private keys to certificates, and you do not apply the canonicalization method manually. All four causes of error code 1006 are managed in the layer the system handles. You just write the invoice, and Qoyod takes care of the entire stamping layer, so your invoice passes to clearance on the first attempt.

The practical difference is large. Direct manual integration with the Fatoora platform may consume weeks of diagnosis and rejection handling, while a certified system works from day one. And if you need confirmation that Qoyod handles the instant clearance of business (B2B) invoices and reporting within twenty-four hours for consumer (B2C) invoices, that is an integral part of its compliance with the second phase.

Frequently asked questions about error code 1006

What does error code 1006 mean in the electronic invoice?

It means the invoice’s cryptographic stamp is invalid — that is, the attached digital signature did not match the cryptographic hash the Fatoora platform computes for the invoice content. The result is that the invoice is rejected and not cleared until the cause is fixed.

Does error code 1006 mean my invoice data is wrong?

No. The category accompanying the error is CRYPTOGRAPHIC_STAMP, meaning the problem is in the stamping layer, not in the invoice fields. Neither the quantities nor the prices nor the tax registration number are the cause. Direct your diagnosis to the certificate, the keys, and the signing method.

What is the most common cause of error code 1006?

Confusing the compliance certificate with the production certificate — that is, signing production invoices with the simulation environment’s certificate or vice versa. This appears specifically after moving from the test environment to the live environment, so start your diagnosis from the environment and the certificate.

Why did all my invoices suddenly stop being cleared with code 1006?

The most likely cause is the expiry of the Cryptographic Stamp Identifier (CSID) certificate. The certificate works for months then expires silently, so all invoices are rejected at once without any change in the system. Check the certificate’s expiry date and renew it with the Authority.

Can I avoid error code 1006 without technical expertise?

Yes. When you use a certified accounting platform such as Qoyod, the entire stamping layer is managed automatically. You do not choose a certificate, monitor its validity, or apply canonicalization manually, so you will most often not see this error at all.

What is the difference between error code 1006 and other signature errors?

Code 1006 means specifically that the signature value does not match the invoice hash, and it has four root causes relating to the certificate, the keys, and canonicalization. For a broader picture of the rest of the signature errors, see the guide on electronic invoice signature errors.

Conclusion

Error code 1006 seems vague because it says “the stamp is invalid” without explaining why, but it is in fact confined to four known cases: a wrong CSID certificate between compliance and production, or an expired certificate, or a private key that does not match the certificate, or signing on a wrong canonical form. Three of these causes concern the certificate, so always start your diagnosis from it before diving into the calculation.

Once you understand the verification mechanism and memorize the four causes, diagnosing any 1006 rejection becomes a matter of minutes. And if you want to avoid this layer entirely, a compliant accounting platform that handles the stamp on your behalf is the shortest path to invoices cleared on the first attempt. For more on signature errors, see electronic invoice signature errors, and for the full picture of e-invoicing, start from the Qoyod electronic invoice.