Import Buchungsstapel

Stellen Sie sich vor, was los ist, wenn versehentlich die Postversanddaten (also alle Ausgangsrechnungen eines Mandanten) im verkehrten Wirtschaftsjahr, oder gar bei einem anderen Mandanten eingespielt werden? (Ja es gibt Madanten, wo die Postversand- Daten mit der Mandantennummer "001" geliefert werden, und dieses von der Buchhaltung monatlich repariert wird.)

Daher bitte wirklich nur die Vorläufe beim Import festschreiben, wo definitiv das Kennzeichen vom Mandanten gesetzt war. Aber auch hier muß es möglich sein, diese Aktion zu canceln. (Undo des Importes.)

EB- Werte: Es gibt einfach EB- Werte, die müssen auf den ersten Sitz korrekt sein. Wo kämen wir denn hin, wenn der Betriebsprüfer anhand der aktuellen GDPDU- Daten sieht, daß der Wert des Warenbestandes im Vorjahr zwei Mal verändert wurde? Natürlich kann man mit dem Erfassen der EB- Werte warten, bis die Bilanz endgültig ist, oder bis die nächste Jahresübernahme durch ist. Aber möchten wir heute wirklich noch so arbeiten?

(Bitte bis Ende nächster Woche keinen telefonischen Rückruf, da nicht erreichbar)

Also ich habe das bisher so verstanden, dass wenn der Mandant uns einen vorläufigen Vorlauf zusendet (echtes DATEV-Format), dann werden diese auch als vorläufig importiert. Dafür ist es dann wohl aber auch zwingend notwendig, das properitäre DATEV-Format zu verwenden. Das wäre dann eine Erziehungsmaßnahme.

Mir geht es aber darum, dass ich echte ASCII-Daten importieren möchte. Da habe ich jetzt wohl nur 2 Möglichkeiten:

1.) Der Import wird sofort festgeschrieben und ich muss diese Festschreibung immer wieder aufheben oder
2.) ich exportiere meine Excel-Daten in das properitäre DATEV-Format. Die Schnittstellenbeschreibung müsste ich mir dann für 280 kaufen. Super!!! So kann man natürlich auch Geld verdienen und das von einer Genossenschaft.

Anmerkung zu 1.)
Wie ich schon im vorherigen Beitrag angemerkt habe, wird in diesem Fall aber 2 falsche Logbucheinträge generiert. Der erste besagt, dass ich festgeschriebene Buchungen importiert habe, was definitiv falsch ist. Der zweite Eintrag besagt, dass ich festgeschriebene Buchungen wieder aufgehoben habe, was auch falsch ist, da es sich um vorläufige Buchungen gehandelt hatte.

Mein Lösung ist dagegen recht einfach. Wird über echter ASCII-Import durchgeführt, dann wird über ein Kennzeichen (Festschreibung: J/N) entschieden, ob auch der Import sofort festgeschrieben wird. Im Logbuch wird das mit vermerkt. In dem Logbuch müsste noch die Anzahl der Buchungssatz-Importe hinterlegt werden, damit man einen Nachweis hat, dass man z. B. die Rechnungsausgangsbücher, Kasse oder was auch immer importiert hatte. Damit würde aus meiner Sicht auch der GOBD genüge getan. Die kann doch nur eine Protokollierung verlangen und mehr nicht.

Anmerkung EB-Werte:

Also die EB-Werte müssen immer vorläufig sein, damit diese bis zum endgültigen JA geändert werden können. Bei der USt.-Übermittlung sind diese bei der Prüfung zu ignorieren oder aber man hinterlegt einfach im Protokolleintrag, dass noch vorläufige EB-Werte vorhanden sind (was aus meiner Sicht aber Quatsch ist).

Also liebe DATEV, was haltet ihr von meinen Vorschlägen.

Gruß A. Martens

P.S.
Ich dachte, ich hätte diese leidigen Diskussionen mit den Software-Anbietern hinter mir. Da streitet man sich zig Jahre mit der Simba und geht aus Frust weg, um dann bei der DATEV weiter zu machen (Gott sei dank auf einem höheren Niveau). Es ist echt zum kotzen!

Eine weitere Anmerkung am Rande: Mit dieser Neuerung wird ja eine automatische Festschreibungsfunktion eingeführt. Gibt es bereits automatische Festschreibungen? Mir ist nichts bekannt. Ich habe einfach die Sorge, dass aufgrund der Komplexität von Rechnungswesen Pro es zu Fehlern kommen kann, bei denen diese automatische Festschreibung ungewollt ausgelöst wird.

Das Problem sind einfach die GOBD selbst. Vollkommen praxisfern und in einigen Punkten auch nicht zu Ende gedacht. Im Grunde müsste man dagegen klagen was aber auch wenig Zweck haben dürfte. Ich war vor knapp einem Jahr bei einer Veranstaltung zur Vorstellung der GOBD und der Großteil der Kollegen, die sich zu Wort gemeldet haben, wäre dem netten Herren, Mitverfasser der GOBD, gerne an die Gurgel gegangen. Die Spannung war schon greifbar.

Es liegt natürlich an Datev und Konkurrenten das ganze irgendwie noch praxisnah umzusetzen und ich bin mir momentan immer noch nicht sicher, ob es Datev nicht gelungen ist oder die GOBD tatsächlich die Schlinge um den Hals so eng gesetzt hat dass es nicht anders zu lösen ist.

So bekommt Datev natürlich den ganzen Ärger ab aber ich denke dass ist zu kurz gedacht. Man sollte die Kraft lieber darauf verwenden, sich gegen die GOBD zu wehren und Verbesserungen einzufordern.

da gebe ich Ihnen völlig recht

aber wer ist da wohl besser im Stande wie die DATEV, die ja die Genossenschaft der Steuerberater ist mit über 40.000 Mitgliedern.

ein einzelner StB hat wohl verloren, aber wenn der zusammenschluss der StB - die DATEV was dagegen unternehmen würde, wäre wohl allen geholfen

so werden wir zu dem gezwungen was wir alle nicht wollen.

Ja es wäre natürlich auch eine Maßnahme wenn die Datev selbst tätig werden dürfte!

bitte den dienstleister datev nicht mit der steuerberaterkammer, dem steuerberaterbverband oder dem bundestagsabgeordneten ihres wahlkreises verwechseln....

Wo bitte steht in der GOBD, dass vorläufige Buchungen sofort festgeschrieben müssen?
Die Importe müssen nur nachvollziehbar sein, dass ist alles. Und das könnte man ganz leicht mit einem Importprotokoll gewährleistet sein.

Also: Wo steht die Textpassage, dass immer sofort festgeschrieben werden muss?

Wie gesagt, etwas anderes sind echte bereits journalisierte DATEV-Vorläufe. Da gehe ich mit der DATEV konform, aber doch nicht vorläufige Buchungen!

Gruß A. Martens

So bekommt Datev natürlich den ganzen Ärger ab aber ich denke dass ist zu kurz gedacht. Man sollte die Kraft lieber darauf verwenden, sich gegen die GOBD zu wehren und Verbesserungen einzufordern.

In die Runde:

Es gibt ein paar Dinge, die wir seit Ewigkeiten vermissen:
(Datenaustausch über das Rechenzentrum)

1. Daß unsere Festschreibung eines Stapels erhalten bleiben, Datum und Sachbearbeiter.
2. Daß unsere Auszifferungen erhalten bleiben.

Wenn wir den Bestand mit den Jahresabschlußbuchungen aus dem Rechenzentrum zurück holen sind alle diese Informationen weg, und die Kanzlei behauptet, das ginge nicht anders, da Nürnberg diese Daten nicht speichern würde.

Hallo,

hier im Beitrag ist so einiges durcheinander gekommen. Letztendlich geht es zum einen ja um die Festschreibung bei Übermittlung der Umsatzsteuer-Voranmeldung und zum anderen um das Festschreiben bei Datenimporten.

Durch Teilnahme an der Pilotphase arbeite ich bereits mit der Jahreswechselversion von Kanzlei-Rechnungswesen pro - hier ein kleiner "Erfahrungsbericht" zum Thema Festschreibung:

Daten senden/Übermittlung Umsatzsteuer-Voranmeldung

Hier ändert sich nichts zur bisherigen Vorgehensweise. Aktuell ist es ja bereits so, dass die Buchungsstapel bis einschließlich des zu übermittelnden Voranmeldezeitraums automatisch zum Festschreiben vorgeschlagen werden. Soll hier nicht festgeschrieben werden, müssen die Buchungsstapel entsprechend abgewählt werden. Diese Möglichkeit besteht auch weiterhin, mit entsprechendem Recht in der Nutzungskontrolle kann auch zukünftig die Festschreibung ausgeschaltet werden.

Die Protokollierung dieses manuellen Eingriffs sehe ich vollkommen unproblematisch und auch gerechtfertigt. Durch die Protokollierung wird nur verdeutlicht, was bereits seit Jahren durch den Vergleich der Sendevorgänge mit den tatsächlichen Festschreibedaten der Buchungsstapel offenkundig ist.

Auch die hier vorgetragenen Sondersachverhalte hinsichtlich der EB-Werte der Sachkonten können also weiterhin (programmseitig) individuell gehandhabt werden. Welche Buchungssachverhalte GoBD-relevant sind, muss jeder für sich entscheiden. Ich sehe allein aufgrund des steuerlichen Gewinnbegriffes Eröffnungsbilanzbuchungen wie jede andere Buchung als "festschreibepflichtig" an. Der Begriff des Geschäftsvorfalles ist in den GoBD konkretisiert, inwieweit diese Definition auslegbar ist, bleibt ebenfalls jedem von uns selbst überlassen.

Nur weil sich die mehr oder weniger konkreten Fristen für die endgültige Verbuchung an der Abgabe der Umsatzsteuer-Voranmeldung orientieren, geht es hierbei jedoch selbstverständlich nicht nur um Buchungen mit umsatzsteuerlichen Sachverhalten.

Importvorgänge

Was passiert ab 2016? Importdaten mit Festschreibeinformationen (Festschreibung=Ja) werden programmseitig beim Einspielen festgeschrieben. Beim Import kann die Festschreibung aufgehoben werden, was protokolliert wird. Die Festschreibung wird übrigens programmseitig automatisch aufgehoben, falls in den Importdaten fehlerhafte Buchungssätze enthalten sind, die übernommen werden sollen.

Importdaten ohne Festschreibeinformationen werden ohne automatische Festschreibung übernommen. Im Rahmen des Imports kann die Festschreibung wahlweise aber auch sofort erfolgen.

Ab 2017 erfolgt bei Importdaten ohne Festschreibeinformationen ein automatisches Festschreiben, auch diese Festschreibung kann deaktiviert werden.

Ab 2018 soll das manuelle Aufheben der Festschreibung wohl nicht mehr möglich sein.

Angaben zur Festschreibung werden beim Import protokolliert. Hierbei wird aber unterschieden, ob bei Importdaten mit Festschreibung=JA die Festschreibung deaktiviert wurde, oder ob die Importdaten keine Festschreibeinformationen enthielten und deswegen nicht festgeschrieben wurden. Erklärungsnöte dürften also nicht entstehen.

Hier sehe ich im Allgemeinen auch bei eventuellen Prüfungen kein Problem. Das Aufheben der Festschreibung dürfte ja immer dann zum Tragen kommen, wenn die Importdaten eventuell später verändert oder angepasst werden sollen. Da auch die dem Import zu Grunde liegenden Quelldaten (z. B. Schnittstellendaten, reine Excel- oder txt.-Dateien) aufbewahrungspflichtig sind, könnte hier im Zweifel durch Vergleich der tatsächlichen Buchung mit den ursprünglichen Daten ein klärender Vergleich erfolgen.

Unterm Strich können wir also weiterhin selbst entscheiden wann und wo festgeschrieben wird, lediglich die programmseitige Vorbelegung orientiert sich an der gesetzlichen Ausgangslage.

Ich denke, wir sollten auch nicht vergessen, dass der Standardfall bisher ohnehin vermutlich beim Festschreiben spätestens beim Senden der Daten bzw. der Datenübermittlung liegen dürfte, also so, wie es im früheren, roten, Kanzlei-Rechnungswesen der Fall war.

Auch sollten wir nicht vergessen, dass ein zu spätes Festschreiben nicht per se gegen die Ordnungsmäßigkeit der Buchführung spricht, hier wird es wohl auch wie bisher auf die berühmten "Umstände des Einzelfalls" ankommen.

Generalumkehrbuchungen und möglicherweise versehentlich festgeschriebene Buchungsstapel

Einen festgeschriebenen Buchungsstapel können Sie schon längere Zeit im Programm komplett "generalumkehren", öffnen Sie dazu die Auswertung Primanota mit dem jeweiligen Buchungsstapel und klicken Sie im Kontextmenü auf "Stapel mit Generalumkehr-Buchungen erzeugen". Dadurch werden die Buchungen neutralisiert.

In der Version zum Jahreswechsel können Sie zudem durch Generalumkehrbuchung stornierte Buchungen in verschiedenen Auswertungen, z. B. im (Abschluss-)Konto, ausblenden lassen. So werden unter anderem auch EB-Werte der Sachkonten bei mehrfacher Übergabe übersichtlich dargestellt.

Es dürfte wohl unstrittig sein, dass die GoBD uns noch mehr abverlangen als ohnehin schon. Ich bin jedenfalls froh, dass die Rechnungswesen-Programme hier zukünftig den Mindeststandard unterstützen. Ich finde es nicht schlimm, dass ich an der einen oder anderen Stellen zukünftig ggf. einen Haken entfernen oder setzen muss, wenn ich vom Standard, aus welchen Gründen auch immer, abweichen möchte. Weitaus bedenklicher und komplizierter bei dieser Thematik stellt sich m. E. der "Dunstkreis" rund um die eigentliche Buchführung dar, wie z. B. Langzeitaufbewahrung weiterer Daten (Import), eingesetzte Fakturierungssysteme beim Mandanten und übrige Fehlerquellen wie Kassenaufzeichnungen bei bargeldintensiven Fällen (z. B. Kassenerfassung für Office).

Jedenfalls sehe ich zurzeit keinen Anlass, nur aufgrund der Programmänderungen zur Festschreibung die eigene Arbeitsweise komplett überdenken zu müssen, in Hinblick auf die GoBD an sich ist das hingegen m. E. teilweise schon erforderlich.

Wie im Beitrag deutlich wurde, gibt es viele unterschiedliche Sachverhalte, Sonderkonstellationen und individuelle Herangehensweisen, die wir aber auch im nächsten Jahr weiterhin so wie bisher umsetzen können. Etwas salopp ausgedrückt "wer will oder muss, kann das weiterhin so machen".

Ich hoffe, ich konnte die eine oder andere Irritation bzw. Unsicherheit mit meinem kleinen Bericht aus der Welt schaffen und wünsche Ihnen allen ein schönes Wochenende - trotz GoBD ; - )

Viele Grüße

Christian Wielgoß

Die Festschreibung wird übrigens programmseitig automatisch aufgehoben, falls in den Importdaten fehlerhafte Buchungssätze enthalten sind, die übernommen werden sollen.

Ab 2018 soll das manuelle Aufheben der Festschreibung wohl nicht mehr möglich sein.

Sehr geehrter Herr Wielgoß,

wird die automatische Festschreibung von Buchungsstapeln auch ab 2018 noch aufgehoben wenn fehlerhafte Buchungssätze vorliegen? Ist dies so zu verstehen, dass der ganze Stapel vollständig änderbar bleibt wenn eine einzige rot markierte fehlerhafte Buchung vorliegt? Muss der Stapel dann manuell festgeschrieben werden oder wird automatisch festgeschrieben sobald die fehlerhafte Buchung geändert wurde?

Mit freundlichen Grüßen,

Florian Mayer

Hallo Herr Mayer,

für 2018 wäre im Moment ein Blick in die Glaskugel erforderlich : - )

Ich denke, hier sollten wir etwas Geduld haben und erst einmal den Jahreswechsel abwarten.

Viele Grüße

Christian Wielgoß