Konvertieren

Wofür. Eine Rechnung in ein anderes Format bringen — zwischen den neun E-Rechnungsformaten und von der ERP-Achse her.

Hinein. Datei oder eingefügter Text. Das Quellformat wird automatisch erkannt; Sie wählen nur das Zielformat. Die Auswahlliste ist gruppiert: E-Rechnungsformate, SAP / EDIFACT (ERP), Weitere Formate (Excel, JSON). Fehlt die Wahl: „Bitte ein Zielformat wählen.“

Laden Sie ein PDF hoch, passiert das Sinnvolle: Eine Hybrid-PDF trägt die Rechnung — sie wird herausgelöst und umgewandelt. Eine gewöhnliche PDF wird abgelehnt und auf „PDF zu E-Rechnung“ verwiesen.

Heraus. Die umgewandelte Datei zum Herunterladen, die Herkunftsanzeige Quellformat → Zielformat, „Prüfung des Ergebnisses“ (derselbe Prüfbericht, auf das Resultat angewandt), eine XML-Vorschau, bei Facturae der Signaturblock und — mit Konto — „Im Archiv speichern“. Schlägt die Umwandlung fehl: „Konvertierung fehlgeschlagen“, ergänzt um den Befund der Engine.

Wenn dem Ergebnis etwas fehlt

Ein Quelldokument kann nicht immer alles liefern, was das Zielformat verlangt. Dann steht neben dem Download „Das Ergebnis ist noch nicht gültig — fehlende Pflichtangaben: 3.“ und unterhalb des Berichts der Knopf „Fehlende Angaben ergänzen“, der das Erstellen-Formular mit dem umgewandelten Inhalt öffnet.

Der Download bleibt erreichbar, tritt aber optisch zurück

Eine Rechnung herunterzuladen, die der Empfänger ablehnt, soll nicht der naheliegende nächste Schritt sein.

Was verloren gehen kann

Die Umwandlung läuft immer über das gemeinsame Modell: Quelle → Modell → Ziel. Ein Feld, das das Zielformat nicht tragen kann, geht dabei verloren — eine Formatgrenze, kein Fehler.

Drei Grenzen, die oft überraschen:

• Nationale Pflichtformate außerhalb Europas werden gelesen, aber nicht geschrieben — ihre Belege tragen Codes, die allein die jeweilige Finanzverwaltung vergibt. Lesbar sind unter anderem Mexiko (CFDI 4.0), Brasilien (NF-e und NFS-e im nationalen Standard), Chile, Uruguay, Paraguay, Bolivien, Ecuador, Costa Rica, Guatemala, die Dominikanische Republik, Korea und China.
• Erkannt und beim Namen genannt, aber nicht gelesen ist eine zweite, kleinere Gruppe: Mexiko in der Altfassung CFDI 3.3, das kommunale ABRASF-Altlayout der brasilianischen NFS-e und die taiwanische eGUI (電子發票). Hier gibt es keine Umwandlung; die Meldung verweist aufs Erstellen.
• ZUGFeRD 1.0 wird gelesen, ist aber älter als EN 16931 und darum nicht prüfbar. Die Umwandlung nach XRechnung oder ZUGFeRD 2.x ist genau der Migrationsweg für ein Altarchiv.
• Die XML-Darstellung von UN/EDIFACT (SAP PI) wird gelesen, aber nicht geschrieben: Sie ist je Middleware verschieden, eine von uns geschriebene Datei wäre nur für eine Installation gültig.

Zwei gegensätzliche Auskünfte, die man nicht verwechseln darf

„Wir lesen das, aber schreiben es nicht“ und „wir können das überhaupt nicht lesen“ führen zu verschiedenen nächsten Schritten. Ein Verweis aufs Konvertieren, wo es keinen Importer gibt, kostet Sie den Weg; umgekehrt eine Sackgassen-Meldung, wo ein Importer bereitsteht, kostet Sie die Umwandlung. Welche Auskunft Sie bekommen, nennt immer den Formatnamen mit.

Wohin als Nächstes

Welches Feld bei welchem Format verlustfrei durchläuft, steht Feld für Feld in der Fidelity-Matrix des Produkt-Repositorys. Die Formate und ihre Grundlagen beschreibt E-Rechnung und ihre Formate.