Kosten für Buchhaltungsintegrationen: Ein Projekt pro Anbieter

Veröffentlichte Schätzungen belaufen sich auf drei Wochen bis zwölf Monate pro Buchhaltungssystem, und der Aufwand lässt sich nicht von einem Anbieter auf den nächsten übertragen. Hier sind die Zahlen, ihre Quellen und die Alternative.

Eine Plattform, die sich mit den Buchhaltungssystemen ihrer Kunden verbindet, baut pro Anbieter eine eigene Integration. Veröffentlichte Schätzungen für eine einzelne Integration reichen von drei bis vier Wochen für eine erste funktionierende QuickBooks-Verbindung bis hin zu sechs bis zwölf Monaten für NetSuite. Jede Schätzung, die wir finden konnten, stammt allerdings von einem Unternehmen, das einen Weg verkauft, genau diese Arbeit zu vermeiden. Die geleistete Arbeit lässt sich zudem nicht übertragen: QuickBooks, Xero, NetSuite und Microsoft Dynamics 365 Business Central verfügen jeweils über eigene Anmeldemethoden, Token-Gültigkeiten, Abfragesprachen, Rate Limits, Gebühren und Deprecationspläne. Sechs Anbieter bedeuten somit sechs Projekte und sechs Wartungsbudgets.

Dieser Artikel fasst die veröffentlichten Zahlen samt ihrer Quellen zusammen, zeigt die Unterschiede zwischen den Anbietern auf und erläutert die Alternative: Die Buchhaltung direkt in Ihrem eigenen Produkt über eine einzige Buchhaltungs-API abzubilden, sodass statt einer Integration pro Anbieter nur noch eine einzige zu entwickeln ist.

Wie lange eine Buchhaltungsintegration dauert

Niemand veröffentlicht eine neutrale Studie über den Entwicklungsaufwand von Integrationen. Die folgenden Zahlen stammen durchgehend von Anbietern vereinheitlichter Buchhaltungs-APIs (unified accounting APIs), die ein wirtschaftliches Interesse daran haben, den Aufwand möglichst groß erscheinen zu lassen. Dennoch sind dies die spezifischsten Zahlen, die am Markt verfügbar sind, und sie decken sich weitgehend, sobald man zwischen einer ersten funktionierenden Version und dem Produktivbetrieb unterscheidet.

Quelle	Aussage	Hintergrund
Apideck (2026)	QuickBooks: „Ein kompetenter Entwickler kann in drei bis vier Wochen etwas Funktionierendes aufbauen.“ Die Pflege von über 35 Connectors erfordert „mindestens einen Entwickler, der sich ausschließlich um die Wartung der Integrationen kümmert“.	Vertreibt eine vereinheitlichte API
Rutter (April 2026)	„Drei Entwicklermonate pro Plattform“, was Rutter als konservative Schätzung bezeichnet. Bei NetSuite „erstreckt sich der Zeitrahmen auf sechs bis zwölf Monate“. Ein Kunde veranschlagte für QuickBooks zwei Entwickler für ein paar Monate; letztlich dauerte es „mindestens drei Monate mit mehreren Iterationen“.	Vertreibt eine vereinheitlichte API
Merge	150 Stunden für die Entwicklung einer Integration und 300 Stunden pro Jahr für deren Wartung, basierend auf einem Gehalt von 150.000 USD. Merge beziffert die Kosten auf „50.000 bis 150.000 USD pro Jahr“.	Vertreibt eine vereinheitlichte API

Zwei Aspekte dieser Zahlen sind wichtiger als die jeweiligen Gesamtsummen.

Erstens markiert die Kluft zwischen drei Wochen und drei Monaten den Abstand zwischen einer Demo und dem Produktivbetrieb. Eine Verbindung, die schlicht eine Rechnung anlegt, steht schnell. Eine Anbindung hingegen, die abgelaufene Tokens, doppelte Webhooks, Rate Limits, Teilausfälle und Kunden übersteht, die versehentlich eine andere Unternehmensdatei verbinden, verschlingt die restliche Zeit. Unser Leitfaden zur Integration einer Cloud-Buchhaltungs-API in eine SaaS-Plattform schlüsselt diese Arbeit Schritt für Schritt auf.

Zweitens übersteigt der Wartungsaufwand im Modell von Merge den Entwicklungsaufwand deutlich: 300 Stunden pro Jahr stehen einmaligen 150 Stunden gegenüber. Diese Kosten fallen jedes Jahr aufs Neue für jeden unterstützten Anbieter an.

Warum die zweite Integration genau so viel kostet wie die erste

Wenn die Anbieter alle dieselbe Schnittstelle anbieten würden, könnte man bei der zweiten Integration auf den Großefteil des Codes der ersten zurückgreifen. Tun sie aber nicht. Die folgende Tabelle vergleicht vier weit verbreitete Systeme.

	QuickBooks Online	Xero	NetSuite	Business Central
Anmeldung	OAuth 2.0	OAuth 2.0	OAuth 2.0; tokenbasierte Authentifizierung für neue Integrationen ab Version 2027.1 geschlossen	Ausschließlich Microsoft Entra ID OAuth
Gültigkeit des Access Tokens	1 Stunde	30 Minuten	60 Minuten	Durch Entra ID festgelegt
Refresh Token	100 Tage gleitend, maximal fünf Jahre	60 Tage gleitend	7 Tage	Durch Entra ID festgelegt
Abfragesyntax	SQL-ähnliches `SELECT … FROM Invoice`, kein `OR`, keine Joins	REST mit einem `where`-Parameter	SuiteQL (SQL) über REST sowie SOAP bis 2028	OData v4
Rate Limit	500 Anfragen pro Minute und 10 pro Sekunde und Unternehmen	60 pro Minute, 5.000 pro Tag und 5 parallele Anfragen pro Unternehmen	5 bis 20 parallele Anfragen pro Konto, je nach Service-Tarif	6.000 Anfragen pro 5 Minuten und 5 parallele Anfragen pro Nutzer
Separate API-Gebühr	App Partner Program: kostenlose Stufe, danach 300 USD bis 4.500 USD pro Monat	App-Tarife von kostenlos bis 1.445 AUD pro Monat	Keine bekannt; zusätzliche Parallelität wird über SuiteCloud Plus-Lizenzen vertrieben	Keine bekannt

Quellen: Intuit-Autorisierungs-FAQ, Intuit Limits und Throttles, Leitfaden zum Intuit App Partner Program, Xero OAuth 2.0-Leitfaden, Xero API-Limits, Xero-Preise, NetSuite OAuth 2.0-Tokens, NetSuite tokenbasierte Authentifizierung, Betriebliche Limits von Business Central.

Tokens laufen nach vier verschiedenen Zyklen ab

Eine Integration muss die Tokens jedes Anbieters vor deren Ablauf erneuern und den neuen Refresh Token jedes Mal fehlerfrei speichern, andernfalls muss sich der Kunde neu verbinden. Die Zyklen unterscheiden sich um den Faktor vierzehn: Ein NetSuite-Refresh-Token hält sieben Tage, das von QuickBooks hingegen 100 Tage. QuickBooks setzt zudem eine harte Obergrenze: Refresh Tokens sind maximal fünf Jahre gültig, sodass langfristig laufende Verbindungen unabhängig von ihrer tatsächlichen Nutzung ab einem festen Stichtag ablaufen. Jeder Zyklus erfordert einen eigenen Erneuerungsjob, eine spezifische Fehlerbehandlung und eine eigene „Bitte erneut verbinden“-Meldung an den Kunden.

Jeder Anbieter hat seine eigene Abfragesprache

Das Auslesen von Daten ist der Bereich, in dem der Code am stärksten voneinander abweicht. QuickBooks akzeptiert einen eingeschränkten SQL-Dialekt ohne OR und ohne Joins, der maximal 1.000 Datensätze pro Seite zurückgibt. Xero filtert über einen where-Ausdruck in der URL und empfiehlt für große Organisationen einfache Gleichheitsprüfungen. NetSuite nutzt SuiteQL, einen vollständigen SQL-Dialekt, der an einen eigenen Endpunkt übermittelt wird. Business Central verwendet OData-Filter. Eine Abfrage, die unbezahlte Rechnungen für einen Kunden ermittelt, erfordert somit vier völlig unterschiedliche Codebasen, von denen jede ihre eigene Paginierung und ihre eigenen Sonderfälle mit sich bringt.

Jeder Anbieter drosselt den Datenverkehr auf andere Weise

QuickBooks und Xero zählen Anfragen pro Unternehmen und Minute. NetSuite misst parallele Anfragen über das gesamte Konto hinweg, sodass sich Ihre Integration das Kontingent mit jeder anderen vom Kunden ausgeführten Integration teilen muss – und NetSuite lehnt Aufrufe jenseits des Limits schlicht ab. Business Central zählt pro Benutzer innerhalb eines Fünfminutenfensters. Ein Massenimport, der bei einem Anbieter problemlos durchläuft, wird von einem anderen gedrosselt, weshalb Drosselungs- und Wiederholungslogik für jeden Anbieter individuell geschrieben werden muss.

Der API-Zugriff ist eine kommerzielle Partnerschaft

Zwei der vier Anbieter berechnen mittlerweile volumenbasierte Gebühren für den API-Zugriff. Das App Partner Program von Intuit bepreist „CorePlus“-Aufrufe, die die meisten Datenlesevorgänge abdecken, und blockiert diese oberhalb eines Freimonts in der kostenlosen Stufe; die kostenpflichtigen Stufen schlagen mit 300 USD, 1.700 USD und 4.500 USD pro Monat zu Buche. Xero hat zum 2. März 2026 kostenpflichtige App-Tarife eingeführt, die von einem kostenlosen Tarif für 5 Verbindungen bis hin zu 1.445 AUD pro Monat für 10.000 Verbindungen reichen. Die laufenden Betriebskosten einer Integration hängen somit maßgeblich davon ab, wie viele Ihrer Kunden den jeweiligen Anbieter nutzen und wie viele Daten Sie abfragen.

Die Anbieter ändern nach eigenem Zeitplan die Regeln

Jede heute funktionierende Integration blickt auf eine bekannte Liste bereits angekündigter, erzwungener Neuentwicklungen:

NetSuite akzeptiert ab der Version 2027.1 keine neuen Integrationen mehr, die auf tokenbasierter Authentifizierung basieren. Laut dem SOAP-Hinweis von Oracle werden „mit der NetSuite-Version 2028.2 alle Endpunkte deaktiviert und SOAP-basierte Integrationen nicht mehr funktionieren“ (NetSuite SOAP-Hinweis).
Xero weist ab März 2026 erstellten Apps granulare Berechtigungsbereiche (Scopes) zu und räumt bestehenden Apps eine Frist bis September 2027 für die Umstellung ein (Xero OAuth 2.0-Übersicht).
QuickBooks setzt die bereits erwähnte Fünfjahres-Obergrenze für Refresh Tokens durch und hat ältere API-Missionsversionen eingestellt, sodass Version 75 nun die Basis bildet.
Business Central Online hat die Annahme von Zugriffsschlüsseln (Basic Authentication) für Webdienste im Jahr 2022 eingestellt; Integrationen mussten auf Entra ID OAuth umgestellt werden (Microsoft-Deprecation-Liste).

Keine dieser Änderungen bringt Ihren Kunden ein neues Feature. Jede einzelne stellt lediglich investierte Entwicklungszeit dar, die aufgewendet werden muss, um eine bestehende Verbindung am Laufen zu halten – multipliziert mit der Anzahl der unterstützten Anbieter.

Die Rechnung für sechs Integrationen

Legt man Rutters Schätzung von drei Entwicklermonaten pro Plattform sowie Merges Angabe von 300 Wartungsstunden pro Jahr zugrunde und rechnet dies auf sechs Buchhaltungssysteme hoch, ergibt sich folgendes Bild:

	Ein Anbieter	Sechs Anbieter
Entwicklung	3 Entwicklermonate	18 Entwicklermonate
Wartung pro Jahr	300 Stunden	1.800 Stunden, was fast einem Vollzeitentwickler entspricht

Dies sind die Annahmen der Anbieter selbst, nicht unsere, und allein NetSuite sprengt diesen Rahmen häufig noch. Entscheidend ist die Skalierung: Die Kosten wachsen proportional mit der Anzahl der Anbieter, und der Wartungsaufwand reißt niemals ab. Eine vereinheitlichte API (Unified API) verkürzt zwar die Entwicklungsphase, macht Sie jedoch davon abhängig, wie gut diese die Schreibvorgänge und Sonderfälle jedes einzelnen Anbieters unterstützt, und schlägt pro Verbindung oder Aufruf zu Buche. Unser Artikel zum Thema Eigenentwicklung versus Kauf kalkuliert diese Kosten transparent durch.

Einmal integrieren: Die Buchhaltung im eigenen Produkt abbilden

Das klassische Connector-Modell geht davon aus, dass die Bücher jedes Kunden in einem System liegen, das dieser selbst gewählt hat, und Ihre Plattform Daten dorthin kopiert. Es gibt jedoch ein zweites Modell: Ihre Plattform führt die Buchhaltung selbst über eine einzige Buchhaltungs-API und bildet sie in Ihrer eigenen Benutzeroberfläche ab. Genau dafür wurde Nordlet entwickelt. Unabhängig davon, welche Buchhaltungssoftware Ihre Kunden zuvor genutzt haben, ist nur eine einzige Integration zu entwickeln.

Wie diese eine Integration in Nordlet aussieht:

Eine einheitliche Anfragestruktur. Jede Operation folgt dem Schema POST /v1/{module}/{resource}/{action}. Jede list-Aktion akzeptiert denselben Filter-, Sortier- und Paginierungskörper, und jeder Fehler nutzt dasselbe Envelope-Format. Code, der für einen Endpunkt geschrieben wurde, funktioniert bei den anderen exakt genauso. Siehe API-Konventionen.
API-Keys statt Refresh Tokens. Ein Schlüssel gehört zu genau einem Unternehmen, besitzt feste Berechtigungsbereiche, kann mit einem von Ihnen festgelegten Ablaufdatum versehen und widerrufen werden. Es müssen keine Refresh Tokens rotiert oder gespeichert werden.
Sichere Wiederholungsversuche (Retries). Jede Änderung akzeptiert einen Idempotency-Key-Header. Wird eine Anfrage mit demselben Schlüssel wiederholt, gibt das System die gespeicherte Antwort zurück, statt versehentlich eine zweite Rechnung anzulegen.
Signierte Webhooks mit Retries. Ereignisse werden in derselben Datenbanktransaktion wie die Änderung geschrieben, mit HMAC-SHA256 signiert und etwa 24 Stunden lang bei Fehlschlägen wiederholt.
Ein einziges, veröffentlichtes Rate Limit. 300 Anfragen pro Minute und API-Key, ausgewiesen in x-ratelimit-*-Headern.
Typisierte SDKs in neun Sprachen, generiert aus einer einzigen OpenAPI-Spezifikation. Siehe SDKs.
Unbegrenzte Sandbox-Unternehmen unter einem einzigen Account für Integrationstests.
Eine transparente Preisliste. Die Tarife werden nach Aufrufen abgerechnet, beginnend bei 10 € pro Monat für 3.000 Anfragen. Siehe Preise.

Das doppelte Buchhaltungssystem, Rechnungen, Bankabgleich, Umsatzsteuervoranmeldungen und Berichte stehen über dieselbe API zur Verfügung, sodass die Integration die Buchhaltung selbst abbildet und nicht nur eine bloße Kopie davon. Die Funktionen-Seite listet die enthaltenen Features auf, und unser Beitrag Was ist eine Buchhaltungs-API? erklärt das zugrundeliegende Modell im Detail.

Kunden, die ihre Bücher bereits woanders führen

Zwei Mechanismen ersetzen die anbieterspezifischen Connectors, die eine Plattform für solche Kunden ansonsten entwickeln müsste:

Datenmigration. Kontenrahmen, Geschäftspartner, Eröffnungsbilanzen oder die vollständige Journalhistorie, offene Rechnungen, Anlagegüter und Bestände werden in einem einzigen Aufruf importiert. Siehe Migration von einem anderen System.
Dateiexporte für den Steuerberater. Wenn der Steuerberater eines Kunden in einer eigenen Software arbeitet, exportiert Nordlet das Hauptbuch in den Formaten, die diese Software einlesen kann: als DATEV-Buchungsstapel (POST /v1/reports/datev) für deutsche Steuerberater und als SIE 4-Datei (POST /v1/reports/sie) für schwedische Anwender. Ein Dateiexport erfordert weder eine Anmeldung, noch einen Token-Refresh oder gebührenpflichtige Aufrufe seitens des Buchhaltungsanbieters.

Wann Connectors nach wie vor die richtige Wahl sind

Die Buchhaltung im eigenen Produkt zu führen, ist nicht für jede Plattform der optimale Weg:

Wenn die Finanzteams Ihrer Kunden darauf bestehen, dass ihr bestehendes Buchhaltungssystem das führende System (System of Record) bleibt, benötigen Sie Connectors zu diesem System – entweder direkt entwickelt oder über eine Unified API.
Wenn Sie lediglich ein paar Dokumente in die Bücher des Kunden übertragen müssen, etwa eine Rechnung pro Bestellung, reicht unter Umständen eine direkte Anbindung an den Anbieter, den die Mehrheit Ihrer Kunden nutzt.
Wenn die überwiegende Mehrheit Ihrer Kunden denselben Anbieter verwendet, verursacht eine einzelne direkte Integration nur ein einziges Projekt, nicht sechs.

Das Argument für die einmalige Integration greift dann, wenn Ihre Plattform die Buchhaltung ihrer Nutzer aktiv betreiben und nicht nur spiegeln muss: Marktplätze, die Auszahlungen an Verkäufer abwickeln, Plattformen, die im Namen ihrer Nutzer Rechnungen stellen, und SaaS-Produkte, bei denen die Buchführung integraler Bestandteil des Produkts ist. Bevor Sie sich für einen Weg entscheiden, listet unser Testplan vor dem Livegang einer Buchhaltungs-API auf, was Sie im Vorfeld testen sollten.

FAQ

Wie lange dauert die Entwicklung einer QuickBooks-Integration?

Apideck veranschlagt drei bis vier Wochen für eine erste funktionierende Version durch einen kompetenten Entwickler. Ein Rutter-Kunde schätzte den Aufwand auf zwei Entwickler für ein paar Monate und benötigte letztlich mindestens drei Monate mit mehreren Iterationen. Die Arbeiten für den Produktivbetrieb – Token-Erneuerung, Retries, Rate Limits, Wiederverbindung und Abgleich – machen den Unterschied zwischen diesen Werten aus.

Wie lange dauert eine NetSuite-Integration?

Rutter beziffert den Zeitrahmen für NetSuite auf sechs bis zwölf Monate. NetSuite bringt kontoweite Parallelitätslimits, siebentägige Refresh Tokens, SuiteQL parallel zu SOAP sowie angekündigte Änderungen mit sich: Keine neuen tokenbasierten Integrationen ab Version 2027.1 und die Deaktivierung von SOAP-Endpunkten in Version 2028.2.

Eliminiert eine vereinheitlichte Buchhaltungs-API (Unified API) den Aufwand pro Anbieter?

Sie reduziert den Entwicklungsaufwand, da eine einzige Schnittstelle mehrere Anbieter abdeckt. Sie beseitigt jedoch nicht die Unterschiede zwischen den Anbietern: Schreibvorgänge, benutzerdefinierte Felder und Sonderfälle werden oft unterschiedlich gut unterstützt, und die Lizenzkosten der Unified API kommen zu den API-Gebühren der Anbieter noch hinzu. Die Vor- und Nachteile werden in unserem SaaS-Integrationsleitfaden beleuchtet.

Was kostet der API-Zugriff auf QuickBooks und Xero?

Das App Partner Program von Intuit bietet eine kostenlose Builder-Stufe sowie kostenpflichtige Tarife zu 300 USD, 1.700 USD und 4.500 USD pro Monat, wobei Datenlesevorgänge oberhalb eines Freimonts berechnet werden. Xero-App-Tarife, die seit dem 2. März 2026 gelten, reichen von einem kostenlosen Tarif für 5 Verbindungen bis hin zu 1.445 AUD pro Monat für 10.000 Verbindungen; größere Tarife sind auf Anfrage erhältlich.

Kann Nordlet die Integrationen mit den Buchhaltungssystemen meiner Kunden ersetzen?

Wenn Ihre Plattform die Buchführung ihrer Nutzer selbst übernimmt: ja. Sie entwickeln eine einzige Integration mit der API von Nordlet anstelle einer pro Buchhaltungsanbieter. Bestehende Bücher werden in einem Aufruf importiert, und Steuerberater, die DATEV- oder SIE-kompatible Software nutzen, erhalten entsprechende Exportdateien. Nordlet synchronisiert Daten jedoch nicht in QuickBooks, Xero, NetSuite oder Business Central hinein. Wenn diese Systeme das führende System bleiben müssen, sind weiterhin direkte Connectors dorthin erforderlich.