Attestwire › Rule reference › BR-CO-09

BR-CO-09 VAT identifiers must carry a country prefix

noun · EN 16931 · fatal · BT-31

a VAT number that forgot which country it belongs to.

Your invoice was refused because a VAT number on it has no country code in front of it. A VAT number is only meaningful with its two-letter country prefix, such as DE or FR, and the fix is to store and send the number as one string with the prefix attached. The fields involved are the seller, buyer and tax representative VAT identifiers (BT-31, BT-48 and BT-63), and BR-CO-09 is the rule that checks them.

Business term

BT-31 — Seller / buyer VAT identifier

Severity

fatal

Applies to

All profiles

The fix

Store VAT identifiers with the prefix, as one string, everywhere in your system, and pass that string as vatId. Splitting them into a country column and a number column is the usual root cause of a stripped prefix: one code path reassembles them and another forgets.

If your seller is Greek, the stored prefix is EL even though the country code in the postal address (BT-40) is GR. Those two fields disagreeing is correct here, so a well-meaning “consistency” check in your own code will break the invoice.

What the rule requires

Each VAT identifier on the invoice must start with the two-letter code of the country that issued it, from the ISO 3166-1 list: DE123456789, FR12345678901, NL123456789B01. That applies to the seller VAT identifier (BT-31), the seller tax representative VAT identifier (BT-63) and the buyer VAT identifier (BT-48).

Greece is the one exception. Greek VAT numbers carry the prefix EL, not the country’s ISO code GR. That mismatch long predates EN 16931, and the rule text calls it out.

This rule is only about the shape of an identifier that is already there. Whether a VAT identifier is required at all is decided by the VAT-category rules (BR-S-02, BR-AE-02, BR-IC-02 and the rest).

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'.

Failing and passing

validateInput({
  // ...
  seller: {
    name: "Acme GmbH",
    vatId: "123456789",        // <- BR-CO-09, no country prefix
    address: { city: "Berlin", postalCode: "10115", countryCode: "DE" },
  },
  // ...
});
// -> { valid: false, errors: [ { rule: "BR-CO-09", field: "BT-31", ... } ] }

validateInput({
  // ...
  seller: {
    name: "Acme GmbH",
    vatId: "DE123456789",      // prefix + national number, one string
    address: { city: "Berlin", postalCode: "10115", countryCode: "DE" },
  },
  // ...
});
// -> { valid: true, errors: [] }

Why it exists

The prefix is what makes a VAT number resolvable at all. The same digits can be a valid identifier in two different member states, and VIES, the EU validation service, is keyed on country plus number. Strip the prefix and neither the buyer’s system nor a tax authority can tell which register to look in.

The prefix is also how a receiving system works out whether a supply is domestic or cross-border, and that changes the VAT treatment.

What the library returns

The full error returned by @attestwire/en16931. It includes the rule ID, affected field and suggested correction. Developers can use this object in their application:

{
  "rule": "BR-CO-09",
  "field": "BT-31",
  "severity": "fatal",
  "message": "The seller VAT identifier (BT-31) must start with a country prefix in accordance with ISO 3166-1 alpha-2, but \"123456789\" does not. Greece is the one exception: it uses the prefix \"EL\" rather than \"GR\".",
  "fix": "Prefix the number with the issuing country's two-letter code — a German number 123456789 becomes \"DE123456789\". Store it prefixed; do not add the prefix only at render time.",
  "example": "\"vatId\": \"DE123456789\"",
  "xpath": "/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID",
  "docsUrl": "https://attestwire.com/rules/BR-CO-09"
}

xpath is always a UBL path. On a CII invoice, look for the matching CII field instead.

How our check differs