Zum Hauptinhalt springen
Invoice-Converter.comInvoice-Converter
Preise
Rechnung umwandelnUmwandeln
Umwandeln
⌘K
Dokumentationsübersicht
Formate und Standards verstehen
Compliance-Leitfäden
XRechnung Standard
ZUGFeRD Format
PDF/A-3 für ZUGFeRD
CII Cross Industry Invoice
UBL Universal Business Language
DIN EN 16931-1 Standard
PEPPOL Network
Länder- und Regulatorikregeln
EU E-Rechnungspflicht
EU-E-Rechnung
E‑Rechnung in der EU 2026: was Sie umsetzen sollten (und warum)
Playbook für Top‑EU‑Märkte (DE, FR, IT, ES, PL, NL)
PEPPOL in der EU: so funktioniert der Austausch wirklich
CTC/Clearance und Portale in der EU: belastbare Integrationen bauen
Länderguides
Deutschland
Frankreich
Italien
Spanien
Polen
Niederlande
Belgien
Österreich
Dänemark
Schweden
Finnland
Validierungs- und Einreichungsprobleme lösen
Leitweg-ID Validierung
Support-Leitfäden
Support
Warum Rechnungen geprüft werden müssen
PDF-Vorbereitung
Quellendaten vorbereiten
Anhänge und Leistungsbeschreibungen
API-Fehler
API-Automatisierung
Umgang mit Schemafehlern
Hilfe zur Prüfvalidierung
Support
Fehlende Angaben
Käuferreferenz
Zahlung und IBAN
USt und Reverse Charge
Summen und Rundung
Anzahlungen
Positionen
ZUGFeRD-PDF-Warnungen
Validierungsleitfäden
Beobachtete Validierungsfälle
Fälligkeit oder Bedingungen
IBAN bei Überweisung
PDF/A-3-Fähigkeit
VATEX-Befreiungsgrund
Review gegen Download
Öffentliche Testrechnungs-Bibliothek
Gültige XRechnung-UBL-Basisrechnung
Ungültige XRechnung ohne Zahlungsbedingungen
Factur-X/ZUGFeRD EN-16931-CII-XML
XRechnung-Rundungs- und IBAN-Grenzfall
KoSIT Validierungsfehler
FEHLER
BR-DE-1
BR-DE-2
BR-DE-3
BR-DE-4
BR-DE-5
BR-DE-6
BR-DE-7
BR-DE-8
BR-DE-9
BR-DE-10
BR-DE-11
BR-DE-14
BR-DE-15
BR-DE-16
BR-DEX-01
BR-DEX-03
BR-DEX-04
BR-DEX-05
BR-DEX-06
BR-DEX-07
BR-DEX-08
BR-DEX-09
BR-DEX-10
BR-DEX-11
BR-DEX-12
BR-DEX-13
BR-DEX-14
BR-CO-3
BR-CO-4
BR-CO-9
BR-CO-10
BR-CO-11
BR-CO-13
BR-CO-14
BR-CO-15
BR-CO-16
BR-CO-17
BR-CO-25
BR-CO-26
BR-S-1
BR-S-5
BR-S-8
BR-CO-05
BR-CO-06
BR-CO-07
BR-CO-08
BR-CO-12
BR-CO-18
BR-CO-19
BR-CO-20
BR-CO-21
BR-CO-22
BR-CO-23
BR-CO-24
BR-61
BR-AE-02
BR-AE-10
BR-E-01
BR-E-05
BR-DE-19
BR-05
BR-22
BR-23
BR-24
BR-25
BR-26
BR-47
BR-57
BR-DE-22
BR-DE-30
BR-DE-31
PEPPOL-EN16931-R001
PEPPOL-EN16931-R010
PEPPOL-EN16931-R020
PEPPOL-EN16931-R046
PEPPOL-EN16931-R120
PEPPOL-EN16931-R130
BR-01
BR-02
BR-03
BR-04
BR-06
BR-07
BR-08
BR-09
BR-10
BR-11
BR-12
BR-13
BR-14
BR-15
BR-16
BR-17
BR-18
BR-19
BR-20
BR-21
BR-27
BR-28
BR-29
BR-30
BR-31
BR-32
BR-33
BR-36
BR-37
BR-38
BR-41
BR-42
BR-43
BR-44
BR-45
BR-46
BR-48
BR-49
BR-50
BR-51
BR-52
BR-53
BR-54
BR-55
BR-56
BR-62
BR-63
BR-64
BR-65
BR-CL-01
BR-CL-03
BR-CL-04
BR-CL-05
BR-CL-06
BR-CL-07
BR-CL-08
BR-CL-10
BR-CL-11
BR-CL-13
BR-CL-14
BR-CL-15
BR-CL-16
BR-CL-17
BR-CL-18
BR-CL-19
BR-CL-20
BR-CL-21
BR-CL-22
BR-CL-23
BR-CL-24
BR-CL-25
BR-CL-26
BR-DEC-01
BR-DEC-02
BR-DEC-05
BR-DEC-06
BR-DEC-09
BR-DEC-10
BR-DEC-11
BR-DEC-12
BR-DEC-13
BR-DEC-14
BR-DEC-15
BR-DEC-16
BR-DEC-17
BR-DEC-18
BR-DEC-19
BR-DEC-20
BR-DEC-23
BR-DEC-24
BR-DEC-25
BR-DEC-27
BR-DEC-28
BR-S-02
BR-S-03
BR-S-04
BR-S-06
BR-S-07
BR-S-09
BR-S-10
BR-Z-01
BR-Z-02
BR-Z-03
BR-Z-04
BR-Z-05
BR-Z-06
BR-Z-07
BR-Z-08
BR-Z-09
BR-Z-10
BR-AE-01
BR-AE-03
BR-AE-04
BR-AE-05
BR-AE-06
BR-AE-07
BR-AE-08
BR-AE-09
BR-E-02
BR-E-03
BR-E-04
BR-E-06
BR-E-07
BR-E-08
BR-E-09
BR-E-10
BR-IC-01
BR-IC-02
BR-IC-03
BR-IC-04
BR-IC-05
BR-IC-06
BR-IC-07
BR-IC-08
BR-IC-09
BR-IC-10
BR-IC-11
BR-IC-12
BR-G-01
BR-G-02
BR-G-03
BR-G-04
BR-G-05
BR-G-06
BR-G-07
BR-G-08
BR-G-09
BR-G-10
BR-O-01
BR-O-02
BR-O-03
BR-O-04
BR-O-05
BR-O-06
BR-O-07
BR-O-08
BR-O-09
BR-O-10
BR-O-11
BR-O-12
BR-O-13
BR-O-14
BR-AF-01
BR-AF-02
BR-AF-03
BR-AF-04
BR-AF-05
BR-AF-06
BR-AF-07
BR-AF-08
BR-AF-09
BR-AF-10
BR-AG-01
BR-AG-02
BR-AG-03
BR-AG-04
BR-AG-05
BR-AG-06
BR-AG-07
BR-AG-08
BR-AG-09
BR-AG-10
BR-B-01
BR-B-02
WARNUNG
BR-DE-17
BR-DE-18
BR-DE-20
BR-DE-21
BR-DEX-02
BR-DE-26
BR-DE-27
BR-DE-28
Referenzdaten nachschlagen
Glossar
E
EN 16931
Einheitencode
E-Reporting
Echtzeit-Meldung
Echtzeit-Rechnungsmeldung (RTIR)
e-Factura RO
EAS (Electronic Address Scheme)
ebInterface
C
CIUS
CII
Codeliste
Chorus Pro
Codice Destinatario
X
XRechnung
XML-Schema (XSD)
XML
Z
ZUGFeRD
Zahlungsart
F
Factur-X
Finvoice
U
UBL
USt-IdNr.
P
PEPPOL
PEPPOL BIS
Participant-ID
PDF/A-3
PDP (Plateforme de Dématérialisation Partenaire)
A
Access Point
S
SMP
SML
Steuerkategorie
Schematron
SDI (Sistema di Interscambio)
Svefaktura
L
Leitweg-ID
K
KoSIT
KSeF
KvK-Nummer
V
Validierung
Vertragsreferenz
ViDA
VeriFactu
ViDA Säule 1: Digital Reporting Requirements
ViDA Säule 2: Einheitliche USt-Registrierung
ViDA Säule 3: Plattformökonomie
B
Business Term (BT)
Business Group (BG)
BIC
Bestellung (PO)
R
Reverse-Charge
Rechnungsart-Code
Rechnungsposition
Rabatt / Zuschlag
I
IBAN
ISO 6523
G
Gutschrift
GLN (Global Location Number)
D
Dokumentenreferenz
D-U-N-S-Nummer
Digipoort
Q
QR-Code Zahlung
T
TicketBAI
O
OVT-tunnus
OIOUBL
N
NemHandel
Codelisten
Währungscodes (häufig)
Ländercodes (häufig)
USt-Kategorie-Codes
Zahlungsmittel-Codes
Maßeinheiten-Codes (häufig)
Rechnungstyp-Codes (häufig in XRechnung)
XRechnung Felder
Rechnungsgrundlagen
BT-1
BT-2
BT-3
BT-5
BT-6
BT-7
BT-8
BT-10
BT-11
BT-12
BT-14
BT-15
BT-16
BT-17
BT-18
BT-19
BT-21
BT-22
BT-23
BT-24
BT-25
BT-26
Lieferung und Zahlung
BT-9
BT-13
BT-20
BT-59
BT-60
BT-61
BT-70
BT-71
BT-72
BT-73
BT-74
BT-75
BT-76
BT-77
BT-78
BT-79
BT-80
BT-81
BT-82
BT-83
BT-84
BT-85
BT-86
BT-87
BT-88
BT-89
BT-90
BT-91
Verkäuferdaten
BT-27
BT-28
BT-29
BT-30
BT-31
BT-32
BT-33
BT-34
BT-35
BT-36
BT-37
BT-38
BT-39
BT-40
BT-41
BT-42
BT-43
BT-62
BT-63
BT-64
BT-65
BT-66
BT-67
BT-68
BT-69
Käuferdaten
BT-44
BT-45
BT-46
BT-47
BT-48
BT-49
BT-50
BT-51
BT-52
BT-53
BT-54
BT-55
BT-56
BT-57
BT-58
Nachlässe und Zuschläge
BT-92
BT-93
BT-94
BT-95
BT-96
BT-97
BT-98
BT-99
BT-100
BT-101
BT-102
BT-103
BT-104
BT-105
Steuern und Summen
BT-106
BT-107
BT-108
BT-109
BT-110
BT-111
BT-112
BT-113
BT-114
BT-115
BT-116
BT-117
BT-118
BT-119
BT-120
BT-121
BT-122
BT-123
BT-124
BT-125
Rechnungspositionen
BT-126
BT-127
BT-128
BT-129
BT-130
BT-131
BT-132
BT-133
BT-134
BT-135
BT-136
BT-137
BT-138
BT-139
BT-140
BT-141
BT-142
BT-143
BT-144
BT-145
BT-146
BT-147
BT-148
BT-149
BT-150
BT-151
BT-152
BT-153
BT-154
BT-155
BT-156
BT-157
BT-158
BT-159
BT-160
BT-161
BT-162
BT-163
ZUGFeRD Profile
MINIMUM
BASIC WL
BASIC
EN 16931
EXTENDED
Formate und Tools vergleichen
Vergleiche
XRechnung vs. ZUGFeRD
PDF24 Tools
sevDesk
Integrieren und umsetzen
Hilfe bei Plattformstörungen
Support
Vorübergehend nicht verfügbar
Fehlendes Ergebnis
Validierung nicht verfügbar
Browserfehler
Konto und Rate Limits
Guthaben und Abonnements
Behördliche Validierung
ERP-Export-Validierungsleitfäden
DATEV
Lexware
SAP Business One
Odoo
Microsoft Dynamics
Vertrauen und Sicherheit
Developer API
Rechnungen per E-Mail
  1. E-Rechnungs-Ressourcen
  2. Developer API
  3. Rechnungen per E-Mail

Integration · 2026-07-10

Markdown-Export

Rechnungen per E-Mail integrieren

Richten Sie einen verifizierten Absender ein, senden Sie an das formatspezifische Postfach aus Ihrem Profil und erhalten Sie nachweisgestützte Antworten im ursprünglichen Thread; nur wenn Anhänge das Größenlimit überschreiten, wird eine Antwort auf mehrere Nachrichten aufgeteilt.

Pro Konto freigeschalteter E-Mail-KanalAbsender vor der ersten Rechnung einrichtenZielformat über die Empfängeradresse wählenVom Eingang bis zur AntwortAbrechnungseinheiten und E-Mail-KontextEndzustände und ArtefakteAkzeptierte Dateien und Grenzen des PilotbetriebsWas weiterhin von Menschen geprüft werden mussE-Mail oder API bewusst wählenOnboarding und SupportAblaufdiagramme

Pro Konto freigeschalteter E-Mail-Kanal#

Nutzen Sie diesen Kanal für kontrollierte Rechnungsabläufe mit geringem Volumen.

Die Rechnungskonvertierung per E-Mail ist in der aktuellen Pilotphase nur für freigeschaltete Enterprise-Konten verfügbar. Erforderlich sind ein aktives Abonnement, ein aktivierter E-Mail-Import und mindestens ein verifizierter Absender.

Maßgeblich sind die formatspezifischen Postfachadressen in Ihrem Profil. Sie können je nach Umgebung abweichen; verwenden Sie deshalb immer die Adressen aus Ihrem Profil und übernehmen Sie keine Adresse fest aus Beispielen oder interner Dokumentation.

Verfügbarkeit

Freischaltung und Absenderverifizierung erfolgen im Onboarding. Ein normales Konto kann den Kanal nicht durch das bloße Senden einer E-Mail aktivieren.

Absender vor der ersten Rechnung einrichten#

Schließen Sie diese Schritte im Kontoprofil ab, bevor Sie Postfach- oder ERP-Regeln automatisieren.

  1. Lassen Sie den E-Mail-Kanal durch das Invoice-Converter-Team für Ihr Enterprise-Konto freischalten.
  2. Fügen Sie die Absenderadresse hinzu und bestätigen Sie sie über den Verifizierungslink, der an dieses Postfach gesendet wird.
  3. Legen Sie fest, ob Antworten an den ursprünglichen Absender oder an eine verifizierte Sammeladresse gehen, und wählen Sie die Antwortsprache.
  4. Kopieren Sie die XRechnung- und ZUGFeRD-Adressen aus dem Profil und testen Sie jede benötigte Route mit einer repräsentativen PDF-Datei.

Zielformat über die Empfängeradresse wählen#

ZielZu verwendende AdresseErfolgreiche Antwort
XRechnungDas XRechnung-Postfach im freigeschalteten Kontoprofil.Validierte XML-Datei plus artefaktgebundener HTML-Prüfbericht.
ZUGFeRD / Factur-XDas ZUGFeRD-Postfach im freigeschalteten Kontoprofil.Validierte hybride PDF/A-3-Datei plus artefaktgebundener HTML-Prüfbericht.

Vom Eingang bis zur Antwort#

Ihre Nachricht wird schnell angenommen; die strikte Konvertierung läuft anschließend asynchron, und die Ergebnisse kommen als Antwort zurück.

  1. Ein verifizierter Absender sendet echte PDF-Anhänge an ein oder mehrere formatspezifische Postfächer.
  2. Der E-Mail-Eingangsdienst erfasst die Nachricht; der Dienst ermittelt das freigeschaltete Konto, den Absender, das Antwortziel und die gewählten Zielformate.
  3. Jede akzeptierte PDF-Datei wird zu einem strikten Konvertierungsauftrag mit verpflichtender Artefaktvalidierung; eine Herabstufung auf Entwurf oder das Übergehen von Warnungen ist nicht möglich.
  4. Das angeforderte Ergebnis wird erst ausgestellt, nachdem autoritative Validierung, Nachweisspeicherung und Artefaktparität erfolgreich abgeschlossen sind.
  5. Antwortnachrichten im selben Thread enthalten die ausgestellten Artefakte und HTML-Berichte; überschreiten die Anhänge das Limit pro Nachricht, wird die Zustellung in weiteren Nachrichten fortgesetzt. Nachricht, Eintrag, Nutzungsereignis, Nachweis und dauerhaft gespeicherte Antwortdateien bleiben über IDs nachvollziehbar.

Abrechnungseinheiten und E-Mail-Kontext#

Berechnen Sie die Einheiten für die gesamte Nachricht vor dem Versand, und bedenken Sie, dass der E-Mail-Text selbst als Konvertierungseingabe gelesen wird.

  • Jede akzeptierte PDF-Datei verbraucht eine Konvertierungseinheit pro erkanntem Zielformat. Beispiel: Zwei PDF-Dateien an beide Formatpostfächer benötigen vier Einheiten.
  • Vor der Konvertierung reserviert der Dienst alle Einheiten der Nachricht: zuerst aus dem enthaltenen monatlichen Kontingent, danach aus vorhandenen API-Guthaben.
  • Reicht die Deckung nicht für alle Einheiten, wird die gesamte Nachricht vor der Konvertierung abgelehnt. Eine Einheit wird erst abgerechnet, wenn ihre Konvertierung erfolgreich war und die Antwortartefakte dauerhaft gespeichert sind; fehlgeschlagene Einheiten werden wieder freigegeben.
  • Wenn die E-Mail Text enthält, dienen Betreff und Text der verifizierten E-Mail als ergänzende Konvertierungseingabe. Sie können fehlende Änderungen, Korrekturen, Referenzen oder Rechnungsangaben liefern. Bei Widersprüchen haben Geldbeträge, Steuersummen und Rechnungspositionen aus der PDF-Datei Vorrang; allein aus dem E-Mail-Text entstehen keine Rechnungspositionen. Es wird nur eine begrenzte Menge Text gelesen und gegebenenfalls gekürzt; halten Sie Signaturen und Begleittext daher kurz, relevant und eindeutig.
  • Im Profil hinterlegte Verkäufer-Stammdaten ergänzen fehlende Verkäuferfelder (Name, Adresse, USt-IdNr., Kontakt), wenn die Standardnutzung aktiviert ist; aus der PDF-Datei extrahierte Werte werden nie überschrieben.

Endzustände und Artefakte#

ErgebnisInhalt der AntwortAnhänge
AusgestelltDie Datei wurde erfolgreich konvertiert und hat die autoritative Validierung bestanden.Angefordertes Hauptartefakt und zugehöriger HTML-Prüfbericht.
TeilweiseMindestens eine Datei wurde abgeschlossen und mindestens eine ist fehlgeschlagen oder wurde übersprungen.Nur nachweisgestützte Artefakte der erfolgreichen Dateien sowie der Status je Datei.
Validierung gestopptBlockierende Validierungsdetails erklären, warum kein Ergebnis ausgestellt wurde.Kein ungeprüftes Ergebnisartefakt und kein artefaktgebundener HTML-Bericht.
Technische AblehnungDie Antwort benennt das Problem: Absender, Datei, Berechtigung, Limit oder eine vorübergehende Störung.Kein Ergebnisartefakt; befolgen Sie die Hinweise in der Antwort, bevor Sie es erneut versuchen.

Akzeptierte Dateien und Grenzen des Pilotbetriebs#

Nutzen Sie diese Punkte als praktische Prüfschritte für diesen Abschnitt.

  • Hängen Sie echte PDF-Dateien an. Eine umbenannte Bilddatei oder ein anderer Dateityp wird abgelehnt, auch wenn Dateiendung oder MIME-Typ PDF vorgeben.
  • Eine Nachricht kann mehrere PDF-Dateien enthalten; der Kanal ist für kontrollierte Abläufe mit geringem Volumen gedacht, nicht für Massenimport.
  • Halten Sie jeden Anhang unter dem im Onboarding genannten Limit; Anbieter- und Umgebungsgrenzen können sich ändern.
  • Erreicht eine Nachricht mehrere erkannte Formatpostfächer, wird jede akzeptierte PDF-Datei einmal je gewähltem Format verarbeitet.
  • Antwortanhänge sind auf rund 15 MB pro Nachricht begrenzt. Würde die nächste Datei dieses Limit überschreiten, folgen die übrigen Anhänge in einer weiteren Nachricht desselben Threads; eine einzelne Datei wird nie aufgeteilt.

Was weiterhin von Menschen geprüft werden muss#

Nutzen Sie diese Punkte als praktische Prüfschritte für diesen Abschnitt.

  • Vergleichen Sie Lieferant, Käufer, Rechnungsnummer, Datumsangaben, Währung, Steuerbeträge, Summen, Zahlungsdaten und jede Position mit der Originalrechnung.
  • Prüfen Sie empfängerspezifische Leitweg- und Endpunktkennungen, Bestelldaten sowie Regeln des Übertragungskanals.
  • Prüfen Sie unsichere Quellenbelege und jede Warnung oder Validierungsangabe, bevor Sie das Ergebnis weiterleiten.
  • Eine erfolgreiche technische Validierung prüft die ausgestellte Datei gegen die gewählten Regeln; sie ersetzt keine kaufmännische, steuerliche oder empfängerseitige Freigabe.

E-Mail oder API bewusst wählen#

KanalGeeignet fürIntegrationskontrolle
E-Mail-KanalManuell betriebene Abläufe oder Postfachregeln mit geringem Volumen, bei denen ein Antwortthread nützlich ist.Formatpostfach, verifizierter Absender, Rücksendeadresse, Sprache und Ergebnis je Nachricht.
External API V1Server-zu-Server-Abläufe mit Idempotenz, Polling, strukturiertem Status und gezieltem Download.Authentifizierte Anfragen, Kundenreferenzen, Korrelations-IDs, Rate-Limit-Header und Artefakt-Endpunkte.

Onboarding und Support#

Teilen Sie im Onboarding die erwarteten Absenderadressen, Zielformate, das Antwortziel, die Sprache und das Monatsvolumen mit.

Dokumentation der External API V1 ansehen
Onboarding für den E-Mail-Kanal anfragen

Ablaufdiagramme#

Die Diagramme fassen dieselben Regeln wie die durchsuchbaren Abschnitte oben zusammen.

Was in die Konvertierung einfließt und was Sie zurückerhalten

Was einfließt

  • PDF-Anhang

    Primärquelle

    Wird sowohl über die Textebene als auch per OCR gelesen. Geldbeträge, Steuersummen und Rechnungspositionen stammen immer aus der PDF-Datei.

  • Betreff und Text der E-Mail

    Ergänzend

    Verifizierter E-Mail-Text kann Referenzen, Korrekturen und fehlende Angaben liefern. Er übersteuert nie Beträge aus der PDF-Datei und kann keine Rechnungspositionen erzeugen.

  • Stammdaten aus dem Profil

    Füllt Lücken

    Im Profil hinterlegte Verkäufer-Stammdaten (Name, Adresse, USt-IdNr., Kontakt) ergänzen fehlende Verkäuferfelder, wenn die Standardnutzung aktiviert ist; extrahierte Werte werden nicht überschrieben.

Strikte Konvertierung

Extraktion, Anreicherung und autoritative Validierung mit Nachweis- und Paritätsprüfung.

Was Sie zurückerhalten

  • Validiertes Artefakt

    XRechnung-XML oder hybride ZUGFeRD-/Factur-X-Datei (PDF/A-3), je nach verwendetem Postfach.

  • HTML-Prüfbericht

    Der artefaktgebundene Bericht belegt die Validierung genau der gelieferten Datei.

  • Antwort in Ihrem Thread

    Alles kommt als Antwort auf Ihre ursprüngliche Nachricht an.

Vom Postfach zur geprüften Antwort

  1. 1

    Verifizierter Absender

    Ein freigeschaltetes Konto sendet echte PDF-Dateien.

  2. 2

    Formatpostfach

    Die Empfängeradresse bestimmt das Zielformat: XRechnung oder ZUGFeRD.

  3. 3

    Strikter Auftrag

    Extraktion und Erzeugung laufen ohne Herabstufung auf Entwurf.

  4. 4

    Nachweisprüfung

    Validierung, Nachweisspeicherung und Paritätsprüfung müssen erfolgreich sein.

  5. 5

    Antwort im Thread

    Artefakt und Bericht kommen in einer oder mehreren Nachrichten; zu große Sendungen werden im selben Thread fortgesetzt.

Jeder Endzustand

Ergebnis der strikten Konvertierung
  • Ausgestellt

    Artefakt plus Bericht

    Es werden nur validierte, nachweisgestützte Dateien angehängt.

  • Teilweise

    Erfolgreiche Dateien werden trotzdem geliefert

    Fertige Artefakte und Fehlermeldungen je Datei stehen im selben Antwortthread.

  • Validierung gestoppt

    Details, kein Artefakt

    Blockierende Regeln verhindern die Ausgabe ungeprüfter Ergebnisse.

  • Technische Ablehnung

    Klare Hinweise für den nächsten Versuch

    Die Antwort erklärt, was Sie vor einem neuen Versuch korrigieren müssen.

Developer API
Auf dieser Seite
Pro Konto freigeschalteter E-Mail-KanalAbsender vor der ersten Rechnung einrichtenZielformat über die Empfängeradresse wählenVom Eingang bis zur AntwortAbrechnungseinheiten und E-Mail-KontextEndzustände und ArtefakteAkzeptierte Dateien und Grenzen des PilotbetriebsWas weiterhin von Menschen geprüft werden mussE-Mail oder API bewusst wählenOnboarding und SupportAblaufdiagramme

Invoice-Converter.com

Wir helfen Unternehmen in ganz Europa, Rechnungen mit Validierungsunterstützung in XRechnung und andere E-Rechnungsformate umzuwandeln. Prüfen Sie Grenzfälle vor der Einreichung.

20.000+ Rechnungen verarbeitet
Schnell & Sicher
Hunderte zufriedene Kunden

Funktionen

PDF umwandeln & erstellen

  • PDF zu XRechnung
  • PDF zu UBL
  • PDF zu XRechnung (CII)
  • PDF zu ZUGFeRD
  • PDF zu Factur-X
  • XRechnung erstellen
  • XRechnung zu PDF

Ansehen & validieren

  • XRechnung/XML Viewer
  • XRechnung Validator

Schnellzugriff

  • Ressourcen
  • Vertrauens- und Sicherheitscenter
  • Developer-API-Dokumentation
  • Blog
  • FAQ
  • Preise
  • Klimabeitrag

Rechtliches

  • Impressum
  • Datenschutz
  • Auftragsverarbeitungsvertrag
  • AGB
  • Geld-zurück-Garantie

Kontakt aufnehmen

contact@invoice-converter.com
Jetzt umwandeln
© 2026 Invoice-Converter.com.Gemacht mit in Europa
DSGVO-konform
Deutsche Server