What Mutabiq reports
One entry for each way this rule can be reported.
- Reported as
- What kind of value was found — empty, not_15_digits and the like — never the value itself.
Seller address has no street name
Reported asstreet_name_missingno street name
What is wrong
The seller's postal address carries no cbc:StreetName element. BR-KSA-09 asks for six fields on the seller's postal address, cac:AccountingSupplierParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), city (BT-37, cbc:CityName), postal code (BT-38, cbc:PostalZone), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). This is reported as a risk and not as a rejection. Under the SDK release the pack read before 2.0.0 (3.0.8), this was the one assertion ZATCA flagged as a warning rather than as an error; SDK 3.4.8, which the pack reads now, flags most of its assertions as warnings, and BR-KSA-09 stays among them: the platform records the shortfall and does not refuse the document for it, so this note does not turn the report to FAIL on its own. SDK 3.0.8 also asked for the additional number (KSA-23, cbc:PlotIdentification); SDK 3.4.8 does not (KSA:1216). The Data Dictionary marks the address subfields mandatory, and that does not change the flag the checker carries. The check is presence only - an empty element satisfies it - and it stops at the first field missing in ZATCA's own order (street name, building number, city, postal code, neighbourhood, country code), so more than one of the six may be absent and only the first is named here. It applies to standard and simplified invoices alike.
What to check in your ERP
The street name normally comes from the first address line of your own company or branch record - this is your address, not the customer's, so the fix is in the company master and not in the customer master. The usual cause is a system that keeps the address as one free-text block: the mapping has nothing to put in cbc:StreetName specifically, so it writes the block into whichever single element it was pointed at and leaves the rest empty. Check every branch or business unit that issues invoices, not only the head office: a branch created after the e-invoicing module was configured is often left with its address in a notes field that no mapping reads.
Seller address has no building number
Reported asbuilding_number_missingno building number
What is wrong
The seller's postal address carries no cbc:BuildingNumber element. BR-KSA-09 asks for six fields on the seller's postal address, cac:AccountingSupplierParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), city (BT-37, cbc:CityName), postal code (BT-38, cbc:PostalZone), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). This is reported as a risk and not as a rejection. Under the SDK release the pack read before 2.0.0 (3.0.8), this was the one assertion ZATCA flagged as a warning rather than as an error; SDK 3.4.8, which the pack reads now, flags most of its assertions as warnings, and BR-KSA-09 stays among them: the platform records the shortfall and does not refuse the document for it, so this note does not turn the report to FAIL on its own. SDK 3.0.8 also asked for the additional number (KSA-23, cbc:PlotIdentification); SDK 3.4.8 does not (KSA:1216). The Data Dictionary marks the address subfields mandatory, and that does not change the flag the checker carries. The check is presence only - an empty element satisfies it - and it stops at the first field missing in ZATCA's own order (street name, building number, city, postal code, neighbourhood, country code), so more than one of the six may be absent and only the first is named here. It applies to standard and simplified invoices alike.
What to check in your ERP
The building number is a four-digit field of the Saudi National Address, and systems built outside the region have no column for it. The usual cause is that the number is typed inside the street line, so a reader sees it in the printed address while cbc:BuildingNumber stays absent in the XML. Add a dedicated field to the company or branch record and map it to that element rather than parsing it back out of the street text, which fails the moment an address is written in a different order.
Seller address has no additional number
Reported asplot_identification_missingno additional number
What is wrong
The seller's postal address carries no cbc:PlotIdentification element, the field ZATCA's message calls the additional number (KSA-23). Only rule packs before 2.0.0 report this: SDK 3.0.8's BR-KSA-09 asked for the additional number among seven seller address fields, and SDK 3.4.8, which rule pack 2.0.0 reads, no longer does (KSA:1216), so a report produced under 2.0.0 never carries this note. It was a warning then too, and never turned a report to FAIL on its own.
What to check in your ERP
The additional number is the four-digit part of the Saudi National Address that follows the building number, and it is the address field most often missing, for two reasons: EN 16931 has no business term for it, so a template derived from a European invoice layout has no slot for it at all, and the UBL element name, cbc:PlotIdentification, does not read like the thing it holds, so it is easy to skip when the mapping is written from element names. Take the value from the company's National Address record and map it explicitly.
Seller address has no city
Reported ascity_name_missingno city
What is wrong
The seller's postal address carries no cbc:CityName element. BR-KSA-09 asks for six fields on the seller's postal address, cac:AccountingSupplierParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), city (BT-37, cbc:CityName), postal code (BT-38, cbc:PostalZone), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). This is reported as a risk and not as a rejection. Under the SDK release the pack read before 2.0.0 (3.0.8), this was the one assertion ZATCA flagged as a warning rather than as an error; SDK 3.4.8, which the pack reads now, flags most of its assertions as warnings, and BR-KSA-09 stays among them: the platform records the shortfall and does not refuse the document for it, so this note does not turn the report to FAIL on its own. SDK 3.0.8 also asked for the additional number (KSA-23, cbc:PlotIdentification); SDK 3.4.8 does not (KSA:1216). The Data Dictionary marks the address subfields mandatory, and that does not change the flag the checker carries. The check is presence only - an empty element satisfies it - and it stops at the first field missing in ZATCA's own order (street name, building number, city, postal code, neighbourhood, country code), so more than one of the six may be absent and only the first is named here. It applies to standard and simplified invoices alike.
What to check in your ERP
Almost every address record holds a city, so a missing one in the output usually means the mapping is reading the wrong record rather than that the data is absent: a shipping address, a correspondence address or a legacy address table instead of the registered company address. Confirm which address the export reads for the seller party, and confirm it is the same one for every document type - some exports read the branch address for invoices and a default company address for credit notes.
Seller address has no postal code
Reported aspostal_zone_missingno postal code
What is wrong
The seller's postal address carries no cbc:PostalZone element. BR-KSA-09 asks for six fields on the seller's postal address, cac:AccountingSupplierParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), city (BT-37, cbc:CityName), postal code (BT-38, cbc:PostalZone), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). This is reported as a risk and not as a rejection. Under the SDK release the pack read before 2.0.0 (3.0.8), this was the one assertion ZATCA flagged as a warning rather than as an error; SDK 3.4.8, which the pack reads now, flags most of its assertions as warnings, and BR-KSA-09 stays among them: the platform records the shortfall and does not refuse the document for it, so this note does not turn the report to FAIL on its own. SDK 3.0.8 also asked for the additional number (KSA-23, cbc:PlotIdentification); SDK 3.4.8 does not (KSA:1216). The Data Dictionary marks the address subfields mandatory, and that does not change the flag the checker carries. The check is presence only - an empty element satisfies it - and it stops at the first field missing in ZATCA's own order (street name, building number, city, postal code, neighbourhood, country code), so more than one of the six may be absent and only the first is named here. It applies to standard and simplified invoices alike.
What to check in your ERP
The Saudi postal code is five digits and is regularly confused with the additional number or with a PO box number, which belong in different fields. The usual cause is that the field is optional in your system and was left blank when the company record was created, or that it is stored joined to the city in a single line. Fill it on the company or branch record and map it to cbc:PostalZone on its own.
Seller address has no neighbourhood
Reported ascity_subdivision_missingno neighbourhood
What is wrong
The seller's postal address carries no cbc:CitySubdivisionName element, which ZATCA's message calls the Neighborhood (KSA-3). BR-KSA-09 asks for six fields on the seller's postal address, cac:AccountingSupplierParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), city (BT-37, cbc:CityName), postal code (BT-38, cbc:PostalZone), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). This is reported as a risk and not as a rejection. Under the SDK release the pack read before 2.0.0 (3.0.8), this was the one assertion ZATCA flagged as a warning rather than as an error; SDK 3.4.8, which the pack reads now, flags most of its assertions as warnings, and BR-KSA-09 stays among them: the platform records the shortfall and does not refuse the document for it, so this note does not turn the report to FAIL on its own. SDK 3.0.8 also asked for the additional number (KSA-23, cbc:PlotIdentification); SDK 3.4.8 does not (KSA:1216). The Data Dictionary marks the address subfields mandatory, and that does not change the flag the checker carries. The check is presence only - an empty element satisfies it - and it stops at the first field missing in ZATCA's own order (street name, building number, city, postal code, neighbourhood, country code), so more than one of the six may be absent and only the first is named here. It applies to standard and simplified invoices alike.
What to check in your ERP
The neighbourhood, or district, is part of the Saudi National Address and has no counterpart in the address formats most systems ship with, so it is either not captured at all or folded into the street line. Check the company or branch record for a district field; if there is none, adding a custom field and mapping it to cbc:CitySubdivisionName is the correct fix, and splitting it back out of the street text is not.
Seller address has no country code
Reported ascountry_code_missingno country code
What is wrong
The seller's postal address carries no cac:Country/cbc:IdentificationCode. BR-KSA-09 asks for six fields on the seller's postal address, cac:AccountingSupplierParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), city (BT-37, cbc:CityName), postal code (BT-38, cbc:PostalZone), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). This is reported as a risk and not as a rejection. Under the SDK release the pack read before 2.0.0 (3.0.8), this was the one assertion ZATCA flagged as a warning rather than as an error; SDK 3.4.8, which the pack reads now, flags most of its assertions as warnings, and BR-KSA-09 stays among them: the platform records the shortfall and does not refuse the document for it, so this note does not turn the report to FAIL on its own. SDK 3.0.8 also asked for the additional number (KSA-23, cbc:PlotIdentification); SDK 3.4.8 does not (KSA:1216). The Data Dictionary marks the address subfields mandatory, and that does not change the flag the checker carries. The check is presence only - an empty element satisfies it - and it stops at the first field missing in ZATCA's own order (street name, building number, city, postal code, neighbourhood, country code), so more than one of the six may be absent and only the first is named here. It applies to standard and simplified invoices alike.
What to check in your ERP
This one is not a direct child of the address the way the other six are: it sits inside a cac:Country block, and that alone is the common cause - a mapping that writes the flat address fields and never emits the nested element. The value is the two-letter ISO 3166-1 code, SA for the Kingdom, and not the country's name, so check that the export writes the code and not the label held in a country description field.
© 2026 Hayatiq AI Solutions F.Z.E. All rights reserved.