Hallo @gio ,
wie @huebi schon sagt - das ist ein derzeit nicht vorhandenes Feature.
Ich gebe dir recht - das wäre ein plausibler und praktischer Use-Case. Allenthalben - da gilt es, einen anderen Weg zu gehen. Auch wenn es über diesen Weg möglich wäre, stellt sich die Frage, ob das immer sinnvoll oder der schnellste Weg ist.
Der Gedanke weiter gesponnen mit Lösungsoptionen:
Mir kam der Gedanke auch bereits - und zwar aus einem ganz pragmatischen Grund: Obwohl ich alle Transaktionen der Bank mehr oder weniger kategorisiert als CSV Export zur weiteren Verarbeitung vorliegen habe, so ist die Datenqualität und/ oder der Export nicht immer brauchbar und man muss die Kategorien der Bank noch auf Steuerkategorien mappen und es fehlt die passende Rechnung im Export. Dieser Umstand erfordert zur Auflösung mit Blick auf die Steuererklärung entweder manuelle Business Rules an irgendeiner Stelle in Zusammenhang mit automatisierter Erkennungslogik zwischen Transaktion und Rechnung als auch Steuerkategorisierung und zusätzlich möchte man im Idealfalle die passenden PDF Rechnungen an die jeweilige Transaktion kleben.
Consumer Accounts von Neo-Banken erlauben zumeist keine API Zugriffe zum lesen von Transaktionen und ggf. angehängten Dateien. Klassische Banken vergessen wir hier gleich mal. Die taugen allenthalben zum Bodenwasser aufwischen, nicht aber für Digitalisierung. Derartigen Service erhält man im Glücksfalle bei Geschäftskonten. Sicherlich ist das der Business-Case No. 1 für Banken, allerdings ärgere ich mich als Privatkunde schwarz, dass solche Funktionalität nicht auch für Consumer Accounts zur Verfügung steht. Dafür ist Digitalisierung ja da. Man hebelt sie an der Stelle allerdings nicht. Typisch Banken eben. Der Business-Case ist aus deren Sicht zu klein. Das sehe ich anders - aber mich fragen die Hampel ja nicht.
Der buchhalterische Weg für den Ottonormalbürger im Selbstbau wäre wie folgt: Export der Banktransaktionen, irgendwo ein Matching zwischen Transaktion und Rechnung (fraglich ist, auf welcher Basis - Stichwort Primärschlüssel) und dann ließe sich auch an gleicher Stelle eine eine Berechnung für die Steuererklärung basteln.
Entweder man scriptet den ganzen Spaß selbst, ob nun lokal oder remote gehostet, oder man nutzt Workflow Systeme wie KNIME, CAMUNDA, N8N oä.
Alternativ machen Buchhaltungssysteme wie Sevdesk oä. genau das: sie lesen Transaktionsdaten (und Rechnungen, sofern vorhanden) aus einer Bankenschnittstelle oder einen manuellen CSV Import und mappen diese gegen unterschiedliche Logiken wie zB. Steuerkategorisierung. Mal geschieht das auf Basis stumpfer Business-rules, mal mit Unterstützung von Erkennungsmustern. Sie schimpfen es KI, ist aber keine 
Ist einfach nur bisschen Statistik und Mustererkennung, kein Deep-learning. Zumindest in den meisten Fällen. Wie auch immer - als letzte Kontrollinstanz kommt der Mensch in’s Spiel und kontrolliert im Clearingmonitor der Tools das automatisch erfolgte Mapping und ggf. Berechnungsgrundlagen. Der letzte Schritt ist nun, den ganzen Krampf in Richtung Finanzamt zu schieben. Dafür haben Buchhaltungssysteme wiederum Schnittstellen zu ELSTER oder Steuersoftware wie Datev, WISO oä.
Auch hier gilt: Es hängt von der Lizenz und Funktionalität des Buchhaltungstools und des Zielsystems ab, was diese Schnittstellen bewerkstelligen können und ob sie überhaupt existieren.
Weiterhin gilt, dass ein Normalbürger keine Lizenz für Datev hat. Denn: viel zu teuer, aufwendig, der Case rechnet sich nicht. Auch hier sind wieder Geschäftskunden die Zielgruppe.
Fassen wir zusammen: Selbstbau ist durchaus möglich - aber mit Fallstricken (Lizenzen), Limitierungen (APIs) und Komplexität (Mapping) versehen. Man muss die Logik irgendwo hosten und einen gewissen Grad an Automatisierung bereitstellen. Ein Monitoring macht Sinn, da sich Schnittstellen per Definition dauernd ändern. Muss man manuell Rechnungen aus paperless hinzuführen und mappen, muss das auch irgendwo geschehen.
Selbst wenn man das alles selbst gebaut bekommt, so sind die Banken die größte Limitierung. Man braucht belastbare Rohdaten als Datenfeed und nicht so kastrierte CSV Exporte. Kein Experte kann mit diesen Aggregaten sinnvoll arbeiten. Man muss in Punkto Transaktions-ID und Kategorisierung zu viel selbst ergänzen. Das ist enorm lästig und fehleranfällig, gleichwohl möglich.
Warum verfasse ich diesen Roman? Ich kann deinen Gedankengang durchaus nachvollziehen. Am Ende des Tages möchtest du Digitalisierung hebeln und weniger Arbeit mit administrativem Quatsch haben. Recht hast du.
Zustände, auf die wir zum heutigen Zeitpunkt keinen Einfluss haben: Entwicklungsstand Banken & Finanzamt. Beide langsamer als ne Kröte.
Es gibt im Moment nur zwei Wege an’s Ziel aus meiner bescheidenen Perspektive:
- Eigenbau wie beschrieben oder
- via Buchhaltungssoftware einen TechStack mit Bank und Steuersoftware aufbauen, Geld in SaaS Anbieter buttern. Happy paying
Ich für meinen Teil bin keinesfalls bereit, ohne Gewerbe für den privaten Zweck Geld für SaaS Anbieter in die Hand zu nehmen - zumal deren Funktionalität auch von den Quell- & Zielsystemen abhängen. Die können auch nicht hexen, bauen auch nur eine Brücke aus Sand.
Ernüchternde Erkenntnis des Entwicklungszustandes eines Industrielandes, wenn du mich fragst.
Ich riet bereits als Student der Sparkasse, auf SW Features zu setzen und diese zu monetarisieren, anstatt Transaktionen zu versilbern. Allerweil - die Jodelbacken hörten mir nicht zu
Wie habe ich es gelöst?
Habe mir einen MVP gebastelt: N8N als Logikbaustein selbst gehostet zwischen Bank CSV Export, Paperless und Steuersoftware (WISO) geklemmt. Ich lese Rechnungen aus Emails und/oder Paperless, ziehe mir die Rechnungsnummer und den Betrag, matche den Betrag über Zuhilfenahme des Datums und optional Produkt/ Artikelname oder Firmierung an eine Transaktion (Im Moment schraube ich an der Einbindung einer LLM Logik, die mir brauchbare Mustererkennung liefert). Das Ergebnis lässt Berechnungen zu, die ich derzeit noch nicht visualisiere. Im Moment landen die Daten lokal in einer PostgreSQL und liegen für den Moment einfach nur herum, bis ich dazu komme, das in einem Dashboard zu visualisieren.
Parallel zu meiner eigenen Matching Logik (Experimentierzustand) reiche ich passende PDF (mit Steuer Label in Paperless geflagged) nach OCR Erkennung via Email automatisiert an WISO weiter (ich pflücke sie mir aus dem Paperless Ordner und WISO hat ne spezielle Email Adresse, an die man das durchjagen kann). Dort wird automatisiert gematched und ich muss es kontrollieren.
Aus meiner Sicht ist das der derzeit gangbarste und eleganteste Weg, eine Pipeline zu bauen. Mehr lassen die Umstände nicht zu.
Mein Gewinn: ich ignoriere die lustigen Kategorisierungen der Banksoftware, muss allerdings manuell mangels API jede Woche oder Monat die CSV auslesen (sucks), um sie lokal für meine Pipeline abzulegen, die das File konsumiert und weiter verarbeitet. Rechnungen handhabt Paperless halb-automatisch, meine Pipeline führt beide Enden zusammen und füttert die Steuersoftware, ich kontrolliere nur noch das Endergebnis Ende des Jahres und drücke auf ok. Fertig.
ich könnte jetzt ausholen, wie hemdsärmelig der Zustand unserer Industrie, Banken & Verwaltungsapparat in diesem Punkt ist, welches Potenzial in einer Steuernummer steckt und wie man solche Workflows richtig mächtig mit potenten Schnittstellen bauen könnte. Aber das werde ich in meinem Leben nicht mehr erleben^^
Over and out - happy building!