02.07.2025
1545
8
0E-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
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte 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: 08.07.2025 um 13:07 Uhr
8 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.
Vielen Dank euch beiden für eure fundierten Rückmeldungen – das hilft mir wirklich weiter, die Lage nochmals klarer zu betrachten.
Ich sehe das mit den drei Bruchstellen genauso: Wenn Access, ein externes Buchhaltungstool und ein Peppol-Dienstleister unabhängig voneinander betrieben werden, entstehen schnell technische und organisatorische Risiken – insbesondere bei Wartung, Automatisierung und Zuständigkeiten.
Die Empfehlung, in Richtung ERP oder vollwertiges DBMS zu denken, ist absolut nachvollziehbar – auch wenn das bei uns aktuell noch nicht realistisch erscheint. Unsere Access-Lösung ist historisch gewachsen, bildet unsere Prozesse inzwischen sehr passgenau ab und wird aktiv gepflegt. Natürlich ist mir bewusst, dass Access auf Dauer keine tragfähige Datenbanklösung ist – aber derzeit fehlt der konkrete Treiber für eine ERP-Umstellung im Unternehmen.
Genau deshalb suchen wir eine Lösung, die ohne Systemwechsel funktioniert, aber trotzdem stabil, automatisierbar und zukunftsoffen ist. B2Router scheint hier also ein sinnvoller Mittelweg zu sein: Die Anbindung per API ist gegeben, die Validierung und der Versand über Peppol sind zuverlässig integrierbar – und wir behalten den Prozess größtenteils in unserer Hand, ohne drei separate Systeme pflegen zu müssen.
Danke nochmals für eure Einschätzungen und auch für den Hinweis zu TRAFFIQX – sehr spannend, das werde ich mir parallel anschauen!
Ich sehe das mit den drei Bruchstellen genauso: Wenn Access, ein externes Buchhaltungstool und ein Peppol-Dienstleister unabhängig voneinander betrieben werden, entstehen schnell technische und organisatorische Risiken – insbesondere bei Wartung, Automatisierung und Zuständigkeiten.
Die Empfehlung, in Richtung ERP oder vollwertiges DBMS zu denken, ist absolut nachvollziehbar – auch wenn das bei uns aktuell noch nicht realistisch erscheint. Unsere Access-Lösung ist historisch gewachsen, bildet unsere Prozesse inzwischen sehr passgenau ab und wird aktiv gepflegt. Natürlich ist mir bewusst, dass Access auf Dauer keine tragfähige Datenbanklösung ist – aber derzeit fehlt der konkrete Treiber für eine ERP-Umstellung im Unternehmen.
Genau deshalb suchen wir eine Lösung, die ohne Systemwechsel funktioniert, aber trotzdem stabil, automatisierbar und zukunftsoffen ist. B2Router scheint hier also ein sinnvoller Mittelweg zu sein: Die Anbindung per API ist gegeben, die Validierung und der Versand über Peppol sind zuverlässig integrierbar – und wir behalten den Prozess größtenteils in unserer Hand, ohne drei separate Systeme pflegen zu müssen.
Danke nochmals für eure Einschätzungen und auch für den Hinweis zu TRAFFIQX – sehr spannend, das werde ich mir parallel anschauen!
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)
Ja alle Anbieter von E-Rechnung haben da noch Lücken. Wir hatten uns auch einige Lösungen angeschaut (nicht nur für uns selbst). Gut, dass noch etwas Zeit eingeräumt wurde denn da geht meist noch nicht viel. Das betrifft auch die SaaS-Plattformen.
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.
Zitat von @kpunkt:
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.
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.
Sicher sind gesetliche Vorgaben der eigentliche Treiber, das bedeutet jedoch nicht, dass der Geschäftsleitung bewusst ist, warum digitale Modernisierung wichtig für das Unternehmen ist. Ganz nach dem Motto: Läuft ja alles und Wandel bedeutet eben Prozesse neu abzubilden, das erscheint hier (und sicher auch anderswo) unangenehm.
