Automation MCP Server Features Blog Pricing Contact
Identifier reference Factur-X profile

urn:factur-x.eu:1p0:basic

The token that names the Factur-X BASIC profile. In the XML it appears as the suffix of a longer identifier, urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic, and that stem is the interesting part: BASIC is the first profile on the ladder that is a real EN 16931 invoice.

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:basic without 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.

Frequently asked questions

Why does the full identifier start with urn:cen.eu:en16931:2017?

Because BASIC is a CIUS, a compliant subset of the EN 16931 core model. The grammar is stem#compliant#profile: the stem names the European standard, the #compliant# separator promises the document stays inside it, and the suffix names the restricting profile.

Is bare urn:factur-x.eu:1p0:basic a valid BT-24 value?

The Factur-X specification defines the full stem#compliant# form as the BASIC identifier. The bare token is the profile's short name, and some tooling emits or matches it loosely, but strict receivers compare the whole string, so emit the full form. The InvoiceXML validator recognises the family either way and tells you what it found.

Does BASIC satisfy the German B2B e-invoicing mandate?

Yes. Because BASIC is EN 16931 compliant, it qualifies as a structured electronic invoice under the German mandate, unlike MINIMUM and BASIC WL. Whether it is sufficient for your invoices is a data question: BASIC only covers simple line structures.

When do I need the EN 16931 profile instead of BASIC?

As soon as your invoices need what the subset cut away: line-level allowances and charges, more party detail, additional references or attachments. If the create endpoint reports fields your chosen profile cannot carry, step up to the EN 16931 profile rather than bending the data.