Guides

Party identifiers

Updated 21 August 2026

An invoice carries a lot of numbers: the seller's, the buyer's, a VAT number, a tax identifier, an electronic address. For a human reader the context is enough to tell them apart. For a machine it is not: a number without its register is only a string of digits, and that is what most of these rules check.

The attribute that names the register. It is called schemeID and it recurs everywhere. On the buyer's global identifier it says whether this is a GLN or a SIRET, which are not read the same way. On a tax registration it says which kind of number this is, "VA" for a VAT number, without which a VAT number and a tax number look alike. On an electronic address it says which register to read it in, EM for an e-mail, 0009 for a SIRET, and its value must come from the official list.

The seller declares only two kinds of registration here: its VAT number under scheme identifier VA, and its tax identifier under FC. A block carrying any other scheme, or none, is not used at this position. It declares one of each kind at most, and each holds a single number: a seller registered for VAT in several countries shows here only the number the transaction is invoiced under.

One identifier, one value. The same discipline recurs on every party. The buyer carries one identifier only, and a second is the usual symptom of two systems each having written their own. One electronic address in its block, because the identifier and its scheme belong together and two values would make routing ambiguous. One tax registration block, one number inside it.

And a fourth party nobody rereads: the seller's tax representative. Where it appears it follows the same rules and fails for the same reasons: one name, one postal address, exactly one country code in that address, one subdivision, one tax registration holding exactly one number. Without that number the block serves no purpose, and a second cannot be chosen between. It is the country that makes the representative identifiable to the administration.

These rules resemble one another because they all say the same thing: an identifier is read with its register, and one value per position. They fail mostly on exports where two pieces of software each wrote their own number. Open your invoice in Pruvue: the report says which block is at fault, quotes the rule's official text and explains it in French, with the file never leaving your device. On addresses and the country code, see seller, buyer and addresses.

Open the applicationPruvue runs in your browser: no upload, no account.

Sources: Factur-X specification 1.09.2 and its Schematron, the SellerTradeParty, BuyerTradeParty and SellerTaxRepresentativeTradeParty blocks (FNFE-MPE, fnfe-mpe.org) ยท EN 16931 (CEN).