What this identifier declares
urn:factur-x.eu:1p0:en16931 names the EN 16931 profile of Factur-X (historically called COMFORT in ZUGFeRD terms): a hybrid PDF/A-3 invoice whose embedded CII XML carries the complete EN 16931 core data set. Full line items, VAT breakdown, allowances and charges at document and line level, payment details, references: everything the European semantic model defines, nothing beyond it. It is the profile to reach for by default in French and German exchange, and the smallest one that keeps every automation option open on the receiving side.
There is a subtlety that brings most people to this page. In the XML itself, this profile does not declare the 1p0:en16931 token. The specification assigns it the plain European core identifier:
<rsm:ExchangedDocumentContext>
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:cen.eu:en16931:2017</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>
The urn:factur-x.eu:1p0:en16931 string is the profile's name within the Factur-X URN scheme. You meet it in validation reports, library configuration, the specification's code lists, and in the wild as the suffix of combined identifiers such as urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:en16931, which ZUGFeRD-branded documents use to make the profile explicit. The PDF's XMP metadata states the same claim as fx:ConformanceLevel with the value EN 16931.
What validators derive from it
Whichever spelling a document carries, profile detection resolves it to the same rulebook: the EN 16931 XSD subset and the full CEN Schematron rule set, more than 200 business rules covering totals arithmetic, VAT category logic, code lists, and conditional presence. The InvoiceXML Factur-X validator recognises the plain core URN, the combined forms, and the legacy zugferd.de:2p0 family, reports what it detected in data.profile, and returns each finding with the rule ID and the XML context that triggered it.
Common problems around this identifier
- Emitting the token as BT-24. Some hand-rolled generators write
urn:factur-x.eu:1p0:en16931directly into the XML. Receivers that match identifiers strictly will not recognise it; the specification's value for this profile is the plain core URN. - Declared profile versus actual content. Declaring the EN 16931 profile does not make the 200-rule core pass. Totals that do not add up, VAT categories missing their required fields, and code-list violations are what actually bounce documents at this level.
- Container disagreement. An XMP conformance level of EN 16931 over an XML declaring EXTENDED (or vice versa) fails consistency checks before content rules even run.
Working with EN 16931 profile documents
To find out what a received hybrid really declares and whether it survives the core rules, validate it in the browser or via the API; extraction into BT-mapped JSON is one call to /v1/extract/json. To produce them, the Factur-X create endpoint takes plain invoice JSON, computes the totals, stamps the correct identifier, and validates against the full rule set before delivery, with the current FNFE-MPE and CEN artifacts maintained server-side. The Factur-X hub compares the profile ladder, and the Factur-X API toolkit is the step-by-step integration guide.
Related identifiers
- urn:cen.eu:en16931:2017, the identifier this profile actually writes into BT-24
- urn:factur-x.eu:1p0:basic, the compliant subset below it
- urn:factur-x.eu:1p0:extended, the extension above it
- urn:factur-x.eu:1p0:minimum and urn:factur-x.eu:1p0:basicwl, the sub-core profiles