BR-O-02Out-of-scope invoice carries the seller's VAT registration number
This rule was retired in rule pack 2.0.0: ZATCA's SDK 3.4.8 no longer includes the assertion it mirrored, so Mutabiq no longer reports it. Reports produced by earlier rule packs may still name it; the explanations below are kept for them.
What kind of value was found — empty, not_15_digits and the like — never the value itself.
Out-of-scope invoice carries the seller's VAT registration number
Reported asseller_vat_registration_presentthe seller's VAT registration number is present
What is wrong
At least one invoice line's cac:Item/cac:ClassifiedTaxCategory is coded O - out of scope - under the VAT tax scheme, and the seller's cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme carries a cbc:CompanyID under a VAT tax scheme. EN 16931 rule BR-O-02, which ZATCA runs, forbids a VAT registration number on any invoice that has an out-of-scope line. The trigger is document-wide: one such line is enough, whatever the VAT breakdowns say, and the rule reads three registrations - the seller's, the tax representative's and the buyer's - although its own published message names only two of them. Now the part that decides what you do next, and it has to be said plainly: this document cannot be repaired by moving the number somewhere else. Measured on an invoice that is otherwise a conforming out-of-scope document, leaving the seller's registration where it is returns BR-O-02; removing the cac:PartyTaxScheme block returns BR-KSA-39, which requires the seller to carry either a VAT registration or a cac:PartyIdentification/cbc:ID whose schemeID is HQ; and adding that HQ identification returns BR-KSA-08, which confines every seller identification scheme to CRN MOM MLS SAG OTH and does not list HQ. Three routes, a refusal on each. There is no invoice with an out-of-scope line that passes both the EN 16931 layer and the KSA layer, and none can be built today.
What to check in your ERP
Do not spend a day reconfiguring the out-of-scope category: no setting in your system clears this note while the category stays. The seller's VAT registration number is not the thing to remove either - it comes from your company or branch record, every other invoice you issue needs it, and taking it out trades this note for BR-KSA-39. The one question worth the time is whether the supply is genuinely outside VAT. That category is chosen far more often than it applies, and the alternatives do have working configurations: an export is zero-rated, a financial service under Article 29 is exempt, and both of those pass. Start at the tax code behind the line in your VAT code table and at the letter it maps to; a code created by copying another one and never re-mapped is the usual cause.
Out-of-scope invoice carries the tax representative's VAT registration number
Reported astax_representative_vat_registration_presentthe tax representative's VAT registration number is present
What is wrong
At least one invoice line is coded O - out of scope - under the VAT tax scheme, neither the seller's block nor the buyer's carries a VAT registration number, and the cac:TaxRepresentativeParty block carries a cbc:CompanyID under a VAT tax scheme. EN 16931 rule BR-O-02, which ZATCA runs, forbids it. This is the reading the rule's own published message does not give you: the message names the seller VAT registration number (BT-31) and the buyer's (BT-48), while the expression that actually runs reads a third path as well, the tax representative's. Note that path has no cac:Party step in it - cac:TaxRepresentativeParty is itself a party block, where the supplier and the customer are wrappers around one - so a system that writes the representative as a nested party is outside this reading. What is true of the other two classes of this rule is true here: removing the block leaves BR-KSA-39 asking for the seller's registration, and the documented way round BR-KSA-39 is refused by BR-KSA-08, whose seller scheme list is CRN MOM MLS SAG OTH. There is no invoice with an out-of-scope line that passes both the EN 16931 layer and the KSA layer, and none can be built today.
What to check in your ERP
Very few systems write a tax representative at all, so the block is usually there for one of two reasons: an export template that emits it unconditionally from a partly filled record, or a fiscal representative captured for another country's e-invoicing profile and then carried into the Saudi one. Check whether the record behind cac:TaxRepresentativeParty is your own company repeated, which is what a default mapping often produces. Removing the block is right if the data is wrong, but it will not make the document pass, so do not treat it as the fix - the category on the line is where the decision is.
Out-of-scope invoice carries the buyer's VAT registration number
Reported asbuyer_vat_registration_presentthe buyer's VAT registration number is present
What is wrong
At least one invoice line is coded O - out of scope - under the VAT tax scheme, and the buyer's cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme carries a cbc:CompanyID under a VAT tax scheme. EN 16931 rule BR-O-02, which ZATCA runs, forbids the buyer VAT registration number (BT-48) on such an invoice as firmly as the seller's. Because the rule is read in the order seller, tax representative, buyer, this note also tells you something the finding does not say outright: neither the seller nor the tax representative carries a registration number under a VAT tax scheme on this document. That is a defect in its own right, since BR-KSA-39 requires the seller to have one, so expect a second note about the seller beside this one. The outcome is the same as for the other two classes: removing the seller's registration to satisfy this rule trips BR-KSA-39, and the HQ-schemed identification BR-KSA-39 accepts instead is refused by BR-KSA-08, whose scheme list is CRN MOM MLS SAG OTH. There is no invoice with an out-of-scope line that passes both the EN 16931 layer and the KSA layer, and none can be built today.
What to check in your ERP
The buyer's VAT registration number comes from the customer master record and is correct data in almost every other context, so this is not a defect in that record. The question to answer is the category on the line: an out-of-scope supply to a VAT-registered buyer is the combination the rule refuses, and the letter O is chosen far more often than it applies. Look at the tax code on the line in your VAT code table and at the letter it maps to, and check the seller's own registration at the same time, because this note is evidence that it is missing or is not sitting under a tax scheme whose cbc:ID is VAT.