Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-54 | Fatal (error) | cbc:EndpointID[@schemeID='0192'] | cac:PartyIdentification/cbc:ID[@schemeID='0192'] | cbc:CompanyID[@schemeID='0192'] |
| Schematron ID: ibr-069 | Field: Norwegian organisation number format across IBT-034, IBT-049, IBT-029, IBT-046, IBT-060, IBT-030, IBT-047, IBT-061 | ||
Classification
Contextual — the rule fires only where an identifier is declared under scheme 0192, the ISO 6523 code for the Norwegian organisation number register. A UAE invoice identifying both parties by TIN under 0235 never meets it; declare 0192 anywhere in the document and the value must survive a Norwegian registry format check.
What the Rule Is Checking
The assert applies two tests to any 0192-flagged value: it must be exactly nine digits, and it must pass the mod-11 check-digit algorithm that Norway's Brønnøysund register uses — the schematron implements the weighted sum and compares the result against the final digit. The check covers endpoints, party identifiers and legal registration identifiers for seller, buyer and payee alike. Eight digits, ten digits, an embedded space or a failed check digit is a fatal error.
Why This Rule Exists
PINT-AE inherits the shared PINT ruleset, and the shared ruleset polices every national identifier scheme it knows about, wherever the invoice originates. Declaring scheme 0192 is a claim that the value is an organisation number issued by the Norwegian registry, and the mod-11 check digit gives validation an arithmetic proof that the claim is at least plausible without querying the registry itself. For a UAE business the rule matters in one situation: a counterparty registered on the Peppol network under a Norwegian identifier. If that counterparty's number is mangled in your master data, the invoice fails before transmission rather than misrouting on the network.
Standard / Code List
Scheme 0192 sits in the same ISO 6523 ICD registry as the UAE's 0235, covered in Peppol EAS and ICD Participant Identifiers. The underlying identifier is the nine-digit organisasjonsnummer assigned by Brønnøysundregistrene.
UAE Data Example
PASSES ✓: <cbc:EndpointID schemeID="0192">974760673</cbc:EndpointID> — nine digits with a valid mod-11 check digit, identifying a Norwegian buyer receiving a UAE export invoice over the Peppol network.
FAILS ✗: A UAE supplier's mapping template carries the counterparty scheme from a previous customer record, so a Dubai buyer's fifteen-digit TRN goes out flagged 0192. The length test fails before the check digit is computed, and the invoice is rejected as fatal.
What Your ERP / IT Team Must Ensure
Store the identifier scheme against each counterparty in master data rather than defaulting it in the mapping layer — scheme defaults are how domestic TINs end up flagged as foreign registry numbers. Where a counterparty genuinely holds a Norwegian identifier, capture it at nine digits with no separators and validate the check digit at data entry. UAE-to-UAE invoicing under scheme 0235 never touches this rule, which makes any 0192 rejection in your logs a signal that a scheme attribute is being set somewhere it should not be.
Related Rules
BR-53 (ibr-068) applies the same registry-format policing to GS1 GLNs under scheme 0088, and BR-55 (ibr-070) covers Danish CVR numbers under 0184. The scheme attribute itself is mandated by BR-49 (ibr-062) and BR-50 (ibr-063).