In short
- A restriction of the European standard, not a separate format.
- Maintained by a public body, versioned on a published cycle, with overlapping support windows.
- Its distinctive element is a routing identifier that only the receiver can supply.
- Worth reading as a specimen: every national profile answers the same three questions.
Germany's national profile is a good place to learn how to read any national profile, because it is well documented, publicly maintained and structurally typical. What follows is as much a method as a description.
The three questions every profile answers
Whatever country you are looking at, a profile tells you three things and you can find them in any order.
What did it make mandatory? The European standard leaves a great deal optional so that it can serve every sector in every Member State. A national profile removes that latitude in the places its administration cares about — typically contact details, payment terms, and identifiers that its own systems need.
What did it forbid? Less commonly noticed, and it causes more confusion. An element that the standard permits and the profile excludes will be rejected, and a supplier who populated it because they had the data experiences that as arbitrary.
What did it add that only exists here? Strictly a profile cannot add, so anything genuinely new is carried in an existing element of the standard used in a specified way. Germany's routing identifier is exactly this: a national concept carried in a general-purpose reference element.
The routing identifier
The distinctive German feature, and a useful illustration of a general problem.
German public authorities receive invoices into infrastructure that must route them onward to the right internal destination. The identifier that makes that possible is issued by the receiving authority. It is not derivable from the authority's name, its VAT number, its address, or anything else a supplier can look up.
Which means it must be collected, per customer, before the first invoice — and collected accurately, because a well-formed but wrong value routes the document somewhere real and useless.
This is the German instance of the most under-planned task in every e-invoicing project: gathering a piece of counterparty data that only the counterparty has. It has direct analogues elsewhere — the recipient code in Italy, the participant identifier on a network — and it is why supplier and customer onboarding is a data-collection exercise rather than a communications exercise.
A missing routing identifier produces a rejection, which is annoying and visible. A wrong one produces a delivery, which is worse: the document is accepted, nobody who needed it receives it, and the first sign of trouble is a payment that does not arrive.
Versioning, and the thing to put in a calendar
The profile is revised on a published cycle. Each version is supported for a defined period alongside its successor, and then withdrawn.
Two implications.
This is a subscription. Somebody has to read the release notes, decide whether anything affects you, and schedule the change. If nobody owns that, you will discover a version change through rejections, which is an expensive way to receive a newsletter.
Test data ages. A test suite built against one version keeps passing after that version is withdrawn, because the tests validate against the rules they were written with. Refresh the validation artefacts as part of adopting each version, or your tests will tell you the truth about a specification nobody uses any more.
The pure-XML and hybrid question
Germany's market uses two shapes of the same content: a pure XML document, and the same XML embedded inside a PDF as described in hybrid invoices.
Both can satisfy the requirement. The choice is about your customers rather than your compliance, and it changes over time. The pragmatic sequence most businesses have followed is to start hybrid, because it keeps the human-readable rendering that everyone's process already assumes, and to move to pure XML for counterparties who can consume it.
What must not happen is a divergence between the two layers. If the PDF says one thing and the XML says another, the structured data is the invoice, and you have issued a document that contradicts itself. Generate both from one source, in one operation, and check the totals match before either leaves the building.
Reading a profile you have never seen before
The method, in the order that wastes least time:
- Find the specification identifier the profile requires. Everything else is validated against it.
- Find the list of mandatory elements it adds beyond the standard. Compare with what your system emits today.
- Find the excluded elements. Check you are not populating any of them.
- Find the code list restrictions, particularly on tax categories and units of measure. This is where master data hits the profile.
- Find any national identifier the profile requires and establish who issues it.
- Find the validation artefacts the maintainer publishes, and run them locally. Never rely on a provider's assurance that they are current.
That sequence takes an afternoon per profile once you have done one. The first one takes a week, which is the argument for doing it properly rather than delegating it to whoever is available. The wider structure is in CIUS and extensions, and the reason all of this sits above a common model is in EN 16931 explained.
