What this identifier declares
urn:factur-x.eu:1p0:basic names the BASIC profile of Factur-X, the Franco-German hybrid PDF/A-3 invoice with embedded CII XML. If you found the token in a real document, it was almost certainly the tail end of the full specification identifier:
urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic
The structure of that string is the actual answer. BASIC is a CIUS of EN 16931: a restricted subset of the European core invoice model that includes invoice lines, which makes it the first profile on the Factur-X ladder that is a genuine, bookable EN 16931 invoice. Below it, MINIMUM and BASIC WL carry standalone identifiers because they fall short of the core; above it, the EN 16931 and EXTENDED profiles widen the data set again.
BASIC exists for simple invoices: standard line items, document-level charges, a normal VAT breakdown. It deliberately omits line-level allowances and charges and other refinements of the full core model.
Where it appears in the XML
The identifier is BT-24, carried in the document context at the top of the embedded factur-x.xml:
<rsm:ExchangedDocumentContext>
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>
In the PDF's XMP metadata the same claim appears as fx:ConformanceLevel with the value BASIC.
What validators derive from it
Profile detection reads BT-24 and picks the rulebook: the BASIC restricted XSD, the EN 16931 core rules, and the BASIC profile rules on top. The InvoiceXML Factur-X validator reports the detected profile in data.profile and names the layer of every finding (XSD, EN 16931 core, or profile), so a failing document tells you which rulebook objected. Legacy identifiers from the older zugferd.de:2p0 family map to the same profile, as the official Factur-X code lists specify.
Common problems around this identifier
- Emitting the bare token. XML that declares
urn:factur-x.eu:1p0:basicwithout the#compliant#stem is not carrying the identifier the specification defines, and strict receivers that match the full string will treat it as unknown. - Outgrowing the subset. Data that BASIC cannot express (line-level charges are the classic case) either gets silently dropped by careless generators or fails the restricted schema. The fix is the EN 16931 profile, not creative mapping.
- Profile mismatch across the container. BT-24 saying BASIC while the XMP conformance level says something else makes validators, and some receiving platforms, reject the file outright.
Working with BASIC documents
Received a file declaring this identifier? Validate it to confirm the declared profile matches the content, then extract the structured data with /v1/extract/json. Sending? The create endpoint stamps the full, correct identifier for whichever profile you request and validates the result against the matching rule set before you ever see the file. The Factur-X hub has the complete profile matrix, and the Factur-X API toolkit is the end-to-end integration guide.
Related identifiers
- urn:cen.eu:en16931:2017, the stem this identifier builds on
- urn:factur-x.eu:1p0:basicwl, BASIC without the lines, and without the compliance claim
- urn:factur-x.eu:1p0:en16931, the full core data set
- urn:factur-x.eu:1p0:extended, beyond the core for complex billing