The most useful thing an accounts payable manager can learn about structured invoicing is not a format. It is a numbering scheme.
The European semantic model gives every piece of information on an invoice a stable identifier. Groups take a BG- prefix, individual terms take BT-. Those numbers are the same in both permitted syntaxes, the same in every national profile, and the same across versions. They are the vocabulary in which every specification conversation in this field is conducted, and they turn arguments into change requests.
Groups and terms
A business group is a container. The seller's information is a group. Payment instructions are a group. Each entry in the VAT breakdown is a group, occurring once per tax category and rate present in the document. Groups nest: a group for the invoice line contains a group for the item, which contains terms for its identifiers.
A business term is a single piece of data inside a group, or at the top level of the document: the issue date, the currency, the seller's legal name, the amount due for payment.
Reading that picture, the useful realisation is that an invoice is not a flat list of fields. It is a small hierarchy in which the same information can legitimately appear at more than one level, and where it appears changes what it means.
The four things a term definition tells you
Look up any term and you get four properties. Each of them causes a specific class of problem when ignored.
A meaning. Written in business language, deliberately not in the vocabulary of any particular accounting system. The definition is the authority when two implementations disagree about what belongs in a field.
A cardinality. How many times the term may appear, expressed as a minimum and a maximum. Zero-to-one means optional. One-to-one means required. Zero-to-many means a repeating element. A profile can raise a minimum from zero to one, and that single change is the most common cause of a rejection that reads as arbitrary to the sender.
A data type. Identifier, text, amount, quantity, code, date, binary object. The distinction between an identifier and text is the one that matters most: an identifier is expected to be qualified by a scheme and to be resolvable in that scheme, whereas text is anything.
A relationship to other terms. Some terms are only meaningful when another is present, and the standard's business rules express those dependencies. A tax category with no rate, or an exemption with no reason, will be caught by a rule rather than by a schema.
The terms worth knowing by number
Not all of them. A working set. These are the ones that appear in almost every real conversation about a rejected invoice, described here by what they do rather than by an exhaustive list, so that you know what to look up.
| What it does | Where it lives | Why it causes trouble |
|---|---|---|
| Specification identifier | Document level | Declares which profile validates the document; wrong value means wrong rules |
| Invoice number and issue date | Document level | The pair that identifies the document to everybody downstream |
| Document type code | Document level | Distinguishes invoice from credit note and from national document types |
| Currency of the invoice | Document level | Distinct from the currency in which tax is accounted for |
| Buyer reference | Document level | Supplied by the buyer for routing; frequently populated with the seller's own reference by mistake |
| Seller and buyer tax identifiers | Party groups | Must be qualified; a bare number is not an identifier |
| Order and contract references | Document or line | Where a buyer's matching process finds its hook |
| Tax category and rate | Line and breakdown | Must be consistent between the two, and complete in the breakdown |
| Exemption reason | Breakdown | Required when the category demands it; a free-text answer where a code is expected fails |
| Allowance and charge | Document and line | Different arithmetic at each level; putting one where the other belongs breaks the totals |
| Document totals | Document level | Derived, and the business rules check the derivation |
Every row in that table is a place where a real implementation has failed, repeatedly, in more than one country.
Why the numbering pays for itself
Three practical reasons, all of them about communication rather than technology.
It removes ambiguity from a change request. "The customer wants their order number on the invoice" can mean at least three different fields with three different meanings. "Populate BT-13 at document level" cannot.
It makes a rejection actionable. A validation report cites the rule and the term. Somebody who knows the vocabulary reads it in seconds; somebody who does not sends it to a consultant.
It survives the vendor. Your ERP calls the field something. Your service provider calls it something else. The profile documentation calls it a third thing. The term identifier is what all three map to, and it is what you should record in your own mapping documentation so that the next person can follow it.
A single sheet mapping each business term you use to the field in your source system that populates it, with the rule that decides the value. It is the document that outlives the project, the consultant and the software, and almost nobody produces one.
Where terms and master data meet
Populating a term correctly means having the data to populate it with. That is the point at which the semantic model stops being a specification and becomes a data quality problem: tax identifiers with schemes, units of measure from a code list, tax categories on every line, addresses broken into components rather than held as three lines of free text.
The vocabulary tells you exactly what is missing, which is the most useful thing it does. Run a sample of last month's invoices through the terms your profile requires and the gap list writes itself. That list is the real start of master data remediation, and it is a far better basis for scoping than any vendor questionnaire. The code list side of the same problem is covered in code lists, identifiers and the schemes behind them.
