The core EN 16931 rules — which fields an invoice has to carry
The BR family is the base layer of EN 16931: it does not check whether your numbers are right, but whether the fields that make a document an invoice under European law are present at all.
58 rules · 58 explained · Rule set v2026-08-31
Why nearly every BR failure has the same cause
These rules almost never fail alone. Map an existing PDF invoice template into XML and the fields that were never visible on paper have no source in the system either — and you get five or ten BR findings at once.
So the fastest route is not to work through them one at a time but to lay the mapping against the mandatory-field list once. The fields that surface are nearly always the same ones: BT-24 (specification identifier), BT-3 (invoice type), BT-5 (currency) and the seller’s tax details.
What these rules do not check
An invoice that passes every BR rule is formally complete and can still be substantively wrong: the wrong tax rate, the wrong description of the supply, the wrong recipient. The BMF letter of 15 October 2025 calls that its own class of error, and no technical check detects it.
The converse also holds: a BR breach matters for VAT only insofar as it touches a mandatory particular. A missing specification identifier makes the document technically unusable and says nothing about the input tax deduction.
All core rules
With the official rule text. Rules with a written explanation carry their cause and fix directly beneath.
- BR-01
An Invoice shall have a Specification identifier (BT-24).
- BR-02
An Invoice shall have an Invoice number (BT-1).
- BR-03
An Invoice shall have an Invoice issue date (BT-2).
- BR-04
An Invoice shall have an Invoice type code (BT-3).
- What the rule requires
- The invoice must carry an invoice type code (BT-3) — the code saying whether this is an invoice, a credit note or a partial invoice.
- Why it fires
- The document type is often a house abbreviation in the source system with no mapping to a standard code. Where the mapping is missing, nothing gets written in preference to something wrong.
- How to fix it
- Set BT-3 to a UNTDID 1001 code — 380 for a commercial invoice, 381 for a credit note, 384 for a correction: cbc:InvoiceTypeCode in UBL, ram:TypeCode in CII. On which codes are permitted, see BR-DE-17.
- BR-05
An Invoice shall have an Invoice currency code (BT-5).
- What the rule requires
- The invoice must name an invoice currency (BT-5). Every amount in the document is read in that currency.
- Why it fires
- A company that invoices only in euro keeps the currency in no field at all — it is printed into the layout. It is then entirely absent from the structured record.
- How to fix it
- Set BT-5 to the ISO 4217 code, EUR on the German market: cbc:DocumentCurrencyCode in UBL, ram:InvoiceCurrencyCode in CII. The amounts additionally carry their own currencyID attribute, which has to agree with it.
- BR-06
An Invoice shall contain the Seller name (BT-27).
- What the rule requires
- The invoice must contain the seller name (BT-27) — the full registered name the company trades under.
- Why it fires
- The sender lives in the letterhead rather than in the invoice data: it is the same on every invoice and so is maintained in the layout instead of the record. It falls out when the XML is produced.
- How to fix it
- Put the registered name in BT-27: cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName in UBL, ram:SellerTradeParty/ram:Name in CII. A differing trading name goes in BT-28 as well.
- BR-07
An Invoice shall contain the Buyer name (BT-44).
- BR-08
An Invoice shall contain the Seller postal address (BG-5).
- BR-09
The Seller postal address (BG-5) shall contain a Seller country code (BT-40).
- What the rule requires
- The seller postal address must contain a country code (BT-40) — the two-letter ISO 3166-1 code, not the country's name spelled out.
- Why it fires
- Addresses live in many systems as multi-line free text with the country on the last line. Splitting them into individual fields leaves exactly that line over, because it carries no code.
- How to fix it
- Translate the country into its ISO code once and set it in BT-40: cac:PostalAddress/cac:Country/cbc:IdentificationCode in UBL, ram:PostalTradeAddress/ram:CountryID in CII. DE, not Germany.
- BR-10
An Invoice shall contain the Buyer postal address (BG-8).
- What the rule requires
- The invoice must contain the buyer postal address (BG-8) — the counterpart to BG-5 on the recipient's side.
- Why it fires
- On public-sector invoices the address is treated as dispensable because the Leitweg-ID already routes the document. The norm wants it regardless: it identifies who received the service, not where the file goes.
- BR-11
The Buyer postal address shall contain a Buyer country code (BT-55).
- What the rule requires
- The buyer postal address must contain a country code (BT-55) — the same requirement as BR-09, on the recipient's side.
- Why it fires
- For purely domestic customers the country is frequently not maintained at all, because it goes without saying. What goes without saying sits in no field.
- How to fix it
- Set the ISO 3166-1 code in BT-55: cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode in UBL, ram:BuyerTradeParty/ram:PostalTradeAddress/ram:CountryID in CII. A mapping default is defensible here.
- BR-12
An Invoice shall have the Sum of Invoice line net amount (BT-106).
- What the rule requires
- The invoice must contain the sum of line net amounts (BT-106). The norm requires each of the totals explicitly — none of them may be left to be inferred from the others.
- Why it fires
- The value is rarely a field in your own invoice object: it follows from the lines and is computed for display. In the document it has to be written out.
- BR-13
An Invoice shall have the Invoice total amount without VAT (BT-109).
- What the rule requires
- The invoice must contain the total amount without VAT (BT-109). The norm requires each of the totals explicitly — none of them may be left to be inferred from the others.
- Why it fires
- Where there are no document-level allowances or charges, this looks identical to the line sum, and only one of the two gets written.
- BR-14
An Invoice shall have the Invoice total amount with VAT (BT-112).
- What the rule requires
- The invoice must contain the total amount with VAT (BT-112). The norm requires each of the totals explicitly — none of them may be left to be inferred from the others.
- Why it fires
- The gross total sits at the bottom of the PDF and is produced there by formatting rather than kept as a data field. It is missing when the mapping runs.
- BR-15
An Invoice shall have the Amount due for payment (BT-115).
- What the rule requires
- The invoice must contain the amount due for payment (BT-115). The norm requires each of the totals explicitly — none of them may be left to be inferred from the others.
- Why it fires
- On invoices without a prepayment the amount due equals the gross total, and an identical value looks redundant. The norm wants it in its own right regardless.
- BR-16
An Invoice shall have at least one Invoice line (BG-25).
- BR-17
The Payee name (BT-59) shall be provided in the Invoice, if the Payee (BG-10) is different from the Seller (BG-4).
- What the rule requires
- Where the payee (BG-10) differs from the seller, the payee name (BT-59) must be provided. Who receives the money may not be left open.
- Why it fires
- The group is created because a different bank account has to be sent — factoring, or a group subsidiary collecting centrally. The name is treated as incidental, since the IBAN steers the payment anyway.
- How to fix it
- Set BT-59 in cac:PayeeParty/cac:PartyName/cbc:Name in UBL, ram:PayeeTradeParty/ram:Name in CII — or omit the group entirely where seller and payee are the same party.
- BR-18
The Seller tax representative name (BT-62) shall be provided in the Invoice, if the Seller (BG-4) has a Seller tax representative party (BG-11).
- What the rule requires
- Where the seller has a tax representative (BG-11), the representative's name (BT-62) must be provided.
- Why it fires
- The group is usually created only to hold the representative's VAT identifier, that being the part with tax consequences. The name does not follow it in.
- BR-19
The Seller tax representative postal address (BG-12) shall be provided in the Invoice, if the Seller (BG-4) has a Seller tax representative party (BG-11).
- What the rule requires
- Where the seller has a tax representative, that representative's postal address (BG-12) must be provided — the same requirement as BR-08, for a third party.
- Why it fires
- In master data the representative is often only a name and a tax number; no full address is maintained, because nothing is ever sent to them.
- How to fix it
- Create cac:TaxRepresentativeParty/cac:PostalAddress in UBL, ram:SellerTaxRepresentativeTradeParty/ram:PostalTradeAddress in CII. The country code inside it is required by BR-20.
- BR-20
The Seller tax representative postal address (BG-12) shall contain a Tax representative country code (BT-69), if the Seller (BG-4) has a Seller tax representative party (BG-11).
- BR-21
Each Invoice line (BG-25) shall have an Invoice line identifier (BT-126).
- What the rule requires
- Every invoice line (BG-25) must carry a line identifier (BT-126). It is the anchor the recipient uses to discuss or dispute a single row.
- Why it fires
- Lines are built as a list whose order implicitly is the number. The index is not written out when serialising, because it was never a field on the source object.
- How to fix it
- Assign an identifier unique within the invoice in BT-126: cbc:ID inside cac:InvoiceLine in UBL, ram:AssociatedDocumentLineDocument/ram:LineID in CII. A counter from 1 is enough.
- BR-22
Each Invoice line (BG-25) shall have an Invoiced quantity (BT-129).
- What the rule requires
- Every invoice line must carry an invoiced quantity (BT-129) — including where the line is a flat fee.
- Why it fires
- For services and flat fees the source system holds no quantity, only an amount. The field stays empty because there seems to be nothing to say in it.
- How to fix it
- For a flat fee write a quantity of 1 and the amount as the unit price: cbc:InvoicedQuantity in UBL, ram:BilledQuantity in CII. Its unit of measure is required by BR-23.
- BR-23
An Invoice line (BG-25) shall have an Invoiced quantity unit of measure code (BT-130).
- What the rule requires
- The invoiced quantity must carry a unit of measure (BT-130) — a code from UN/ECE Recommendation 20, not your item master's own abbreviation.
- Why it fires
- Systems keep units as text: pcs, hrs, kg. The code is a translation that has to be built in the mapping first, and without it the attribute stays empty.
- How to fix it
- Set the unitCode attribute on cbc:InvoicedQuantity in UBL, ram:BilledQuantity in CII: C62 for pieces, HUR for hours, KGM for kilograms, MTR for metres.
- BR-24
Each Invoice line (BG-25) shall have an Invoice line net amount (BT-131).
- What the rule requires
- Every invoice line must carry a net amount (BT-131) — the amount of the row before VAT.
- Why it fires
- The amount is computed from quantity and price for display and so is not kept as a field of its own. The document needs it written out, and written so that it adds up.
- How to fix it
- Write the row amount into cbc:LineExtensionAmount in UBL, ram:LineTotalAmount in CII. How it must follow from quantity, price and discounts is checked by PEPPOL-EN16931-R120.
- BR-25
Each Invoice line (BG-25) shall contain the Item name (BT-153).
- BR-26
Each Invoice line (BG-25) shall contain the Item net price (BT-146).
- What the rule requires
- Every invoice line must carry an item net price (BT-146) — the price per unit after any price discount.
- Why it fires
- Flat fees, and lines that know only a total, carry no unit price. The row then has an amount and nothing it could have come from.
- How to fix it
- Write the unit price into cac:Price/cbc:PriceAmount in UBL, ram:NetPriceProductTradePrice/ram:ChargeAmount in CII. For a flat fee the unit price is the total, at a quantity of 1.
- BR-27
The Item net price (BT-146) shall NOT be negative.
- BR-28
The Item gross price (BT-148) shall NOT be negative.
- BR-29
If both Invoicing period start date (BT-73) and Invoicing period end date (BT-74) are given then the Invoicing period end date (BT-74) shall be later or equal to the Invoicing period start date (BT-73).
- What the rule requires
- Where both the start and the end of the invoicing period are given, the end must fall on or after the start.
- Why it fires
- The period is filled from two fields maintained separately. A typo in the year, or an end date left over from the previous month, reverses the order.
- How to fix it
- Check the order before writing cac:InvoicePeriod in UBL, ram:BillingSpecifiedPeriod in CII. A single-day period with identical start and end is permitted.
- BR-30
If both Invoice line period start date (BT-134) and Invoice line period end date (BT-135) are given then the Invoice line period end date (BT-135) shall be later or equal to the Invoice line period start date (BT-134).
- What the rule requires
- Where both the start and the end of a line period are given, the end must fall on or after the start — the same check as BR-29, per line.
- Why it fires
- Line periods are produced in a loop out of contract data. Where a contract runs across a year boundary, the year on one of the two dates is readily computed wrong.
- How to fix it
- Check the order per line before writing cac:InvoicePeriod inside cac:InvoiceLine. That the period must also fit inside the invoicing period is required by PEPPOL-EN16931-R110 and R111.
- BR-31
Each Document level allowance (BG-20) shall have a Document level allowance amount (BT-92).
- What the rule requires
- Every document-level allowance (BG-20) must carry an amount (BT-92). An allowance or charge without an amount changes nothing, and then does not belong in the document.
- Why it fires
- The discount is already folded into the line amounts and the group is created only as an explanation — with a reason, but no amount.
- How to fix it
- Write the amount into cbc:Amount inside cac:AllowanceCharge in UBL, ram:ActualAmount inside ram:SpecifiedTradeAllowanceCharge in CII. On how amount, base amount and percentage relate, see PEPPOL-EN16931-R040.
- BR-32
Each Document level allowance (BG-20) shall have a Document level allowance VAT category code (BT-95).
- What the rule requires
- Every document-level allowance (BG-20) must carry a VAT category code (BT-95). It decides which block of the VAT breakdown the amount flows into.
- Why it fires
- The allowance or charge is thought of as a bare amount rather than as something taxable. Only the breakdown needs the classification — and then fails to find it.
- How to fix it
- Set BT-95 in cac:AllowanceCharge/cac:TaxCategory/cbc:ID together with cbc:Percent and cac:TaxScheme in UBL, or ram:CategoryTradeTax in CII. It is the same category code as on the lines — S, E, Z, AE.
- BR-33
Each Document level allowance (BG-20) shall have a Document level allowance reason (BT-97) or a Document level allowance reason code (BT-98).
- What the rule requires
- Every document-level allowance (BG-20) must carry a reason — in plain text (BT-97), as a code (BT-98), or both. An amount with no justification is something the recipient cannot check.
- Why it fires
- This rule and BR-CO-21 are one check written twice in the norm. They always report together: a single missing reason produces two error codes, not two errors.
- BR-36
Each Document level charge (BG-21) shall have a Document level charge amount (BT-99).
- What the rule requires
- Every document-level charge (BG-21) must carry an amount (BT-99). An allowance or charge without an amount changes nothing, and then does not belong in the document.
- Why it fires
- Freight and packaging are carried as text in the invoice footer. The group is built from that text, and the amount stays inside it rather than in a field of its own.
- How to fix it
- Write the amount into cbc:Amount inside cac:AllowanceCharge in UBL, ram:ActualAmount inside ram:SpecifiedTradeAllowanceCharge in CII. On how amount, base amount and percentage relate, see PEPPOL-EN16931-R040.
- BR-37
Each Document level charge (BG-21) shall have a Document level charge VAT category code (BT-102).
- What the rule requires
- Every document-level charge (BG-21) must carry a VAT category code (BT-102). It decides which block of the VAT breakdown the amount flows into.
- Why it fires
- The allowance or charge is thought of as a bare amount rather than as something taxable. Only the breakdown needs the classification — and then fails to find it.
- How to fix it
- Set BT-102 in cac:AllowanceCharge/cac:TaxCategory/cbc:ID together with cbc:Percent and cac:TaxScheme in UBL, or ram:CategoryTradeTax in CII. It is the same category code as on the lines — S, E, Z, AE.
- BR-38
Each Document level charge (BG-21) shall have a Document level charge reason (BT-104) or a Document level charge reason code (BT-105).
- What the rule requires
- Every document-level charge (BG-21) must carry a reason — in plain text (BT-104), as a code (BT-105), or both. An amount with no justification is something the recipient cannot check.
- Why it fires
- This rule and BR-CO-22 are one check written twice in the norm. They always report together: a single missing reason produces two error codes, not two errors.
- BR-41
Each Invoice line allowance (BG-27) shall have an Invoice line allowance amount (BT-136).
- What the rule requires
- Every invoice line allowance (BG-27) must carry an amount (BT-136). An allowance or charge without an amount changes nothing, and then does not belong in the document.
- Why it fires
- Line discounts arrive from pricing as a percentage. The percentage is carried through and the amount that follows from it is never worked out.
- How to fix it
- Write the amount into cbc:Amount inside cac:AllowanceCharge in UBL, ram:ActualAmount inside ram:SpecifiedTradeAllowanceCharge in CII. On how amount, base amount and percentage relate, see PEPPOL-EN16931-R040.
- BR-42
Each Invoice line allowance (BG-27) shall have an Invoice line allowance reason (BT-139) or an Invoice line allowance reason code (BT-140).
- BR-43
Each Invoice line charge (BG-28) shall have an Invoice line charge amount (BT-141).
- BR-44
Each Invoice line charge (BG-28) shall have an Invoice line charge reason (BT-144) or an Invoice line charge reason code (BT-145).
- What the rule requires
- Every invoice line charge (BG-28) must carry a reason — in plain text (BT-144), as a code (BT-145), or both. An amount with no justification is something the recipient cannot check.
- Why it fires
- This rule and BR-CO-24 are one check written twice in the norm. They always report together: a single missing reason produces two error codes, not two errors.
- BR-45
Each VAT breakdown (BG-23) shall have a VAT category taxable amount (BT-116).
- What the rule requires
- Every VAT breakdown block (BG-23) must contain the category taxable amount (BT-116). The breakdown is where the tax becomes traceable.
- Why it fires
- The breakdown is built from the tax amounts, those being what is visible on the invoice. The taxable base behind them is an intermediate result and does not get written out.
- How to fix it
- Write BT-116 into cac:TaxTotal/cac:TaxSubtotal/cbc:TaxableAmount in UBL, or ram:BasisAmount inside ram:ApplicableTradeTax in CII. How base, rate and tax amount must agree is checked by BR-CO-17.
- BR-46
Each VAT breakdown (BG-23) shall have a VAT category tax amount (BT-117).
- What the rule requires
- Every VAT breakdown block (BG-23) must contain the category tax amount (BT-117). The breakdown is where the tax becomes traceable.
- Why it fires
- For exempt categories a tax amount of zero reads like an absence of information and gets left out. The norm requires the zero explicitly.
- How to fix it
- Write BT-117 into cac:TaxTotal/cac:TaxSubtotal/cbc:TaxAmount in UBL, or ram:CalculatedAmount inside ram:ApplicableTradeTax in CII. How base, rate and tax amount must agree is checked by BR-CO-17.
- BR-47
Each VAT breakdown (BG-23) shall be defined through a VAT category code (BT-118).
- BR-48
Each VAT breakdown (BG-23) shall have a VAT category rate (BT-119), except if the Invoice is not subject to VAT.
- What the rule requires
- Every VAT breakdown block must carry a VAT category rate (BT-119), unless the invoice is not subject to VAT at all.
- Why it fires
- For exempt categories the rate is omitted, because there is none. The norm wants an explicit zero there — the statement “zero per cent” differs from “no value”.
- How to fix it
- Set BT-119 in cac:TaxSubtotal/cac:TaxCategory/cbc:Percent in UBL, ram:RateApplicablePercent in CII, explicitly as 0 for E, Z and AE. On the German path BR-DE-14 applies as well.
- BR-49
A Payment instruction (BG-16) shall specify the Payment means type code (BT-81).
- What the rule requires
- A payment instruction (BG-16) must state the payment means code (BT-81) — how the invoice is meant to be paid.
- Why it fires
- The group is created to hold the IBAN, and the IBAN seems to explain the route already. For automatic processing the code is the decisive field, not the account number.
- How to fix it
- Set a UNTDID 4461 code in cbc:PaymentMeansCode in UBL, ram:TypeCode in CII: 58 for SEPA credit transfer, 59 for SEPA direct debit, 30 for a general transfer, 48 for card payment.
- BR-50
A Payment account identifier (BT-84) shall be present if Credit transfer (BG-16) information is provided in the Invoice.
- What the rule requires
- Where a credit transfer is given as the payment means, the payee account identifier (BT-84) must accompany it. An instruction to transfer needs somewhere to transfer to.
- Why it fires
- The bank details sit in the footer of the PDF and are not repeated in the structured record, being already visible there to a human reader.
- How to fix it
- Write the IBAN into cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID in UBL, ram:PayeePartyCreditorFinancialAccount/ram:IBANID in CII. On the IBAN being correct, see BR-DE-19.
- BR-51
In accordance with card payments security standards an invoice should never include a full card primary account number (BT-97). At the moment PCI Security Standards Council has defined that the first 6 digits and last 4 digits are the maximum number of digits to be shown.
- BR-52
Each Additional supporting document (BG-24) shall contain a Supporting document reference (BT-122).
- What the rule requires
- Every additional supporting document (BG-24) must carry a reference (BT-122) — the number under which the recipient can find the document.
- Why it fires
- The group is created to carry an attachment, and the attachment has a filename. No identifier is assigned to the document itself, the filename seeming description enough.
- How to fix it
- Set BT-122 in cac:AdditionalDocumentReference/cbc:ID in UBL, ram:AdditionalReferencedDocument/ram:IssuerAssignedID in CII. On filenames being distinct where there are several attachments, see BR-DE-22.
- BR-53
If the VAT accounting currency code (BT-6) is present, then the Invoice total VAT amount in accounting currency (BT-111) shall be provided.
- What the rule requires
- Where a separate VAT accounting currency (BT-6) is given, the tax total in that currency (BT-111) must be provided too. A currency on its own states no amount.
- Why it fires
- BT-6 is set from a company code or a template while the conversion of the tax amount is never triggered — it needs a rate the invoice object does not hold.
- How to fix it
- Write the converted tax amount into a second cac:TaxTotal without a cac:TaxSubtotal, with the accounting currency as currencyID — or drop BT-6. How many such blocks are allowed is governed by PEPPOL-EN16931-R054, and their sign by R055.
- BR-54
Each Item attribute (BG-32) shall contain an Item attribute name (BT-160) and an Item attribute value (BT-161).
- BR-55
Each Preceding Invoice reference (BG-3) shall contain a Preceding Invoice reference (BT-25).
- What the rule requires
- Every preceding invoice reference (BG-3) must contain the preceding invoice's number (BT-25). Without it the group refers to nothing in particular.
- Why it fires
- The group is created to carry the original invoice's date, or comes out of a correction template empty. The number sits in a different field from the one expected.
- How to fix it
- Set BT-25 in cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID in UBL, ram:InvoiceReferencedDocument/ram:IssuerAssignedID in CII. When the reference is required at all is covered by BR-DE-26.
- BR-56
Each Seller tax representative party (BG-11) shall have a Seller tax representative VAT identifier (BT-63).
- What the rule requires
- Every tax representative party (BG-11) must carry its VAT identifier (BT-63). Without it the representation cannot be traced for tax purposes.
- Why it fires
- The representative is treated as one more address and mapped like an address — name, city, country. That a tax identifier is mandatory here rather than merely useful gets lost.
- How to fix it
- Set BT-63 in cac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID with a cac:TaxScheme/cbc:ID of VAT in UBL, or the representative's ram:SpecifiedTaxRegistration/ram:ID in CII. The country prefix is required by BR-CO-09.
- BR-57
Each Deliver to address (BG-15) shall contain a Deliver to country code (BT-80).
- BR-61
If the Payment means type code (BT-81) means SEPA credit transfer, Local credit transfer or Non-SEPA international credit transfer, the Payment account identifier (BT-84) shall be present.
- BR-62
The Seller electronic address (BT-34) shall have a Scheme identifier.
- What the rule requires
- Where the seller electronic address (BT-34) is sent, it must carry a scheme identifier. The attribute says which register the identifier comes from — without it the value is only a string.
- Why it fires
- The address is mapped as a plain string, because in the source system it is one. The scheme attribute beside it has no counterpart there and stays empty.
- How to fix it
- Set the schemeID attribute on cac:AccountingSupplierParty/cac:Party/cbc:EndpointID in UBL, and the corresponding schemeID on the same element in CII. PEPPOL-EN16931-R020 requires the address itself.
- BR-63
The Buyer electronic address (BT-49) shall have a Scheme identifier.
- What the rule requires
- Where the buyer electronic address (BT-49) is sent, it must carry a scheme identifier. The attribute says which register the identifier comes from — without it the value is only a string.
- Why it fires
- The same cause as BR-62, sharpened: for public bodies the Leitweg-ID is entered as the address, and then the scheme is 9958 rather than EM — a choice that only surfaces if the field exists at all.
- How to fix it
- Set the schemeID attribute on cac:AccountingCustomerParty/cac:Party/cbc:EndpointID in UBL, and the corresponding schemeID on the same element in CII. PEPPOL-EN16931-R010 requires the address itself.
- BR-64
The Item standard identifier (BT-157) shall have a Scheme identifier.
- What the rule requires
- Where the item standard identifier (BT-157) is sent, it must carry a scheme identifier. The attribute says which register the identifier comes from — without it the value is only a string.
- Why it fires
- The GTIN sits in the item master as a number. That it must additionally say which numbering scheme it comes from does not follow from your own system.
- How to fix it
- Set the schemeID attribute on cac:Item/cac:StandardItemIdentification/cbc:ID in UBL, and the corresponding schemeID on the same element in CII. 0160 denotes a GTIN.
- BR-65
The Item classification identifier (BT-158) shall have a Scheme identifier.
NormAPI provides technical validation, not tax or legal advice.