Ich danke für eure antworten, die habe die Gewerbesteuer Rückstellung nun in 2023 mit folgendem Buchungskonten aufgelöst.
Im ersten Beitrag ging es noch um eine Gewerbesteuerernachzahlung die geleistet wurde. Jetzt schreibst Du davon eine Gewerbesteuerrückstellung aufzulösen, anscheinend ohne eine Zahlung. Der Grund für die Auflösung der Rückstellung wird nicht erwähnt.
Sicher, ich muss nicht wissen was Du da tust. Mir kommt es aber so vor, als weißt Du es selbst nicht so genau. Kann das sein?
Die Angabe zur Position ‚Betriebsvermögen zum Ende des vorangegangenen Wirtschaftsjahres‘
stimmt nicht mit dem um den Wert für
‚Nicht durch Eigenkapital gedeckter Fehlbetrag / nicht durch Vermögenseinlagen gedeckter Verlustanteil / nicht durch Vermögenseinlagen gedeckte Entnahmen / nicht durch Vermögenseinlagen gedeckte Abfindungen, Privatkonto (Einzelunternehmen) [Aktivseite], Anfangskapital‘
verminderten Summenwert für
‚Gezeichnetes Kapital / Kapitalkonto / Kapitalanteile, Privatkonto (Einzelunternehmen), Anfangskapital [Privatkonto, Passivseite]‘
und
‚Eigenkapital, steuerlicher Ausgleichsposten, steuerlicher
Ausgleichsposten - des letzten Stichtags‘
überein.
Damit sollte der Fehler durch die KPH-Gruppe gefunden und korrigiert werden können.
Meine erste Frage wäre gewesen, welche Version verwendet wird, was wegen des beschnittenen Screenshot nicht zu erkennen ist. 
Es genügt, jedoch auch eine Rechnung ohne Artikel zu erfassen um aus dem so erstellten OP eine Mahnung erstellen zu lassen.
nutze ich noch die Mini-Version.
Zum Kennenlernen des Programms lege Dir eine Test-Firma an und probiere die Funktionen ausgiebig. Dafür ist die Mini-Version ausreichend und in den hier benötigten Programmbereichen ohne Unterschied zu den lizenzpflichtigen Versionen.
Viel Erfolg!
um abzuwägen, ob eine entsprechende Arbeit NÜTZLICH wäre.
... muss ein mitlesender Entwickler erkennen können, unter welchen Voraussetzungen die gewünschte Funktion die gewünschte effiziente Prüfung überhaupt ermöglicht. Das hat mit "Technikkeule" nichts zu tun.
Was als Weitpinkelwettbewerb missverstanden wurde ist der Versuch, die Fehlerursache zu erkennen um eine Lösung für das eigentliche Problem zu suchen. Das eigentliche Problem ist aber, dass Belege von Hand verknüpft werden und dabei offensichtlich ohne den Dateinamen zu beachten falsche Verknüpfungen vorgenommen werden. Eine intelligente Lösung würde hier ansetzen und nicht erst bei einer nachträglichen Prüfung.
Ich kann die Entwickler nur darum bitten, ihre Kapazitäten nicht für solche Aufgaben einzusetzen, sondern z. B. die Verarbeitung von Eingangsrechnungen als E-Rechnung zu priorisieren. Damit ist ein - wie auch immer erfolgendes - umbenennen der Dateinamen unnötig (Fehlerquelle ausgeschlossen) und eine Belegzuordnung eindeutig an Hand der vorliegenden Belegdaten (statt Dateinamen) möglich.
Ähnliches könnte die Belegscanfunktion bieten, die seit geraumer Zeit auf der Liste "In Vorbereitung" steht.
Ich denke außerdem, dass eine Erklärung, die den Inhalt des Handbuchs in anderen Worten erläutert stets besser ist, als ein Verweis auf oder ein Zitat des original Textes.
Das kann man vielleicht für begrenzte Passagen aus dem Handbuch machen, die gelesen aber nicht verstanden wurden. Aber offenbar mehrere Bereiche der Hilfe sich in neuer individualisierter Formulierung herunterschreiben zu lassen halte ich für einen Anspruch den kein mir bekanntes Forum erfüllt. Individuelle Einführungen in ein Programm - wenn man sich nicht selbst mit den Grundlagen auseinander setzen mag - leisten bei allen mir bekannten Programmen externe Dienstleister.
Weiterhin halte ich es grundsätzlich in Foren für einen schlechten Ton, dem Hilfesuchenden zu unterstellen, er habe nicht ausreichend gesucht.
Ich finde hingegen ein berechtigtes RTFM - auch noch so freundlich umschrieben wie oben - dient der Erinnerung an forenübliche Gepflogenheiten. Schließlich wurde statt des einfachen Verweises auf die Hilfe noch eine individuelle Zusammenstellung der betreffenden Bereiche geliefert, die vermutlich bisher einfach nicht gelesen wurden.
Wirtschaftsjahr abgeschlossen, in der Hoffnung, dass automatischen Buchungen erfolgen - leide rnicht.
Wie sollte das auch gehen? Das Programm kann ja nicht erahnen, welche Buchungen vergessen wurden.
Durch das Abschließen d. WJ im Programm werden lediglich weitere Buchungen in dem Jahr verhindert. Dabei werden nie Buchungen ausgeführt.
Um evtl. nicht erfolgte Buchungen nachzuholen muss das "Abscließen" rückgängig gemacht werden.
Mein Rat, bitte nicht einfach herumprobieren. Befasse Dich vor der Verwendung von Funktionen damit, so dass Du auch weißt was Du da tust.
Ich habe schon etliche Buchhaltungen aus Fremdsystemen nach Taxpool übernommen. Dabei ist nicht nur erfotderlich sich die passenden Dateien aus dem Vorsystem zu besorgen, man muss auch wissen, was darin für Daten stecken und wie man damit vorgeht.
Die Konten sollte man natürlich zuerst Importieren, bevor Buchungen importiert werden, die ja auf die Konten zugreifen.
Erhältst Du denn irgendwo einen Hinweis, welche Konten konkret fehlen?
Es werden wohl die Personenkonten fehlen.
Ich wundere mich, warum man sich bei der Auswahl des eingesetzten Programms nicht über den Stand der jeweiligen teils verzweifelt benötigten Funktionen an der Dokumentation orientiert. Demnach ist der Amazon-Transaktions-Import ein Prototyp und der setzt voraus, dass man sich die Dateien selbst besorgt.
Der Ausblick auf kommende Versionen, die einen automatischen Abruf ermöglichen sollen ist ohne jegliche Zusage zu einem Zeitpunkt gemacht.
Wer nach dem Prinzip Hoffnung darauf setzt, die Umsetzung erfolge rechtzeitig genug um eigenen Notwendigkeiten zu entsprechen muss mit dem negativen Ausgang seiner Wette rechnen. Auch wenn ich mitfühle und leider auch nicht helfen kann, sehe ich keinen Grund, Taxpool nun als quasi auskunftspflichtig anzusehen.
Vielleicht findt sich aber doch noch ein Forums-User, der helfen kann. Ich drücke die Daumen!
Importiert Amazon-Transaktionen aus Textdateien (bisher Prototyp).
In folgenden Versionen wird auch ein automatischer Abruf der Daten mittels der Amazon-API möglich sein.
Bereits importierte Transaktionen werden automatisch erkannt.
Wichtig: Es ist zu empfehlen, sich vor der ersten Nutzung zuerst eine Testfirma anzulegen, in die die Daten importiert werden können, um die Importeinstellungen zu testen.
Und nicht zu vergessen: Wenn ich Taxpool via API mit anderen Programmen verbunden habe, ist es deutlich schwieriger auf eine andere Fibu zu wechseln.
Ob also das im Interresse des Anwenders ist mag jeder für sich entscheiden. Für mich ist Taxpool für viele Mandanten genau deshalb das geeignete Programm, weil es weder Preisstaffeln nach Mandantenanzahl noch hohe Fixkosten verursacht, ganz anders als Programme die es dem Anwendrr schwer machen zu wechseln.
Für das komplette End-to-End Verständnis mag es sinnvoll sein, ...
Tut mir Leid, wenn ich genau das verstehen wollte.
, aber das wird bei jedem Anwender völlig individuell sein.
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.
Es gibt keinen nachvollziehbaren Grund für tiefgehende Änderungen der Benutzerführung wegen der Linux Version.
Hoffen tue ich auch. Aber dss Prinzip Hoffnung hat mich zu oft entteuscht. 
Wenn auch nicht bei Taxpool.
Für mich sind vielleicht auch im Grunde wenig tiefgehende Veränderungen schon solche, die mich aus dem Konzept bringen. Softwareentwickler haben da bestimmt eine andere Schmerzgrenze als der unbedarfte User, der z. B. eine gut gemeinte intuitive Benutzerführung nicht begreift.
In solchen Dingen ist langjährige Erfahrung eher hinderlich. Wenn der gewohnte Umgang sich ändert ist es schwieriger sich darauf einzustellen als ohne "Vorbelastung" etwas neu zu lernen.
Das Problem kenne ich z. B. bei Buchhaltungs-Neulingen. Wenn sie erst mal etwas falsches verinnerlicht haben, muss erst das "bekämpft" werden ehe Platz für das (neue) Richtige ist. 
Und was spricht dagegen, hier trotzdem einen guten Service zu leisten
Geht es denn besser?
Funktioniert die Darstellung in der Vorschau nun bei Dir?
So langsam macht mir die Linuxversion Angst.
Als Linux-Laie dachte ich bisher nicht an Unterschiede der Distributionen, welche ich bislang nur in Unterschiede der enthaltenen Programme vermutet habe. Daher Danke für die Frage und die Antworten hier.
Ich befürchte nun noch mehr, dass die Anpassungen hin - zu Linux und ggf. dort für unterschiedliche Distributionen - die Fähigkeiten und Bedienung (Oberfläche) der Windowsversion derart ändern, dass ich mich nicht mehr zurechtfinde. Womöglich auf einen Schlag.
Da ich Taxpool schon seit langer Zeit einsetze kenne ich die für mich wichtigen Änderungen auch wenn sie in der Hilfe teils nur knapp hinzugefügt oder für mich teils garnicht auffindbar sind. Auch dazu befürchte ich, dass die Anpassungen bisher erworbenes Wissen nutzlos macht.
Wenn dann die Hilfe in ähnlich knapper Form wie bei Ergänzungen (z. B. beim DMS) erfolgt und nur IT-Leuten verständlich genug ist, müsste ich passen.
Ich kenne mich mit einigen Programmen (Buchhaltungen/Lohn) aus und verfolge deren Entwicklung, lerne also stets damit umzugehen. Allerdings lehne ich bereits Aufträge ab, die vorgegebenermaßen in einem für mich neuen Programm zu erledigen wären, einfach weil ich nicht in zu vielen Programmen auf dem Laufenden bleiben kann.
Würde Taxpool sich so verändern, dass es quasi wieder Neuland für mich ist, muss ich abwägen (ohne damit drohen zu wollen!) ob ich damit weiter arbeite. Es wäre verdammt schade!
Meine Befürchtungen würde ich mir nur zu gerne zerstreuen lassen.
Andere DMS, die sich auf bequeme Dokumenentenablage spezialisiert haben, stecken das Taxpool DMS bequem in die Tasche, lassen aber häufig genau diesen Nachweis außer Acht (oder sind sau teuer).
Ich halte den Vergleich von zwei DMS mit unterschiedlicher Spezialisierung/Aufgabenstellung für wenig Aussagefähig, auch wenn das optionale Taxpool-DMS für seinen Zweck dabei sehr gut ausfällt.
Wenn man sich auskennt, ist wahrscheinlich ein Workflow ...
Das ist mir viel zu kompliziert. Der Beleg wird in Taxpool auf eine Buchung gezogen, dabei erfolgt die Verknüpfung der Buchung zum Beleg (eindeutig, progressiv und retrograd).
Mehr sollte nicht zu tun sein und das mit oder ohne der Nutzung des unter Windows (!) laufenden DMS bei Taxpool.
Im Absatz Hintergrund und Anforderung fehlt mir der Hintergrund dazu
Bei den präventiven Maßnahmen sind einige, die ich nicht verstehe oder auch deren Sinn nicht erkenne:
Hinterlegung eines Pattern/Musters für den Dateinamen pro Buchungskonto
Welches der beiden Buchungskonten soll das führende Konto dabei sein?
Automatische Prüfung bei Verknüpfung eines Belegs gegen das Pattern
Ablehnung/Sperre bei Drag&Drop, wenn ein Beleg nicht dem erwarteten Muster entspricht
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.
Die danach aufgeführte Übersteuerbarkeit für Ausnahmefälle ist dann auch nicht mehr nötig.
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.
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.
* Welche die geeignetsten sein können hängt von den Fehlerquellen ab, zu denen nicht viel bekannt ist.
Spätestens wenn der StB die Buchungen erhält, wirst Du die doppelt erfassten Buchungen zu Rechnungen die von Hand und automatisch gebucht wurden nicht einfach ignorieren können.
Solche Änderungen am Vorgehen sollten immer vorab und nicht in der "echten" Firma getestet werden. Wenn die Buchungen dann auch noch an anderer Stelle weiter bearbeitet werden (etwa beim StB) sollte diese Stelle rechtzeitig vorher einbezogen werden, statt evtl. erst am Jahresende alle Buchungen des Jahres zu übermitteln, die dann über etliche Monate hinweg zu korrigieren sind.
soweit nicht Gewerbesteuerrückstellungen aus Vorjahren aufzulösen waren.
Ich würde auch erst prüfen, ob nicht eine Rückstellung zu bilden vergessen wurde.
Wir wissen ja nicht genauer als im Titel angegeben "Nachzahlung Vorjahre" worauf sich der Betrag bezieht.
Ich hätte erwartet, dass eine explizite Prozentangabe im Kontennamen auch einen festen Steuersatz bedeutet. Aber ich verstehe nun, dass die "19%" in vielen DATEV-Kontobezeichnungen eher eine (historische) Momentaufnahme war/ist und nicht als technische Spezifikation verstanden werden soll.
Genau so ist es und daher tragen die Kontenrahmen der DATEV eine Jahresangabe "Gültig für JJJJ" und bei Bedarf gibt es Kontenrahmenänderungen nicht nur zum nächsten Jahr, sondern auch innerhalb eines Jahres.
Mein IT-Gehirn hätte sich Kontobezeichnungen ohne "hartcodierte Prozentangaben" gewünscht - so wie es bei anderen Konten ja auch gemacht wird (z.B. Konto 6325 heißt einfach "Gas, Wasser, Strom" und nicht "Gas, Wasser, Strom 19% VSt").
Wenn Du Aufwandskonten mit Ertragskonten vergleichst ist das wie mit Äpfeln und Birnen. Der Vergleich hinkt. Automatikkonten gibt es in den Aufwandskonten nicht.
Warum dann nicht auch "Sonstige Erträge betrieblich und regelmäßig" ohne die "19% USt"?
Welche sonstigen betrieblichen und regelmäßigen Erträge würden denn nicht mit dem vollen USt-Satz der USt zu unterwerfen sein? 
