E-Rechnung Gateway-Lösung vs. Buchhaltungssoftware
Hallo zusammen,
wir stehen aktuell vor der Entscheidung, wie wir die Pflicht zur E-Rechnung (insbesondere für den Versand an öffentliche Auftraggeber und für den grenzüberschreitenden B2B-Handel) technisch umsetzen sollen.
Unser bisheriger Stand:
Die Buchhaltung erfolgt aktuell nicht über eine klassische Software, sondern wir pflegen alle Daten (Ein- und Ausgangsrechnungen) über eine eigene Access-Datenbank.
Die erzeugten Rechnungen sind als strukturierte Daten vorhanden.
Unser Ziel: eine möglichst automatisierte, revisionssichere und Peppol-konforme E-Rechnungserstellung und -versandlösung.
Wir vergleichen aktuell zwei Varianten:
✅ Variante A – Gateway-Lösung (z. B. B2Router):
SFTP oder API-Anbindung an Access möglich
Validierung + Versand via Peppol integriert
Einmalige Einrichtungskosten + jährliche Gebühr
Kein Buchhaltungsmodul, reine technische Lösung
✅ Variante B – Softwarelösung mit API (z. B. sevDesk, Lexware XL):
Teilweise günstiger (keine Einrichtungskosten, Abo-Modell)
REST-API verfügbar, aber keine native Access-Schnittstelle
Kein Peppol-Zugang → Drittanbieter notwendig
Fokus auf Kleinunternehmer-Use-Cases mit integrierter Buchhaltung
❓ Meine Fragen an euch:
Was würdet ihr aus technischer Sicht für ein mittelständisches Unternehmen mit eigener Datenbankstruktur empfehlen?
Hat jemand Erfahrungen mit der Anbindung von Access an sevDesk oder Lexware per API oder CSV-Workflow?
Lohnt sich eurer Meinung nach der Mehraufwand + Einrichtungskosten für eine Gateway-Lösung langfristig – oder sind Tools wie sevDesk technisch „gut genug“?
Ich freue mich sehr über eure Erfahrungen, Einschätzungen und ggf. auch Warnungen.
Danke vorab & viele Grüße
Anna
DEAM GmbH & Co. KG
wir stehen aktuell vor der Entscheidung, wie wir die Pflicht zur E-Rechnung (insbesondere für den Versand an öffentliche Auftraggeber und für den grenzüberschreitenden B2B-Handel) technisch umsetzen sollen.
Unser bisheriger Stand:
Die Buchhaltung erfolgt aktuell nicht über eine klassische Software, sondern wir pflegen alle Daten (Ein- und Ausgangsrechnungen) über eine eigene Access-Datenbank.
Die erzeugten Rechnungen sind als strukturierte Daten vorhanden.
Unser Ziel: eine möglichst automatisierte, revisionssichere und Peppol-konforme E-Rechnungserstellung und -versandlösung.
Wir vergleichen aktuell zwei Varianten:
✅ Variante A – Gateway-Lösung (z. B. B2Router):
SFTP oder API-Anbindung an Access möglich
Validierung + Versand via Peppol integriert
Einmalige Einrichtungskosten + jährliche Gebühr
Kein Buchhaltungsmodul, reine technische Lösung
✅ Variante B – Softwarelösung mit API (z. B. sevDesk, Lexware XL):
Teilweise günstiger (keine Einrichtungskosten, Abo-Modell)
REST-API verfügbar, aber keine native Access-Schnittstelle
Kein Peppol-Zugang → Drittanbieter notwendig
Fokus auf Kleinunternehmer-Use-Cases mit integrierter Buchhaltung
❓ Meine Fragen an euch:
Was würdet ihr aus technischer Sicht für ein mittelständisches Unternehmen mit eigener Datenbankstruktur empfehlen?
Hat jemand Erfahrungen mit der Anbindung von Access an sevDesk oder Lexware per API oder CSV-Workflow?
Lohnt sich eurer Meinung nach der Mehraufwand + Einrichtungskosten für eine Gateway-Lösung langfristig – oder sind Tools wie sevDesk technisch „gut genug“?
Ich freue mich sehr über eure Erfahrungen, Einschätzungen und ggf. auch Warnungen.
Danke vorab & viele Grüße
Anna
DEAM GmbH & Co. KG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673663
Url: https://administrator.de/forum/e-rechnung-gateway-buchhaltung-mittelstand-673663.html
Ausgedruckt am: 04.07.2025 um 18:07 Uhr
7 Kommentare
Neuester Kommentar
Ich denke, es kommt auf den Umfang an. Die Frage ist da, ob es diese Software-Anbieter, die ja zum Teil für kleinere Unternehmen ausgelegt sind, mit einer Masse an Rechnungen umgehen kann.
Insgesamt sind das so Fire-and-Forget-Lösungen. Wenn das passt und da die zusätzliche Middleware für Peppol auch damit kann, dann stünde dem ja nix dagegen. Du hast da aber dann gleich 3 Bruchstellen. sevDask-ähnliches Zeugs, dat Ding für Peppol und schlussendlich deine Datenbank.
Von daher würde ich wohl eher soviel in einer Hand haben wollen, wie geht. B2BRouter sieht ja nicht schlecht aus. Hab da aber keine Erfahrungswerte, weil ausschließlich B2C.
Ich würde ehrlich gesagt erst mal das ERP bzw. Warenwirtschaftssystem angehen. Die sind ja, in meinen Augen, als erstes für den E-Rechnungs-Sums zuständig. Da fällt dann auch Middleware und so weg.
Insgesamt sind das so Fire-and-Forget-Lösungen. Wenn das passt und da die zusätzliche Middleware für Peppol auch damit kann, dann stünde dem ja nix dagegen. Du hast da aber dann gleich 3 Bruchstellen. sevDask-ähnliches Zeugs, dat Ding für Peppol und schlussendlich deine Datenbank.
Von daher würde ich wohl eher soviel in einer Hand haben wollen, wie geht. B2BRouter sieht ja nicht schlecht aus. Hab da aber keine Erfahrungswerte, weil ausschließlich B2C.
Ich würde ehrlich gesagt erst mal das ERP bzw. Warenwirtschaftssystem angehen. Die sind ja, in meinen Augen, als erstes für den E-Rechnungs-Sums zuständig. Da fällt dann auch Middleware und so weg.
Ich schließe mich @kpunkt an, die Menge an Rechnungen wäre definitiv interessant. Aber mich wundert ein wenig die vorhandene Lösung. Ich habe großen Respekt vor Eigenbau ERP Lösungen, ich will da nichts schlecht machen. Dennoch muss man sich die Frage gefallen lassen, ob Access so eine gute Idee ist. Was genau passiert denn da und wieso passiert es nicht in einem vollwertigen DBMS, z.B. zumindest ein MSSQL als Backend für ein Access Frontend? Also eventuell doch nochmal einen Schritt zurück schauen ob es sinnvoll ist, größere Änderungen im Prozess davor umzusetzen.
Wir haben leider ebenfalls eine sehr antiquierte Fakturierungslösung, die sich auch nicht einfach ändern lässt. Der Umbruch wird kommen aber ist noch ein paar Jahre entfernt. Wir haben für den Rechnungsversand eine Portallösung im TRAFFIQX Netzwerk, das funktioniert ganz okay. Da testen wir zur Zeit per OCR die E-Rechnungsdaten zu ermitteln und dann nach ZUGFeRD zu konvertieren, alles andere als Ideal. Ich weiß aber, das die auch strukturierte Daten entgegen nehmen könnten. Könnte ich diese selbstständig auslesen, so wie ihr es scheinbar könntet, dann gäbe es aber sicher auch Möglichkeiten, sich selbst eine X-Rechnung oder ZUGFeRD zusammen zu bauen.
Wir haben leider ebenfalls eine sehr antiquierte Fakturierungslösung, die sich auch nicht einfach ändern lässt. Der Umbruch wird kommen aber ist noch ein paar Jahre entfernt. Wir haben für den Rechnungsversand eine Portallösung im TRAFFIQX Netzwerk, das funktioniert ganz okay. Da testen wir zur Zeit per OCR die E-Rechnungsdaten zu ermitteln und dann nach ZUGFeRD zu konvertieren, alles andere als Ideal. Ich weiß aber, das die auch strukturierte Daten entgegen nehmen könnten. Könnte ich diese selbstständig auslesen, so wie ihr es scheinbar könntet, dann gäbe es aber sicher auch Möglichkeiten, sich selbst eine X-Rechnung oder ZUGFeRD zusammen zu bauen.
Die TRAFFIQX Plattformen sind schon etwas altbacken, aber die Funktionalität ist ganz gut. Da geht es nicht so sehr um schicke SaaS GUI sondern um Schnittstellen und Konverter. Grade bei B2G oder B2B in bestimmte Branchen wie z.B. Autozulieferer wird es dort spannend. Da spielen die Kosten gar nicht mehr so die Rolle, wenn da die Rechnungen nicht in Format Y vorliegen, bist du da nicht mehr Zulieferer.
Wir entwickeln selbst ERP-Software und setzen dazu die Firebird-Datenbank ein. Kann aber auch sagen, dass unser Entwickler viel Zeit reingesteckt hat damit die Implementierung von Faktur-X ausgereift ist. Er selbst hat da noch Punkte gefunden, die vom Gesetzgeber für die Verarbeitung gar nicht berücksichtigt wurden wie z.B. der Umgang mit Anzahlungsrechnungen und glaub auch Gutschriften...
Daher als Tipp: Augen auf bei der Wahl von ERP-Systemen. Es wird leider oft zu viel versprochen was noch gar nicht eingebaut ist... (hatten wir auch neulich bei der Präsentation einer DMS-Software)
Daher als Tipp: Augen auf bei der Wahl von ERP-Systemen. Es wird leider oft zu viel versprochen was noch gar nicht eingebaut ist... (hatten wir auch neulich bei der Präsentation einer DMS-Software)
Nur so als Gedankengang: de Treiber ist der, weswegen du hier die Frage stellst.
Ich sag mal so, wenn eine gesetzliche Anforderung an einen Prozess nicht ausreicht, über den Wechsel des ERP nachzudenken, dann wüsste ich jetzt nicht wirklich, was da dem/der/den CEO dazu bewegen würde, Geld in die Hand zu nehmen.
Ich sag mal so, wenn eine gesetzliche Anforderung an einen Prozess nicht ausreicht, über den Wechsel des ERP nachzudenken, dann wüsste ich jetzt nicht wirklich, was da dem/der/den CEO dazu bewegen würde, Geld in die Hand zu nehmen.