Key Mandatory Fields in e-Invoices Prescribed in KSA

In the new regulations rolled out for e-invoicing in the Kingdom of Saudi Arabia (KSA), the Zakat, Tax and Customs Authority (ZATCA) has issued guidelines to generate and issue electronic invoices. While many fields in the e-invoice require the transaction details to be filled, specific mandatory fields need an understanding to better comply with the rules and regulations.

e-Invoice mandatory fields prescribed by the ZATCA

Universally Unique Identifier (UUID) 

UUID is mandatory for e-invoices and simplified e-invoices, indicating an internationally unique number that identifies an invoice and tracks it throughout its lifecycle.

A UUID appears like this – 061c95lv-d6bb942-e-aa6-24cb09ec1d001

The taxpayer’s compliant solution automatically generates UUID that should be seen on an electronic invoice XML. However, it cannot be located on a printed invoice.

ZATCA guidelines suggest that if any systematic error occurs after generating an e-invoice that is not in a compliant format, the e-invoice generated again or associated note must have the same UUID.

Cryptographic Stamp

Cryptographic Stamp is submerged inside the QR code and is automatically generated from the complaint solutions. e-Invoicing Integration Portal generates Cryptographic Stamp that is a mandatory field of an e-invoice required by ZATCA. 

On the other hand, the simplified e-invoices must include a Cryptographic Stamp automatically generated through the taxpayer’s invoice solution. Hence, the taxpayer must make sure their solutions are compliant and registered as required by ZATCA. 

Cryptographic Stamp Identifier

Cryptographic Stamp Identifier (CSID) is linked to the Cryptographic Stamp that helps connect the stamp with the registered invoice solution. It is issued and managed by the e-Invoicing Integration Portal.

You can request and manage such identifiers from the portal using your login credentials if you are subject to the e-invoicing regulations. 

Previous Invoice Hash

ZATCA required the previous invoice hash to be present in the subsequent electronic invoice or note document. Hence, all the compliant vendors will have to ensure that their solutions can generate the previous invoice hash in the next invoice.

An invoice hash is like a digital invoice fingerprint generated automatically within the invoice solution. 

Previous Invoice Hash looks like this – NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzIzOWRkNGU5MWI0NjcyOWQ3M2EyN2ZiNTdlOQ==

QR Code

The QR code embeds basic details of the invoice and is automatically generated from the invoice solutions on the printed and the electronic invoice.

It typically includes the seller’s name, VAT registration number, date and time, invoice and VAT amount, and Cryptographic Stamp, among other specific details. These details are embedded in the QR Code in the safest manner that cannot be tampered with. It is key to verify the invoice to ensure whether the invoice is a ZATCA requirements complaint. 

Invoice Counter

It is a number that gets generated automatically from the invoice solutions. The number increases as new invoices are issued. The invoice counter can be the same for different invoice solutions owned by the same taxpayer. 

It is in a numeric form that may look like this – 23881.

The fields mentioned above are specific fields that relate to different phases – integration or generation. These key mandatory fields are particular requirements by ZATCA apart from the other compulsory general fields of the e-invoice KSA. 

Decimals in KSA e-Invoice

Decimals place an important role while creating an invoice as most of the time, the price for a good or service will not be rounded off to a riyal. The ZATCA e-invoice XML implementation standard specifies the maximum decimals allowed.

The below table states the maximum number of decimals allowed:

Also, all the decimals shall be rounded off using “half-up” rounding. Suppose the 3rd decimal is exactly 5 or higher, then round up to the 3rd decimal, else round down to the 2nd decimal.

Also, the taxpayer shall follow the below rules to reduce the risk of differences due to rounding:

1. All document level totals shall be rounded to two decimals for accounting.
2. Rounding shall be done on the final calculations but not based on any intermediate results.
3. VAT category tax amount shall be rounded on the document level but not as a summation of rounded invoice line VAT amounts.
4. The taxpayer shall consider only significant decimals in the VAT rate, i.e. any difference in trailing zeros should not result in different VAT breakdowns.

When is it mandatory to add these key fields?

Note: Phase 1 is called the generation phase, whereas phase 2 is called the integration phase.