Preface

The master data is one of the key data sets of eInvoicing. As a taxpayer all the required master data needs to be maintained in the appropriate place as per the format required by the tax authority, ZATCA.

Well, there is a big list of master data information required of which some are optional, some are mandatory and other few are conditional. Please refer to the XML implementation standard document for the detailed list of required master data and their validation business rules.

With the introduction of eInvoicing integration with the Tax authority we all know how important it is to maintain clean master data in our ERP’s. This blog is to provide the technical mapping and its specific details to be noted regarding the master data maintenance objects for KSA eInvoicing.

Context

In a broad context, there are two main master data elements in customer centric eInvoicing regulatory requirement in KSA.

Supplier master data

This generally is the company code master data for all the business scenarios in customer invoicing scenarios. Only In the case of self-billing, this company code master is represented as customer data in the XML as company code is the buyer doing the self-generating the invoices on behalf of the vendor.

The other master data element of self-billing is the vendor master. In the XML, the accounting supplier party is mapped to the vendor master created in BP.

Customer master data

This is the buyers master data created in the BP transaction in S4HANA and XD01 transaction in ECC.

Master data mapping in general

Please refer to the below master data mapping table that clarifies at which place i.e., the relevant master data field the information needs to be maintained.

Table 1: General Master data mapping

Master data specific for onboarding

Apart from the various other master data required for onboarding, which is explained in the onboarding blog, there are two specific master data objects that are required only for onboarding.

1. TIN number of the supplier 

This is the tax identification of the individual entity which is belonging to a group company having group VAT registration number.

This needs to be maintained in the company code additional parameter called SATAXN.

This is mapped to the Org unit field of the Cryptographic stamp request.

1. Industry of the supplier 

This is the main Industry in which the supplier’s business is in. This is mapped to the company code additional parameter SAINDU.

This is mapped to the industry field of the Cryptographic stamp request.

Scheme Id specific master data

In addition to the Tax scheme Id which is always VAT number, ZATCA identifies the supplier and the customer in the XML with the help of the XML tag schemeID as shown below in the sample XML snippet.

schemeID (BT-46-1) denotes the various identification types of a taxpayer. This XML tag under the AccountingSupplierParty XML group, denotes the supplier’s identification type and the same under the XML group AccountingCustomerParty denotes the customers identification type.

ZATCA has defined multiple scheme ID’s that can be referred to in the XML as listed below.

Table 2: List of schemeID

The buyer identification (BT-46) and the seller identification (BT-29) in the XML must exist only once with one of the above listed scheme ID (BT-46-1) and must contain only alphanumeric characters.

In case multiple IDs exist for a taxpayer or a consumer then one of the above must be reported in the XML following the sequence specified above.

Scheme Id specific master data mapping

Please refer to the below master data mapping table that clarifies at which place the relevant scheme ID needs to be maintained.

Table 3: schemeID Mapping matrix

Scheme Id at transaction level for simplified (B2C) eDocuments

Not all customers are consumers. In case of B2C customers who are referred to as consumers for whom generally no unique customer master is created but transaction is completed with a generic onetime customer, the schemeID can still be maintained at the individual billing document and accounting document level.

For SD billing documents it should be maintained at the header level in the new text field SAID and for FI invoices this should be maintained at the Reference Key 3 (XREF3) field at the header level of the accounting document.

Data format

Irrespective of the place where the schemeID other than CRN is being maintained, the data needs to be maintained in the below format.

Where schemeID should consists of one of the scheme ID’s listed in table 2 and IDNUM is the number of the identification document.

For example: IQA:6534565243524

Note

• In business partner for customer and Vendor you may enter multiple documents with the identification type SABYID with different or same validity dates but only one currently valid document according to the priority in the sequence listed in table 2 is reported in XML.
• In additional parameters SASEID and CREGNO at company code level you can maintain only one currently valid Identification document.

Important SAP Notes:

3242982 – BP ID type “SABYID” for KSA e-invoice regulation

3257432 – Saudi Arabia: Configure and Maintain Other Buyer ID for Outgoing Invoices

3212218 – Company code additional parameters for KSA E-invoicing – SAP ONE Support Launchpad

Other eInvoicing blogs

Solution onboarding guide

Some useful links

Note: For accessing the last three links listed above you need to login to MENA Localization SIG – Overview (sapjam.com)

Thank you for reading this blog. I hope the information is useful to you. Please share your feedback in the comments section below.

I encourage you to follow my profile for similar content.