Eigene Schnittstelle entwickeln lassen — wenn kein Plugin deinen Ablauf kennt.

Wann es sich lohnt.

• Abonnements und Ratenzahlungen, bei denen aus einer Bestellung viele Belege werden (Abos).
• Teillieferungen, die Teilrechnungen erzeugen.
• Mehrere Marken oder Mandanten, die getrennt gebucht werden müssen.
• Eigene Preis- oder Rabattlogik, etwa im Großhandel (B2B).
• Eine Warenwirtschaft dazwischen, die den eigentlichen Beleg erzeugt.
• Sehr viele Bestellungen, bei denen ein Standardwerkzeug an Grenzen stößt.
• Eine Software, für die es schlicht keine fertige Verbindung gibt.

Der Vergleichsmaßstab ist nicht „Plugin kostet wenig, Entwicklung kostet mehr“, sondern die Summe aus Werkzeugkosten und dem monatlichen Aufwand für Nacharbeit. Wenn jemand jeden Monat einen Tag mit Korrekturen verbringt, ist die Rechnung schnell gemacht.

Wann nicht.

Ich sage es auch, wenn sich der Aufwand nicht lohnt. Bei einem Standardshop mit gewöhnlichem Sortiment, überschaubaren Mengen und einer verbreiteten Buchhaltungssoftware ist ein fertiges Plugin die richtige Wahl — da baue ich nichts dazu.

Ebenso, wenn die Abläufe selbst noch nicht geklärt sind. Eine Schnittstelle macht einen unklaren Prozess nicht klarer, sie zementiert ihn. Dann ist der erste Schritt ein Gespräch mit dem Steuerberater, nicht ein Entwicklungsauftrag (Reihenfolge beim Automatisieren).

Was dazugehört.

Die ersten beiden Zeilen sind das, woran die meisten denken. Die restlichen sechs machen den Unterschied zwischen etwas, das im Test funktioniert, und etwas, das im Alltag trägt.

Warteschlange und Wiederholung.

Eine Übertragung darf nie direkt im Bestellvorgang laufen. Wenn das fremde System langsam antwortet oder gerade nicht erreichbar ist, würde sonst die Kasse hängen — im schlimmsten Fall bricht der Kauf ab.

Richtig ist: Die Bestellung wird in eine Warteschlange gelegt, und ein eigener Vorgang arbeitet sie ab. Scheitert eine Übertragung, wird sie mit wachsendem Abstand erneut versucht. Erst nach mehreren Fehlversuchen gilt sie als gescheitert und löst eine Meldung aus.

Wichtig ist dabei, dass ein Vorgang nicht doppelt ankommt. Dafür bekommt jede Übertragung ein eindeutiges Merkmal, und vor dem Anlegen wird geprüft, ob es den Beleg schon gibt — sonst erzeugt ein Wiederholungsversuch nach einer Zeitüberschreitung eine zweite Rechnung.

Protokoll und Überwachung.

Zu jedem Vorgang gehört ein Eintrag: Zeitpunkt, was übertragen wurde, Antwort des anderen Systems, Ergebnis. Das ist nicht nur für die Fehlersuche wichtig, sondern auch, um nachweisen zu können, dass und wann etwas übergeben wurde.

Dazu eine aktive Benachrichtigung bei Fehlern und ein regelmäßiger Mengenabgleich: Wie viele Bestellungen gab es, wie viele Belege sind entstanden? Diese Zahl einmal im Monat anzusehen, fängt fast jeden stillen Ausfall ab.

Testbarkeit.

Die Schnittstelle muss sich gegen eine Testumgebung betreiben lassen — sowohl auf Shopseite als auch, wenn möglich, auf Seiten der Buchhaltung. Dazu gehört ein Schalter, der klar macht, in welchem Modus gearbeitet wird, und ein Schutz davor, aus der Testumgebung versehentlich in die echte Buchhaltung zu schreiben.

Das klingt banal und ist einer der häufigsten Schäden: Testbestellungen in der echten Buchhaltung, die dann einzeln aufgeräumt werden müssen (Staging einrichten).

Zugangsdaten und Sicherheit.

Die Schnittstelle hat Zugriff auf Umsatz- und Kundendaten. Entsprechend gehören die Zugangsschlüssel nicht in den Quelltext und nicht in die Datenbank im Klartext, sondern in die Serverkonfiguration. Der Zugriff sollte so eng wie möglich berechtigt sein.

Dazu kommt der Datenschutz: Es werden personenbezogene Daten an einen Dienstleister übermittelt, was in das Verarbeitungsverzeichnis gehört und je nach Konstellation einen Vertrag zur Auftragsverarbeitung erfordert (Kundendaten und DSGVO).

Betrieb und Wartung.

Eine Schnittstelle ist nicht fertig, wenn sie läuft. Die Gegenseite ändert ihre Programmierschnittstelle, der Shop bekommt Updates, PHP-Versionen wechseln, und dein Geschäft entwickelt sich. Rechne mit gelegentlicher Anpassung und plane, wer sich darum kümmert.

Ich übernehme das auf Wunsch im Rahmen der laufenden Betreuung — dann wird die Schnittstelle mitüberwacht und bei Änderungen nachgezogen (WooCommerce-Wartung).

Ablauf eines Projekts.

1. Gespräch: Was läuft heute, wo ist die Handarbeit, welche Sonderfälle gibt es?
2. Abstimmung mit dem Steuerberater: Zuordnung, Konten, Steuerschlüssel.
3. Konzept: Datenströme, Auslöser, Fehlerbehandlung — schriftlich, bevor gebaut wird.
4. Umsetzung in einer Testumgebung.
5. Test mit deiner Fallliste, inklusive Storno und Auslandsfällen.
6. Parallelbetrieb für einige Wochen mit Stichproben.
7. Übergabe mit Dokumentation und einer kurzen Einweisung.

Schritt zwei ist der, der am häufigsten übersprungen wird, und der, der am meisten Nacharbeit erspart.

Was ich von dir brauche.

• Womit buchst du, und wie viele Bestellungen kommen im Monat zusammen?
• Welche Zahlungsarten nutzt du?
• Verkaufst du ins Ausland, an Geschäftskunden, mit Abos?
• Gibt es eine Warenwirtschaft oder andere Systeme?
• Was genau machst du heute von Hand — und wie lange dauert das?
• Was hat dein Steuerberater zur Zuordnung gesagt?

Mit diesen Angaben kann ich dir ziemlich genau sagen, ob ein fertiges Werkzeug reicht und, wenn nicht, was eine eigene Lösung umfasst. Diese Einschätzung kostet dich nichts.

Wenn du nicht weiterkommst.

Wenn du den Verdacht hast, dass dein Ablauf zu eigen für ein Standardwerkzeug ist. Ich richte die Verbindung ein, teste sie mit echten Bestellungen und zeige dir, woran du erkennst, dass sie läuft: WooCommerce-Support. Soll die Übertragung dauerhaft überwacht werden, geht das über die WooCommerce-Wartung. Passt kein fertiges Werkzeug, baue ich die Verbindung selbst: eigene Schnittstelle entwickeln lassen.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich baue und repariere WordPress- und WooCommerce-Systeme und verbinde sie mit anderer Software — Buchhaltung, Warenwirtschaft, Versand. Was ich dabei mache, ist die technische Seite: Daten sauber aus dem Shop holen, richtig zuordnen, zuverlässig übertragen und nachvollziehbar protokollieren.

Was ich ausdrücklich nicht mache: steuerliche Beratung. Welches Konto bebucht wird, wie Steuersätze bei deinem Geschäftsmodell anzusetzen sind und was dein Steuerberater für den Jahresabschluss braucht — das klärst du mit ihm, und ich setze es technisch um. Diese Arbeitsteilung funktioniert gut, weil beide Seiten dann über dasselbe reden: Ich frage beim Steuerberater nach den Vorgaben, er bekommt von mir eine Datei oder Übertragung, die zu seinen Vorgaben passt.

Wenn du mir schreibst, sag mir am besten gleich, womit gebucht wird und wie viele Bestellungen im Monat zusammenkommen. Daraus ergibt sich fast immer schon, ob ein fertiges Plugin reicht.