UBL or CII: which XML syntax do I need?
Usually you do not choose. The format you are targeting chooses for you, and only XRechnung genuinely leaves the decision open.
UBL and CII are two XML languages for writing the same invoice. EN 16931 defines invoice content once, as a syntax-neutral model, and then names both as valid ways to express it. So the same business facts can be written either way, with different element names and a different document shape, and mean exactly the same thing.
That is why the question is less open than it looks: the target format almost always decides.
The choice is usually made for you
The network carries UBL, so this is not negotiable.
Embedded in the PDF.
This is the one real choice.
Both build on Peppol BIS Billing 3.0.
These are separate national XML formats with their own schemas.
The last row is worth pausing on. FatturaPA, Facturae and e-SLOG are not EN 16931 syntaxes at all. They predate or sit outside the European harmonisation, they are validated against their own authority schema, and the UBL-or-CII question simply does not arise for them.
When you actually choose: XRechnung
XRechnung permits both bindings, and German receiving systems differ in what they read. The practical guidance is to send what the receiver asks for, and if nobody has asked, CII is the safer default in Germany because it is what most existing German integrations already handle. Beliq emits CII by default for XRechnung and produces the UBL binding on request. The German rules apply identically to both.
What the choice does not change
It changes none of the compliance picture. The same EN 16931 business rules run over both bindings, the same country overlay applies, and a document is exactly as valid in one syntax as in the other. It is not a compatibility trade-off or a strategic decision. It is a serialisation format.
What it does change is which libraries and mappings your own systems need. If your ERP already emits UBL, and your only obligation is Peppol, there is no reason to go near CII. If you are producing hybrid PDFs, you are producing CII whether you thought about it or not, because that is what goes inside the file.
Converting between them
If you already have a document in the wrong syntax, POST /v1/convert moves between them across the EN 16931 family, in both directions, and can also swap an XRechnung CII document to XRechnung UBL while keeping the German CIUS intact.
The route is deliberately fail-closed. Where the target genuinely cannot represent something the source carried, the conversion is refused with the unmappable paths named, rather than performed with silent data loss. Two cases hit this today: French CTC process codes on a UBL target, which you can opt into dropping explicitly, and synthesising Peppol endpoint identifiers from a source that never had them, where there is no opt-in and the right move is to generate the document fresh instead.
National formats have no converter, and that is not a gap waiting to be filled. There is no published equivalence between FatturaPA and EN 16931, so a converter would be inventing a mapping and calling it a standard. Generate those from your structured data instead.