Datev vs. Integrierte Buchhaltung

Dieses Thema wird natürlich bei jedem Projekt heiß diskutiert. 

Der Hintergrund ist ganz klar, eine integrierte Buchhaltung und eine sofortige Rückmeldung der damit verbundenen, diversen Aspekte ist mehr als nur eine charmante Sache. Das Einfachste ist die Rückmeldung des Zahlstatus‘ einer Rechnung und der damit verbundenen Forderung, womit ein integriertes Mahnwesen möglich ist, was wiederum den Mahnstatus des Kunden für Vertrieb und Verkauf transparent darstellt.

Und natürlich erspart man sich eine Finanzsoftware und benötigt eine Brücke, unabhängig, ob bidirektional oder unidirektional, ob manuell oder automatisiert.

Doch warum die Diskussion?

Hier der aktuelle Stand aller relevanten Informationen, beginnend bei den bekanntesten Vertretern:

Datev

Pro Datev

Datev ist der Platzhirsch in Deutschland. Und wahrscheinlich auch nur aus diesem Grunde führt man überhaupt diese Diskussion. Datev erscheint unfehlbar und 100% sicher. Ob dem wirklich so ist, oder ob das Image ähnlich ist wie das von SAP, das besagt, dass es keine gescheiterten SAP Implementierungen gibt, und wenn doch, dann lag es nicht an der Wahl des Systems, kann man wohl nicht genau sagen. Denn weder gibt es ein unfehlbares System und noch weniger eines, das jede Art von Fehleingabe verhindern kann. Denn das System würde es nur aus dem Grunde verhindern, weil es niemand schaffen könnte, auch nur die kleinste Information darin zu erfassen.

Doch das Gefühl an Sicherheit macht sicherlich den größten Anteil an der Datev Vorherrschaft aus. Die Tatsache, dass Odoo in Deutschland nicht zertifiziert ist, trägt ein übriges dazu bei. Hinzu kommt, dass die meisten Fachkräfte die Erfahrung im Umgang mit Datev oder den bekanntesten Alternativen haben.

Diese Punkte sprechen also eindeutig für Datev.

Schnittstellen und Datenaustausch

Es bleibt weiter gut, denn Datev hat immerhin einen CSV Export für Stapelbuchungen und einen XML Export für belegbezogene Buchungen und seit neuerdings eine REST-API. Über den Export ist auf jeden Fall der Weg zu Datev tatsächlich gesichert. Die REST-API kennen wir aktuell noch nicht gut genug um genau sagen können, was im Detail ausgetauscht werden kann und was an Informationen wiederum abgefragt werden kann, doch an sich sind die Hoffnungen und Erwartungen groß.

Was auch immer Teil des Datenaustausches sein wird, es bleibt bei einer Anbindung, und eine Anbindung ist kostenintensiv in der Implementierung und ebenso kostenintensiv in der Unterhaltung. Dazu gibt es so oder so immer einen Zeitversatz in der Aktualität auf jeder Seite, solange keine API im Einsatz ist.

Und diese Punkt sind zu bedenken, und sie sprechen nicht nur gegen Datev, sondern natürlich auch gegen Alternativen.

Der Datentransfer selbst

Welche Daten sind betroffen, was ist kritisch und was nicht?

Im Grunde gibt es maximal 2 Kategorien an Daten (Stammdaten und Bewegungsdaten), doch Datev gliedert sie auf in 4 Kategorien: Stammdaten, Konten, Kostenstellen und Buchungen. Das Gute ist, dass im Gegensatz zu Shop-Anbindungen, ein bidirektionaler Datenaustausch bei keiner Kategorie wirklich notwendig ist. Denn die Stammdaten sind meist im ERP am aktuellsten. Getätigte Buchungen werden grundsätzlich nicht geändert, sondern maximal durch Gegenbuchungen korrigiert. Wenn neue Konten und Kostenstellen angelegt werden müssen, dann auch nur im führenden System. Dies kommt bei einem einmal festgelegt Kontenrahmen so oder so eher selten vor, solange nicht von Debitoren und Kreditoren die Rede ist. Dies nimmt einen großen Teil an Brisanz heraus.

Doch betrachten wir die Punkte im Einzelnen:

Stammdaten

Die Stammdaten sind der vielleicht unkritischste Punkt, daher wird er hier auch als erster behandelt.

Grundsätzlich gibt es eine für den Import von Debitoren und Kreditoren dedizierte Beschreibung und somit auch eine Datei, doch die zu übermittelnde Anzahl von Spalten ist so immens umfangreich, dass eine Entwicklung sehr aufwendig wäre. Dabei wären die Stammdaten hauptsächlich für einen Mahnprozess notwendig, der in der Regel im ERP durchgeführt wird. Daher hat dieser Datenübertrag nicht die höchste Priorität, zumal Adressdaten mit dem Buchungssatz mitgegeben werden können.

Buchungen

Am Ende des Tages generiert Odoo ebenfalls einen Buchungsstapel, egal, ob dieser im Hintergrund durch die entsprechende Anlage der Belege generiert wird oder vom Benutzer direkt. Da einmal gebuchte Buchungen nicht mehr verändert werden können, durchläuft ein Export einfach nur den bereits bestätigten Buchungsstapel und übermittelt diesen an eine API oder in eine Datei. Bei Datev muss hier lediglich unterschieden werden, ob es zu der Buchung einen Beleg gibt, dann erfolgt der Export in eine XML, andernfalls in eine CSV. Theoretisch wäre auch nur eine CSV denkbar.

Dieses Vorgehen setzt natürlich voraus, dass der Kontenplan und alle in den Buchungen hinterlegten Zuweisungen mit Datev oder der Finanzsoftware übereinstimmen.

Da Odoo nach einem erfolgreichen Exportdurchlauf die exportierten Buchungssätze als „exportiert“ markieren kann, wäre sichergestellt, dass es zu keinem Doppeltexport kommen kann.

Ob der umgekehrte Fall notwendig ist, ist sehr stark vom Aufsatz abhängig. Erfolgt die Mahnung in Odoo, geht es nicht anders. Ist dies nicht der Fall, ist ein Rückimport eher Luxusware, denn auch die Ergebnisse eines Monats- oder Jahresabschlusses sind wenig ERP relevant. Aber klar, auch wenn sie irrelevant ist, sollte man überlegen, ob eine Abstimmung beider Seiten nicht sogar Sinn machen würde und zwar nur aus einem Grund: Wenn es zu Differenzen kommt, muss es Ansätze geben, von denen aus man ins Detail gehen kann, um den Grund für die Differenzen zu finden. Wenn auf jeweils einer Seite immer ein Stück von der Gegenseite fehlt, kann der Aufwand hier größer und quälender werden.

Doch soll das Mahnwesen in Odoo durchgeführt werden, weil es mehrsprachig ist und Datev womöglich nicht oder weil der Mahnstatus für die Lieferungen oder für einen Vorkassenprozess notwendig ist, müssen wenigstens die Zahlungen zurückgebucht werden können. Denn der Status einer Rechnung ist im Kern zwar ein physikalisch existierendes Feld, doch dieser Wert kann nicht manuell von einem Benutzer bestimmt werden, sondern wird vom System errechnet und auf Basis der offenen Posten zugewiesen. D.h. der Saldo ergibt sich automatisch aus der Differenz der miteinander verbundenen Buchungen für die Forderung bzw. Verbindlichkeit und der Buchung für die Zahlung.

Wie das Szenario mit der REST API von Datev ausschaut, können wir aktuell noch nicht sagen, demnach bleibt nur ein dateibasierter Export an Odoo. Hier unterstützt Datev auch eine „XML Variante“, doch diese ist eigentlich nur eine CSV in einer XML, mehr nicht. Das CSV ist ein reiner Stapelexport der vorab markierten Buchungen. Und hier liegt die Krux, denn die Buchungen müssen vorher in Datev markiert und können erst dann exportiert werden. Einen Delta Export – à la „gib mir alles, was noch nicht exportiert wurde“ – gibt es natürlich nicht.

Fehlerunanfällig ist etwas anderes, aber wenn es nicht anders geht, dann muss man den Weg gehen. Womöglich ändert sich dies in der Zukunft über die API.

Konten

Auch hier bietet Datev einen dedizierten Import zur Anlage der Konten an. Doch wie oft ändert sich ein Kontenrahmen, wenn man mal Debitoren und Kreditoren ausklammert? Da dies nicht sehr häufig vorkommen wird bzw. sollte, ist die Nutzung dieses Punktes nicht notwendig, besonders wenn man für die Ausnahmen Datev als das führende System definieren kann und somit jedes angelegte Konto in Odoo ebenfalls angelegt werden müsste.

Problematik Debitoren/Kreditoren

Problematischer wird es bei Debitoren und Kreditoren, denn hier gibt es zwei verschiedene Denkansätze in Datev und Odoo.

Odoo pflegt in den Stammdaten ein verstecktes Feld namens „Commercial Partner“ oder auf Deutsch „gewerbliche Einheit“. Legt ein Benutzer ein Unternehmen an, ist in dem Feld die eigene Datenbank ID hinterlegt. Legt der Benutzer einen Kontakt an, ist dort die Datenbank ID des zugehörigen Unternehmens hinterlegt. Wird also eine Rechnung erstellt, egal, ob diese an das Unternehmen adressiert wird oder an die abweichende Rechnungsadresse, wird bei der Validierung der Buchungssatz geschrieben. Dabei erfolgen mehrere automatische Zuordnungen:

• Erlöse/Aufwand

  Jedes Produkt hat eine Warengruppe. Entweder dort oder am Produkt können ein Erlös- und ein Aufwandskonto konfiguriert werden. Diese Information wird zur Verbuchung von Erlös respektive dem Aufwand genutzt

• Steuern

  Durch den am Produkt hinterlegten Steuersatz und die am Kunden bzw der Rechnung konfigurierte Steuerzuordnung ergibt sich die Steuerkonsequenz. Dies sollte eine erhebliche Erleichterung in der Buchhaltung bedeuten.

• Forderung/Verbindlichkeit

  Bei Anlage der Rechnung wird das Debitor- bzw. Kreditorkonto vom Kunden oder Lieferanten gezogen und der Rechnung zugewiesen bzw. bei der Formulierung des Buchungssatzes genommen und diesem der jeweilige Bruttowert aus der Rechnung zugewiesen.

Das Prinzip ist gleich, egal ob Ausgangs- oder Eingangsrechnung bzw. Ausgangs- oder Eingangsrechnungskorrektur.

Doch wird in den Buchungssatz grundsätzlich der Commercial Partner bzw. die gewerbliche Einheit in ein separates Feld geschrieben. Somit ist egal, um welches Konto es geht oder um welche Kontenstruktur oder ob diese vielleicht sogar gänzlich umgebaut wurde. Über diese Verknüpfung können grundsätzlich immer über die Kunden- oder Lieferantenkarteikarte die mit dem Partner verbundenen Buchungen geholt und eingesehen werden. Dies funktioniert natürlich in beide Richtungen, denn so kommt man vom Partner (also vom Kunden oder Lieferanten) zu den Buchungen oder von einer Buchung auf das komplette Datenblatt des Debitoren bzw. Kreditoren und von dort wieder zu allen Buchungen oder allen Rechnungen, Aufträgen, oder was auch immer als Information benötigt wird und wofür der Benutzer eine Berechtigung hat.

D.h. an sich spielt es in Odoo keine Rolle, mit einem allgemeinen oder einem dedizierten Konto pro Partner zu arbeiten. Die eigentliche Forderung oder Verbindlichkeit wird über die Commercial Partner Zuweisung gesetzt. Das heißt aber natürlich auch, dass man in der Stammdatenpflege Rechnungsadressen nicht umschreiben sollte!

Da dies Odoo deutlich flexibler macht, ist das System im Standard so aufgesetzt, dass es auf ein allgemeines Konto bucht, das sogar das Konto des Hauptbuches ist. Mir ist bewusst, dass dies zu einem Aufschrei in der Buchhaltung kommt, doch hierauf werden wir separat eingehen. Der Hintergrund, warum das so ist, ändert an diesem Punkt nicht, dass es so ist. Denn Datev arbeitet hier mit einzelnen Konten im Nebenbuch und es wird auf ein Konto im Hauptbuch hochkonsolidiert. Odoo wiederum schreibt auf das Hauptbuch und legt demnach keine separaten Konten an, dafür muss es nicht hochkonsolidieren. Mit anderen Worten, hier treffen zwei unterschiedliche Ansätze aufeinander.

Natürlich kann man Odoo beibringen, dass es bei Auftrags- bzw. Rechnungsbestätigung an einen Kunden prüft, ob es der erste Auftrag oder die erste Rechnung ist, so dass vorab ein Konto für den Partner angelegt und das allgemeine Konto gegen dieses ausgetauscht werden kann. Damit ist man in der Logik Datev.

Doch dies bedeutet auch, man muss das Konto vor einem Export an Datev erst einmal manuell in Datev anlegen. Ein weiterer Nachteil stellt sich in Odoo ein. Die Konten, die in Datev zum Hauptbuch gehören, sind in Odoo natürlich so konfiguriert, dass sie in der Bilanz erscheinen. Da nun keine Konsolidierung vom Nebenbuch ins Hauptbuch in Odoo erfolgt, ist demnach das Konto, ebenso wie der Punkt in der Bilanz. Alternativ ist es natürlich möglich, die einzelnen Debitoren- und Kreditoren-Konten bei der automatischen Anlage als bilanzrelevant zu konfigurieren, doch dann wird jedes einzelne Konto in der Bilanz ausgewiesen, was natürlich – dem Szenario angepasst – korrigiert werden kann.

Kurzum, wie man es dreht und wendet, jeder der möglichen Ansätze ist nicht ganz zufriedenstellend. Am Einfachsten wäre womöglich ein Rückimport aus Datev, doch wie gesagt, auch hier ist eine Fehlerquelle enthalten.

Dies kann man nur durch gemeinsame Abstimmung lösen.

Kostenstellen

Odoo verknüpft die Kostenstelle ebenfalls in den Buchungssatz. Da jeder Buchungssatz einzelne Zeilen generiert, können tatsächlich mehrere Kostenstellen innerhalb einer Sachbuchung angesprochen werden und somit kann die Information ebenfalls exportiert und an Datev übermittelt werden.

Ob dies jedoch tatsächlich notwendig ist, bleibt die entscheidende Frage. Denn jede Art von Kostenstelle ist eine betriebswirtschaftliche Auswertungsebene und wenig relevant für die Sachbuchhaltung, für Monats- oder Jahresabschlüsse. Das Gleiche gilt auch für Umbuchungen innerhalb der Kostenstellenstruktur, sei es zur Auflösung von allgemeinen Kosten auf Projekte oder zur Umbuchung von Materialien.

Sollte es jedoch mitgeführt werden, so wäre Odoo ebenfalls als führendes System zu betrachten. Nach der Anlage eines neuen Projektes, einer Kostenstelle, eines Kostenträgers, etc. müsste dies noch vor einem Export in Datev angelegt werden.

Die Konfiguration

Natürlich müssen Odoo und Datev abgestimmt konfiguriert werden. Dabei sind die angesprochenen problematischen Punkte mit besonderem Augenmerk zu berücksichtigen. Durch den manuellen Export ist es in den einzelnen Bereichen umso entscheidender, das führende System zu bestimmen.

Odoo

Man könnte meinen, das alles, was gegen Odoo spricht pro Datev ist und umgekehrt. Doch ganz so einfach ist es nicht. Daher: Was spricht für Odoo und was muss bei einem Aufsatz bedacht werden?

Was spricht für Odoo?

Was eindeutig für Odoo spricht, ist die in der Einleitung genannte real-time Verarbeitung der Belege und direkte Verfügbarkeit der Informationen in allen anderen Modulen, also das direkte Zusammenspiel aller Komponenten. Ebenfalls dafür spricht, dass es keine Übersetzung zwischen unterschiedlichen Logiken geben muss, denn jede Übersetzung ist fehleranfällig und wartungsintensiv, und dies ganz besonders in der Bereinigung von Fehlern, denn dabei muss die Logik der externen Komponente mit bedacht werden.

Bei wachsender Anzahl der zu verarbeitenden Datenmengen sollte die Anzahl der Spieler auf dem Spielfeld reduziert werden, um Schnittflächen und Sollbruchstellen zu reduzieren. Die Nutzung der Buchhaltung ist das Naheliegendste, denn zusammenfassend kann man sagen:

Odoo bringt ein paar neue Gedanken mit hinein, die für die sehr klassischen Systeme ungewohnt sind, aber eine Erleichterung darstellen, wenn man sie nutzt. Ansonsten sind die Prinzipien die gleichen, und Odoo, wenn es richtig aufgesetzt ist, spielt auch in der Buchhaltung nach den Regeln.

Was ebenso dafür spricht ist, dass durch die Nutzung der Module Verkauf, Einkauf und Lager bereits ein Großteil aller Geschäftsvorgänge soweit erfasst und vorbereitet ist, dass nach einer Prüfung die jeweils zu verbuchenden Informationen bereits bekannt sind. D.h. in diesem Fall, dass nach einer visuellen und inhaltlichen Prüfung direkt nach der Bestätigung die Generierung der Buchungssätze/-zeilen vom System vorgenommen werden kann. Und hierbei geht es nicht nur um die Erstellung von Ausgangsrechnungen oder die Prüfung und Verbuchung der Eingangsrechnungen und der dazugehörigen Zahlungen, sondern auch um die Bewertung der Warenbewegungen sowie der Anlage von Verträgen und somit um die Erstellung der darauf basierenden wiederkehrenden Buchungen.

Was muss bedacht werden

Um dies zu erwirken, müssen natürlich diverse Dinge beim Aufsatz und in der Nutzung bedacht werden:

Die technische Basis

Das Wichtigste ist, dass keine Module installiert sind, die die Revisionssicherheit gefährden oder untergraben. Hierzu haben wir einen seperaten Blog veröffentlicht

Dazu gehört das Stornieren einer bestehenden Buchung ohne Gegenbuchung und die Möglichkeit, generierte Rechnungsbelege löschen zu können.

Fachpersonal

Auch wenn Odoo durch die Vorkontierung der Geschäftsvorfälle einen Teil der Arbeit übernimmt, wird es bei der Verbuchung von Bankkonten, Ausbuchung von Forderungen, beim Erfassen von Quittungen, oder bei der Umbuchung auf Grund von falschen Stammdaten oder falsch verbuchten Vorfällen, also bei der Bewertung und richtigen Erfassung der Informationen, nicht viel einfacher als in anderen Systemen. Dies sollte folglich von einem Benutzer mit entsprechenden Kenntnissen in der Buchhaltung durchgeführt werden.

Schulung

Und ebenso wichtig ist natürlich die Durchführung einer Schulung durch eine Person, die die typischen Anwendungsfälle kennt und im Fachjargon Fragen beantworten kann. Dabei geht es nicht nur um die Schulung in der richtigen Anwendung des Moduls, sondern auch darum, Vertrauen ins System zu schaffen. Denn unabhängig davon, dass Odoo eine webbasierte Anwendung und ein unbekannter Name ist, sind gedanklich neue Ansätze integriert worden, deren Vorteile ebenfalls erklärt und gezeigt werden müssen. Dies ist notwendig, um Bedenken zu nehmen und nicht nur Vertrauen in die gleichen Ergebnisse zu schaffen, sondern auch um ein Verständnis für diesen Ansatz zu vermitteln, damit der Vorteil auch wirklich ein Vorteil wird.

Fehlende Zertifizierung

Nun verbleibt der letzte Kritikpunkt. Odoo hat bislang keine Zertifizierung in Deutschland erlangt. Auch wenn dies an sich kein Hexenwerk ist, existiert aktuell noch kein GoBD-konformer Export. Doch dieser Export ist eine Empfehlung und muss nicht zwingend von einer Software bereitgestellt werden. Voraussetzung ist natürlich, dass man Einzelbuchungen auf einem Konto nachweisen und ausdrucken kann (wird von Odoo erfüllt) und zu jeder belegbezogenen Buchung dieser Beleg bereit gestellt werden kann (wird von Odoo erfüllt) und dass die Belege unveränderbar sind (auch dies kann erfüllt werden, siehe oben „Technische Voraussetzungen“).

Die Anbindung an Datev betreffend bedeutet dies, dass es nicht ausreichend ist, monatlich eine SuSa mit Datev abzugleichen, sondern hier ein Export der Einzelbuchungen erfolgen sollte. Doch würde auch in Odoo ein Monatsabschluss erstellt werden, können die dazu gehörigen Buchungen Teil des Stapelexports an Datev sein. Doch in diesem Fall würde Odoo als führendes System genutzt und Datev für den Jahresabschluss, wobei dies auch auf Basis der Einzelbuchungen erfolgen könnte.

Fazit

Odoo erfüllt technisch und strukturell die Vorgaben, eine umfassende Buchhaltung ordentlich zu integrieren. Da es jedoch einen internationalen und einen generischen Ansatz verfolgt, sind teilweise zu viele Dinge erlaubt und offen, die in Deutschland definiert und reglementiert sind. Dies muss beim Aufsatz bedacht und entsprechend umgesetzt werden. Hier ist der größte Teil durch Konfiguration lösbar, aber ein Teil bleibt programmatisch.

Da wir die Details nicht genau kannten und demnach den Umfang nicht genau abschätzen konnten, haben wir (wie wahrscheinlich viele andere) auf den Datev-Export gesetzt, mit allen damit verbundenen Diskussionen und halbherzigen Lösungen, wenn es um die Rückführung der Daten ging. Doch abhängig von der Projektgröße und der Besetzung der Buchhaltung beim Kunden, gehen wir auf eine integrierte Lösung. Denn auch wenn eine Alternative im Einsatz ist, die eine deutlich bessere API zur Verfügung stellt, würde dies einen höheren Aufwand im Aufsatz bedeuten, um diese API entsprechend nutzen zu können. Obendrein müssten auch hier unterschiedliche Logiken miteinander verknüpft werden.

Doch eine Präferenz bleibt eine Präferenz. Zum einen muss in jedem Projekt mit Vernunft und Augenmaß an die Entscheidung herangegangen werden. Außerdem müssen die einzelnen Pros und Cons bewertet werden, was dann zur Entscheidung führt, wie viel von dem einen und wie viel von dem anderen genutzt wird. Auch wenn Odoo eine Zertifizierung erreichen wird, erledigt sich das Thema und dieses Augenmaß wohl erst einmal nicht. Denn dazu wird Odoo erst einmal bekannter werden und somit einen besseren Stand im Punkt „Vertrauen“ erlangen müssen.