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

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

The token naming the Factur-X EXTENDED profile. In the XML it appears as urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended, and the word conformant, not compliant, is the whole story: this profile steps outside the European core on purpose.

What this identifier declares

urn:factur-x.eu:1p0:extended names the EXTENDED profile, the top of the Factur-X ladder. A document declaring it is a hybrid PDF/A-3 invoice whose embedded CII XML is allowed to go beyond the EN 16931 core model: additional party roles, multiple deliveries, richer logistics and packaging detail, complex allowance and charge structures, and other fields the European core deliberately left out. It exists because real supply chains, French industry ones in particular, carry data a lowest-common-denominator model cannot.

The full BT-24 value spells out the relationship precisely:

urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended

Note #conformant# where the BASIC profile has #compliant#. Compliant means "a subset of the core"; conformant means "consistent with the core but possibly beyond it". One word in the string tells a receiver whether to expect anything outside the EN 16931 model.

Where it appears in the XML

<rsm:ExchangedDocumentContext>
  <ram:GuidelineSpecifiedDocumentContextParameter>
    <ram:ID>urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended</ram:ID>
  </ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>

The PDF's XMP metadata carries the matching fx:ConformanceLevel of EXTENDED. As with every Factur-X profile, the two declarations must agree.

What validators derive from it

The identifier switches the validator onto the widest rulebook: the EXTENDED XSD, which admits the extra structures, plus the EXTENDED Schematron rules, with the applicable EN 16931 core logic still enforced underneath. This selection matters more here than for any other profile, because a validator that ignores BT-24 and runs the plain core schema will report perfectly legal extended fields as errors. The InvoiceXML Factur-X validator detects the profile from the declared identifier and treats extended content as first-class, never as a failure.

Common problems around this identifier

  • False errors from core-only validators. The most common EXTENDED complaint is not a broken file but the wrong rule set applied to a correct one.
  • Reaching for EXTENDED "to be safe". If your data fits the core, declaring EXTENDED only narrows your audience: every receiver handles the EN 16931 profile, not every receiver maps extended structures. Use the smallest profile that carries your data.
  • Lossy conversions. Converting an EXTENDED invoice to a core-profile document or to UBL drops whatever the target cannot express. If a downstream system needs the extended fields, the conversion is the wrong place to find out.

Working with EXTENDED documents

Run any received file through the Factur-X validator to confirm the declared profile and see rule-level findings, and use /v1/extract/json or /v1/extract/xml to pull the data or the raw CII out of the hybrid. To produce EXTENDED documents without maintaining the widest schema in the standard yourself, the create endpoint generates and validates the file server-side with the current FNFE-MPE artifacts. The Factur-X hub positions EXTENDED against the other four profiles, and the Factur-X API toolkit covers integration patterns.

Frequently asked questions

What is the difference between #compliant# and #conformant#?

#compliant# marks a CIUS: a subset that stays strictly inside the EN 16931 core, like Factur-X BASIC or XRechnung. #conformant# marks an extension: a specification that is consistent with the core but allowed to carry data beyond it. EXTENDED is the standard example of the second kind.

Will Chorus Pro and the French PDPs accept EXTENDED invoices?

EXTENDED is a defined profile of the French reform's format, and platforms that implement Factur-X fully handle it. The practical risk sits with individual receivers whose systems only map the core fields; the extra data arrives intact but may be ignored. Agree on the profile with your counterparty when the extended structures actually matter.

When do I actually need EXTENDED?

When your invoices carry information the core model cannot express: multiple deliveries or delivery parties on one invoice, detailed logistics and packaging structures, complex charge cascades, sector-specific references. If none of that applies, the EN 16931 profile interoperates more widely.

Does an EXTENDED invoice pass EN 16931 validation?

Not against the plain core rule set: the extra elements are outside the core schema by definition. Validators must select the EXTENDED XSD and rules based on the declared identifier. That is why the InvoiceXML validator never counts a legitimate extended field as a failure, while still applying every core rule that remains in scope.