WooCommerce lexoffice Schnittstelle

Was eine WooCommerce-lexoffice-Anbindung wirklich leistet

WooCommerce weiß alles über einen Verkauf - die Positionen, die je Zeile ausgewiesene Steuer, den Gutschein, den Versand, die Zahlungsgebühr, die Teilerstattung drei Tage später. lexoffice braucht das als Buchhaltungsdatensätze: einen Kontakt für den Kunden, eine Rechnung oder einen Beleg mit korrekt besteuerten Zeilen, eine Rechnungskorrektur für die Erstattung und Buchungskategorien, die bis in den DATEV-Export durchlaufen, den Ihr Steuerberater abruft.

In der Lücke zwischen einem WordPress-Shop und einem deutschen Buchhaltungssystem steckt die Arbeit. Eine WooCommerce-lexoffice-Anbindung schließt sie automatisch: Sie liest jeden relevanten Bestellvorgang aus WooCommerce, wendet Ihre Buchungslogik an, entdubliziert den Kunden und schreibt einen sauberen Datensatz nach lexoffice, auf den sich Ihr Finanzablauf verlassen kann - ohne dass jemand Zahlen abtippt.

Welche Daten fließen

Objekt / Vorgang in WooCommerce	Wird in lexoffice zu	Hinweis
Bezahlte Bestellung (processing / completed)	Verkaufsrechnung oder Beleg	Modell je nach Buchhaltung; ein Datensatz je Bestellung
Rechnungskunde der Bestellung	Kontakt (Debitor)	Abgeglichen über E-Mail und USt-IdNr., nicht blind angelegt
Bestellpositionen	lexoffice-Positionen mit Einzelpreis und Menge	Netto oder brutto je nach Ihrer taxType-Konvention
Steuerpositionen	taxType + taxRatePercentage je Zeile	19 % / 7 % Inland, grenzüberschreitend der richtige Steuer-Subtyp
Versandposition	Eigene Positionszeile	Versand ist selbst steuerbar und wird separat verbucht
Gebühren / Zahlungsgebühren	Eigene Zeile oder Aufwandsbeleg	Getrennt vom Umsatz, damit die Nettoauszahlung stimmt
Gutschein / Rabatt	Reduzierte Positionsbeträge	lexoffice kennt kein Rabattobjekt; der Nettobetrag wird je Zeile angewandt
Erstattung / Teilerstattung	Rechnungskorrektur (salescreditnote)	Gleiche Zeilen und Steuerschlüssel wie das Original, mit Datum der Erstattung

Die konkreten Buchungskategorien, die Steuerbehandlung und das Modell Rechnung-oder-Beleg stimmen wir einmalig ab und hinterlegen sie in der Pipeline. Danach kontiert niemand mehr eine Bestellung von Hand.

Die Details, an denen einfache Synchronisationen scheitern

Ein Verzeichnis-Plugin oder ein einmaliger Export bringt Sie zu 80 % ans Ziel und lässt die teuren 20 % auf Ihrem Schreibtisch liegen:

• Kontakt-Dubletten. lexoffice hat kein Upsert. Naiv gebucht, erzeugt jede Bestellung einen frischen Kontakt - aus einem Stammkunden werden zwanzig Debitoren und Ihre Offene-Posten-Liste ist wertlos. Der Abgleich über E-Mail und USt-IdNr. vor Anlegen-oder-Verknüpfen ist Pflicht, nicht Kür.
• Steuer-Subtyp, nicht nur Steuersatz. Ein Inlandsverkauf mit 19 %, ein Artikel mit 7 %, ein EU-B2B-Verkauf als innergemeinschaftliche Lieferung und ein Export in die Schweiz sind keine vier Steuersätze - es sind unterschiedliche taxType- und taxSubType-Werte in der lexoffice-API. Einer falsch, und die Umsatzsteuervoranmeldung stimmt nicht.
• Kategorien statt SKR. lexoffice bucht Erlöse gegen eigene Buchungskategorien (per ID referenziert) und mappt diese erst im DATEV-Export auf SKR03/SKR04. Die Pipeline muss je Produktart die richtige Kategorie-ID auflösen, nicht eine rohe Kontonummer.
• Rechnungsnummern sind heilig. Eine lexoffice-Rechnung verbraucht eine fortlaufende Rechnungsnummer. Ein naiver Import beim zweiten Lauf zieht entweder Nummern für Dubletten oder reißt Lücken - beides beanstandet Ihr Steuerberater. Wo nur die Verbuchung nötig ist, vermeidet ein Beleg die Nummer ganz.
• Rate-Limits und Teilfehler. Die lexoffice-API begrenzt auf rund zwei Anfragen pro Sekunde und liefert unter Last 429; WooCommerce paginiert bei 100 Bestellungen je Seite und liegt auf Ihrem Shared-Hosting. Eine Synchronisation ohne Drosselung, Retry und Checkpoint verliert Bestellungen mitten im Lauf und hinterlässt ein halb gefülltes lexoffice.
• Zeitpunkt der Erstattung. Eine Teilerstattung in WooCommerce muss zu einer Rechnungskorrektur gegen genau die Zeilen und Steuerschlüssel der ursprünglichen Bestellung werden - mit dem Datum der Erstattung, nicht als negative Zeile an einem neuen Beleg.

Wie wir sie bauen und betreiben

Wir behandeln das als Pipeline, nicht als Plugin. Bestell- und Erstattungsvorgänge aus WooCommerce werden zeitgesteuert (oder per Webhook) abgeholt, validiert, gegen bestehende lexoffice-Kontakte abgeglichen, in Ihre abgestimmten lexoffice-Datensätze überführt und über den Invoices- oder Vouchers-Endpunkt geschrieben - mit einer Drosselung, die das Rate-Limit respektiert und bei 429 sauber zurückweicht.

Die Pipeline ist idempotent: Jede WooCommerce-Bestellung trägt eine stabile ID, sodass ein erneuter Lauf nie eine zweite Rechnung, einen doppelten Beleg oder einen Phantom-Kontakt erzeugt. Sie läuft auf cloud-nativer, vollständig EU-gehosteter AWS-Infrastruktur - Bestell- und Kundendaten verlassen die EU nicht, was AVV und DSGVO sauber hält und gerade bei einem deutschen System wie lexoffice zählt.

Und dann halten wir sie am Laufen. Monitoring, Alerting, Incident Response und das Beobachten von API-Änderungen bei WooCommerce und lexoffice liegen vertraglich bei uns. Ihr Monatsabschluss hängt nicht mehr an einem WordPress-Cronjob, für den sich niemand zuständig fühlt.

Wann sich diese Anbindung lohnt

Wenn Sie eine Handvoll Bestellungen im Monat mit einem einzigen Steuersatz abwickeln, ist ein Verzeichnis-Plugin oder sogar die manuelle Erfassung in lexoffice völlig in Ordnung - und das sagen wir Ihnen auch. Die Anbindung lohnt sich, wenn das Volumen steigt, wenn Sie grenzüberschreitend verkaufen und korrekte Steuer-Subtypen brauchen, wenn Erstattungen und mehrere Zahlungsanbieter die Abstimmung zur monatlichen Pflichtübung machen, oder wenn doppelte Kontakte und zerrissene Rechnungsnummern Sie bereits Zeit kosten, die Ihr Steuerberater zurückberechnet. Ab da ist ein Plugin auf Ihrem Webserver ein Risiko, und eine betreute, EU-gehostete Pipeline mit festem Ansprechpartner rechnet sich.