ZATCA Phase 2 Waves: Deadlines, Thresholds and What Your ERP Must Do
ZATCA Phase 2 waves through Wave 25 (SAR 187,500, due February 1, 2027), the rules that set your date, and what Fatoora demands of your ERP.
Luka Abramovic21 min read
ZATCA has announced Wave 25 of Phase 2, the e-invoicing integration phase: every taxpayer whose revenue subject to VAT exceeded SAR 187,500 in 2022, 2023, 2024 or 2025 must integrate its e-invoicing solution with the Fatoora platform by February 1, 2027. That halves Wave 24's SAR 375,000 threshold, and it is the first wave to count 2025 revenue (ZATCA). In every ZATCA Phase 2 wave, two parts of the rule matter more than the threshold: one year over it is enough, and a higher threshold means an earlier wave. A business above SAR 375,000 in any year from 2022 to 2024 had a deadline of June 30, 2026 or earlier. One that first passed SAR 375,000 in 2025 is in Wave 25, because Wave 24 counted only 2022 to 2024.
Below are the waves we could confirm on zatca.gov.sa or in two independent sources, the rules that set your date, what Phase 2 requires of your invoicing system, and what that means for an ERP, POS or billing integration. Checked in September 2026. This is a practical summary, not legal or tax advice, and the e-invoicing pages of the Zakat, Tax and Customs Authority (ZATCA) are the authority. It covers Saudi Arabia only: the UAE's e-invoicing program is separate, with its own model and dates, and other Gulf states set their own rules.
The Phase 2 waves and their dates
Phase 2, the integration phase, started on January 1, 2023 and is rolled out in waves by revenue (ZATCA's Detailed Guidelines for E-Invoicing, version 2). ZATCA gave early waves a start date and recent ones a deadline, and the table keeps that distinction. A dash marks a detail we could not confirm on zatca.gov.sa or in two independent sources, and range rows cover the waves we could not confirm one by one.
| Wave | Revenue subject to VAT above | In any of these years | Start date or deadline | Source |
|---|---|---|---|---|
| 1 | SAR 3 billion | 2021 | From January 1, 2023 | Two secondary sources agree; Phase 2 start date in ZATCA's guidelines |
| 2 | SAR 500 million | — | From July 1, 2023 | Two secondary sources agree |
| 3 | SAR 250 million | 2021 or 2022 | From October 1, 2023 | ZATCA |
| 4 | SAR 150 million | 2021 or 2022 | From November 1, 2023 | ZATCA |
| 5 | SAR 100 million | 2021 or 2022 | From December 1, 2023 | ZATCA |
| 6 to 11 | Between Wave 5's SAR 100 million and Wave 12's SAR 10 million | — | Between Wave 5's and Wave 12's dates | Not listed row by row: the secondary sources we found disagree on these dates |
| 12 | SAR 10 million | 2022 or 2023 | From December 1, 2024 | ZATCA |
| 13 | SAR 7 million | 2022 or 2023 | From January 1, 2025 | ZATCA |
| 14 to 20 | Between Wave 13's SAR 7 million and Wave 21's SAR 1.25 million. Wave 15 was SAR 4 million and Wave 20 SAR 1.5 million | 2022 or 2023 (confirmed for Waves 15 and 20) | Between Wave 13's and Wave 21's dates | ZATCA for Wave 15 and Wave 20. Other rows not listed, for the same reason |
| 21 | SAR 1.25 million | 2022, 2023 or 2024 | No later than November 30, 2025 | ZATCA |
| 22 | SAR 1 million | 2022, 2023 or 2024 | No later than December 31, 2025 | ZATCA |
| 23 | SAR 750,000 | 2022, 2023 or 2024 | No later than March 31, 2026 | Two secondary sources agree |
| 24 | SAR 375,000 | 2022, 2023 or 2024 | No later than June 30, 2026 | ZATCA |
| 25 | SAR 187,500 | 2022, 2023, 2024 or 2025 | No later than February 1, 2027 | ZATCA |
Four rules that decide your date
- One year is enough. "Exceeded SAR 375,000 during 2022, 2023 or 2024" is met by any single year. A business whose revenue peaked in 2022 is placed by 2022, whatever it earned since.
- Read from the top. Thresholds fall wave by wave, so your wave is the first row whose threshold you crossed in one of the years that row lists. A business over SAR 1 million in 2023 belonged to Wave 22 or an earlier one, not Wave 24. Ask whoever prepares your VAT returns for the revenue subject to VAT in each year from 2021 to 2025, then read down the table, checking each row only against its own years. Your highest year alone can mislead: 2025 revenue counts only for Wave 25.
- The notice starts your clock. ZATCA must notify each group at least six months before its date, and sends the notice to the official email and SMS contacts registered with it. Its guidelines say a taxpayer isn't required to implement Phase 2 until notified, and may integrate voluntarily before then. Check which mailbox and phone number your ZATCA account holds today. If they belong to someone who has left, fix that first.
- Waves 24 and 25 sit on the VAT registration thresholds. SAR 375,000 is Saudi Arabia's mandatory VAT registration threshold and SAR 187,500 the voluntary one, so Wave 25 also reaches voluntarily registered businesses whose revenue passed SAR 187,500.
What the integration phase requires of your system
Two flows carry everything. A standard tax invoice, usually B2B, must be cleared by ZATCA before the buyer receives it, and only the cleared invoice is valid. A simplified tax invoice, usually B2C, is issued at the point of sale and reported to ZATCA within 24 hours. Credit and debit notes follow the invoice they belong to (Detailed Guidelines, section 6.4). The rule IDs below come from the validation rules file in ZATCA's SDK, release 238-R3.4.8, and ZATCA's API reports failures under the same IDs.
| Requirement | Standard tax invoice and its notes | Simplified tax invoice and its notes |
|---|---|---|
| Flow | Clearance through the API before you share it | Reporting within 24 hours of issue. A later submission draws warning BR-KSA-98, not a rejection |
| Format | UBL 2.1 XML. The buyer receives the cleared XML, or a PDF/A-3 with that XML embedded | UBL 2.1 XML that you store. The customer gets a printed or electronic copy |
| Type code | 388 invoice, 381 credit note, 383 debit note, 386 prepayment, with subtype 01 (name="0100000") | The same codes with subtype 02 (name="0200000") |
| Cryptographic stamp | Applied by ZATCA during clearance | Applied by your unit to every document, with its own key |
| QR code | Generated by ZATCA at clearance. You print the string it returns | Generated by your unit: tags 1 to 5 (seller name, VAT number, timestamp, total with VAT, VAT total), 6 invoice hash, 7 signature, 8 public key, and 9, ZATCA's stamp on your public key |
| Identity and chain | A UUID, the invoice counter value (ICV) and the previous invoice hash (PIH) in every document (BR-KSA-03, BR-KSA-33, BR-KSA-61) | |
| Buyer | Name, plus a 15-digit VAT number starting and ending in 3 (BR-KSA-44, an error) or another ID under a listed scheme such as CRN or NAT (BR-KSA-14, BR-KSA-81). A full national address for Saudi buyers (BR-KSA-63) | Not required in general |
| Credit and debit notes | A reason (BR-KSA-17, an error) and the original invoice's reference (BR-KSA-56). ZATCA's guidelines say a credit note without a reference breaches Article 54 of the VAT Implementing Regulations | |
| Language and currency | The human-readable invoice must be in Arabic, with other languages allowed alongside. The VAT total must also be given in SAR (BR-KSA-68, BR-KSA-EN16931-02) | |
The counter and the hash chain
Each unit numbers every document it issues with the ICV, a counter that can't be reset, and embeds the previous document's hash as the PIH, so a deleted or replaced invoice breaks the chain (ZATCA's implementation resolution). Both sit in AdditionalDocumentReference blocks. Note that the counter goes in an element named UUID, which is not the invoice's own UUID. From ZATCA's sample standard invoice:
<cac:AdditionalDocumentReference>
<cbc:ID>ICV</cbc:ID>
<cbc:UUID>23</cbc:UUID>
</cac:AdditionalDocumentReference>
<cac:AdditionalDocumentReference>
<cbc:ID>PIH</cbc:ID>
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzIzOWRkNGU5MWI0NjcyOWQ3M2EyN2ZiNTdlOQ==</cbc:EmbeddedDocumentBinaryObject>
</cac:Attachment>
</cac:AdditionalDocumentReference>Rule BR-KSA-26 defines the hash: remove the UBLExtensions block, the QR code reference and the cac:Signature block, canonicalize with C14N 1.1, take the SHA-256 digest and base64-encode the binary result. That gives a 44-character string. The first document has no predecessor, so it carries the fixed value shown above. ZATCA describes it as the base64 SHA-256 of "0", but it is the base64 encoding of the 64-character hex text of that hash, which is 88 characters long. Compute it the way the rule describes, from the binary digest, and you get X+zrZv/IbzjZUnhsbWlsecLbwjndTpG0ZynXOif7V+k=, which isn't ZATCA's value. Copy the constant rather than computing it.
The name attribute on the type code is the transaction code. In SDK release 238-R3.4.8 it has nine positions: the subtype (01 or 02), then flags for third party, nominal, export, summary, self-billed, continuous supply and B2G. Seven-character codes still pass. Setting the B2G flag makes a contract ID mandatory on tax invoices (BR-KSA-92, an error).
Errors, warnings, and why warnings aren't free
A failed error rule rejects the document. A failed warning rule lets it through as accepted with warnings. Some flags surprise people:
- Rejected: a buyer VAT number that isn't 15 digits starting and ending in 3 (BR-KSA-44), a buyer VAT number equal to the seller's (BR-CUSTOM-VALIDATION-01), a note without a reason (BR-KSA-17), an issue date later than today (BR-KSA-04), and a standard-rated line at a rate other than 15% or 5% (BR-KSA-84).
- Accepted with a warning: an incomplete buyer national address or a postal code that isn't five digits (BR-KSA-63, BR-KSA-67), a seller building number that isn't four digits (BR-KSA-37), a note without its billing reference (BR-KSA-56), and a simplified invoice reported after 24 hours (BR-KSA-98).
ZATCA's guidelines say warnings are accepted temporarily, might become rejections in the future, and that continuous warnings will be investigated. Our rule is to treat every warning as a defect with a deadline.
Onboarding each EGS unit, from OTP to production CSID
An EGS (e-invoice generation solution) unit is the part of your software that keeps a hash chain and stamps simplified invoices. Every device issuing invoices under your VAT number must be registered, and a unit may run only one chain at a time (ZATCA's guidelines and implementation resolution). Onboarding happens one unit at a time:
- Decide what the unit will issue. The invoice type in the certificate signing request (CSR) is four digits mapped to "TSCZ": standard, simplified and two positions reserved for future use. 1100 means both, 1000 standard only, 0100 simplified only. The value is written into the certificate (ZATCA's sample certificates carry
title=1100), so changing it later means a new certificate. - Generate a key pair and a CSR on the unit, with the fields in the table below. ZATCA's SDK does both:
fatoora -csr -csrConfig unit.properties -privateKey unit.key -generatedCsr unit.csr -pem. - Request an OTP. Log in to the Fatoora portal with your ERAD taxpayer credentials and request a one-time password for each unit.
- Get a compliance CSID. Call
POST /compliancewith the OTP in a header and the CSR in the body. The answer is a compliance cryptographic stamp identifier: abinarySecurityTokenand asecret. - Pass the compliance checks. Send
POST /compliance/invoicesone sample of each document type the unit will issue. For 1100 that is six: standard invoice, credit note and debit note, and simplified invoice, credit note and debit note. - Get the production CSID. Call
POST /production/csidswith the compliance request ID. ZATCA's developer manual says this call returns an invalid response until the compliance checks are complete. The production token and secret become the unit's username and password (HTTP Basic) for clearance and reporting.
| Property | What goes in | ZATCA's example |
|---|---|---|
csr.common.name | A unique name or asset tracking number for the unit | TST-886431145-399999999900003 |
csr.serial.number | 1-solution provider|2-model or version|3-serial number | 1-TST|2-TST|3-ed22f1d8-e6a2-1118-9b58-d9a8f11e445f |
csr.organization.identifier | Your VAT number, 15 digits starting and ending in 3. For a VAT group, the group number, whose 11th digit is 1 | 399999999900003 |
csr.organization.unit.name | The branch name. For a VAT group, the member's 10-digit TIN | Riyadh Branch |
csr.organization.name | The taxpayer's name | Maximum Speed Tech Supply LTD |
csr.country.name | SA | SA |
csr.invoice.type | TSCZ, as in step 1 | 1100 |
csr.location.address | Where the unit sits, preferably the short national address | RRRD2929 |
csr.industry.business.category | Industry or sector | Supply activities |
ZATCA's developer manual says it doesn't validate this identification data further, and the taxpayer is fully responsible for its accuracy. Its security standard lists inaccurate certificate data as a reason to revoke, along with a compromised key and a unit that is damaged, decommissioned or transferred.
Certificates expire, and renewal rotates the key
The illustrative certificate profile in ZATCA's Electronic Invoice Security Features Implementation Standards (version 1.1) sets validity at up to 60 months, and the test certificates in ZATCA's SDK samples run five years. Read your own expiry date rather than assuming it. The token in a CSID response is base64 of the base64 certificate, so decode it twice:
echo "$BINARY_SECURITY_TOKEN" | base64 -d | base64 -d > unit07.der
openssl x509 -inform DER -in unit07.der -noout -subject -enddate -ext subjectAltNameThe subjectAltName line shows what ZATCA recorded for the unit: serial, VAT number, invoice type and address. Renewal is its own call, PATCH /production/csids, with a new OTP from the portal and a new CSR. The implementation resolution requires a new stamping key at every renewal, ZATCA's certificate authority revokes the existing certificate when it issues the new one, and the portal sends a reminder before expiry. So a renewal is a key rotation with a hard cut-over, not a background refresh. Check how your software handles it: Odoo's Saudi module (versions 17 to 19), for example, lets a journal renew only after its certificate has expired, and refuses to submit invoices from an expired journal, so renewal day needs someone with portal access on hand.
ZATCA's responses and outages, and what to do with each
This table combines ZATCA's guidelines (section 10) with its API documentation. The last column is our default.
| Response | Meaning | Action | What we store |
|---|---|---|---|
| 200 | Cleared or reported | For a standard invoice, share the XML ZATCA returns, not your pre-clearance copy. It carries ZATCA's stamp and QR code | The returned XML, the response and the time |
| 202 | Accepted with warnings | As for 200, then fix the cause before the next invoice | Warning codes, counted by rule each week |
| 303 (clearance) | ZATCA has switched clearance off | Submit the same invoice to the reporting endpoint | The 303 and the reporting result |
| 400 | Rejected | Fix the data and issue a new invoice with its own counter and hash. The rejected one keeps its place in the chain | The rejected XML and the errors |
| 401 | Certificate or secret not accepted | Check the credentials, then resend | The attempt |
| 409 (reporting) | Already reported successfully | Treat it as success | As for 200 |
| 413 | Too large. ZATCA gives the limit as around 10 MB | Reduce the payload and resend | The attempt |
| 429, 500, 503, 504, or no response | Not received, or unknown | Resend the same signed XML | Every attempt, with its time |
What keeps this safe is resending the same signed XML, never a regenerated one: regenerating assigns a new counter, UUID and hash, which makes a second invoice for the same sale. ZATCA's guidelines say to keep resending the same invoice when there is no answer. Their FAQ adds that the same document must not be submitted twice, though a repeat isn't rejected at submission, and the reporting API answers a repeat with 409. Odoo's Saudi module (versions 17 to 19) goes further and blocks the next invoice in a journal until the previous one's outcome is known. Why a timeout doesn't mean a failure is covered in our guide to connecting business systems.
When ZATCA or your system is down
- Simplified invoices, either side down. Keep selling and queue. The resolution requires the solution to stay operational offline and report once connected. You have 24 hours from issue, so retry at intervals and keep evidence of each attempt. If you can't report within 24 hours, notify ZATCA through the form on its website, and again when the connection is back.
- Standard invoices, ZATCA down. In ZATCA's own example, the seller retries clearance for about five minutes, then shares the uncleared invoice, keeps records, confirms the buyer's contact details, retries about every 15 minutes and sends the cleared invoice once it goes through. ZATCA marks both timings "TBC". You don't need to notify ZATCA of its own outage. The uncleared invoice is treated as a VAT invoice until the cleared one is issued.
- Standard invoices, your side down. A tax invoice may be issued up to 15 days after the end of the month of supply (Article 53(1) of the VAT Implementing Regulations), which is your buffer. If you still can't clear in time, notify ZATCA through its form. ZATCA says uncleared invoices aren't eligible for VAT deduction, so your buyer's finance team will chase the cleared one.
- Device broken. Notify ZATCA immediately, invoice manually, then generate and submit the e-invoice with the original transaction date once the device is fixed. Manual invoices aren't eligible for VAT deduction, and ZATCA says frequent or long failures will be investigated.
What this means for your ERP, POS and billing integrations
ZATCA writes its rules per unit and per chain, while most businesses invoice from several systems at once. In this table the rule column is ZATCA's and the design column is our default.
| Situation | The rule that applies | Design that holds up |
|---|---|---|
| Branches, tills or several sales journals | Every device issuing invoices under your VAT number is registered, and each unit runs one chain | One unit per issuing point, each with its own key, certificate, counter and last hash. Odoo onboards each sales journal as a unit, with a serial of the form 1-Odoo|2-version|3- followed by the journal's identifier |
| Several servers or batch jobs posting at once | A unit must not run more than one sequence at a time, and each document embeds the previous one's hash | One signer per unit: a queue or lock that signs one document at a time. Add units for throughput, not threads |
| An ERP for B2B and a web shop or POS for B2C, one VAT number | The same rules, across systems | Separate units per system. Never share a key or counter between systems, and keep your own invoice numbers separate from the ICV |
| Tills that go offline | Queue offline and report within 24 hours. No clock changes, and no issue date later than today (BR-KSA-04) | Store and forward on the device, with an alert when the oldest unreported invoice is 12 hours old (our threshold, to leave time to act). Keep clocks synced: a till whose clock runs ahead can date an invoice tomorrow, and that is rejected |
| Rejections | A rejected document keeps its counter and hash, and the corrected one is a new invoice. Invoices can't be canceled, only credited and reissued | Advance the chain on every signed document, whatever ZATCA answers. Link each rejected attempt to its replacement for audit |
| Transfers and recharges between branches | The same VAT number on both sides is rejected (BR-CUSTOM-VALIDATION-01) | Keep documents within one VAT registration out of the e-invoicing flow |
| Several commercial registrations | The seller ID should be the registration of the branch issuing the invoice (BR-KSA-08) | Store the CR number per branch and choose it at signing time |
| Keys in a hosted ERP | The stamping key must be non-exportable, with disk encryption if it's held in software. An export option is a prohibited function | Keep each unit's key in a software or hardware key vault that signs without releasing it, which is what ZATCA's guidelines expect of vendors, not in a field an administrator can copy |
| Archive | Files named with VAT number, timestamp and invoice reference number. Cloud-hosted data must be reachable by ZATCA through a direct link, and exportable to external archival | Archive the XML ZATCA returned after clearance under that name, and export it to storage you control |
Several rows come down to master data. If your customer records need profiling before any of this, start with the master-data queries in our ERP integration guide.
Questions for your ERP or POS vendor
| Ask | An answer that should worry you |
|---|---|
| How many EGS units will we register, and what is each one: a till, a journal, a branch or a server? | "One for the whole company," when you invoice from more than one system or site |
| How do you sign when two users post invoices at the same moment? | No answer about locking or queuing |
| After a timeout, do you resend the same XML or build a new one? | "We regenerate it" |
| What do you do with a 303 or a 409? | They are logged as errors for someone to look at |
| Where does each unit's private key live, and can anyone export it? | "An admin can download it from the settings screen" |
| How long can a till work offline, and what warns us before 24 hours pass? | Nothing warns until ZATCA does |
| When a certificate expires, what stops, and who renews it? | "It renews automatically," with no mention of a portal OTP |
Penalties, and what to do if your date has passed
E-invoicing fines come from the VAT Law, applied according to ZATCA's violation classifications (implementation resolution, clause Eighth). ZATCA's published e-invoicing violations start at SAR 5,000 for not issuing e-invoices and SAR 10,000 for deleting or amending an issued one. Some start with a warning, including a missing QR code on a simplified invoice, a missing buyer VAT number on a tax invoice, and not telling ZATCA about a malfunction that stops you issuing e-invoices. Fines depend on the type of violation and on repetition (ZATCA, as of September 2026).
If your wave's date has passed and some of your invoicing isn't integrated:
- Find ZATCA's notice in the email and SMS contacts registered with your account, and confirm your wave and date against the table above.
- In the Fatoora portal, open View List of Solutions and Devices, which lists every solution and device you have integrated. Compare it with the unit register at the end of this guide. Every till or system that issues invoices and isn't on the list still needs onboarding.
- Onboard the missing units, starting with the systems that issue the most invoices.
- Record the date each unit went live, and ask your tax adviser how ZATCA will treat the invoices issued before it.
Checks to run this week
1. Find the customer records ZATCA will reject
Someone comfortable with SQL can run this against a copy of the customer table (PostgreSQL syntax; adjust the names to your schema). It reports the first problem per customer and whether ZATCA would reject the invoice or accept it with a warning.
SELECT * FROM (
SELECT c.customer_id, c.name,
CASE
WHEN c.vat_number IS NOT NULL AND c.vat_number !~ '^3[0-9]{13}3$'
THEN 'rejected: BR-KSA-44, VAT number must be 15 digits, first and last 3'
WHEN c.vat_number = '399999999900003' -- replace with your own VAT or VAT group number
THEN 'rejected: BR-CUSTOM-VALIDATION-01, same VAT number as the seller'
WHEN c.vat_number IS NULL AND c.other_id IS NOT NULL
AND (coalesce(c.other_id_scheme, '') NOT IN ('TIN','CRN','MOM','MLS','700','SAG','NAT','GCC','IQA','PAS','OTH')
OR c.other_id !~ '^[A-Za-z0-9]+$')
THEN 'rejected: BR-KSA-14, other ID needs a listed scheme and only letters and digits'
WHEN c.vat_number IS NULL AND c.other_id IS NULL
THEN 'warning: BR-KSA-81, no VAT number and no other buyer ID'
WHEN coalesce(trim(c.name), '') = ''
THEN 'warning: BR-KSA-42, buyer name missing'
WHEN c.country_code = 'SA' AND '' IN (coalesce(trim(c.street), ''),
coalesce(trim(c.building_number), ''), coalesce(trim(c.postal_code), ''),
coalesce(trim(c.city), ''), coalesce(trim(c.district), ''))
THEN 'warning: BR-KSA-63, national address incomplete'
WHEN c.country_code = 'SA' AND c.postal_code !~ '^[0-9]{5}$'
THEN 'warning: BR-KSA-67, postal code must be 5 digits'
END AS first_problem
FROM customers c
WHERE c.receives_tax_invoices
) t
WHERE first_problem IS NOT NULL
ORDER BY first_problem;Run the same checks on your own branch records: street, a four-digit building number, a five-digit postal code, city and district (BR-KSA-09, BR-KSA-37, BR-KSA-66), and the commercial registration number each branch will send.
2. Prove each unit's chain is intact
If your system stores what it signed, including rejected documents, this finds counter gaps, repeats and broken links per unit. Where a unit was onboarded again, ask your vendor what happened to its counter and chain (Odoo's Saudi module, for example, restarts a journal's counter at 1) and start a new unit_id from that point. Its first row may then be flagged, which is expected.
WITH d AS (
SELECT unit_id, icv, invoice_hash, pih,
LAG(icv) OVER w AS prev_icv,
LAG(invoice_hash) OVER w AS prev_hash
FROM zatca_documents
WINDOW w AS (PARTITION BY unit_id ORDER BY icv)
)
SELECT * FROM (
SELECT unit_id, icv,
CASE
WHEN prev_icv IS NULL
AND pih <> 'NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzIzOWRkNGU5MWI0NjcyOWQ3M2EyN2ZiNTdlOQ=='
THEN 'first document without ZATCA''s starting value'
WHEN prev_icv IS NOT NULL AND icv <> prev_icv + 1 THEN 'counter gap or repeat'
WHEN prev_icv IS NOT NULL AND pih <> prev_hash THEN 'chain break'
END AS problem
FROM d
) t
WHERE problem IS NOT NULL;3. Validate one real invoice before the API sees it
ZATCA's SDK runs the XSD, EN 16931 and KSA rule sets locally. Export one real standard invoice and one simplified invoice from your system and run:
fatoora -validate -invoice INV-10442.xml
fatoora -generateHash -invoice INV-10442.xmlThe SDK's readme asks for a Java version between 11 and 15, so check the one on the machine first. The hash it prints should match the one your system wrote into the QR code and will send as invoiceHash.
4. Start the unit register
| Unit | System and location | Invoice type | Certificate expiry | Chain state stored in | Private key held in | Owner |
|---|---|---|---|---|---|---|
| POS-RUH-07 | Till 7, Riyadh branch | 0100 | From openssl, above | The till's local database | Ask the POS vendor | Store operations lead |
One row per unit. Fill the expiry column from each certificate, not from memory.
If you're mapping EGS units across an ERP, a web shop and tills, or the chain check turns up gaps, send us the unit register and the response to one rejected invoice. We'd start with which system signs each document and where its key lives. Our systems integration work begins there.