Build vs. Buy

Viele Produktteams starten bei DATEV-Integrationen mit einer scheinbar einfachen Frage:

Können wir die DATEV-Schnittstelle nicht selbst bauen?

Die ehrliche Antwort: Ja, oft könnt ihr das.

Ein guter Entwickler bekommt in vielen Fällen einen ersten Zugriff hin. Ein Prototyp ist selten das größte Problem. Die eigentliche Frage ist eine andere:

Wollt ihr über Jahre selbst lernen, wie DATEV-Integration in echten Kanzlei-Umgebungen betrieben wird?

Denn zwischen einem erfolgreichen API-Call und einer belastbaren DATEV-Schnittstelle für viele Kanzleien liegt ein großer Unterschied. Genau dort entscheidet sich Build vs. Buy.

Die eigentliche Frage ist nicht nur „bauen oder kaufen“

Bevor ihr über Eigenentwicklung oder fertige Infrastruktur entscheidet, müsst ihr klären, was ihr wirklich integrieren wollt.

Nicht jede DATEV-Schnittstelle ist gleich.

Typische Use Cases sind:

• Stammdaten aus einem CRM nach DATEV übertragen
• Mandanten oder Adressaten aus einem Onboarding-Formular anlegen
• Dokumente und Metadaten aus DATEV DMS abrufen
• Rechnungswesen-Daten für Reporting oder Power BI nutzen
• Belege oder Rechnungen aus einem Shopsystem übertragen
• DATEV-Daten für AI-, MCP- oder Workflow-Szenarien lesbar machen

Diese Use Cases haben unterschiedliche technische Wege. Manchmal reicht DATEVconnect. Manchmal sind DATEV Online APIs relevanter. Manchmal braucht es tieferen Zugriff auf DATEV Desktop-Daten. Manchmal ist eine fertige Standardintegration besser als ein individuelles Projekt.

Deshalb ist „Build vs. Buy“ keine abstrakte Architekturfrage. Es ist eine Use-Case-Frage.

Was „Build“ bei einer DATEV-Schnittstelle wirklich bedeutet

Build klingt erstmal klar:

Ihr lest die API-Dokumentation, baut einen Connector, integriert ihn in euer Produkt und seid fertig.

In der Praxis ist das zu kurz gedacht.

Eine eigene DATEV-Schnittstelle bedeutet nicht nur Entwicklung. Sie bedeutet auch Betrieb.

Ihr müsst typischerweise klären:

• Welche DATEV-Daten werden gebraucht?
• Liegen sie in DATEV Desktop, DATEV DMS, Rechnungswesen, Stammdaten oder DATEV Unternehmen Online?
• Ist DATEVconnect für den Use Case ausreichend?
• Wird nur gelesen oder auch geschrieben?
• In welchem Benutzerkontext erfolgt der Zugriff?
• Welche Rechte braucht der Benutzer in DATEV und im Windows-Umfeld?
• Läuft die Kanzlei lokal, in DATEVasp oder in PARTNERasp?
• Wer installiert und betreibt den lokalen Dienst?
• Wer überwacht den Connector?
• Wer debuggt Fehler bei Kunden?
• Wer spricht mit Kanzlei-IT, Hosting-Partnern und Produktteam?
• Wer erkennt, ob ein Problem an DATEV, an Rechten, am Netzwerk, am lokalen Windows-Service oder an eurer Anwendung liegt?

Das ist der Teil, der in vielen Build-Rechnungen fehlt.

Der Prototyp ist selten das Problem

Ein funktionierender Prototyp beweist nur, dass der technische Weg grundsätzlich möglich ist.

Er beweist nicht, dass ihr den Betrieb verstanden habt.

In echten DATEV-Umgebungen treten Probleme auf, die nicht in einer sauberen Entwicklungsumgebung sichtbar werden:

• Rechte fehlen, obwohl die Installation formal korrekt aussieht
• ein Windows Service läuft, aber der Zugriff im Benutzerkontext passt nicht
• DATEVasp oder PARTNERasp verhalten sich anders als lokale Setups
• eine Kanzlei hat mehrere Anbieter im selben DATEV-Umfeld
• DMS-Dokumente sind für einen Benutzer sichtbar, für einen anderen aber nicht
• Updates verändern Randbedingungen
• IT-Partner haben eigene Sicherheitsregeln
• der Kunde beschreibt ein Fachproblem, tatsächlich ist es ein Infrastrukturproblem
• Monitoring zeigt „Service läuft“, aber DATEV-Zugriff schlägt trotzdem fehl

Das ist kein Randthema. Das ist der Alltag einer produktiven DATEV-Schnittstelle.

Der Vorsprung liegt nicht nur im Code. Der Vorsprung liegt in den Fehlerbildern, die man schon gesehen hat.

Die Technik ist nicht der größte Burggraben

Viele Teams überschätzen die Schwierigkeit des ersten technischen Zugriffs und unterschätzen den Wert von Produktionshistorie.

Nach ein paar Wochen kann ein gutes Team oft einen ersten Connector bauen.

Nach mehreren Jahren weiß ein gutes Team, welche Dinge in echten Kanzleien regelmäßig schiefgehen.

Das ist ein anderer Wert.

Es geht nicht nur darum, eine API anzusprechen. Es geht darum, über viele Kanzleien hinweg Muster zu erkennen:

• Welche Rechteprobleme treten immer wieder auf?
• Welche Kanzlei-IT-Fragen kommen vor jeder Installation?
• Welche DATEVasp-Setups brauchen besondere Abstimmung?
• Wo wird Benutzerkontext kritisch?
• Welche Fehler sind technisch, welche organisatorisch?
• Welche Daten sind über DATEVconnect erreichbar und welche nicht?
• Wann sollte man einem Kunden sagen: Dieser Weg ist nicht der richtige?

Wer selbst baut, muss durch denselben Lernprozess. Es gibt keine Abkürzung, die mehrere Jahre Produktionsbetrieb vollständig ersetzt.

Das unterschätzte Asset: ein erfahrenes DATEV-Integrationsteam

Build heißt nicht: „Wir stellen zwei Entwickler ab.“

Ein belastbares DATEV-Integrationsteam braucht mehrere Kompetenzfelder gleichzeitig:

• DATEVconnect und DATEV Desktop APIs
• DATEV DMS, Rechnungswesen und Stammdaten
• DATEV Online APIs und deren Abgrenzung zu Desktop-Szenarien
• DATEVasp, PARTNERasp und lokale DATEV-Installationen
• Windows Services, Benutzerrechte, Domain-Setups und Netzwerk
• Kanzlei-Prozesse und typische Arbeitsweisen
• Supportkommunikation mit Kanzleien und IT-Partnern
• Produktgrenzen: Was geht, was geht nicht, was sollte man nicht versprechen?

Ein Team mit dieser Kombination ist kein Standard-API-Team.

Es sitzt an der Schnittstelle zwischen DATEV, Kanzlei-IT, Produktentwicklung und Betrieb. Genau diese Mischung ist schwer zu finden, schwer aufzubauen und schwer dauerhaft zu halten.

Für CTOs und Produktteams ist das der wichtigste Punkt:

Nicht fragen: Können wir das bauen?

Besser fragen: Wollen wir dieses Spezialgebiet dauerhaft selbst besitzen?

DATEVconnect, DATEV Online APIs und Enterprise API sauber trennen

Ein häufiger Fehler ist, „DATEV API“ als eine einzige Kategorie zu behandeln.

Das führt zu schlechten Architekturentscheidungen.

DATEV Online APIs und DATEVconnect lösen unterschiedliche Probleme. Entscheidend ist, wo die benötigten Daten liegen und welcher Workflow umgesetzt werden soll.

DATEVconnect ist relevant, wenn Daten in DATEV Desktop-Umgebungen liegen und über DATEVconnect-unterstützte Module erreichbar sind. Typische Bereiche sind DATEV DMS, Stammdaten, Rechnungswesen und weitere DATEVconnect-unterstützte Bereiche.

DATEV Online APIs sind für andere Szenarien relevant. Besonders bei DATEV Unternehmen Online muss man sauber prüfen, ob der gewünschte Workflow überhaupt ein DATEVconnect-Thema ist.

DATEV verweist für technische Details zu Desktop APIs und Online APIs auf das DATEV Developer Portal.

Wichtig ist auch:

DATEVconnect ist keine universelle API für alle DATEV-Daten.

Wenn DATEVconnect den benötigten Datenbereich nicht abdeckt, braucht ihr einen anderen Weg. Bei Reporting, Power BI, Controlling, Bescheidprüfung oder tieferen Desktop-Daten kann die Enterprise API besser passen.

Für DATEVconnect-basierte Integrationen ist das DATEVconnect Gateway der naheliegende Einstieg.

Wann Buy sinnvoller ist

Buy ist besonders sinnvoll, wenn DATEV-Zugriff eine Voraussetzung für euer Produkt ist, aber nicht euer eigentliches Kernprodukt.

Beispiele:

• Ihr baut ein TaxTech-Produkt und braucht DATEV-Daten.
• Ihr wollt CRM-Daten mit DATEV Stammdaten synchronisieren.
• Ihr wollt DMS-Dokumente aus DATEV in Workflows nutzen.
• Ihr wollt n8n, interne Portale oder Automatisierung mit DATEV verbinden.
• Ihr wollt mehrere Kanzleien anbinden.
• Ihr wollt euer Produktteam nicht mit Connector-Betrieb blockieren.

In solchen Fällen ist das DATEVconnect Gateway oft sinnvoller als Eigenentwicklung.

Das Gateway stellt Zugriff auf DATEVconnect-basierte Daten und Workflows bereit, ohne dass ihr den kompletten Connector-Betrieb selbst aufbauen müsst.

Das bedeutet nicht, dass keine technische Klärung mehr nötig ist. DATEV bleibt DATEV. Rechte, Umgebung, Benutzerkontext und Use Case müssen weiterhin sauber geprüft werden.

Aber ihr müsst nicht bei null anfangen.

Wann Build sinnvoll sein kann

Build ist nicht falsch.

Es gibt Fälle, in denen Eigenentwicklung sinnvoll ist:

• Ihr habt nur eine oder wenige kontrollierte DATEV-Umgebungen.
• Ihr habt bereits viel DATEV-Erfahrung im Engineeringteam.
• Ihr habt die Ressourcen im Team, um euch langfristig mit dem Thema beschäftigen zu können.
• DATEV-Integration ist strategischer Kern eures Produkts.
• Ihr wollt maximale Kontrolle über Architektur und Deployment.
• Ihr akzeptiert bewusst, dass Betrieb und Support intern liegen.

Dann kann Build richtig sein.

Aber dann sollte die Entscheidung ehrlich gerechnet werden. Nicht nur Entwicklung. Auch Betrieb, Support, Monitoring, Fehleranalyse, Kanzlei-IT-Kommunikation, Dokumentation und langfristige Wartung.

Eine DATEV-Schnittstelle ist kein einmaliges Projekt. Sie wird zu einem Teil eures Produkts.

Build vs. Buy ist auch eine Fokusentscheidung

Die härteste Ressource in einem guten Produktteam ist nicht Geld. Es ist Fokus.

Wenn euer eigentliches Produkt Reporting, Workflow, Kanzleisoftware, Dokumentenverarbeitung, CRM, AI oder Mandantenkommunikation ist, dann ist DATEV-Zugriff wahrscheinlich Infrastruktur.

Infrastruktur muss funktionieren. Aber sie muss nicht zwingend selbst gebaut werden.

Die zentrale Frage lautet:

Bindet eine eigene DATEV-Schnittstelle euer Team an ein Spezialproblem, das euch vom eigentlichen Produkt wegzieht?

Wenn ja, ist Buy oft die bessere Entscheidung.

Nicht, weil euer Team es nicht könnte. Sondern weil es andere Dinge bauen sollte.

Entscheidungsmatrix: DATEV-Schnittstelle selbst bauen oder kaufen

Kriterium	Build	Buy / DATEVconnect Gateway
Erster Prototyp	oft machbar	meist schnell, wenn Use Case passt
Produktionsbetrieb	komplett intern	durch bestehende Infrastruktur unterstützt
DATEVconnect-Erfahrung	muss aufgebaut werden	vorhanden
DATEVasp / PARTNERasp	selbst klären	bekannte Setup-Muster
Kanzlei-IT-Koordination	intern	gemeinsam strukturiert
Monitoring	selbst bauen	Teil des Betriebsmodells
Fehleranalyse	eigenes Team	weniger Connector-Last im Produktteam
Skalierung auf viele Kanzleien	anspruchsvoll	stärkerer Fit
Benutzerkontext	selbst modellieren	zentraler Architekturpunkt
Sonderdaten / tiefe Desktop-Daten	individuell lösen	Enterprise API prüfen
Kontrolle	maximal	geteilt
Fokus	bindet internes Team	Produktteam bleibt näher am Kernprodukt
Risiko	technischer Betrieb liegt intern	Anbieterabhängigkeit, aber weniger Eigenbetrieb

Die Tabelle zeigt den Kern: Build gibt Kontrolle. Buy reduziert operativen Schmerz.

Beides hat einen Preis.

Häufiger Fehler: API-Abdeckung mit Produktreife verwechseln

Eine API zu nutzen heißt nicht, dass das Produkt integrationsfähig ist.

Produktreife zeigt sich erst im Betrieb:

• stabile Installation
• nachvollziehbare Logs und Monitoring
• bekannte Fehlerbilder
• klare Supportprozesse
• sauberes Berechtigungsmodell
• verständliche Dokumentation und Updatefähigkeit
• klare Grenzen gegenüber Kunden

Gerade bei DATEV ist das entscheidend. Ein Kunde bewertet am Ende nicht, ob euer erster API-Call elegant war. Er bewertet, ob die Integration im Alltag funktioniert und ob Probleme gelöst werden.

Kosten: Nicht nur Lizenz gegen Entwicklerstunden rechnen

Viele Build-vs-Buy-Rechnungen vergleichen nur Lizenzkosten mit Entwicklungskosten. Das reicht nicht. Relevanter sind:

• Zeit bis zum produktiven Rollout
• Supportlast und Fehleranalyse
• Betrieb, Monitoring und Wartung
• Kundensetup und Kanzlei-IT-Abstimmung
• Dokumentation
• Opportunitätskosten im Produktteam
• Risiko durch Personalwechsel
• Lernkurve über echte DATEV-Umgebungen

Ein internes Team kann günstiger wirken, bis es dauerhaft Support für Integrationsinfrastruktur leisten muss. Der eigentliche Kostenblock ist nicht der Code. Es ist die Verantwortung.

Sicherheits- und Compliance-Fragen nicht nachträglich behandeln

Bei DATEV-Daten geht es oft um sensible Kanzlei- und Mandantendaten.

Deshalb müssen Sicherheitsfragen früh in die Architektur:

• Welcher Benutzer darf welche Daten sehen?
• Wird im Benutzerkontext gearbeitet?
• Welche Daten werden übertragen?
• Werden Daten dauerhaft gespeichert?
• Ist read-only für den Start ausreichend?
• Wie werden Zugriffe nachvollziehbar gemacht?
• Welche Rolle spielen Kanzlei-IT und technische Dienstleister?
• Welche §203-StGB- und DSGVO-Fragen müssen intern geprüft werden?

Gerade bei AI-Workflows ist read-only oft der bessere Start. Suchen, Zusammenfassen, Prüfen und Vorbereiten sind wertvolle erste Schritte. Direkte Schreibzugriffe in DATEV sollten nicht der Default sein.

Praktische Entscheidungsregel

Baut selbst, wenn DATEV-Integration euer strategischer Kern ist und ihr bereit seid, Betrieb und Produktionslernen dauerhaft zu tragen.

Kauft Infrastruktur, wenn DATEV-Zugriff wichtig ist, aber euer eigentlicher Wert woanders liegt.

Wenn euer Use Case auf DATEVconnect basiert, ist das DATEVconnect Gateway der naheliegende Startpunkt.

Wenn DATEVconnect nicht reicht, prüft die Enterprise API.

Wenn es um AI, MCP, DMS-Suche oder Workflow-Unterstützung geht, schaut euch Klarvos an.

FAQ

Kann man eine DATEV-Schnittstelle selbst bauen?

Ja. Ein erster technischer Zugriff ist für gute Entwickler oft machbar. Der größere Aufwand liegt meist nicht im Prototyp, sondern im Betrieb über echte Kanzlei-Umgebungen hinweg.

Wann lohnt sich ein DATEVconnect Gateway statt Eigenentwicklung?

Wenn der Use Case durch DATEVconnect abgedeckt ist und ihr nicht selbst Connector-Infrastruktur, Monitoring, Installation, Updates und Support bei vielen Kanzleien betreiben wollt.

Ist DATEVconnect eine vollständige DATEV API?

Nein. DATEVconnect bietet Zugriff auf DATEVconnect-unterstützte Daten und Module in DATEV Desktop-Umgebungen. Es ist keine universelle API für alle DATEV-Daten.

Was ist der Unterschied zwischen DATEVconnect und DATEV Online APIs?

DATEVconnect ist relevant für DATEV Desktop-Umgebungen. DATEV Online APIs adressieren Online- und Cloud-Szenarien. Entscheidend ist, wo die benötigten Daten liegen und welcher Workflow umgesetzt werden soll.

Funktioniert eine DATEV-Schnittstelle auch in DATEVasp oder PARTNERasp?

Ja, aber Setup und Betrieb müssen sauber abgestimmt werden. Der Connector muss normalerweise dort laufen, wo DATEVconnect erreichbar ist. In gehosteten Umgebungen braucht es oft Koordination mit Kanzlei-IT oder Hosting-Partnern.

Kann man über eine DATEV-Schnittstelle auch schreiben?

Teilweise, abhängig von Modul, API-Abdeckung, Prozess und Berechtigungen. Für viele Integrationen ist read-only der sinnvollere Start. Schreibzugriffe sollten bewusst geplant und fachlich abgesichert werden.

Welche DATEV-Daten eignen sich für eine Integration?

Typische Bereiche sind Stammdaten, DATEV DMS, Rechnungswesen und weitere DATEVconnect-unterstützte Module. Für tiefere Desktop-Daten oder spezielle Reporting-Anforderungen kann eine Enterprise-Integration notwendig sein.

Ist Buy teurer als Build?

Nicht zwingend. Build wirkt oft günstiger, wenn nur Entwicklung gerechnet wird. Realistisch müsst ihr Betrieb, Support, Monitoring, Kundensetup, Fehleranalyse, Kanzlei-IT-Koordination und langfristige Wartung einbeziehen.

Was ist bei mehreren DATEV-Anbietern in einer Kanzlei zu beachten?

Wichtig sind klare Rechte, Benutzerkontext, saubere Trennung der Zugriffe und eindeutige Verantwortlichkeiten. Das Problem ist nicht, dass mehrere Anbieter existieren. Das Problem ist ein unsauberes Setup.

Welche Klardaten-Lösung passt für welchen Fall?

Das DATEVconnect Gateway passt für DATEVconnect-basierte Integrationen. Die Enterprise API passt für tiefere DATEV Desktop-Daten, Reporting, Power BI, Controlling und Sonderfälle. Klarvos passt für AI- und Workflow-Szenarien auf DATEV-Daten.

Nächster Schritt

Eine DATEV-Schnittstelle zu bauen ist machbar. Sie über viele Kanzleien zuverlässig zu betreiben, ist der eigentliche Aufwand.

Wenn ihr DATEV-Zugriff braucht, aber nicht selbst mehrere Jahre Produktionslernen durchlaufen wollt, prüfen wir mit euch den passenden Weg: DATEVconnect Gateway, Enterprise API oder bewusst eigener Build.