Zwischen einer Bestellung im Shop und einer Rechnung in der Buchhaltung liegen in vielen Betrieben ein Export, eine Tabelle und ein Nachmittag. Die öffentliche Schnittstelle von Lexware Office nimmt Belege und Artikel direkt entgegen, aber sie tut es zu ihren Bedingungen: zwei Anfragen je Sekunde (Lexware), höchstens 300 Positionen je Beleg (Lexware) und ausschließlich EUR als Währung (Lexware). Wer diese Kanten vor dem ersten Aufruf kennt, baut eine Strecke, die auch im Weihnachtsgeschäft trägt. Wer sie erst im Betrieb entdeckt, baut sie zweimal.
Das Wichtigste in Kürze
- Die Schnittstelle taktet, sie staut nicht: Eine Anbindung darf bis zu zwei Anfragen je Sekunde stellen (Lexware). Übersteigt die Rate diesen Deckel, kommt HTTP 429 zurück und der Aufruf wird gar nicht erst ausgeführt (Lexware).
- Ein Beleg fasst höchstens 300 Positionen (Lexware). Sammelrechnungen mit vielen Kleinstpositionen werden vorher geteilt oder verdichtet, sonst scheitert die Übergabe an der Grenze und nicht am Inhalt.
- Der Artikelstamm ist eng geführt: zugelassen sind die Steuersätze 0, 7 und 19 (Lexware), die GTIN wird gegen GTIN-8, GTIN-12, GTIN-13 und GTIN-14 geprüft (Lexware), und abgerechnet wird ausschließlich EUR (Lexware).
- Ob aus einer übergebenen Rechnung eine E-Rechnung wird, steuert der Kontakt und nicht ein Feld am Beleg: electronicDocumentProfile meldet das erzeugte Profil, also NONE, EN16931 oder XRechnung, und ist nur lesbar (Lexware). Dort trifft die Anbindung das Umsatzsteuerrecht.
- Der Belegweg endet nicht beim Versand: Buchungsbelege sind acht Jahre aufzubewahren (Abgabenordnung), und für Rechnungen wiederholt das Umsatzsteuerrecht dieselbe Frist eigenständig (Umsatzsteuergesetz).
Was die Schnittstelle zulässt und was sie abweist
Eine Anbindung beginnt selten mit der Frage, was ein System kann. Sie beginnt mit der Frage, wo es aufhört, denn die Grenzen bestimmen die Architektur und nicht die Wunschliste. Bei Lexware Office sind diese Grenzen ausdrücklich dokumentiert und damit planbar. Die wichtigste steht gleich am Anfang: Eine Anbindung darf bis zu zwei Anfragen je Sekunde stellen (Lexware). Das klingt großzügig, solange man an einzelne Bestellungen denkt. Es wird eng, sobald ein Katalogabgleich mehrere tausend Artikel prüfen soll, und es wird zur Architekturfrage, sobald der Shop eine Bestellspitze abarbeitet.
Der zweite Satz dazu ist wichtiger als der erste: Übersteigt die Rate der eingehenden Anfragen die verfügbaren Grenzen, kommt HTTP 429 zurück und der Aufruf wird nicht ausgeführt (Lexware). Die Schnittstelle puffert also nicht, sie weist ab. Für die Anbindung heißt das, dass der Takt auf die eigene Seite gehört. Eine Warteschlange mit fester Entnahmerate ist der übliche Weg, und sie muss einen abgewiesenen Aufruf wiederholen können, ohne ihn doppelt zu buchen. Wie das ohne Doppelbelege gelingt, hängt an einem sauberen Schlüssel je Vorgang; das Muster ist dasselbe wie bei Idempotenz und Wiederholstrategien an jeder anderen Schnittstelle.
| Grenze | Wert laut Dokumentation | Was daraus folgt |
|---|---|---|
| Anfragen je Sekunde | 2 (Lexware) | Takt auf der eigenen Seite, keine Stapelaufrufe |
| Antwort bei Überschreitung | HTTP 429, Aufruf nicht ausgeführt (Lexware) | Wiederholung mit wachsender Pause, Vorgangsschlüssel je Beleg |
| Positionen je Beleg | höchstens 300 (Lexware) | Sammelbelege teilen oder Positionen verdichten |
| Seitengröße der Listen | 25 als Standard, bis 250 (Lexware) | Seitengröße setzen, sonst 200 Aufrufe statt 20 |
| Suchfenster der Belegliste | 10.000 Einträge (Lexware) | Abgleich in Zeitscheiben zerlegen und Merker führen |
| Anhang je Beleg | 5 MB (Lexware) | PDF vor der Übergabe verkleinern und die Größe prüfen |
| Lesefrist des Rückrufs | 5.000 ms (Lexware) | Rückruf nimmt an und verarbeitet danach |
Zwei dieser Zeilen werden regelmäßig übersehen. Die Standardseite einer Liste ist auf 25 Einträge gesetzt und lässt sich je nach Endpunkt auf 100 oder 250 erhöhen (Lexware). Wer das versäumt, holt einen Bestand von 5.000 Artikeln in 200 Aufrufen statt in 20 und steht damit sofort wieder am Deckel von zwei Anfragen je Sekunde. Und die Belegliste gibt über alle Seiten hinweg nur ein Fenster von 10.000 Einträgen zurück (Lexware). Ein Abgleich über ein ganzes Geschäftsjahr läuft deshalb nicht als ein Lauf, sondern als Folge von Zeitscheiben, Monat für Monat, mit einem Merker, wie weit man gekommen ist.
Der Zugang hat den Namen gewechselt
Der Belegweg: von der Bestellung zur Rechnung
Eine Bestellung im Shop ist noch kein Beleg. Sie wird erst zu einem, wenn ihr Inhalt auf die Felder abgebildet ist, die das Buchhaltungssystem führt, und diese Abbildung ist die eigentliche Arbeit der Anbindung. Der Kopf des Belegs trägt Datum, Kunde, Anschrift und Steuerlogik. Die Positionen tragen Menge, Einheit, Nettopreis, Steuersatz und die Verknüpfung zum Artikelstamm. Die Summenebene trägt Netto, Steuer und Brutto und eine Währung, die genau einen Wert kennt: Die Schnittstelle unterstützt derzeit ausschließlich EUR (Lexware). Ein Shop, der in Franken oder Pfund abrechnet, rechnet vor der Übergabe um und hält den Kurs am Beleg fest, sonst ist die Zahl später nicht mehr erklärbar.
Die zweite Kante sitzt bei den Positionen. Ein Beleg fasst höchstens 300 Positionen (Lexware), und laut Dokumentation gilt dieselbe Grenze auch für Gutschriften, Auftragsbestätigungen, Lieferscheine und Angebote. Für den klassischen Einzelbestellvorgang ist das reichlich. Für eine Monatssammelrechnung eines B2B-Kunden mit täglichen Kleinabrufen ist es das nicht. Zwei Wege führen daran vorbei: den Sammelbeleg an einer fachlich sinnvollen Kante teilen, etwa je Lieferung oder je Kostenstelle, oder gleiche Artikel zu einer Position mit Gesamtmenge verdichten. Beides ist eine fachliche Entscheidung und keine technische; sie gehört vor den ersten Aufruf und nicht in den Ausnahmezweig.
shop.bestellung -> lexware.invoice
bestellnummer -> introduction # Freitext; voucherNumber vergibt Lexware
bestelldatum -> voucherDate
kunde.id -> address.contactId # sonst address.name + Anschrift
waehrung -> totalPrice.currency # nur EUR
positionen[] -> lineItems[] # max. 300
artikelnummer -> id (Artikelverweis) oder name + description
menge -> quantity
einheit -> unitName
einzelpreis_netto -> unitPrice.netAmount
steuersatz -> unitPrice.taxRatePercentage
versandkosten -> lineItems[] # eigene Position, kein Summenfeld
rechnungsformat -> xRechnung.buyerReference # Profil kommt read-only zurück
beleg_pdf -> files/ # max. 5 MBZwei Felder in dieser Abbildung verdienen besondere Aufmerksamkeit. Das erste ist die Belegnummer, und zwar als Gegenbeispiel: Sie wird bei der Anlage von Lexware selbst vergeben und ist nur lesbar (Lexware). Die Bestellnummer aus dem Shop lässt sich dort also nicht hinterlegen; sie gehört in ein frei beschreibbares Feld wie Titel, Einleitungstext oder Bemerkung oder an die Kontaktzuordnung. Beide Nummernkreise laufen damit nebeneinander, ohne dass der eine Lücken in den anderen reißt; die Anbindung muss nur festhalten, welche Bestellnummer zu welchem Beleg gehört, und zwar als Feld und nicht als Konvention. Das zweite sind die Versandkosten. Sie sind keine Summenkorrektur, sondern eine Position mit eigenem Steuersatz; wer sie am Summenfeld abzieht, erzeugt einen Beleg, dessen Positionen nicht zur Summe passen. Diese Abstimmung ist der Teil der Schnittstellenentwicklung, der die meiste Rückfrage kostet und am wenigsten Code.
- Auslöser festlegen. Nicht jede Bestellung ist ein Beleg. Üblich sind Zahlungseingang oder Versand, nicht der Klick auf den Kaufen-Knopf. Der Auslöser gehört dokumentiert, weil er die Umsatzperiode bestimmt.
- Kunde zuordnen. Existiert der Kontakt bereits, wird auf ihn verwiesen, sonst wird die Anschrift am Beleg mitgegeben. Ein neuer Kontakt je Bestellung führt binnen Monaten zu einem unbrauchbaren Adressbestand.
- Positionen bilden. Menge, Einheit, Nettopreis und Steuersatz je Zeile, Versandkosten als eigene Zeile, Rabatte dort, wo sie fachlich hingehören, und nicht als nachträgliche Summenkorrektur.
- Beleg anlegen und Antwort auswerten. Die Antwort trägt die Kennung des Belegs. Sie wird an der Bestellung gespeichert, bevor irgendetwas anderes passiert; ohne sie ist der Vorgang bei der nächsten Wiederholung nicht mehr auffindbar.
- Anhang nachreichen. Das Beleg-PDF geht über den Datei-Endpunkt und hat eine harte Obergrenze von 5 MB (Lexware); zulässig sind laut Dokumentation die Formate PDF, JPG, PNG und XML.
Die Kennung ist der Anker
Artikelstamm: ein Endpunkt mit klaren Kanten
Einen eigenen Endpunkt für Artikel gibt es noch nicht lange. Er wurde am 11.07.2024 ergänzt (Lexware). Anbindungen aus der Zeit davor haben Stammdaten über Belegpositionen mitgeschleppt, mit allen Folgen für Auswertbarkeit und Pflege. Wer heute anbindet, trennt beides sauber: Der Artikelstamm wandert über den Artikel-Endpunkt, der Beleg verweist darauf. Das ist keine Stilfrage, sondern entscheidet darüber, ob eine Preisänderung an einer Stelle passiert oder an tausend.
Artikelnummer
Frei setzbar und der natürliche Schlüssel zwischen Shop und Buchhaltung. Sie sollte aus dem führenden System kommen und dort bleiben, eine je Artikel und nicht eine je Kanal. Wie man daneben noch Kundenartikelnummern führt, ist eine eigene Frage.
GTIN
Anders als die Artikelnummer wird sie geprüft: Ist ein Wert angegeben, muss er den Formaten GTIN-8, GTIN-12, GTIN-13 oder GTIN-14 entsprechen (Lexware). Ein aus dem Shop übernommenes Freitextfeld fällt hier sofort auf.
Steuersatz
Am Artikel sind die Sätze 0, 7 und 19 zugelassen (Lexware). Sonderfälle wie innergemeinschaftliche Lieferung, Umkehr der Steuerschuld oder Kleinunternehmerregelung werden auf der Belegebene gelöst und nicht am Stammdatensatz.
Preis und Währung
Der Preis hängt an einer Währung, und die Schnittstelle unterstützt derzeit ausschließlich EUR (Lexware). Mehrere Währungen im Shop bedeuten also Umrechnung vor der Übergabe, mit festgehaltenem Kurs je Beleg.
Einheit
Mengeneinheit und Verpackungsgröße gehören zusammengeführt, bevor die erste Position entsteht. Wie Gebinde und Mengeneinheiten umgerechnet werden, entscheidet über jede spätere Auswertung.
Abgleich
Ein Katalogabgleich liest über Seiten. Die Seitengröße steht standardmäßig auf 25 und lässt sich je nach Endpunkt auf 100 oder 250 anheben (Lexware); für den Artikel-Endpunkt nennt die Tabelle den höheren Wert.
Der Artikelabgleich ist der Teil, der am ehesten in den Deckel läuft. Ein Bestand von 5.000 Artikeln ist bei einer Seitengröße von 250 in 20 Leseaufrufen gelesen, bei 25 sind es 200. Schreibend wird es schnell teurer, denn jede Änderung ist ein eigener Aufruf: Bei zwei Anfragen je Sekunde (Lexware) dauert ein Vollabgleich von 5.000 Artikeln über 40 Minuten, wenn jeder Datensatz angefasst wird. Deshalb wird nicht alles geschrieben, sondern nur das Geänderte, erkennbar an einem Abdruck je Datensatz und nicht an einem Zeitstempel, der beim Spiegeln ohnehin verrutscht.
- Ein Artikel gehört genau einem führenden System. Wird er in beiden gepflegt, entstehen zwei Wahrheiten und ein wiederkehrender Abgleichaufwand; das Muster ist aus der Stammdatensynchronisation bekannt.
- Variantenartikel haben im Shop eine Struktur, in der Buchhaltung aber eine Nummer und einen Preis. Die Abbildung wird vor dem Bau festgelegt, nicht danach.
- Gelöschte Artikel verschwinden nicht rückwirkend aus Belegen. Der Beleg trägt die Bezeichnung zum Zeitpunkt der Ausstellung; das ist gewollt und beim Abgleich zu berücksichtigen.
- Ein Abgleich ohne Merker beginnt jedes Mal von vorn. Der Merker gehört auf die eigene Seite, weil das Suchfenster der Belegliste bei 10.000 Einträgen endet (Lexware).
Takt statt Stapel: Deckel, Seiten und Konflikte
Die Dokumentation nennt neben dem Deckel von zwei Anfragen je Sekunde (Lexware) auch das Verhalten bei Rückrufen, und das ist für den Betrieb mindestens so wichtig. Die konfigurierte Lesefrist liegt bei 5.000 ms, und lange laufende Prozesse synchron im Rückruf auszulösen, wird ausdrücklich nicht empfohlen (Lexware). Ein Rückruf nimmt also entgegen, schreibt in eine Warteschlange und antwortet; die Verarbeitung passiert danach. Ob ein Rückruf oder ein getakteter Abruf der richtige Weg ist, hängt am Volumen und an der Toleranz für Verzögerung. Die Abwägung zwischen Rückruf und Abfrage fällt hier meist zugunsten des Rückrufs aus, solange die Verarbeitung entkoppelt ist.
Fällt der eigene Endpunkt aus, gibt die Gegenseite nicht sofort auf. Die erste Phase bringt fünf Wiederholungen nach 10, 20, 40, 80 und 160 Sekunden (Lexware); danach folgt laut derselben Stelle eine Pause von 30 Minuten und eine zweite Phase mit 20 Wiederholungen im Abstand von zwei Stunden. Das ist großzügig und genau deshalb heikel, denn ein stiller Ausfall fällt erst nach vielen Stunden auf, wenn niemand hinsieht. Eine Anbindung ohne eigene Überwachung bemerkt den Ausfall am Monatsende und nicht am Vormittag. Wie eine belastbare Fehlerbehandlung an Schnittstellen aussieht, ist deshalb Teil der Anbindung und kein Nachtrag.
09:00:00.0 GET /v1/articles?page=0&size=250 200 250 Artikel
09:00:00.5 GET /v1/articles?page=1&size=250 200 250 Artikel
09:00:00.7 GET /v1/articles?page=2&size=250 429 abgewiesen
09:00:02.7 GET /v1/articles?page=2&size=250 200 Wiederholung nach Pause
...
09:16:40.0 POST /v1/invoices 201 Kennung gespeichert
09:16:41.0 PUT /v1/articles/47f1 409 Konflikt
09:16:42.0 GET /v1/articles/47f1 200 Datensatz neu gelesen
09:16:43.0 PUT /v1/articles/47f1 200 gespeichertZwei Statuscodes bestimmen den Betrieb. Der eine ist die 429, die keine Warteschlange bedeutet, sondern eine Absage (Lexware). Der andere ist die 409: Wurde ein Datensatz zwischenzeitlich von jemand anderem geändert, kommt HTTP 409 Conflict zurück (Lexware). Gleichzeitige Schreibzugriffe werden also nicht gesperrt, sondern abgewiesen, und die Anbindung löst den Konflikt selbst auf, indem sie neu liest, zusammenführt und erneut schreibt. Wer das nicht vorsieht, verliert bei jedem parallelen Eingriff aus der Oberfläche stillschweigend eine Änderung. Takt, Warteschlange und Protokoll sind genau die Aufgaben, für die eine Middleware zwischen Shop und Buchhaltung gebaut wird.
Zwei Anfragen je Sekunde sind ein Entwurfsparameter
E-Rechnung: was über das Format entscheidet
Ob aus einer übergebenen Rechnung eine elektronische Rechnung wird, entscheidet nicht ein Formatfeld am Beleg. Das Feld electronicDocumentProfile meldet nur, welches Profil erzeugt wurde: NONE, EN16931 als hybrides Format oder XRechnung (Lexware); die Dokumentation weist es als nur lesbar aus (Lexware). Gesteuert wird über den Kontakt. Sind dort die Leitweg-ID des Kunden und die eigene Lieferantennummer beim Kunden hinterlegt, entstehen daraus Rechnungen nach dem XRechnung-Standard (Lexware); je Rechnung lässt sich die Leitweg-ID über das xRechnung-Objekt am Beleg übersteuern (Lexware). Damit ist die Anbindung an eine gesetzliche Entwicklung angeschlossen, die parallel läuft. Seit 2025 steht im Gesetz, was eine elektronische Rechnung ist: eine Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht (Umsatzsteuergesetz). Ein PDF im Anhang erfüllt das nicht; es ist nach derselben Vorschrift eine sonstige Rechnung. Welche Empfängergruppe welches Format braucht, gehört auf die Seite zur E-Rechnung und nicht in den Ausnahmezweig der Anbindung.
Für kleinere Betriebe gibt es eine Übergangsregelung, aber sie hängt an einer festen Grenze. Bis zum 31. Dezember 2027 dürfen Rechnungen für Umsätze des Jahres 2027 noch auf Papier oder in einem nicht konformen elektronischen Format übermittelt werden, wenn der Gesamtumsatz des ausstellenden Unternehmers im vorangegangenen Kalenderjahr nicht mehr als 800.000 Euro betragen hat (Umsatzsteuergesetz). Wer darüber liegt, hat diese Verlängerung nicht. Und unabhängig davon läuft die Ausstellungsfrist: Bei Leistungen an andere Unternehmer ist die Rechnung innerhalb von sechs Monaten nach Ausführung der Leistung auszustellen (Umsatzsteuergesetz). Eine Anbindung, die Belege sammelt und erst zum Quartalsende überträgt, arbeitet hier gegen die Frist.
| Wert oder Norm | Was dahintersteht | Wofür es zählt |
|---|---|---|
| NONE | kein elektronisches Rechnungsprofil (Lexware) | Belege, die nicht als E-Rechnung gelten sollen |
| EN16931 | hybrides Format aus PDF und eingebetteten Daten (Lexware) | Empfänger, die beide Teile verarbeiten |
| XRechnung | rein strukturiertes Format (Lexware) | Empfänger, die diesen Standard verlangen |
| Norm dahinter | EN 16931, veröffentlicht am 28. Juni 2017 (Forum elektronische Rechnung Deutschland) | keine Neuerung, sondern ein Termin |
| Formatstand | ZUGFeRD 2.5.2 (Forum elektronische Rechnung Deutschland) | wandert schneller als die Anbindung |
| Standfassung | XRechnung 3.0, in Kraft seit dem 01.02.2024 (KoSIT) | die Vorgängerfassung trat am selben Tag außer Kraft |
Der Blick lohnt über die nationale Frist hinaus. Der Rat der Europäischen Union baut die Mehrwertsteuer in Stufen um, und nur die letzte davon liegt 2030: Artikel 5 der Richtlinie ändert die Mehrwertsteuersystemrichtlinie mit Wirkung vom 1. Juli 2030 (Rat der Europäischen Union), eine frühere Stufe greift bereits mit Wirkung vom 1. Juli 2028 (Rat der Europäischen Union). Zur Stufe 2030 gehört die kürzere Rechnungsfrist: Für grenzüberschreitende Umsätze wird künftig spätestens zehn Tage nach Eintreten des Steuertatbestands eine Rechnung ausgestellt (Rat der Europäischen Union), wo bisher der fünfzehnte Tag des Folgemonats galt. Begründet wird der Umbau mit einer Einnahmenlücke, die für 2020 unionsweit auf schätzungsweise 93 Mrd. EUR beziffert wurde (Rat der Europäischen Union). Wer heute eine Belegstrecke baut, baut sie für diesen Horizont mit und behält die früheren Stufen im Blick; die Details der nationalen Umsetzung stehen im Beitrag zur E-Rechnungspflicht ab 2027.
Aufbewahrung: was nach dem Versand noch passiert
Ein Beleg ist mit der Übergabe nicht erledigt. Buchungsbelege sind acht Jahre aufzubewahren (Abgabenordnung), und für Rechnungen wiederholt das Umsatzsteuerrecht dieselbe Frist eigenständig: Sie beginnt mit dem Schluss des Kalenderjahres, in dem die Rechnung ausgestellt worden ist (Umsatzsteuergesetz). Praktisch heißt das, dass eine Rechnung aus dem Januar 2026 bis Ende 2034 vorzuhalten ist, in einer Form, die lesbar und maschinell auswertbar bleibt. Das betrifft nicht nur das Buchhaltungssystem, sondern auch die Anbindung selbst: Protokolle, Zuordnungen und die Kennungen, über die ein Shop-Vorgang und ein Beleg zusammenfinden.
- Die Kennung des Belegs an der Bestellung speichern und nicht nur in einem Protokoll. Ein Protokoll wird rotiert, eine Bestellung bleibt.
- Die Zuordnung zwischen Shop-Vorgang, Beleg und Zahlung als Datensatz führen und nicht als Bericht, der jedes Mal neu gerechnet wird.
- Anhänge vor dem Hochladen gegen die Grenze von 5 MB prüfen (Lexware) und das Ergebnis der Prüfung protokollieren.
- Nummernkreise und ihre Lücken dokumentieren. Was heute selbsterklärend ist, ist bei einer Prüfung in sechs Jahren eine Rückfrage.
- Die Verfahrensbeschreibung mitschreiben, solange gebaut wird; der Aufwand für eine Verfahrensdokumentation im Nachhinein ist ein Vielfaches.
- Die Aufbewahrung technisch abbilden: acht Jahre ab dem Schluss des Kalenderjahres (Umsatzsteuergesetz), abrufbar ohne Handarbeit.
Und der Belegstrom ist selten der einzige, der aus denselben Daten entsteht. Wer importiert, führt neben Rechnung und Artikel noch Meldedaten mit Warennummer, Ursprungsland und Menge; die CBAM-Frist am 27. September zeigt, wie schnell neben der Buchhaltung ein zweiter Datenstrom mit eigener Frist entsteht. Beide greifen auf dieselben Bestell- und Artikeldaten zu, und beide werden schlechter, wenn sie an unterschiedlichen Stellen gepflegt werden.
Wie groß der Belegstrom wirklich ist
Der Onlinehandel in Deutschland ist kein Nischenkanal. Er wuchs zuletzt um 3,9 Prozent auf 92,3 Mrd. Euro netto (HDE), und der Onlineanteil am gesamten Einzelhandel liegt bei 13,5 Prozent (HDE). Jeder dieser Umsätze erzeugt mindestens einen Beleg, der in die Buchhaltung muss. Auf der Angebotsseite ist der Anteil ähnlich greifbar: Im Datensatz des Web Almanac 2025 wurden 19,9 Prozent aller untersuchten Desktop-Seiten als Shop erkannt (Web Almanac). Der Beleg- und Artikelabgleich ist damit kein Sonderfall, sondern ein Standardproblem mit einer bekannten Lösungsform.
Bemerkenswert ist, wie klein die Betriebe dabei oft sind. In der Europäischen Union hatten 23,59 Prozent der Unternehmen elektronische Verkäufe (Eurostat); bei den kleinen Unternehmen mit 10 bis 49 Beschäftigten sind es 21,38 Prozent, die 8,65 Prozent ihres Umsatzes darüber erzielen (Eurostat). Und wer dort verkauft, tut es weit überwiegend über die eigene Website: 91,19 Prozent der kleinen Unternehmen mit elektronischen Verkäufen nutzen dafür das Web, 17,52 Prozent den Austausch strukturierter Nachrichten (Eurostat). Genau in dieser Größenordnung rechnet sich Automatisierung nur, wenn sie ohne tägliche Betreuung läuft.
Dazu passt das Bild aus Deutschland. Etwas mehr als die Hälfte der Unternehmen ab zehn Beschäftigten nutzt kostenpflichtige Cloud-Dienste, nämlich 54 Prozent im Jahr 2025 (Statistisches Bundesamt). Warenwirtschaft und Kundenverwaltung sind darunter aber vergleichsweise selten, jeweils 23 Prozent der Cloud-nutzenden Unternehmen (Statistisches Bundesamt). Eine Anbindung verbindet also häufig eine Buchhaltung in der Cloud mit einer Warenwirtschaft, die im eigenen Haus steht. Wie diese Brücke gebaut wird, ohne dass beide Seiten sich gegenseitig ausbremsen, ist die Kernfrage jeder Warenwirtschaftsanbindung.
Was vor dem ersten Aufruf feststehen sollte
Die meisten Anbindungen scheitern nicht an einem Feld, sondern an einer Frage, die niemand gestellt hat. Deshalb steht vor dem ersten Aufruf eine kurze Liste von Festlegungen. Jede davon kostet in der Klärung Minuten und im Nachbau Tage. Wir gehen diese Liste in einem Vorgespräch zur Lexware-Anbindung einmal komplett durch, bevor eine Zeile Code entsteht.
- Auslöser für den Beleg festlegen: Bestellung, Zahlungseingang oder Versand. Das entscheidet über die Umsatzperiode.
- Führendes System je Datenart benennen: Artikel, Preise, Kunden, Belege. Für jede Art genau eines.
- Nummernkreise trennen und die Zuordnung als Feld führen, nicht als Konvention im Kopf.
- Grenzwerte in die Architektur übernehmen: zwei Anfragen je Sekunde, höchstens 300 Positionen je Beleg, 5 MB je Anhang (Lexware).
- Wiederholung und Vorgangsschlüssel festlegen, bevor die erste 429 im Protokoll steht (Lexware).
- Konfliktbehandlung vorsehen: Eine 409 ist kein Fehler, sondern die Aufforderung, neu zu lesen und erneut zu schreiben (Lexware).
- Rechnungsformat je Empfängergruppe festlegen und am Kontakt hinterlegen, also Leitweg-ID und Lieferantennummer beim Kunden (Lexware); das Feld electronicDocumentProfile meldet das erzeugte Profil nur zurück (Lexware).
- Überwachung einplanen, die einen stillen Ausfall vor dem Monatsabschluss meldet, und einen Notbetrieb für den Fall, dass die Gegenseite länger schweigt.
Eine Anbindung ist so gut wie ihr Verhalten im Ausnahmefall. Der Normalbetrieb steht in der Dokumentation; was bei einer 429, einer 409 und einem stillen Rückruf passiert, entscheidet darüber, ob am Monatsende jemand nacharbeitet.
Quellen und Studien