# Sandbox Production CSID not tied to submitted CSR — blocks Simplified (Reporting) invoice testing

**URL:** <https://zatca1.discourse.group/t/sandbox-production-csid-not-tied-to-submitted-csr-blocks-simplified-reporting-invoice-testing/10520>\
**Category:** Clearance and Reporting\
**Created:** [July 8, 2026, 3:00pm UTC](https://zatca1.discourse.group/t/sandbox-production-csid-not-tied-to-submitted-csr-blocks-simplified-reporting-invoice-testing/10520 "2026-07-08T15:00:56Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Abrar](https://avatars.discourse-cdn.com/v4/letter/a/8e8cbc/32.png) [@Abrar](https://zatca1.discourse.group/u/Abrar)\
**Post date:** [July 8, 2026, 3:00pm UTC](https://zatca1.discourse.group/t/sandbox-production-csid-not-tied-to-submitted-csr-blocks-simplified-reporting-invoice-testing/10520/1 "2026-07-08T15:00:56Z")

</div>

Hi Support,

We’re testing the full onboarding + invoicing flow against Sandbox and have hit a blocker with **Production CSID issuance**.

**Can we Test Non VAT Customers Invoices on Sandbox. ?**

**Flow followed:**

1. `POST /compliance` with a fresh CSR (unique EGS Serial Number, unique VAT/branch identity) → returns `200 OK`, `ISSUED`, valid Compliance CSID.
2. `POST /compliance/invoices` with signed Standard + Simplified sample invoices → returns `200 OK`, compliance checks pass.
3. `POST /production/csids` with the resulting `compliance_request_id` → returns `200 OK`, `dispositionMessage: ISSUED`, a new `binarySecurityToken`/`secret`.

**Issue:** the certificate inside that returned `binarySecurityToken` does not correspond to our submitted CSR at all. Decoding it shows:

- A different EGS identity embedded in the SAN (`1-TST|2-TST|3-...`) than what we submitted.
- A different Location/Industry than what we submitted.
- The exact same certificate (same serial, same validity window `2024-01-11` to `2029-01-09`) returned across multiple different branches/CSRs/EGS serials we tested — it never changes regardless of input.

**Impact:** since this certificate doesn’t match our actual signing key, every real invoice submission using it fails at `/invoices/reporting/single` with:  
`publicKey_QRCODE_INVALID`, `invalid-certificate`, `certificate-hashing`, `certificate-signing-time-format`.

Notably, `/invoices/clearance/single` (Standard invoices) succeeds, because Standard invoices don’t include QR Tag 9 (Cryptographic Stamp). Simplified invoices always include Tag 9, so they’re the only ones that expose this mismatch.

**Question:** is `/production/csids` in the **Sandbox environment** expected to issue a certificate matching the submitted CSR, or does it always return a fixed/shared demo certificate for this environment? If the latter, how are we meant to test real Simplified/Reporting invoice submission end-to-end in Sandbox?

We’re testing using the documented dummy VAT number `399999999900003` from your Developer Portal Manual — happy to provide full request/response logs if useful.

Thank you.