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, e-SLOG and KSeF FA(3) 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. Beliq generates XRechnung as CII, and converts it to the UBL binding when the request declares the source as plain cii. 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 turn an XRechnung CII document into XRechnung UBL when the request declares the source as plain cii. It validates the converted XML before it returns it, and a conversion whose result fails validation is refused with CONVERSION_OUTPUT_INVALID instead of being returned.
The route also fails closed on the two losses it knows about. Where one of them applies, the conversion is refused with the unmappable paths named: 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. Some other losses come with the conversion you asked for, such as Peppol endpoints stripped when you leave Peppol BIS or a PDF envelope dropped for an XML target: the document is returned, and the X-Lost-Elements header lists them. The two converters are not checked field by field, so any other field one of them leaves out shows only where a validation rule sees it. The one exception is the invoice total VAT amount (BT-110): where the UBL to CII converter leaves it out and the source states exactly one in the invoice currency, Beliq writes the source’s own value back.
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.