Zuordnung "Beleg zu Buchungssatz": Effiziente Prüfung

Mir ist bewusst, dass aktuell viele Ressourcen in die umfangreiche GUI-Überarbeitung fließen und die hier vorgestellten Ideen sicherlich nicht "mal eben" umzusetzen sind. Dennoch möchte ich diese Gedanken im Forum teilen, damit sie dokumentiert sind und vielleicht zu einem späteren Zeitpunkt als Anregung dienen können.

Hintergrund & Anforderung

Die Prüfung der korrekten Zuordnung von Belegen zu Buchungssätzen dient der Qualitätssicherung in der Buchhaltung - unabhängig davon, ob die Belege weitergegeben werden oder nicht. Eine effiziente Prüfmöglichkeit kann Fehlzuordnungen minimieren und die Zuverlässigkeit und Konsistenz der Buchhaltungsdaten erhöhen.

In meinem konkreten Anwendungsfall geht es um eine Vorab-Prüfung bzw. eine Plausibilitätskontrolle vor der Weitergabe der Buchungsdaten per DATEV-Export an den Steuerberater. Ich möchte dabei prüfen, ob meine Belege (PDF-Dokumente) korrekt mit den Buchungssätzen verknüpft sind. Dies umfasst:

1. Vollständigkeitsprüfung: Sind allen relevanten Buchungssätzen (für die Belege erwartet werden) die entsprechenden Dokumente zugeordnet?
2. Konsistenzprüfung: Stimmt die Zuordnung zwischen Belegen und Buchungssätzen inhaltlich überein?

Die Vollständigkeitsprüfung ist seit Version 19.09 (siehe hier) nach meinem Dafürhalten bereits effizient möglich: Durch Umsortierung der Buchungsliste und anschließende Sichtprüfung lässt sich leicht erkennen, ob das Dokument-Icon (in der ersten Spalte) bei jedem relevanten Buchungssatz erscheint.

Die Konsistenzprüfung hingegen stellt nach wie vor eine Herausforderung dar, da es keine effiziente Möglichkeit gibt, die Zuordnung zwischen Beleg und Buchungssatz zu überprüfen.

Ich verwende eine systematische Benennung meiner Belegdateien nach folgendem Schema:

YYYY-MM-DD-Aussteller-Zusatzinformationen.pdf

Dabei ist der Aussteller je nach Belegart der Lieferant, Dienstleister oder bei selbst erstellten Dokumenten (wie beispielsweise Ausgangsrechnungen, Gutschriften etc.) der eigene Firmenname.

Beispiele

2024-01-16-R+V-Allgemeine-Versicherung-AG-Beitragsrechnung-2024.pdf

2024-01-18-Telekom Deutschland GmbH-2024-01-Rechnung_555999666.pdf

Diese Benennung ermöglicht bereits eine (erste) Plausibilitätsprüfung der Zuordnung zwischen Buchungssatz und Beleg anhand des Dateinamens.

Stand jetzt habe ich leider keine Möglichkeit gefunden, in einer Liste oder Berichtsform zu den Buchungssätzen die jeweils verknüpften Dateinamen auszugeben. Leider erschwert dies einen effizienten Vergleich zwischen den Buchungssätzen und den zugeordneten Belegen.

Anregungen für Lösungen

Kurzfristige Verbesserung

In einem früheren Beitrag hatte ich bereits die Idee eines Tooltip-Features erwähnt:

Beim Überfahren des Beleg-Icons eines Buchungssatzes (in der ersten Spalte der Buchungsliste) könnten per Tooltip die Dateinamen angezeigt werden, die mit diesem Buchungssatz verknüpft sind. So würde durch bloßes Überfahren des Icons mit der Maus eine direkte Prüfung ermöglicht, ob die verknüpften Dokumente vom Dateinamen her zum jeweiligen Buchungssatz passen.

Die Umsetzung dieses Features könnte bereits einen praktischen ersten Schritt darstellen, um verknüpfte Dateinamen und Buchungssätze effizienter zu vergleichen als mit der derzeit einzigen Möglichkeit (Doppelklick auf jeden Buchungssatz, Menü "Dokumente" öffnen und dort die verknüpften Dokumente einsehen). Offensichtliche Fehlzuordnungen könnten so wesentlich schneller erkannt und sodann bereinigt werden.

Übersichtsbericht für Belegprüfung

Als umfassendere Lösung käme eventuell ein Bericht in Frage, der:

• Alle Buchungssätze bzw. solche mit verknüpftem Beleg auflistet
• Idealerweise nach Buchungskonto aufgeteilt ist
• Pro Buchungssatz die verknüpften Dateinamen anzeigt (in den meisten Fällen wird dies nur ein Beleg sein, dennoch sollten immer alle verknüpften Dateinamen aufgelistet werden und nicht etwa nur der erste oder gar ein zufälliger)

Mit dieser Darstellung wäre es einem Anwender möglich, per Sichtprüfung schnell zu erfassen, ob eine Datei falsch zugeordnet wurde (z.B. eine Telekom-Rechnung zu einem buchhalterischen Vorgang, der nichts mit der Telekom zu tun hat).

Nach meinem Kenntnisstand bietet Taxpool aktuell keine Methode zur Ausgabe eines entsprechenden Berichts bzw. überhaupt eines Berichts, der die konkret zugeordneten Dateinamen ausgibt.

Erweiterte Ideen: Präventive Maßnahmen

Neben dem Prüfbericht wären auch präventive Funktionen denkbar und hilfreich:

1. Dateinamenmuster-Definition
   
   • Hinterlegung eines Pattern/Musters für den Dateinamen pro Buchungskonto
   • Möglichkeit regulärer Ausdrücke (Pattern)
2. Automatische Prüfung bei Belegzuordnung
   
   • Automatische Prüfung bei Verknüpfung eines Belegs gegen das Pattern
   • Ablehnung/Sperre bei Drag&Drop, wenn ein Beleg nicht dem erwarteten Muster entspricht
3. Übersteuerbarkeit für Ausnahmefälle
   • Bei Drag & Drop: Übergehung der Prüfung durch gleichzeitiges Drücken einer Zusatztaste (z.B. Strg, Alt oder Shift)
   • Im "Dokument hinzufügen"-Dialog: Checkbox zur Bestätigung oder Nachfrage bei Abweichung des Dateinamens vom definierten Dateinamens-Pattern

Nutzen

Diese Funktionen würden:

• Zeit bei der manuellen Prüfung sparen
• Die Konsistenz der Buchhaltung erhöhen
• Fehler vor der Übergabe an den Steuerberater reduzieren
• Besonders bei größeren Belegmengen die Übersichtlichkeit für die (technische oder zumindest visuelle) Konsistenzprüfung verbessern bzw. überhaupt erst sinnvoll ermöglichen

Zusätzliche Möglichkeiten bei E-Rechnungen

Ich habe mich mit den technischen Details von E-Rechnungen (ZUGFeRD, XRechnung) bisher nicht befasst, aber möglicherweise bieten diese strukturierten Formate zusätzliche Möglichkeiten für automatisierte Prüfungen, die über die hier vorgeschlagenen Funktionen hinausgehen können. Beispielsweise Prüfung der Belegzuordnung anhand der UStID zum Kreditor anstatt des Dateinamens.

Beste Grüsse!

Hi Chris, Danke für die Rückmeldung. Aber ich vermute, dass es da ein Mißverständnis bzgl. dem Thema + Bedarf gab.

Hallo Taxoloop,

vielen Dank für Deine Mühe und die ausführliche Darlegung der Überlegungen und der Rückfragen.

Vollständigkeitsprüfung: Ja, wie geschildert ist das - zumindest für meine Belange - mit den Icons nun hinreichend für eine effiziente Prüfmöglichkeit gelöst. Ob bei einem größerem Buchungsvolumen weitere technische Hilfsmittel sinnvoll sein könnten, möchte ich nicht ausschließen.

Zur Konsistenzprüfung:

Ich schrieb ja bereits "Diese Benennung ermöglicht bereits eine (erste) Plausibilitätsprüfung der Zuordnung zwischen Buchungssatz und Beleg anhand des Dateinamens.".

Das reicht zumindest mir vollkommen. Wie weiter dargelegt würde mich von daher interessieren, ob ich beispielsweise beim Kreditorenkonto "Deutsche Telekom" Buchungen finde, bei denen der Dateinamen beispielsweise "Amazon" enthält.
Aus meiner Sicht wäre für eine manuelle Prüfung am hilfreichsten schlicht ein Bericht, in dem ich das mit dem eigenen Auge - also visuell - schnell überfliegen kann. "Sichtprüfung" habe ich ja extra genannt.
Danach kann man einen so gefunden Beleg (hier also etwa "Amazon" auf dem Kreditorenkonto "Deutsche Telekom") manuell prüfen. Entweder es ist wirklich von Amazon und damit falsch zugeordnet oder aber der Dateiname wurde falsch vergeben. Jedenfalls hat man die Stelle leicht identifizieren können, um eine Prüfung durchzuführen.

Die Notwendigkeit der Prüfung von Datum oder aber Betrag benötige ich nicht.

Technisch unterstützt - also weiter verbessert - wäre denkbar, dass man valide Dateinamen-Pattern direkt auf einem Buchungskonto hinterlegen kann (primär Debitoren-/Kreditoren).
Verknüpft man entweder per "Dokument hinzufügen" oder aber Drag&Drop einen Beleg zu einem Buchungssatz, könnte auf diese Art technisch der Dateinamen gegen das hinterlegte Pattern geprüft werden.

Du führst ergänzend noch diverse Überlegungen und Fragen aus, die ausserhalb der Sphäre von Taxpool liegen und daher irrelevant sind.
Denn: Ob es bei der Vergabe des Dateinamens zu einem Fehler ausserhalb von Taxpool kam, spielt keine Rolle. Das kann und soll Taxpool ja auch gar nicht beurteilen oder kontrollieren.
Wenn der Dateiname falsch vergeben wurde, ist das eben so. Das ist/war aber nichts, wobei Taxpool involviert war bzw ist, da es ausserhalb der Software stattfand.

Und ob der Dateiname ausserhalb von Taxpool manuell vergeben wurde oder aber automatisiert durch bspw. a) einen automatischen Abruf bei den Kreditoren, b) durch einen Extrakt aus E-Mails und anhand von diversen Merkmalen (Absender-E-Mailadresse, PDF Inhalt, PDF Metadaten etc.) oder c) eine ganz andere Zuführungsmethode, spielt gar keine Rolle.

Quote

Auch für eine nur "erste" Plausibilitätsprüfung der Zuordnung zwischen Buchungssatz und Beleg ist der Dateiname m. E. nicht geeignet.

Diese Schlussfolgerung erschließt sich mir nicht, denn hierbei werden Prozessverantwortlichkeiten/-zuständigkeiten in der IT vermischt.
Es ist an dieser Stelle nicht Aufgabe von Taxpool, die externe Vorarbeit zu "challengen", solange es dazu technisch keine Möglichkeit hat.

Und: Das Thema "E-Rechnungen" ist ein ganz separates. Die Belege werde weltweit übermorgen nicht alle samt als E-Rechnung vorliegen. Diese bieten aber sicherlich ganz andere/zusätzliche Chancen für technische Prüfungen. Steht ja auch so im Originalposting unten.

Kurz und knapp:
Ich möchte fehlerhafte Belegzuordnung / Verknüpfungsfehler identifizieren können über die Massendaten hinweg. Mein Anliegen ist nicht herauszufinden, ob der Dateiname korrekt vergeben wurde.

Beste Grüße!
blinky

Hallo wiko-services.de,

Danke auch Dir für Deine Mühe der Rückmeldung

Zu Deinen Fragen:

Quote

wie es zu den Dateinamen kommt. Von Hand vergeben oder wie wird der Dateiname gebildet, bevor die Datei als Beleg verknüpft wird.

Wie es zu dem Dateinamen kommt, ist für Taxpool völlig irrelevant. Für das komplette End-to-End Verständnis mag es sinnvoll sein, aber das wird bei jedem Anwender völlig individuell sein.
Es ist ja nicht die Aufgabe von Taxpool, den Dateinamen zu erzeugen, sondern es wird eine Datei mit einem bestehenden Dateinamen importiert.
Möglichkeiten, wie der Dateiname entstanden sein könnte, habe ich im Posting zuvor erwähnt. Möglicherweise manuell, möglicherweise automatisiert.

Quote

ob die Datei lediglich verknüpft wird oder die Datei auch nach Taxpool kopiert wird und wenn ja, wie dabei der Dateiname gebildet wird

Mein Szenario geht davon aus, dass ein Beleg entweder a) per Drag&Drop oder b) über "Dokument hinzufügen" verknüpft wird. Ob dabei nun das DMS genutzt wird oder nicht, spielt dabei keine Rolle.

Über ausführliche weitere Ideen zum DMS mit MD5 Prüfsummen, Dublettenerkennung und -vermeidung, Kontrolle, ob jeder buchungsrelevante DMS-Beleg einer Buchung zugeordnet ist, wie automatisch Rumpfbuchungssätze anhand der importieren Dateien (stützend auf die Patternerkennung) erfolgen können, lasse ich mich gegenwärtig noch gar nicht aus. Da hab ich noch diverse Ideen seit Monaten, habe aber die weiteren Vorschläge zurückgehalten, da modular mit Verweis auf die Arbeiten an der Linux-Version darum gebeten hatte, keine weiteren Vorschläge einzureichen.

Hinterlegung Pattern je Buchungskonto
Sind Szenarien denkbar, bei denen beide Buchungskonten ein Pattern hinterlegt haben? Vielleicht. Mein Verwendungszweck wären erstmal nur Debitoren- und Kreditorenkonten gewesen. Die Frage ist bestimmt valide und ich vermute, Du hast hier mehr Erfahrung aus der Praxis. Insofern gut, dass es hier eine Austauschmöglichkeit gibt

Das könnte man sicher auch behandeln, indem ein Popup mit einem Hinweis und zur Übersteuerung erscheint (sowieso wünschenswert) und/oder Taxpool ermöglicht, zwei Pattern je Konto zu definieren. Ein Pattern für das Szenario, dass das Konto im Soll bebucht wird, ein zweites Pattern für das Szenario der Bebuchung im Haben. Bei Konten, bei denen es kein Muster gibt, hinterlegt man schlicht kein Prüfpattern.

Quote

Beides geht wohl davon aus, dass der Dateiname vor dem Verknüpfen nicht einer systematischen (ggf. manuellen) Vergabe unterzogen wurde. Hier sollte eine Dateinamensprüfung bei der externen Namensvergabe erfolgen, die dann auch dem gewünschten Muster entspricht.

Nein, beides kümmert sich erneut rein gar nicht darum, was ausserhalb von Taxpool passiert ist. Es ist auch nicht relevant für Taxpool.
Taxpool kann bei Nutzung der Programmfunktionen Prüfungen durchführen, es hat nicht die Vorarbeit in Frage zu stellen. Das Endresultat ist natürlich immer nur so gut, wie die gesamte Prozesskette:

Ist vorgelagert die Dateinamensvergabe 100% korrekt sichergestellt? Und dann auch in Taxpool die Verknüpfung validiert? Perfekt!

Aber: Geschieht vorgelagert ein Fehler bei der Dateinamensvergabe und wird eine solche Datei dann in Taxpool falsch verknüpft, dann mag das vorkommen. Logischerweise ist der Gesamtprozess dann nicht 100%ig sicher, aber qualitativ immer noch besser, als ohne Prüfung.

Quote

Ich würde insgesamt die externe Dateinamensvergabe nicht in Taxpool prüfen, sondern in dem (externen) Prozess. Dort kann die Prüfung und Korrektur gewiss viel gezielter erfolgen. Überdies sehe ich den (geänderten) Dateinamen als untauglich um darin Buchungs- und/oder Belegdaten zu hinterlegen, die dann zu einer Prüfung der Buchung führen sollen.

Ganz genau Denn nur so macht das Sinn in IT. Jedes Modul in einer Kette hat seine Verantwortlichkeiten. Das jeweils nächste System prüft jeweils nur das auf Validität, basierend auf (maximal) dem, was für das jeweilige System prüfbar ist. Dabei helfen End-to-End Sichtweisen natürlich. Hat man den ganzen Datenfluss unter Kontrolle (denke an Eigenentwicklung diverse Module/Anwendungen, die Daten austauschen), hilft es natürlich, wenn man schon Checksummen, "Datei-Ende"-Markierungen etc. konzeptionell vorsieht respektive spezifiziert. Das ermöglicht dem Folgesystem, Prüfungen durchzuführen.

Quote

Es bietet sich an, erprobte buchhalterische Prüfungen* zu nutzen um mögliche Fehler zu finden statt an der fragwürdigen Plausibilität des Dateinamens etwas ablesen zu wollen, was nur indirekten Zusammenhang zur Buchung hat.

"In meinem konkreten Anwendungsfall geht es um eine Vorab-Prüfung bzw. eine Plausibilitätskontrolle vor der Weitergabe der Buchungsdaten per DATEV-Export an den Steuerberater. Ich möchte dabei prüfen, ob meine Belege (PDF-Dokumente) korrekt mit den Buchungssätzen verknüpft sind." So schrieb ich das ja eingangs.

Ich möchte am Jahresende nicht alle Buchungen manuell durchgehen und öffnen müssen, sondern unterstützend ein Instrument haben/nutzen können, dass mich bei der Qualitätssicherung der Massendaten (der Buchungssätze) vor der Weitergabe unterstützt. Stand heute bin ich mit Blick auf die Dokumente allerdings leider "blind", da ich nicht anzeigen lassen kann und daher nicht prüfen kann, welche Belege bei den Buchungssätzen verknüpft/hinterlegt sind und somit nicht sehen kann, was ich exportiere und weiterleiten werde.

Beste Grüsse!
blinky

Die Diskussion mit der API unter jedes Thema zu setzen mag zu Demonstrationszwecken toll sein, aber ist auch wenig hilfreich betreffend der Übersichtlichkeit. Denn es lenkt immer vom Hauptthema ab.

Logisch will man als Entwickler, dass es möglich ist die Software von Aussen kontrollieren zu können, um mehr selbst zu erledigen und weniger von den Entwicklungszyklen bzw. der Herstellerbereitschaft abhängig zu sein, etwaige Features einzubinden. Das ist irgendwie nachvollziehbar, keine Frage.

Eventuell tut es aber dafür einfach ein eigenes Hauptthema dazu?

Wie der Hersteller die Software "schneiden" will, ist im Endeffekt natürlich ihm überlassen. Man muss dabei auch bedenken, dass so etwas organisch gewachsen ist und daher nicht immer perfekt ist. Diverse nativen Drittanbieter-Schnittstellen würde ich persönlich mittlerweile sicherlich auch modular gestalten, zubuchbar - eben gerne für einen Extrapreis, denn man muss hier anerkennen, dass man wirklich ein gutes Stück Software kriegt für einen sehr fairen Preis. Langjährige User mögen sich dabei aber etwas vor den Kopf gestoßen fühlen.

Und das nicht bspw. jede Drittanbieter-Schnittstelle nativ vom Hersteller angeboten werden muss, ist auch nachvollziehbar. Ggf. könnte man sich so im Verlauf der Zeit gar einem gewissen Ballast entledigen.

Nun aber nochmal zum "Schneiden" der Software. Es gibt eine gewisse Kernfunktionalität. Und diese sollte es auch geben. Und eben gewisse grundlegende Funktionen, die eine Anwendung um die Kernfunktionalität herum einfach out-of-the-box integriert haben sollte, damit man damit auch sinnvoll arbeiten kann. Nun bei jedem einzelnen Thema zu rufen "mit API lösbar" mag technisch richtig sein, aber nicht unbedingt die richtige Balance zwischen externen Tools/Modulen sein und dem, was im originären Hauptmodul (=Taxpool) vorhanden sein sollte. Die Meinungen mögen hier differieren, aber evtl. macht es doch mehr Sinn, dies in dem erwähnten Haupt-Diskussionsthema auszudiskutieren. Und eben nicht vergessen: Es ist nun mal der Hersteller, der die letzte Entscheidung hat, wie er seine Software gestalten respektive anbieten möchte.

Just my 2 cent.

Hi Taxoloop ,

ich verstehe Deine Ausführungen. Aber Du versuchst hier erneut einen Fehler zu lösen, der nach eigener Erklärung bereits ausserhalb von Taxpool stattfindet. Und das ist nicht die Aufgabe und auch nicht die Idee der möglichen Kontrollmöglichkeit zu Qualitätssicherung.

Wenn die Dateien unsauber benamt sind, können Fehler passieren. Aber dann ist das schlicht nichts, was automatisch zu erkennen wäre. Daher ist das auch gar nicht Bestandteil der Anforderung an Taxpool.

Es wird nicht um den Wunder-Knopf mit der Funktion "Prüfe alles und stelle absolut sicher, dass jegliche Zuordnung 100% korrekt ist".

Es geht darum zu erkennen, wo Belege offensichtlich falsch zugeordnet wurden. Zum Beispiel weil durch Abo-Buchungen und/oder den Buchungsassistenten anhand von Importen (Kontoauszüge, andere Importquellen) Buchungssätze prinzipiell schon vollständig erzeugt wurden, so dass nur noch der Beleg zugeordnet werden muss. Aber bei eben dieser anschließenden Belegzuordnung (also dem verknüpfen des PDFs mit dem Buchungssatz) möglicherweise ein Fehler geschehen ist. Die Annahme der Prüffunktion muss hierbei natürlich sein, dass die Dateinamen korrekt sein. Wenn dies nicht der Fall ist, ist klar, dass das Prüfresultat nicht stimmt. Aber das liegt ja dann auch nicht an Taxpool, sondern eben der vorgelagerten Arbeit bzw. Applikation, die schlecht gearbeitet hat. Taxpool muss die Arbeit der vorgelagerten Applikation aber nicht wiederholen, sonst hätte es die Anwendung davor ja erst gar nicht gebraucht.

Nennt sich auch "Separation of Concerns" - die Trennung der Verantwortlichkeiten/Zuständigen von Applikationen.
In der IT ganz normal: Garbage In, Garbage Out. Wobei "Garbage Out" hier auf das Prüfresultat abstellt, wenn "Garbage In" (also ein falscher Dateiname) angedient wurde.

wiko-services.de

Quote from wiko-services.de

Tut mir Leid, wenn ich genau das verstehen wollte.

Sorry - meine Antwort bzw. die Art und Weise der Ausführung war nicht als Vorwurf gemeint. Die Frage an sich ist natürlich legitim.
Ich wollte es nur aus technischer Sicht beschreiben, dass es für die gewünschte Taxpool-Funktion irrelevant ist. Denn es ist etwas, dass ausserhalb der Anwendung stattfindet.

Quote

Stimmt. Dann ist für mich die Prüfung auf Dateinamensbestandteile uninteressant, da ich die Belegzuordnung nicht über den Dateinamen vornehme und auch nicht darüber kontrolliere.

Fair Point. Nicht jeder hat den gleichen Workflow.

Taxoloop

Freut mich, dass wir uns jetzt prinzipiell bzgl. der Anforderung verstehen!

Dennoch glaube ich, es liegt ein Missverständnis vor, wie IT-Systeme normalerweise arbeiten.

Kein System prüft die Vorarbeit anderer Systeme vollumfänglich. Denn sonst müsste es die Arbeit nochmal machen. Es kann höchstens einfache Validierungen durchführen, ob das Dateiformat stimmt, die Datei vollständig ist.

Ich gebe Taxpool Dateien mit bestimmten Namen.
Taxpool soll mir helfen zu prüfen: "Wurde diese Datei auf mit den richtigen Buchungssatz verknüpft?"
Nicht: "Ist der Dateiname überhaupt korrekt?"

Letzteres kann Taxpool technisch gar nicht - dafür müsste es den PDF-Inhalt analysieren, Firmennamen erkennen etc. Das wäre ein riesiges Feature und weit weg von der Kernaufgabe einer Buchhaltungssoftware.

Beispiel 1: Windows Datei-Verschieben
- Du hast einen Ordner "C:\Rechnungen\2024\Telekom"
- Du ziehst versehentlich "Amazon-Rechnung.pdf" dort hinein
- Prüft Windows, ob die Datei wirklich in diesen Ordner gehört? Nein.
- Windows verschiebt sie einfach dorthin, wohin du sie ziehst.
(Visuell würde eine solche Datei in dem Verzeichnis aber sofort ins Auge fallen, wenn Du 100 Dateien mit "Deutsche Telekom" hast und eine heraussticht, weil dort Amazon steht.)

Beispiel 2: Analogie aus der realen Welt
- Ein Brief kommt mit Adressaufkleber "Musterstraße 5"
- Der Postbote wirft es in Briefkasten "Musterstraße 12"
- Kann der Postbote prüfen, ob der Absender die richtige Adresse auf den Aufkleber geschrieben hat? Nein - dafür müsste er den Brief öffnen, den Inhalt verstehen, evtl. über die Situation des Empfängers Bescheid wissen und beurteilen können, ob er der richtige ist. Unmöglich.
- Er kann nur prüfen: "Habe ich es an die Adresse laut Aufkleber zugestellt?"

Das ist überall so. Jedes System arbeitet mit den Daten, die es bekommt, und verarbeitet sie dann entsprechend.

Aktuell habe ich keine Möglichkeit einzusehen, welche Belege bei einem DATEV-Export tatsächlich mitgeschickt werden. Ich kann die Verknüpfungen nicht überblicken. Ich bin "blind". Möchte ich aber nicht. Daher würde ich genau diese fehlende Übersicht ganz gerne haben.

Die Prüfung ist bewusst simpel - aber genau das macht sie auch praktikabel und schnell implementierbar.

Eventuell noch als Ergänzung, falls das Untenstehende nicht offensichtlich sein sollte:

Die Prüfung kann auch hilfreich sein, wenn der Ausstellernamen nicht im Dateinamen vorkommt.
Arbeitet man mit den Original-Dateinamen der Aussteller, werden Ausreißer trotzdem sichtbar, da die Dateinamen ja von den Ausstellern normalerweise ja durchgängig einem bestimmten Muster folgen:

Beispiel

RE000323.pdf
RE000421.pdf
RE000425.pdf
invoice.pdf         <-- sticht klar heraus und man kann prüfen, ob die Zuordnung passt.
RE000525.pdf