Converting

What for. To move an invoice into another format — between the nine e-invoice formats and from the ERP side.

In. A file or pasted text. The source format is detected automatically; you only choose the target format. The list is grouped: E-invoice formats, SAP / EDIFACT (ERP), Other formats (Excel, JSON). If the choice is missing: “Please choose a target format.”

Upload a PDF and the sensible thing happens: a hybrid PDF carries the invoice — it is extracted and converted. An ordinary PDF is rejected with a pointer to “PDF to e-invoice”.

Out. The converted file for download, the provenance line source format → target format, “Validation of the result” (the same report applied to the output), an XML preview, with Facturae the signature block, and — with an account — “Save to archive”. If the conversion fails: “Conversion failed”, along with the engine’s finding.

If the result lacks something

A source document cannot always supply everything the target format requires. The download is then accompanied by “The result is not yet valid — missing mandatory entries: 3.”, and below the report sits the button “Add missing details”, which opens the create form with the converted content.

What can be lost

Conversion always runs through the shared model: source → model → target. A field the target format cannot carry is lost in the process — a limit of the format, not a fault.

Three limits that often come as a surprise:

National mandatory formats outside Europe are read but not written — their documents carry codes issued solely by the respective tax authority. Readable are, among others, Mexico (CFDI 4.0), Brazil (NF-e and NFS-e in the national standard), Chile, Uruguay, Paraguay, Bolivia, Ecuador, Costa Rica, Guatemala, the Dominican Republic, Korea and China.
Recognised and named, but not read is a second, smaller group: Mexico in the legacy version CFDI 3.3, the municipal ABRASF legacy layout of the Brazilian NFS-e, and the Taiwanese eGUI (電子發票). There is no conversion here; the message points to Create.
ZUGFeRD 1.0 is read but predates EN 16931 and is therefore not validatable. Converting it to XRechnung or ZUGFeRD 2.x is precisely the migration route for a legacy archive.
The XML rendering of UN/EDIFACT (SAP PI) is read but not written: it differs from middleware to middleware, so a file written by us would only be valid for one installation.

Where to go next

Which field passes through losslessly for which format is set out field by field in the fidelity matrix of the product repository. The formats and their foundations are described under E-invoicing and its formats.