Buchhaltungs-Software mit "intelligentem" Import

Hallo zusammen,

kennt wer eine Buchhaltungs-Software mit „intelligentem“ Import?

Also wir importieren regelmäßig die Transaktionen von Bank-Konten per CSV-Datei und verbuchen jede Transaktion manuell. Es gibt auch Programme, die auf Basis der in der Buchhaltung bereits vorhandenen Buchungen mit Maschinenlernen-Algorithmen bzw. „künstlicher Intelligenz“ für einen neuen Import Vorschläge erstellt, wie die neuen Transaktionen zu verbuchen sind, die dann manuell nur noch geprüft und in Einzelfällen korrigiert werden müssen. Sowas hätten wir gerne.

Hat wer nen Tipp? Vielleicht sogar ein als freie Software lizenziertes Produkt, das wir selbst auf Linux betreiben können ohne auf eine Cloud-Lösung angewiesen zu sein?

Es gibt hier verschiedene Ansätze: Das „intelligente Importieren“ von Bankumsätzen ist eine Standardfunktion von Buchhaltungsprogrammen - ich habe gute Erfahrungen mit Datev gemacht (wobei diese Importtätigkeiten durchs Steuerbüro gemacht wurden).

Wenn es allerdings um den Import von Spendendaten und Mitgliedsbeiträgen etc. geht, würde ich einen anderen Weg einschlagen: Diese Daten solltet ihr in CiviBanking importieren, habt dann sofortigen Zugriff (z.B. für das Erstellen von Spendendank-Briefen) und schiebt diese Daten jeweils erst nach dem Monatsende summarisch in die Buchhaltung.

Danke Detlev für die Rückmeldung!

Wenn ich das auf die schnelle richtig nachgesehen habe, unterstützt Datev nur Windows-Arbeitsplätze. Unser Standard-Arbeitsplatz ist Linux-basiert. Könnte man ein Windows reintun, möchte ich aber standardmäßig erstmal versuchen zu vermeiden.

Die Buchhaltungs-Standardlösung mit wenigen Anforderungen und für Linux ist GnuCash, und soweit ich das überblicke, kann GnuCash kein „intelligentes Importieren“. Derzeit nutzen wir LinHabu und das kann das auch nicht.

Aber vielleicht hat ja noch wer einen Tipp?

@RoWo-DS Was ich meinte, ist die Nutzung von „DatevUnternehmenOnline“, das ist ein Browser-basiertes (und Linux-erprobtes) Frontend mit dem Belege hochgeladen werden können und auch die Vorkontierung gemacht werden kann. Ebenso sind die Freigabe von Rechnungen und die Erstellung von Überweisungsdateien damit möglich. Für viele Organisationen scheint mir das eine gute Lösung zu sein.

Aber du hast recht, Daniel: Die volle Datev-Funktionalität (also selber im Backend buchen) benötigt weiterhin Windows.

Hallo zusammen,
ich möchte das Thema hier gerne nochmal aufgreifen, weil ich aktuell vor der gleichen Herausforderung stehe.

Wir möchten idealerweise automatisiert (zB per API) den Zahlungsstatus von Rechnungen aus Datev Unternehmen Online EXPORTIEREN und in CiviCRM IMPORTIEREN und dort dann entsprechend den vorhandenen Status nach einem Matching anpassen (Abgeschlossen, Storniert etc).

Ich bin noch nicht ganz sicher, ob ich das mit CiviBanking so bewerkstelligen kann oder ob ich hier stattdessen doch direkt das Bankkonto einbinden sollte.

Ich habe schon ein bisschen zur DATEV API recherchiert, aber so richtig schlau werde ich nicht, ob das geplante möglich ist.

Vielleicht hat hier jemand einen Erfahrungswert?

Hallo Lucas,

deine Frage scheint mir mehrere Aspekte zu haben:

  1. Export der Datev-Daten mittels Datev-API:
    Ich bin nicht sicher, ob hier überhaupt die Datev-API benötigt wird: Buchhaltungsprozesse sind nämlich immer „stapelorientiert“, ich würde also einfach zu festgelegten Zeiten (sinnvollerweise nach Monatsende, wenn im Datev alles gebucht ist) eine csv-Datei aus Datev exportieren. Diese sollte eine eindeutige Zuordnung der jeweiligen Zahlungen zu den CiviCRM-Kontakten bzw. den offenen Zuwendungen enthalten, z.B. über die „Externe ID“ oder die „Contribution ID“.

  2. Import der Daten mittels CiviBanking
    CiviBanking ist sehr flexibel konzipiert, indem es die Schritte „Import“ und „Verarbeitung“ voneinander trennt: Standardmäßig nutzt man einen „Importer“, der Daten aus der Bank ins CiviCRM übernimmt. Denkbar ist aber auch ein Importer, der stattdessen die aus dem Datev exportierte csv-Datei importiert - die dann mit besseren Identifikatoren ausgestattet ist und im nächsten Verarbeitungsschritt von CiviBank eine höhere Automatisierung ermöglicht.

  3. Alternativ statt CiviBanking: Import mit CiviCRM-Bordmitteln
    Unter Umständen ist es sinnvoll, mit CiviCRM-Bordmitteln zu arbeiten (also: „Import Contributions“, wo man auch vorhandene contributions anpassen kann), oder sich z.B. mit der Extension CiviCRM Advanced Import zu befassen. Dieser Lösungsweg scheint mir sinnvoll, wenn es sich um sehr spezifische Zahlungsprozesse handelt und hat den Vorteil, dass die Abläufe für die Anwender·innen noch besser automatisierbar sind.

Moin @detlev.sieber: Danke dir für das Feedback!

Ich habe mittlerweile auch feststellen müssen, dass DATEV (zumindest zur Zeit) keine Abfrage der entsprechenden Informationen über eine Online-API ermöglicht. Über eine On-Premise-API wäre es wohl möglich, das passt aber nicht zu unserem Use Case.

Ich werde mich dann Mal weiter mit dem Thema CSV-Export aus DATEV beschäftigen. Da aktuell nur mein Kunde Direktzugang hat, bin ich da noch nicht so tief eingestiegen.

Mit dem Import in Civi-Banking bin ich auch schon ein Stück weiter und werde dann versuchen, die CSV-Infos aus Datev entsprechend zu matchen.

Wenn ich da einen klaren Workflow habe, werde ich das hier nochmal teilen.

Viele Grüße,
Lucas

1 „Gefällt mir“

Hej zusammen,

eigentlich kommen hier viele Dinge zusammen, die man vorab klären sollte. Zuallervorderst: was ist das führende System?

CiviCRM ist, wie alle CRM, keine Buchhaltungssoftware (kurz: FiBu). Aber deren Exporte sind gut geeignet, um eine FiBu (wie Datev etc.) zu füttern. Zahlungseingänge kann man, wie @detlev.sieber schreibt, nach CiviCRM importieren und anschließend an die FiBu übergeben (wie auch immer, bspw. CSV). In diesem Fall wäre CiviCRM das führende System.

Andersrum wird auch ein Schuh draus: wenn die Zahlungsinformationen aus der FiBu nach CiviCRM importiert werden. Dazu gibt es verschiedene Methoden. Der Nachteil dabei ist, dass Reaktionen wie ein Dankeschön-Mailing nicht zeitnah erfolgen.

Hier wurde nach „intelligenten“ Methoden gefragt. Eine API zu Datev werden die sich vergolden lassen, aber ganz ohne Hochglanzprospektschlagworte wie KI und so: Natürlich gibt es so etwas! Bei CiviBanking steckt keine „KI“ bzw. LLM dahinter, sondern ein solider Algorithmus.

Die nicht-freie FiBu-Software Abacus (aus der Schweiz) kann in Kombination mit der OCR von deepbox.swiss Deine Rechnungs-PDF aus CiviCRM (nach einer kurzen Anlernzeit) lesen und so also gänzlich ohne manuelles Zutun übernehmen - das ersetzt aber nur einen CSV-Import. Auch hier wäre CiviCRM das führende System und Du müsstest einen File-Share einrichten, wo Deepbox die PDFs abholt. Die Deepbox-Kosten bleiben bei weniger als 200 monatlichen Transaktionen bei null EUR, immerhin.

Die verbundene Frage nach einem Open-Source-Fibu bleibt damit unbeantwortet. Ich glaube, weil Deine Frage ungenau gestellt ist: Möchtest Du gnucash an CiviCRM anbinden und wenn ja, was ist das führende System? Andere Open-Source-Lösungen sehe ich nicht.

Oder pragmatisch: habt Ihr so viele Buchungen, dass sich eine Schnittstelle statt eines manuellen CSV-Imports lohnt? Und habt Ihr in CiviCRM schon Batches probiert?

@Lucas_Paradies : Dein Anwendungsfall nimmt also Datev als führendes System. Das ist auch ok. Welche Daten hast Du denn vorliegen, dass Du CiviBanking damit bemühst? Das finde ich auch spannend so herum :slight_smile:

Hallo zusammen,
@torben.bertram : Danke für deinen Input!

Ich habe jetzt einen Ablauf eingerichtet, der (hoffentlich) ein gute Balance zwischen Automatisierung und Kontrolle findet. Bislang wurde er aber noch nicht durch den Kunden in der Praxis erprobt, das folgt zeitnah.

  1. Aus DATEV Unternehmen Online wird ein CSV-Kontoauszug gelesen. Die Daten sind hier in unserem Fall besser strukturiert, als bei der Bank.
  2. Die Daten aus diesem Export kopieren wir in eine leicht angepasste CSV-Vorlage.
    Ich habe darin die Spalten maschinenlesbarer gestaltet und den Verwendungszweck aufs Wesentliche reduziert. Ist aber möglicherweise nur für unseren Use Case sinnvoll / hilfreich.
  3. Dieser CSV-Kontoauszug wird dann in Civi-Banking importiert. Ich habe verschiedene Plugins gebaut, die den Kontoauszug bei der Prüfung dann abarbeiten.
  4. Es werden pro Buchung nach Wahrscheinlichkeit (Parameter: IBAN, Name des Urhebers der Buchung, Betrag) passende Zuwendungen in CiviCRM vorgeschlagen.
  5. Dieser letzte Schritt, kann komplett manuell und mit Prüfung auf Sicht + Stichproben erfolgen, oder man stellt ein, dass CiviBanking bei ausreichender Wahrscheinlichkeit die Verbuchung selbst vornimmt.
  6. Das Buchen stellt die Zuwendung dann auf Abgeschlossen und könnte z.B. auch noch einen Text in das Notizfeld der Zuwendung schreiben.
  7. Wenn man es noch etwas komplexer haben möchte, kann man auch Teilzahlungen, Abweichungen vom Betrag (z.B. wegen Tippfehlern) oder Rücklastschriften miteinfließen lassen. In unserem Fall ist das Ausmaß der Buchungen aber relativ überschaubar, sodass hier eine manuelle Kontrolle reicht.
  8. Wie kommen die Zuwendungen (Rechnungs-PDFs) ursprünglich nach DATEV? Hier ist der Plan, dass wir eine Funktion von DATEV nutzen, die einen E-Mail-Import von Belegen erlaubt. Wir setzen entsprechend eine E-Mail-Adresse in BCC bei jeder versandten ausgehenden Rechnung und sie sollte in DATEV hochgeladen werden. Das ist aber noch Theorie und nicht in der Praxis erprobt.

Mit dem manuellen Export von Rechnungen aus CiviCRM habe ich gerade noch ein paar Probleme. Es gibt über „Zuwendungen finden“ natürlich eine passende Aktion, allerdings kann ich das nur machen, wenn die Rechnung einen passenden Status hat („Bitte wähle nur Zuwendungen mit dem Status: Abgeschlossen, Unerledigt, Storniert/Abgebrochen oder Teilweise bezahlt.“). Das wurde natürlich übersetzt, dennoch kann ich „Unerledigt“ gerade nicht Zuordnen.

Hier würde ich gerne die Logik anpassen können. Wir haben beispielsweise einen weiteren Status „In Bearbeitung“, der mir hier sinnvoll erscheint. Ein weiteres Problem kommt bei diesem Export dazu: Rechnungen werden nur im Stapel „gedruckt“, also alle ausgewählten Zuwendungen in eine PDF mit dem Dateinamen der ersten ausgewählten …

Der Workaround ist zur Zeit sich die PDFs vom Webserver zu holen, da wird jede erzeugte PDF einzeln abgelegt.