Back to the error catalogue
BR-CO-09BT-31
input

A VAT identifier has no country prefix

The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) must start with the ISO 3166-1 alpha-2 code of the issuing country; Greece may use `EL`.

Only the issuer holds this value: Factlint reports it and never fabricates it. Test your invoice to find out whether it is affected.

The message your validator prints

Copied verbatim from the sealed artefact: this is the exact sentence the check prints when this rule fails.

[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’.

Quoted from schematron-cen 1.3.16, licensed under EUPL-1.2.

Common searches around this code

These phrases mirror what an integrator searches for: code, syntax, rule, business field and correction.

BR-CO-09 A VAT identifier has no country prefixBR-CO-09 CEN EN 16931 SchematronBR-CO-09 BT-31[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’.BR-CO-09 correction

Test your file with this error in mind

Upload the invoice involved: the report will say whether this code appears, where it appears in the document, and whether Factlint can only report it or also fix it.

To automate this check in an ERP flow, call the validation API and link every returned code to its public page.

Why this error happens

The prefix is lost whenever a number is taken from an internal repository that stores only its national part. This is common in France, where the number circulates daily without its `FR`, and on intra-community invoices where the buyer was keyed in by hand.

How to fix it

The prefix is restored at source, in the party record. It is not inferred from the address country: an assumed country would produce a syntactically valid and fiscally wrong number, which is more dangerous than its absence.

XML correction example

BEFORE (invalid)
<ram:ID schemeID="VA">123456789</ram:ID>
AFTER (compliant)
<ram:ID schemeID="VA">FR12123456789</ram:ID>