The delivery block

An invoice does not only say who sells and who buys. It can also say where the goods went and when, in a delivery block separate from both parties. It is the section an issuer fills in most mechanically, often copied from a delivery note, and that is why it produces refusals that seem to come from nowhere.

The actual delivery date. It is written once and once only: several dates in the same block are refused. And like every date in Factur-X it carries an attribute saying how to read it, whose only possible value is 102, meaning YYYYMMDD. A perfectly written date without that attribute fails, and writing it with any other value fails too.

The goods recipient. It carries at most one identifier and at most one global identifier, and the two do not follow the same rule. On the plain identifier the schemeID attribute is not foreseen: if it is there, that is what has to go, not the identifier. On the global identifier the same attribute is expected, and its value is compared against a code list. Two neighbouring fields, two opposite requirements.

The recipient's address. It must carry a country code, and only one: none fails, two fail as well, even when both carry the same value. That code is then compared against a list, so a misspelled country, or one written out in words, is refused on its value rather than on its presence. The country subdivision, for its part, may appear only once.

The despatch advice. Its block expects one identifier, and only one. A block the issuing tool opened without putting anything in it fails exactly as one holding two does: it is to be removed rather than kept empty.

What links these five: none of them shows on the PDF. The printed delivery note is right, the invoice is readable, and the file is refused over a piece of information nobody typed by hand. Drop your invoice into Pruvue: the report names the failing rule, quotes its official text and explains it in French, in your browser, with the file going nowhere. For the other shape checks, see structure errors.