E-Rechnung ohne Systemwechsel: HubSpot, Stripe, Shopify & Co. weiter nutzen?

E-Rechnung klingt für viele Unternehmen sofort nach Systemprojekt. Neues ERP, neue Faktura, neue Schnittstellen, neues Budget, neue Abstimmungsrunden. Das ist manchmal richtig. Aber oft ist es zu früh.

In vielen Fällen funktioniert der operative Ablauf bereits: Leads, Angebote, Bestellungen, Abos, Leistungen und Zahlungen laufen in bestehenden Systemen. Das Problem entsteht nicht unbedingt in HubSpot, Stripe, Shopify, Pipedrive, Salesforce, monday.com, einer PSA-Lösung oder einer Branchenanwendung. Es entsteht am Ende: beim Rechnungsoutput.

Wenn dort nur ein PDF, ein E-Mail-Anhang, ein Portaldownload oder ein unstrukturierter Export herauskommt, kann der Prozess fachlich funktionieren und trotzdem nicht als strukturierter E-Rechnungsprozess ausreichen.

Gute Systeme können trotzdem eine Output-Lücke haben

Ein CRM ist kein E-Rechnungsstandard. Ein Payment- oder Billing-System ist nicht automatisch eine deutsche E-Rechnungsstrategie. Ein Shopsystem kann Bestellungen, Steuern und Kundenkommunikation abbilden, ohne dass der finale Rechnungsoutput genau dem benötigten strukturierten Format entspricht.

Das ist kein Vorwurf an diese Systeme. Es ist eine Frage des Einsatzkontexts.

HubSpot dokumentiert Rechnungsfunktionen und weist zugleich darauf hin, dass Rechnungsanforderungen je nach Land variieren können. Stripe Invoicing unterstützt Rechnungen über Dashboard und API. Shopify beschreibt VAT-Invoice-Flows für EU/UK und PDF-basierte Kundenabläufe. Das zeigt: Rechnungsfunktionen sind vorhanden. Es beweist aber nicht automatisch, dass jeder konkrete deutsche B2B-E-Rechnungsfall fertig gelöst ist.

Deshalb sollte die Frage nicht lauten: „Ist System X gut oder schlecht?“
Sie sollte lauten: „Was erzeugt unser konkreter Prozess am Ende – und reicht dieser Output für das benötigte E-Rechnungsformat?“

Warum Systemwechsel oft die falsche erste Reaktion ist

Ein bestehendes System enthält mehr als nur eine Rechnungsschaltfläche. Dort liegen Kundendaten, Produkte, Preise, Rabatte, Verträge, Zahlungslogik, Workflows, Freigaben, Automationen und interne Gewohnheiten.

Wer wegen eines Output-Problems sofort das System ersetzt, kann ein Formatproblem lösen und gleichzeitig neue Prozessprobleme schaffen.

Natürlich gibt es Fälle, in denen Migration sinnvoll ist. Wenn Stammdaten falsch sind, Pflichtangaben fehlen, Steuern manuell korrigiert werden oder Rechnungen nur mit Workarounds entstehen, sollte das Quellsystem geprüft werden. Aber wenn das System fachlich korrekte Rechnungen erzeugt und lediglich der finale Output unstrukturiert ist, kann ein kleinerer Weg sinnvoller sein.

Der Ausgangspunkt ist dann nicht Migration. Der Ausgangspunkt ist Output-Prüfung.

Die fünf Fragen vor jeder Systementscheidung

Bevor Sie ein ERP-, Billing- oder Shop-Projekt starten, prüfen Sie diese fünf Fragen.

1. Sind die fachlichen Rechnungsdaten vollständig?

Hat das System Verkäufer, Käufer, Rechnungsnummer, Rechnungsdatum, Leistungszeitraum, Positionen, Steuern, Summen und Zahlungsinformationen vollständig und konsistent? Wenn die Daten schon im System fehlen, löst eine Output-Schicht das nicht vollständig.

2. Wie entsteht der finale Rechnungsoutput?

Wird eine PDF-Datei generiert? Gibt es eine gehostete Rechnung? Wird eine E-Mail versendet? Gibt es einen Export oder eine API? Der relevante Prüfpunkt ist nicht nur das System, sondern der konkrete Ausgangskanal.

3. Bleibt das Layout oder Datenmodell stabil?

Wiederkehrende Layouts sind leichter zu aktivieren als ständig wechselnde Sonderfälle. Mehrere Marken, Länder, Rechnungstypen oder Templates können zusätzliche Prüfung erfordern.

4. Welches Zielformat wird benötigt?

Wenn der Empfänger XRechnung verlangt, ist eine andere Umsetzung nötig als bei einem ZUGFeRD-fähigen Prozess. Die Formatentscheidung gehört vor die technische Umsetzung.

5. Was soll nach der Erstellung passieren?

Reicht Download oder Ablage? Muss die E-Rechnung an Buchhaltung, DMS, ERP, Kundenportal oder ein anderes Zielsystem übergeben werden? Die Übergabe ist wichtig, aber sie sollte nicht vor der Output-Qualität geplant werden.

Beispiele: Was bei HubSpot, Stripe, Shopify & Co. zu prüfen ist

Bei CRM-nahen Systemen wie HubSpot ist häufig die Frage, ob Angebot, Deal, Unternehmen, Kontakt, Steuern und Rechnungsdaten vollständig im Rechnungsoutput landen. Wenn die Rechnung aus einem Quote- oder Deal-Prozess entsteht, sollte geprüft werden, ob alle Pflichtdaten und Positionen in der finalen Datei sauber enthalten sind.

Bei Billing- und Payment-Systemen wie Stripe ist relevant, ob wiederkehrende Zahlungen, Abos, Steuern, Rechnungsnummern, Kundendaten und PDF-/Hosted-Invoice-Ausgaben so zusammenspielen, dass ein strukturiertes Zielformat abgeleitet werden kann. API-Verfügbarkeit ist hilfreich, ersetzt aber nicht die fachliche Prüfung des Outputs.

Bei Commerce-Systemen wie Shopify geht es oft um Bestellungen, VAT-Logik, Kundeninformationen, PDF-Rechnungen, Apps und E-Mail-Flows. Hier sollte geprüft werden, ob B2B-spezifische Daten vollständig vorhanden sind und ob der Rechnungsoutput für das Zielformat reicht.

Bei PSA-, Projekt- oder Work-Management-Systemen stehen Leistungszeiträume, Projekte, Zeiten, Pauschalen, Abschläge und Freigaben im Vordergrund. Diese Daten müssen im Output nachvollziehbar sein, wenn daraus eine strukturierte E-Rechnung werden soll.

Der ValiMesh-Ansatz: bestehendes System behalten, Output prüfen

ValiMesh setzt nicht am Austausch des Quellsystems an. Der Ansatz lautet:

Bestehendes System → realer Rechnungsoutput → ValiMesh-Prüfung → strukturierter E-Rechnungsoutput

Der erste Schritt ist eine echte Rechnung aus dem laufenden Prozess. Kein Idealbeispiel, keine manuell optimierte Demo-Datei, sondern der Output, der wirklich beim Kunden ankommt.

Diese Datei zeigt, ob die relevanten Informationen vorhanden sind, ob das Layout stabil ist und ob ein Weg in XRechnung oder ZUGFeRD realistisch erscheint. Wenn der Output geeignet ist, kann ein wiederkehrender Prozess vorbereitet werden. Wenn nicht, zeigt der Test, ob Daten im Quellsystem ergänzt, Templates angepasst oder der Prozess anders geführt werden muss.

So wird aus „Brauchen wir ein neues System?“ eine präzisere Frage: „Ist unser heutiger Output gut genug?“

Wann Systemwechsel trotzdem sinnvoll sein kann

Es wäre unseriös zu behaupten, Systemwechsel sei nie nötig. Es gibt Situationen, in denen das bestehende System tatsächlich nicht mehr passt:

● Pflichtdaten fehlen dauerhaft oder können nicht gepflegt werden.

● Steuerlogik und Summen müssen regelmäßig manuell korrigiert werden.

● Rechnungstemplates wechseln unkontrolliert.

● Mehrere Teams erzeugen Rechnungen ohne gemeinsamen Prozess.

● Der gewünschte Folgeprozess braucht Daten, die im Quellsystem nicht vorhanden sind.

● Strategisch ist ohnehin eine Konsolidierung der Systemlandschaft geplant.

Auch dann ist ein Output-Test sinnvoll. Er macht sichtbar, welche Lücken technisch und fachlich bestehen. Aber die Schlussfolgerung kann dann lauten: Zuerst Quellsystem oder Prozess verbessern, dann E-Rechnungsoutput stabilisieren.

Entscheidungshilfe: behalten, ergänzen oder ersetzen?

Diese Matrix schützt vor pauschalen Entscheidungen. Nicht jedes PDF-Problem ist ein ERP-Problem. Aber auch nicht jedes ERP-Problem lässt sich mit einem PDF-Konverter lösen.

Fazit: Erst Output prüfen, dann über Migration sprechen

E-Rechnung ohne Systemwechsel bedeutet nicht „ohne Prüfung“. Es bedeutet: Bevor ein funktionierendes System ersetzt wird, sollte der konkrete Rechnungsoutput bewertet werden.

HubSpot, Stripe, Shopify und andere Systeme können wichtige Teile des Prozesses abbilden. Entscheidend ist aber, was am Ende entsteht und ob daraus ein strukturierter E-Rechnungsoutput in XRechnung oder ZUGFeRD werden kann.

ValiMesh hilft, diese Frage pragmatisch zu beantworten: echtes PDF testen, Output-Lücke erkennen, nächste Maßnahme ableiten. Erst danach lohnt sich die größere Diskussion über Systemwechsel, Integration oder Migration.