MoneyWorks: Vorgaben vor dem Laden alter Bankdaten prüfen

Diese Anleitung folgt dem derzeit öffentlichen Kapitel Cash Transactions im MoneyWorks-Handbuch unter Importing Bank Statements. Die Seite nennt nicht Ihre installierte Version. Weichen die Bedienelemente ab, klären Sie zuerst die passende Produktanleitung. Hier wird eine Vorbereitung beschrieben, kein ausgeführter Import.

Die Desktop-Apps exportieren Datum, Beschreibung und Betrag als CSV. Öffnen Sie die CSV in Excel und speichern Sie dort eine XLSX-Datei. Prüfen Sie das Ergebnis anhand Ihres eigenen PDFs; die Unterstützung hängt vom Auszugsformat ab.

Importweg und Einstellungen unterscheiden

Das Handbuch öffnet Statement Coding über Command → Load Bank Statement. Erfassen Sie vor Auswahl oder Annahme einer Datei die vorhandenen Einstellungen:

Einstellung	Dokumentierte Aufgabe	Prüffrage
Bank	Zielbankkonto in MoneyWorks	Ist dies das in der Quelle belegte Konto?
Source	Interpretation der Auszugsdatei	Native QIF/OFX-Datei oder Generic CSV?
Default Income A/c / Default Expense A/c	Auffangcodes für nicht per Regel zugeordnete Vorgänge	Passen die gemerkten Codes zu diesem Auftrag?
Exclude items before / And after	Vorgänge außerhalb der Grenzen auslassen	Würden benötigte historische Zeilen fehlen?
Auto-Reconcile	Erkannte bestehende Vorgänge auslassen und Abstimmungsstatus setzen	Ist diese Wirkung bewusst geprüft?

Eine Änderung von Source repariert kein falsches Bank-Ziel. Auch ein plausibles Standardaufwandskonto beweist nicht, dass jede Auszahlung richtig eingeordnet wird.

Dateipfad und Zeitraum gemeinsam prüfen

Das Handbuch beschreibt native Bankformate wie QIF und die OFX-Familie, eine Auswahl Generic CSV sowie einen gesonderten Import Transactions-Weg für Textdaten. Daraus folgt kein identischer CSV-Assistent für alle MoneyWorks-Produkte. Die für Australien und Neuseeland erwähnten Bank Feeds sind ein eigener Dienst, keine hier behauptete weltweite Funktion.

Identifizieren Sie Produkt und einzelnes Quellbankkonto. Bewahren Sie die Bankdatei unverändert auf.
Lesen Sie die bestehende Statement-Coding-Konfiguration, ohne für diese Prüfung neue Daten zu laden oder anzunehmen.
Vergleichen Sie erste und letzte benötigte Quelldaten mit beiden Datumsgrenzen. Das Handbuch verknüpft den „before“-Standard mit dem letzten Vorgang des vorigen Imports. Prüfen Sie den tatsächlichen Wert statt einer vermuteten Monatsgrenze.
Notieren Sie die gemerkten Auffangkonten und relevante Regeln. Ungeklärte Zuordnungen bleiben offen; die Vorgaben des letzten Imports sind kein Beleg für diesen Fall.

Auto-Reconcile verändert mehr als eine Filteransicht

Laut Handbuch vergleicht die Option mit bestehenden Transaktionen, markiert erkannte bestehende Vorgänge zum Auslassen und neue Vorgänge als abgestimmt; auch der erkannte bestehende Vorgang kann den Abstimmungsstatus erhalten. Das ist keine bloße Datumsfilterung und kein Nachweis einer vollständigen Kontoauszugsprüfung.

Erhalten Sie vorher die Übersicht vorhandener Vorgänge und erwarteter Quellzeilen. Prüfen Sie Konto und Belege auch bei einer erkannten Übereinstimmung. Diese Anleitung hat die Option weder ausgeführt noch ihr Verhalten in einem konkreten Unternehmen bestätigt.

Synthetische Vorprüfung mit mehreren offenen Punkten

Die Quelle gehört zu Konto A und September. In Statement Coding stehen noch Bank B, eine „before“-Grenze vom 15. September, die Codes PriorIncome und PriorExpense; Auto-Reconcile ist ausgewählt.

Schon das falsche Zielkonto stoppt die Entscheidung. Auch nach dessen Klärung könnten die Daten vom 1. bis 14. September ausgeschlossen werden. Kontocodes und Abstimmungswirkung bleiben zusätzlich zu prüfen. Die Korrektur eines einzelnen Feldes macht nicht die ganze Konfiguration verlässlich.

Übergeben Sie Quell- und Zielidentität, Grenzen, Auffangcodes und ungeklärte Wirkungen als Prüfliste. Sie begründet den nächsten autorisierten Schritt, ohne einen erfolgreichen Import, sichere Dublettenerkennung oder automatische Buchungsrichtigkeit zu behaupten.

Die Datumsentscheidung getrennt von der Anwendung prüfen

Für Buchhaltungskräfte, die historische Umsätze vorbereiten, bezeichnet der Quellzeitraum die im Original vorhandenen Daten; der Filterzeitraum ist die in Statement Coding eingestellte Spanne. Beide müssen nicht übereinstimmen. Ein falsches Ziel unter Bank stoppt die Entscheidung bereits davor.

Das fiktive Datumsarbeitsblatt betrachtet ausschließlich die dokumentierten Grenzen „before“ und „after“. Für den einschließlich gedachten Zeitraum 15.–30. September ergab eine ausgeführte Python-Prüfung:

Fiktiver Datensatz	Datum	Modell der dokumentierten Zeitspanne
M1	14. September 2026	Außerhalb, vor der Untergrenze
M2	15. September 2026	Innerhalb, an der Untergrenze
M3	30. September 2026	Innerhalb, an der Obergrenze
M4	1. Oktober 2026	Außerhalb, nach der Obergrenze

Damit liegen im Modell zwei Zeilen innerhalb und zwei außerhalb. Die CSV ist ein Lehrarbeitsblatt, keine MoneyWorks-Importdatei; Python hat weder MoneyWorks noch dessen Parser ausgeführt. Klären Sie zuerst das falsche Bank-Ziel und notieren Sie danach die wirklichen Filterwerte sowie benötigte, dadurch ausgelassene Zeilen. Auch bei passenden Daten bleiben gespeicherte Kontierung und Auto-Reconcile getrennt zu prüfen. Ein korrigierter Zeitraum ist noch kein erfolgreicher oder abgestimmter Import.

Synthetischer Prüffall. Die Werte sind Lehrdaten, kein Herstellerexport und keine Importdatei.

Für eine Bankquelle nur als PDF: LocalExtract herunterladen. Es verarbeitet jeweils ein PDF lokal zu CSV mit date,description,amount; prüfen und ergänzen Sie die Daten für das tatsächliche Ziel.

Weiterführende Anleitung: Kontoauszug als CSV: Format vor dem Buchhaltungsimport prüfen.

Dokumentation für die ergänzte Aufgabe am 16. Oktober 2026 geprüft.