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.
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.
- 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.
- 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.
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
- 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:
Other eInvoicing blogs
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.