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.
Saudi buyer's address has no street name
Reported asstreet_name_missingno street name
What is wrong
The buyer's postal address carries no cbc:StreetName element. The buyer's country code is SA and the document is a standard tax invoice or its credit or debit note (invoice transaction code KSA-2 beginning 01), so BR-KSA-63 requires six fields on cac:AccountingCustomerParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), postal code (BT-38, cbc:PostalZone), city (BT-37, cbc:CityName), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). SDK 3.4.8 flags the document under BR-KSA-63 as a warning, not a rejection, when one of them is absent or blank: the finding is reported without failing the document by itself. Earlier SDK releases also asked for a seventh field, the additional number (KSA-19, cbc:PlotIdentification), and tested presence only, so an empty element satisfied it; SDK 3.4.8 drops the additional number and tests presence AND content together, so an empty element no longer satisfies it. The check stops at the first field missing or blank in the guard's own order, which is the order listed above, so more than one of the six may be absent and only the first is named here. It reaches this document only because the buyer's cac:Country/cbc:IdentificationCode is exactly SA; the comparison is made on the value as written, so a code padded with spaces does not enter this rule at all, and a non-Saudi buyer's address is judged by BR-KSA-62 instead. A simplified invoice's buyer address is not judged here either.
What to check in your ERP
The buyer address comes from the customer master, so the gap is per customer and not per document: expect it on a subset of your invoices, typically the customers created before the address fields were split, or imported in bulk from a legacy system into a single free-text address block. Check which of the customer's addresses the export reads - a billing address, a delivery address and a legal address are three different records in most systems, and only one of them is the right source here.
Saudi buyer's address has no building number
Reported asbuilding_number_missingno building number
What is wrong
The buyer's postal address carries no cbc:BuildingNumber element. The buyer's country code is SA and the document is a standard tax invoice or its credit or debit note (invoice transaction code KSA-2 beginning 01), so BR-KSA-63 requires six fields on cac:AccountingCustomerParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), postal code (BT-38, cbc:PostalZone), city (BT-37, cbc:CityName), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). SDK 3.4.8 flags the document under BR-KSA-63 as a warning, not a rejection, when one of them is absent or blank: the finding is reported without failing the document by itself. Earlier SDK releases also asked for a seventh field, the additional number (KSA-19, cbc:PlotIdentification), and tested presence only, so an empty element satisfied it; SDK 3.4.8 drops the additional number and tests presence AND content together, so an empty element no longer satisfies it. The check stops at the first field missing or blank in the guard's own order, which is the order listed above, so more than one of the six may be absent and only the first is named here. It reaches this document only because the buyer's cac:Country/cbc:IdentificationCode is exactly SA; the comparison is made on the value as written, so a code padded with spaces does not enter this rule at all, and a non-Saudi buyer's address is judged by BR-KSA-62 instead. A simplified invoice's buyer address is not judged here either.
What to check in your ERP
The building number is a four-digit field of the Saudi National Address. On the buyer side the usual cause is that it was never asked for at onboarding: the customer typed a single-line address into a portal or an order form, and the system has nowhere to hold the number separately. Collecting the customer's National Address is the fix; parsing the number back out of a free-text line is not, because it will be right for some customers and silently wrong for others.
Saudi buyer's address has no postal code
Reported aspostal_zone_missingno postal code
What is wrong
The buyer's postal address carries no cbc:PostalZone element. The buyer's country code is SA and the document is a standard tax invoice or its credit or debit note (invoice transaction code KSA-2 beginning 01), so BR-KSA-63 requires six fields on cac:AccountingCustomerParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), postal code (BT-38, cbc:PostalZone), city (BT-37, cbc:CityName), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). SDK 3.4.8 flags the document under BR-KSA-63 as a warning, not a rejection, when one of them is absent or blank: the finding is reported without failing the document by itself. Earlier SDK releases also asked for a seventh field, the additional number (KSA-19, cbc:PlotIdentification), and tested presence only, so an empty element satisfied it; SDK 3.4.8 drops the additional number and tests presence AND content together, so an empty element no longer satisfies it. The check stops at the first field missing or blank in the guard's own order, which is the order listed above, so more than one of the six may be absent and only the first is named here. It reaches this document only because the buyer's cac:Country/cbc:IdentificationCode is exactly SA; the comparison is made on the value as written, so a code padded with spaces does not enter this rule at all, and a non-Saudi buyer's address is judged by BR-KSA-62 instead. A simplified invoice's buyer address is not judged here either.
What to check in your ERP
The postal code is five digits and belongs in its own field. Common causes on the buyer side are a customer record created with the field left blank because it is optional in your system, a PO box number recorded instead, and a mapping that writes the code only when the customer's country is filled in. Check the customer master for the Saudi customers you invoice most and confirm the field is populated and mapped.
Saudi buyer's address has no city
Reported ascity_name_missingno city
What is wrong
The buyer's postal address carries no cbc:CityName element. The buyer's country code is SA and the document is a standard tax invoice or its credit or debit note (invoice transaction code KSA-2 beginning 01), so BR-KSA-63 requires six fields on cac:AccountingCustomerParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), postal code (BT-38, cbc:PostalZone), city (BT-37, cbc:CityName), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). SDK 3.4.8 flags the document under BR-KSA-63 as a warning, not a rejection, when one of them is absent or blank: the finding is reported without failing the document by itself. Earlier SDK releases also asked for a seventh field, the additional number (KSA-19, cbc:PlotIdentification), and tested presence only, so an empty element satisfied it; SDK 3.4.8 drops the additional number and tests presence AND content together, so an empty element no longer satisfies it. The check stops at the first field missing or blank in the guard's own order, which is the order listed above, so more than one of the six may be absent and only the first is named here. It reaches this document only because the buyer's cac:Country/cbc:IdentificationCode is exactly SA; the comparison is made on the value as written, so a code padded with spaces does not enter this rule at all, and a non-Saudi buyer's address is judged by BR-KSA-62 instead. A simplified invoice's buyer address is not judged here either.
What to check in your ERP
A customer record with no city at all is unusual, so this normally points at the mapping reading an address that is not the one you think: a one-off ship-to address entered on the order, or an address block that the export builds from a different table for some document types. Confirm the source the buyer party is built from, and confirm it is the same for invoices, credit notes and debit notes.
Saudi buyer's address has no neighbourhood
Reported ascity_subdivision_missingno neighbourhood
What is wrong
The buyer's postal address carries no cbc:CitySubdivisionName element, which ZATCA's message calls the Neighborhood (KSA-3). The buyer's country code is SA and the document is a standard tax invoice or its credit or debit note (invoice transaction code KSA-2 beginning 01), so BR-KSA-63 requires six fields on cac:AccountingCustomerParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), postal code (BT-38, cbc:PostalZone), city (BT-37, cbc:CityName), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). SDK 3.4.8 flags the document under BR-KSA-63 as a warning, not a rejection, when one of them is absent or blank: the finding is reported without failing the document by itself. Earlier SDK releases also asked for a seventh field, the additional number (KSA-19, cbc:PlotIdentification), and tested presence only, so an empty element satisfied it; SDK 3.4.8 drops the additional number and tests presence AND content together, so an empty element no longer satisfies it. The check stops at the first field missing or blank in the guard's own order, which is the order listed above, so more than one of the six may be absent and only the first is named here. It reaches this document only because the buyer's cac:Country/cbc:IdentificationCode is exactly SA; the comparison is made on the value as written, so a code padded with spaces does not enter this rule at all, and a non-Saudi buyer's address is judged by BR-KSA-62 instead. A simplified invoice's buyer address is not judged here either.
What to check in your ERP
The neighbourhood is part of the Saudi National Address and has no counterpart in the address layouts most systems ship with, so customer records rarely hold it unless it was asked for deliberately. Check whether your customer master has a district field for Saudi customers; if the data is genuinely not held, it has to be collected, because the export cannot derive it from the city or the postal code.
Saudi buyer's address has no country code element
Reported ascountry_code_missingno country code
What is wrong
The buyer's postal address carries no cac:Country/cbc:IdentificationCode. This case is worth reading twice: the rule reaches this document only because a buyer cac:Country/cbc:IdentificationCode equal to SA exists somewhere under the buyer party, while the six conjuncts are checked over the buyer's cac:PostalAddress elements, so a document can enter the rule through one address and fail this field on another. The buyer's country code is SA and the document is a standard tax invoice or its credit or debit note (invoice transaction code KSA-2 beginning 01), so BR-KSA-63 requires six fields on cac:AccountingCustomerParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), postal code (BT-38, cbc:PostalZone), city (BT-37, cbc:CityName), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). SDK 3.4.8 flags the document under BR-KSA-63 as a warning, not a rejection, when one of them is absent or blank: the finding is reported without failing the document by itself. Earlier SDK releases also asked for a seventh field, the additional number (KSA-19, cbc:PlotIdentification), and tested presence only, so an empty element satisfied it; SDK 3.4.8 drops the additional number and tests presence AND content together, so an empty element no longer satisfies it. The check stops at the first field missing or blank in the guard's own order, which is the order listed above, so more than one of the six may be absent and only the first is named here. It reaches this document only because the buyer's cac:Country/cbc:IdentificationCode is exactly SA; the comparison is made on the value as written, so a code padded with spaces does not enter this rule at all, and a non-Saudi buyer's address is judged by BR-KSA-62 instead. A simplified invoice's buyer address is not judged here either.
What to check in your ERP
The country code is not a direct child of the address: it sits inside a cac:Country block, and a mapping that writes the flat address fields without emitting that nested element is the usual cause. If your export can write more than one cac:PostalAddress for a party, check that the one carrying the country is the one carrying the rest of the address, and that the value is the two-letter ISO 3166-1 code SA rather than the country name.
Saudi buyer's address has no additional number
Reported asplot_identification_missingno additional number
What is wrong
The buyer's postal address carries no cbc:PlotIdentification element, the field ZATCA's message calls the additional number (KSA-19). Only rule packs before 2.0.0 report this: SDK 3.0.8's BR-KSA-63 asked for the additional number among seven fields on a Saudi buyer's address on a standard tax invoice, and SDK 3.4.8, which rule pack 2.0.0 reads, no longer does (KSA:1645), so a report produced under 2.0.0 never carries this note.
What to check in your ERP
This is the address field that customer records are least likely to hold: EN 16931 has no business term for it, so an address form built to an international template has no place to capture it, and the UBL element name does not read like the thing it holds. It is also the field that most often makes the difference on its own, because the six others are asked for by EN 16931's own buyer-address rule as well and would have been reported earlier. Add a National Address field to the customer master for Saudi customers and map it to cbc:PlotIdentification.
© 2026 Hayatiq AI Solutions F.Z.E. All rights reserved.