Gelöst Datev Export - Schnittstellen - Sinnhaftigkeit v. Nexus und Jera

[ruth]

Hallo,

ich habe mir die Schnittstellen Jera und Nexus auf der Webseite angeschaut und auch hier

https://forum.jtl-software.de/threa...nittstelle-zum-steuerberater-finanzamt.90705/

gelesen. Ich habe eine Frage über die Sinnhaftigkeit der Lösungen, die ich derzeit nicht finden kann.

Wo ist hier mein Denkfehler? Wozu werden die Programme tatsächlich benötigt? Meine Überlegungen:

1.) Die Ausgangsrechnungen werden per Ameise ( Datev) exportiert und Debitorisch (Sammel JTL2017, 12017) gebucht.
2.) Bei allen Rechnungen die über Amazon erfolgten erfolgt sofort die Bezahlbuchung über ein Verrechnungskonto. Geht ja auch über einen Import.
3.) Die monatlichen Rechnungen von Amazon werden über 3123 (SKR03) kreditorisch gebucht und sofort über das Verrechnungskonto als bezahlt gebucht.
4.) Die Bankauszahlung von Amazon bucht man nun ebenfalls an das Verechnungskonto.

Die Rechnungen die über die Bankkonten bezahlt werden, werden ja in der buchhaltung über die Onlinebankingmodule automatisch weggebucht.

Was brauchst da eine Schnittstelle? Die Frage mag provokant sein, tatsächlich frage ich aber ob ich nicht etwas falsch liege. Es nutzen ja wohl einige die Schnittstellen. Ich frage halt warum? Ich möchte meine Frage also Konstrutiv verstanden wissen.

 

[_simone_]

Hm, seit wir Nexus nutzen hat die Buchhaltung öfters mal die Beine aufm Schreibtisch, meistens gute Laune und ist immer bereit für ne Kaffeepause; das war vor Nexus nicht so.
Ich hab nicht wirklich die Ahnung warum das so ist, aber das ganze Buchen ist wohl schnell und zuverlässig gemacht.

Unsere Buchhaltungssimone wird sich aber bestimmt dazu auch noch zu Wort melden.

 

[Simone_die_Echte]

Na klar sagt die Buchhaltungssimone auch was dazu:
1. Wann bitteschön liegen meine Beine auf dem Tisch? Unverschämtheit!
2. Gute Laune bringt der Nexus definitiv!

Ich finde es einfach ungemein praktisch, dass sich dieses Programm mit nur einem Klick die Daten aus JTL zieht und alles vollautomatisch zu Buchungssätzen verarbeitet.
Das Einspielen der Abrechnungen von Paypal und Amazon ist ebenfalls ein Klacks.
Die Amazonabrechnungen werden - ebenfalls duch nur einen Klick- charmant in die entsprechenden Buchungssätze verwandelt. Inklusice Aufteilung von Shipping Gebühren, Verkaufsprovisionen, Subcriptrion Fee.
Ebenso sieht es mit den Paypalabrechnungen aus. Auch dort werden die Gebühren vollautomatisch erfasst.

Es gibt sicherlich mehrere Wege die ans Ziel führen. Vielleicht fehlte mir auch einfach das Vertrauen in die Exportkünste der Ameise bzw. meinem Umgang damit.

Für mich ist die Wawi in erster Linie eine Warenwirtschaft. Wenn ich sehe, wie fehlerhaft und unanwenderfreundlich mitunter Bereiche sind, die nicht zu ihrer Kernkompetenz gehören (z.B. die Statistik) liegt der Gedanke halt nahe, sich für diese Bereiche auf Programme zu verlassen, die genau dieses (nämlich die Buchführung) als ihre Kernkompetenz haben.

Mich hat einfach die Narrensicherheit des Programms überzeugt. Und wenn ich doch mal ein Problem, eine Frage oder einen Änderungswunsch habe, erhalte ich im Nullkommanix einen Rückruf und superkompetente Hilfe.
Ich höre es schon vom Nebentisch "Luxusweib" rufen...

 

[ruth]

Vielen Dank für die Antworten. Viel Inhalt haben sie aber nicht wirklich. Außer das ich eine Hotline habe, lese ich nichts was die Schnittstellen notwendig macht. Kann den keiner klar inhaltlich Stellung nehmen?

Was heißt denn:

"Die Amazonabrechnungen werden - ebenfalls duch nur einen Klick- charmant in die entsprechenden Buchungssätze verwandelt. Inklusice Aufteilung von Shipping Gebühren, Verkaufsprovisionen, Subcriptrion Fee.
Ebenso sieht es mit den Paypalabrechnungen aus. Auch dort werden die Gebühren vollautomatisch erfasst."

Es muß doch über 3123 gebucht werden, oder baut ihr euch noch extra Konten? Wenn ja warum?

Wenn die Schnittstellen die JTL-DB lesen und das fehlerfrei passiert, dann kann ich doch erst recht davon ausgehen, dass JTL-Ameide die eigene DB genauso gut lesen kann.

Und nun zur Amazonrechnungsbuchung: Ich will natürlich an dem Buchhungsatz den Beleg angehängt haben und nicht auch noch extern, außerhalb der Buchführung Beleg revisionsicher aufbewahren. D.H. ich muß eh zum BS und das PDF anhängen. Da kann ich doch schneller mit einer Buchungsvorlage arbeiten. Das PDF anhängen, Betrag eintrag, fertig. Oder ich schicke die PDFs zu Datev, die mir dann einen fertigen Buchungssatz mit Beleganhang machen.

 

[Simone_die_Echte]

Also noch mal, diesmal auf den Inhalt beschränkt:
1. Bei Nexus brauche ich mich nicht selber um Einrichtung und richtige Zuordnung zu kümmern. Für Menschen wie mich mit einem rudimentären Wissen um Buchführung und Datenbanken genau das Richtige.
2. Der Sinn von extra Konten liegt für mich in der detaillierteren Auswertungsmöglichkeit.
3. Es ist einfach, schnell und um Probleme die entstehen wenn zum Beispiel Paypal mal wieder das Format der Abrechnungen ändert, brauche ich mich nicht zu sorgen.
Es ist also die Ich-nehm-etwas-Geld-in-die-Hand-und-lass-andere-das-machen-wovon-ich-keine-Ahnung-habe-Lösung

Aber du scheinst ja schon sehr genau zu wissen, was du wie buchen möchtest und bist dir auch ob der technischen Möglichkeiten im Klaren.

Teste doch einfach die Features der Ameise und schau, ob es für dich der richtige Weg ist.
Wenn dir dies dann zu umständlch ist, bleibt ja immer noch von anderen Programmen eine Testversion zu installieren und diese auszuprobieren.

Es lässt sich sicherlich nicht pauschal beantworten, was für wen und welchen Betrieb DIE Lösung ist.

Oder stell deine Fragen an Jera und Dekodi und schau, ob sie dich mit ihren Antworten überzeugen.

 

[ruth]

Danke für die klare Antwort Simone die Echte.

zu 1. Da ich als Vollkaufmann für die Buchführung selbst verantwortlich bin und dafür hafte, kümmere ich mich natürlich um das notwendige wissen. Die IHK und Datev bieten entsprechende Kurse an, für den Rest hat es den Steuerberater.
zu 2. Die Auswertung bekomme ich auch auf einem Konto hin oder halt mit den Berichten von Amazon u. Co. / wenn ich es denn tatsächlich brauche
zu 3. Paypal macht schon immer csv, seit Jahrzehnten was wurde da bisher geändert?

"Ich-nehm-etwas-Geld-in-die-Hand-und-lass-andere-das-machen-wovon-ich-keine-Ahnung-habe-Lösung" Warum dann das Geld nicht zum Steuerberater tragen, der dann wenigstens bei falscher Buchhaltung haftet.

Jera und Dekodi können mir tatsächlich nicht die Fragen beantworten. Weder haben sie auf der Website die notwendigen Informationen, noch konnten sie befriedigente Antworten auf der JTL Hausmesse geben. Zumindest jene die da waren. Deshalb frage ich ja hier nach der Sinnhaftigkeit solcher Tools, mit konkren Beispielen. Und diese könnten weniger gut, oder sogar falsch sein und dann könnte man vernüftig Antwort geben um damit den Sinn solcher Lösungen darzustellen.

 

[dekodi]

Hallo ruth,

wir sind nicht auf der JTL-Hausmesse vertreten, weil in Bayern zu dieser Zeit noch Schulferien sind
und wir uns schwer tun, genug Personal (viele MA mit schulpflichtigen Kindern) für den Stand zusammenzubekommen.
Dass unsere Kundenbetreeung deine Fragen nicht beantworten konnte, tut mir leid.
Ich habe das zum Anlass genommen, unser Team nochmals entsprechend zu schulen.

Nun zu deiner Frage nach der Sinnhaftigkeit von "Tools" wie Nexus.
Ich wage den Versuch einer Erklärung, obwohl das Thema für einen Forenbeitrag
an sich zu vielschichtig und komplex ist.

Zunächst einmal muss man die Aufgaben der Buchhaltung beschreiben.
Die Buchhaltung soll (u. a.) zunächst einmal sicherstellen, das der Unternehmer korrekt Steuern zahlt.
Das Gesetz spricht hierbei von einer progressiven und einer retrograden Funktion der Aufzeichnungspflicht.
D. h., dass man von der Steuererklärung "rückwärts" alle Belege finden muss, die in die Steuererklärung
eingeflossen sind und andersherum alle Belege "vorwärts" bis in die Steuererklärung hinein
verfolgen können muss.
Nun bringt es der Onlinehandel mit sich, dass durch den Versand aus und nach aller Herren Länder
eine umsatzsteuerliche Vielfalt entseht, die beinahe die Ausmaße eines internationalen Konzerns
annimmt (Ein durchschnittlicher Onlinehändler, der europaweit handelt hat rd. 30 umsatzsteuerliche
Einzefälle. Wenn er noch Amazon PAN EU macht, sind wir bei rd. 60 Einzelfällen.)
Darüber hinaus sind mehrere Systeme an der Geschäftsabwicklung beteiligt (JTL, Amazon, ebay, Shops,
Finanzbuchhaltunghaltung usw.)
Die Aufgabe der Buchhaltung besteht nun darin, alle Geschäftsvorfälle so aufzuzeinchen, dass daraus
(unter anderem)klar hervorgeht, welche Steuerlast an wen (welches Land) zu bezahlen ist.

Diese Aufzeichnung hat lt. Gesetz sinngemäß aus eigenen Unterlagen und aus den Originalbelegen zu erfolgen.
D. h., dass du deine Rechnungen aus der JTL-Wawi verbuchen musst und ebenso den Amazon-Settlement-Report,
den PayPal-Kontoauszug und auch den ganz normalen Kontoauszug deiner Bank.
Nun ordnest du in deiner JTL-Wawi z. T. von Hand, z. T. automatisch jeden Tag die PayPal- und Bank-Zahlungen
den Bestellungen zu, Amazon geht sowieso automatisch.
Die Buchhaltung muss nun aber sicherstellen, dass der PayPal-Kontoauszug (genauso die Bank und Amazon usw.)
VOLLSTÄNDIG in der Buchhaltung aufgezeichnet wird; also alle Gebühren, Bezahlung von Lieferanten,
Sicherheitseinbehalte etc. Viele dieser Positionen werden in der Warenwirtschaft nicht erfasst und
können demnach auch nicht exportiert werden.

Um nun den gesetzlichen Anforderungen gerecht zu werden, braucht es zwei Dinge:
1. Eine offene Posten Buchhaltung
2. Die vollständige Verbuchung der Originalbelege

Die offene Posten-Buchhaltung ist ein Vefahren, bei dem jede Rechnung einzeln eingebucht wird.
Die Zahlungen (Amazon, PayPal, Bank etc.) werden nun ebenfalls einzeln den Rechnungen zugeordnet.
Wenn z. B. jede Zahlung aus dem Amazon-Settlement-Report einer entsprechenden Rechnung aus JTL zugeordnet
ist, dann ist klar, dass du kein Geld am Fiskus vorbeigeschleust hast und dass Amazon alle Rechnungen
bezahlt hat. Und genau hier kommt unser Nexus zum Einsatz.
Er holt sich aus der JTL-Wawi die einzelnen Rechnungen, prüft diese rechnerisch und auch unter
umsatzsteuerlichen Gesichtspunkten (z. B. war der auf der Rechnung angegebene Steuersatz
zum Zeitpunkt der Rechnungsstellung überhaupt zulässig) und erstellt dann die sog. Debitoren-Sollstellungen.
D. h. er erzeugt eine Buchungsdatei, die in das Finanzbuchhaltungssystem eingelesen wird.
Dort sind dann zunächst einmal alle Rechnungen einzeln aufgezeichnet.
Anschließend liest man die Abrechnungen/Kontoauszüge von Amazon, Paypal etc. ein.
Nun geht es genau andersherum: Nexus sucht zu jeder Zahlung die entsprechende Rechnung und gleicht
diese aus. Gebühren, Währungswechsel, Sicherungseinbehalte, Käuferkonflikte etc. werden dabei
ebenfalls einzeln gebucht. Anschließend geht dann wieder alles in die Finanzbuchhaltung.
Wenn man die Buchhaltung systemisch korrekt aufzieht (Details würden an dieser Stelle zu weit führen),
kann gegenüber dem Finanzamt problemlos nachgewiesen werden, dass alles seine Richtigkeit hat.
Weiterhin kann man Nexus so einstellen, dass wichtige betriebswirtschaftliche Zahlen direkt
in der BWA ablesbar sind. Z. B. der Umsatz pro Verkaufskanal, Retouren und die versteckten Wechselgebühren,
die PayPal beim Währungstausch erhebt, die aber nirgends stehen.
Was von den meisten Händlern unterschätzt wird, ist die Meldung falscher Umsatzsteuerwerte.
Die Korrekturmaßnahmen, Säumniszuschläge etc. können sehr schnell Ausmaße annehmen, die
selbst ein gut aufgestelltes Onlinehandelsunternehmen in die Insolvenz treiben.
Wenn es ganz dick kommt, drohen auch noch strafrechtliche Konsequenzen.


Ich hoffe, dass ich dir zumindest ein bischen aufzeigen konnte, warum man sowas wie unseren Nexus braucht.
Der ist übrigens kein "Tool", sondern eine ausgewachsene Software: Das aktuelle Handbuch hat über 1000 Seiten.
Übrigens: Die Software ist nur die halbe Miete. Wichtig ist eine komplette Beschreibung, wie die Buchhaltung
abläuft, aus welchem System welche Daten kommen, wie diese verprobt, abgestimmt und archiviert werden.
(sog. GoBD-Verfahrensdokumentation).

Wer es etwas einfacher haben möchte: auf wwww.dekodi.de/Videos haben wir ein paar Erklärfilme (auch in verschiedenen Dialekten)
in denen das Buchhaltungsthema nochmals recht anschaulich und vor allem lustig erläutert wird.

Ansonsten kannst du uns gerne anrufen.

Viele Grüße aus Franken
Stefan

 

[ruth]

Hallo,

vielen Dank für die ausführliche Antwort aus der sich mir aber nicht wirklich viel erschließt.

Mag sein, dass ich völlig naiv bin, das schließe ich nicht aus. Deshalb frage ich. Wenn es mich fachlich überzeugt, werde ich sicher ein solches Tool nutzen.

Nun konkret:

wie bereits mit Eröffnung des Themas teilweise geschrieben, stelle ich mir die Buchungen in der BH wie folgt vor.

1. AR aus JTL werden Debitorisch gebucht, somit Offene Posten-Führung. Die Rechnungen sind korrekt mit Ust. EU und DL, außer die ID liegt vor. Keine ins andere Ausland. D.H. der Import erfolgt über die Konten 8200,8300,8400 usw. Alles Automtikkonten. Hier erfolgt somit die korrekte Steuerberechnung.
2. Alle Amazon-AR-Rechnungen werden gegen ein Verrechnungskonto gebucht. Also Verrechnungskonto an Debitor.
3. Die Rechnungen zu Verkaufsgebühren werden Kreditorisch (Amazon) gebucht, also 3123 an Kreditor.
4. Sofort als nächsten BS Kreditor an Verrechnungskonto.
5. Den Bankeingang von Amazon buche ich gegen das VK, also Bank an VK. VK ist ausgelichen.

Den Transaktionsbericht von amazon lade ich als txt datei herunter und kopiere ihn bei den BS Gebühren ins Notizfeld meiner Buchführung. Bei der Prüfung kopiere ich den Text in ein Editor und suche nach der einzelnen Transaktionnummer (kann mir aber nicht wirklich vorstellen, das dies jemals notwendig sein wird). Desweiteren mache ich ein PDF daraus und hänge es dem BS dran. Konkret heisst das ich habe die Aufzeichnung über jede einzelne Buchung, da ich natürlich auch mittels Ameise die externe Bestellnummer exportiere und diesen Wert entweder ins Belegfeld 2 ( Datev) schreibe oder mit den Kundennamen als Buchungstext (Lexware und andere Programme).

"Wichtig ist eine komplette Beschreibung, wie die Buchhaltung abläuft, aus welchem System welche Daten kommen, wie diese verprobt, abgestimmt und archiviert werden. (sog. GoBD-Verfahrensdokumentation)."

Alle Eingangsrechnungen hänge ich den BS an. Alle AR gehen als PDF in ein DMS / oder Jahres-CD --> Banksafe / Kopfkissen meiner Oma / usw. Dateiname Rechnungsnummer.

Meine Verfahrensdokumentation steht ja nun hier

Fertig!

Paypal buche ich wie eine Bank, der angesprochene Sicherheitseinbehalt würde als Forderung gegenüber Paypal gebucht werden müssen. Oder je nach rechtlicher Situation anders. Hier wird sich auch Nexus an die rechtlichen Vorgaben und Kontenrahmen halten müssen/wollen.

Das Vorgehen von Amazon bezüglich Einbehalt der Erlöse und Abrechnung ist doch ähnlich zu sehen wie eine Kreditkartenabrechnung, oder etwa nicht?

https://www.haufe.de/unternehmensfu...en-der-gebuehren_idesk_PI11444_HI3549298.html

Dieser Artikel ist die Grundlage meiner Darlegung.

Was macht nun Nexus anders und besser? Was ist an meinen Überlegungen falsch? Was würde buchhalterisch nicht abgedeckt werden bei meiner Darstellung? Warum braucht's Nexus?

Bitte konkret antworten. Vielen Dank.

Und wie erwähnt, ich nutze sicher die Software wenn es einen tatsächlichen Nutzen für mich gibt. Was ich auch gern hier schreiben würde.

 

[SebiW]

Was die Software für die macht ist schlicht und ergreifend den Zeitaufwand für die ganzen von Dir durchgeführten Aktionen deutlich zu drücken. Allein das rechtfertigt ab einer gewissen Mengen an Buchungen schon die Anschaffung, außer Du hast in der für die Buchhaltung verwendeten Zeit keine sonstigen sinnvollen Tätigkeiten zu erledigen.
Im Endeffekt machen diese Tools genau das in ihrem Einsatzzweck was eben jede Software machen sollte: Den Arbeitsaufwand für insbesondere repetitive Tätigkeiten reduzieren.

Deiner Logik nach brauchst Du auch keine Wawi. Denn natürlich kannst Du auch alle Funktionen der Wawi mit Excel, der Seller Central und im Zweifel Papier und Stift erledigen.

Natürlich machen diese Tools nichts was man nicht auch anders lösen kann. Sie sorgen nur dafür dass die Abläufe schnell, unkompliziert und fehlerfrei durchgeführt werden und vereinfachen die Übergabe bspw nach Unternehmen Online.
Und das ist Dir entweder Geld wert oder nicht. In unserem Fall hat die Einführung sich schon nach einem halben Jahr amortisiert und uns zb dank sauberer Schwellenwertauswertung vor dem ein oder anderen Fauxpas bewahrt.

 

[dekodi]

Hallo,

es tut mir leid, wenn meine Erklärung eine Themaverfehlung war, ich hab mir echt Mühe gegeben

Hier einige Anmerkungen:

zu 1:
Das Automatikkonto bucht nur dann richtig, wenn auch die Steuer auf der Rechnung dazu passt.
Beispiel du buchst eine Rechnung mit 19% (durch falsche Einstellung der WaWi) auf 8300.
Dann werden nur 7% Steuer abgeführt, obwohl du 19% schuldest.
Je mehr Länder, Lieferschwellen etc. im Spiel sind, desto größer wird die Gefahr, dass hier auch mal was schief geht.
Dies ist nur ein Hinweis - wir erleben sowas beinahe jeden Tag.

zu 2:
Ich nehme an, das es sich um eine in JTL geschriebene Rechnung handelt, die über eine Amazon-Bestellung ausgelöst wurde?
Dann muss der Debitor gegen ein Amazon-Verrechnungskonto ausgeglichen werden die Amazon-Order-ID und die Position (Principal)
muss in den Buchungstext oder in eine Zusatzfeld. Damit ist klar, welche Position aus dem Amazon-Settlement-Report (ich meine die txt-Datei) die Zahlung der Rechnung betrifft.
Nun müssen die Gebühren ebenfalls gegen das Verrechnungskonto in den Aufwand gebucht werden.
Am Schluss noch die Zahlung von Amazon auf das Verrechnungskonto, dass muss dann 0 sein.
Ich denke dass machst du genau so.


Deine Überlegungen sind - swoeit ich das nachvollziehen kann - überhaupt nicht falsch - ich bitte um Nachsicht, wenn dieser Eindruck enstanden ist.
Es ist eben einfach sehr aufwendig, mit Editor und Copy & Paste usw. zu arbeiten.
Genau diese Arbeiten (einschl. Kontrolle soweit möglich) erledigen wir mit unserer Software.
Wenn du mal deinen kalkulatorischen Unternehmerlohn für die Buchhaltungsarbeiten ansetzt, wird deine Art der Buchhaltung
mit zunehmender Anzahl an Rechnungen ziemlich teuer und auch fehleranfällig.
Hier ist es auf Dauer einfach günstiger und vor allem sicherer, Software einzusetzen zumindest dann, wenn man mehrere hundert oder tausend Bestellungen im Monat abwickelt.
Ist jetzt deine Frage beantwortet?

Hier noch ein paar Hinweise zur GoBD-Verfahrensdokumentation:
- eine Mustervorlage kann dir dein Steuerberater geben (gibt´s umsonst vom Verband)
- Die Doku muss alle Vorsysteme, aus denen buchungsrelevante Daten stammen, genau beschreiben (Hersteller, Version, Einstellungen usw.)
(z. B. die in JTL hinterlegten Erlöskonten)
- Sie muss beschreiben, wo welche Daten archiviert sind.
- Ausdrucken elektronischer Belege ist unzulässig. Diese müssen im Originalformat archiviert werden (DMS ist hier genau das Mittel der Wahl)
- Verprobungs- und Kontrollschritte müssen ebenfalls dokumentiert werden
- Am besten du fragst mal einen StB (aber einen der Ahnung von eCommerce hat!)

Viele Grüße
Stefan

 

[ruth]

Hallo Stefan,

zunächst danke, dass es jetzt konkret wird. Ich will natürlich eine gute und effektive Lösung, bei der das Preisleistungsverhältnis passt.

-----
zu 1:
Das Automatikkonto bucht nur dann richtig, wenn auch die Steuer auf der Rechnung dazu passt.
Beispiel du buchst eine Rechnung mit 19% (durch falsche Einstellung der WaWi) auf 8300.
Dann werden nur 7% Steuer abgeführt, obwohl du 19% schuldest.
Je mehr Länder, Lieferschwellen etc. im Spiel sind, desto größer wird die Gefahr, dass hier auch mal was schief geht.
Dies ist nur ein Hinweis - wir erleben sowas beinahe jeden Tag.
------

Die Steuer bekommen wir vom Lieferanten und wird mit dem Artikeldaten importiert. Bzw. wenn der Artikel eine falsche Satz hat, wie merkt das Nexus? Ob es ein Buch 7% eine Spiel 19%, oder ein Buch mit CD (Ein Anteil 7 und ein Anteil 19) kann ja nur aus den Produktdatenkommen, also JTL, oder nicht? Wie kann ich da die Rechnung falsch buchen? Die Rechnung führt die Sätze je nach Artikel aus und so wird sie gebucht, importiert. Was macht da Nexus anders?

Den zweiten Teil (Je mehr Länder, ... ) bitte genauer erläutern. Reicht aber auch ein Link zur Webseite wo es beschrieben ist.

---
zu 2:

Ich nehme an, das es sich um eine in JTL geschriebene Rechnung handelt, die über eine Amazon-Bestellung ausgelöst wurde?
Dann muss der Debitor gegen ein Amazon-Verrechnungskonto ausgeglichen werden die Amazon-Order-ID und die Position (Principal)
muss in den Buchungstext oder in eine Zusatzfeld. Damit ist klar, welche Position aus dem Amazon-Settlement-Report (ich meine die txt-Datei) die Zahlung der Rechnung betrifft.
Nun müssen die Gebühren ebenfalls gegen das Verrechnungskonto in den Aufwand gebucht werden.
Am Schluss noch die Zahlung von Amazon auf das Verrechnungskonto, dass muss dann 0 sein.
Ich denke dass machst du genau so.
-------

Genau, es sind JTL-Rechnungen. Und es ist ein Sammeldebitorkonto pro Jahr eins (12014,12015,12016, usw. ) Macht auch keinen Sinn für Personenkonten für jeden eins anzulegen.

Nein Positionen aus Amazon-Settleemnt-Report sind nicht im Buchungstext. Müssen sie ja auch nicht sind ja Positionen der Rechnung. Es reicht den Report aufzubewahren.

Ja und der Ausgleich erfolgt sofort als zweiten Schritt gegen das Verrechnungskonto. D.H. Debitor ist immer ausgelichen. Die Order-ID kommt per Import in die Buchungstextzeile. Der Report kommt als anhang zur Auszahlungsbuchung und ist durchsuchbar.

Die Gebührenrechnung wird Aufwand an Kreditor gebucht und sofort wieder gegen das VK gebucht. ja und dann die Bank, so wie Du es beschreibst, und das VK ist null.

So wie ich es bis jetzt verstanden habe muß ich bei meiner Lösung etwas Exportieren um es in die Buchaltung importieren. Bei Nexus wird es nicht anders sein, oder?

Ja ich importiere und mache die laufende Buchhaltung selbst. Ich bin gelernte Kauffrau und es sind ja nur wenige Aufwands und Ertragskonten die im Tagesgeschäft bebucht werden. Und die Auswertung mache ich mit der Buchungssoftware. Da hat's ja auch den Button Bankenmappe und ich muß der Bank nichts erklären da sie die Aufbereitung kennt.

Trotzdem will ich natürlich, wenn es geht, weiterhin effektiver werden. Und wenn Nexus mir dabei hilft - werde ich sicher Kunde.

Welche Schritte spare ich mir den mit Nexus?

Wie sehen die BS aus, die Nexus exportiert? Ist Nexus nach GoBD-Verfahren, neben der Buchhaltungssoftware als Zweitsystem zu verstehen? Konkret wird der Finanzamtprüfer aus Nexus Daten sehen wollen?

Mit freundlichen Grüßen

 

[dekodi]

Hallo ruth,

zu 1:
Wir holen uns aus JTL die Rechnungsrohdaten und buchen diese mit einer eigenen Steuerlogik.
Dadurch hat man nochmals eine Kontrollinstanz, ob die Rechnungen richtig geschrieben sind.
Beispiel: Es kommt bei ganz vielen Händlern immer wieder zu Verkäufen im Inland, bei
denen keine USt. abgerechnet wird. Einige solcher Fälle genügen dem Betriebsprüfer bereits
als Angriffspunkt. Nexus würde so eine Rechnung als fehlerhaft ausweisen.
Ursache sind oft falsche Einstellungen in der WaWi, fehlerhafte manuelle Eingaben etc.
Nexus kann derzeit nicht prüfen, ob die Steuer für einen Artikel richtig angegeben ist.

Genauso verhält es sich mit den Ländern:
Je mahr Versendungs- und Lieferländer hat (z. B. bei Amazon FBA) umso größer ist die
Wahrscheinlichkeit, dass irgendwann mal eine Rechnung geschrieben wird, die falsche
Steuer ausweist (z. B. weil Lieferschwelle übersehen wurde, die Registrierung im Ausland
noch nicht abgeschlossen wurde usw.). Auch hier bildet unsere Software nochmals
eine Kontrollschicht. Nexus kann sogar falsch ausgestellte Rechnungen buchen.

Zu Amazon:
Ich glaube, dass wir da aneinander vorbeigeschrieben haben.
Wir lesen den Amazon-Settlement-Report-Flat-File V1 ein. Darin ist jede einzelne
Amazon-Order-ID und jede einzelne Gebühr enthalten. So eine Datei kann mal schnell 40000 - 100000 Zeilen haben.
Diese einzelnen Positionen dieses Zahlungsavis ordnet Nexus dann den entsprechenden Rechnungen zu.
Die summarische Buchung eines Reports geht solange gut, wie kein Fehler auftritt.
Was machst du, wenn dein Ama-Sammeldebitor nicht aufgeht?

Import-Export:
JTL lesen wir automatisch aus, wenn wir Zugriff auf die Datenbank haben.
Amazon muss man manuell herunterladen und einlesen.
Export in die Fibu entweder ebenfalls manuell bzw. wenn die Datev-Fibu auf dem
selben Rechner liegt, vollautomatisch.

Welche Schritte spare ich mir:
Was Nexus macht und spart habe ich ja schon erläutert.
Das Thema ist sehr, sehr komplex.
Bitte ruf einfach mal bei uns an.
Bei uns gibts eine spezielle Präsentation für buchhaltungskundige, die fachlich sehr tief ist
und in der wir alle Fragen, bis hin zu Buchungschlüssel und Gegenkonto erklären.
Die Erläuterung erfolgt anhand von anonymisierten Echtdaten eines JTL Händers
oder wenn du magst sogar mit deinen eigenen Daten.

GoBD
Nexus ist wie alle anderen Datenkonverter ein Vorsystem, dass unter die GoBD fällt.
Aus diesem Grund haben wir eine sehr umfangreiche Bedienungsanleitung, in der auch
die Logik der Software sauber beschrieben wird (mit T-Konten ), erstellt.
Diese kann (muss!) als Teil der GoBD-Verfahrensdokumentation verwendet werden.
Nexus selber speichert keine Daten dauerhaft. Er archiviert aber die eingelesenen JTL, Amazon, Paypal usw.
Daten in entsprechende Verzeichnisse. In Verbindung mit einer Verfahrensdokumentation kann
man also jederzeit nachweisen, welche Daten wann verbucht wurden.
Wir haben regelmäßig den obersten deutschen Umsatzsteuerprüfer für eEcommerce bei uns
zu besuch. Dem war vor allem wichtig, dass die Buchhaltung systemisch in sich geschlossen ist
- und genau das leisten wir mit unserer Software.
Wir sind mit Nexus jetzt seit 2009 auf dem Markt und haben von unseren Kunden konstant
die Rückmeldung, dass die Beriebsprüfer die mit Hilfe von Nexus erstellte Buchhaltung so gut wie nicht angreifen
bzw. dieses Vorhaben wieder schnell bleiben lassen.
Weil eben alles einzeln und ganz genau gebucht wurde (kann ein Mensch gar nicht leisten).

In den letzten zwei Jahren dorht die Gefahr allerdings aus dem Ausland.
Fast alle EU-Staaten, besonders aber Österreich, Frankreich, Italien und Dänemark
machen Jagd auf Onlinehändler, die die Lieferschwelle überschritten haben und
sich zu spät oder gar nicht in den jeweligen Ländern registrieren haben lassen.
Spätestens hier wird klar: Man braucht gute Software, aber mindestens genauso
wichtig ist eine gute Organisation.

 

[ruth]

zu 1:
Wir holen uns aus JTL die Rechnungsrohdaten und buchen diese mit einer eigenen Steuerlogik.
Dadurch hat man nochmals eine Kontrollinstanz, ob die Rechnungen richtig geschrieben sind.
Beispiel: Es kommt bei ganz vielen Händlern immer wieder zu Verkäufen im Inland, bei
denen keine USt. abgerechnet wird. Einige solcher Fälle genügen dem Betriebsprüfer bereits
als Angriffspunkt. Nexus würde so eine Rechnung als fehlerhaft ausweisen.
Ursache sind oft falsche Einstellungen in der WaWi, fehlerhafte manuelle Eingaben etc.
Nexus kann derzeit nicht prüfen, ob die Steuer für einen Artikel richtig angegeben ist.

Kann man so machen. Aber richtige Einstellungen in der Wawi tut es auch. Und ob eine Artikel 7 oder 19 oder sogar 7 und 19 (Bundle-Produkte) hat erkennt Nexus nicht. Also sorgfältiges Arbeiten ist weiterhin notwendig.

Genauso verhält es sich mit den Ländern:
Je mahr Versendungs- und Lieferländer hat (z. B. bei Amazon FBA) umso größer ist die
Wahrscheinlichkeit, dass irgendwann mal eine Rechnung geschrieben wird, die falsche
Steuer ausweist (z. B. weil Lieferschwelle übersehen wurde, die Registrierung im Ausland
noch nicht abgeschlossen wurde usw.). Auch hier bildet unsere Software nochmals
eine Kontrollschicht. Nexus kann sogar falsch ausgestellte Rechnungen buchen.

Ich muß mich also nicht damit beschäftigen:

https://services.amazon.de/programme/versand-durch-amazon/steuerinformationen.html

Das macht alles Nexus für mich?

Zu Amazon:
Ich glaube, dass wir da aneinander vorbeigeschrieben haben.
Wir lesen den Amazon-Settlement-Report-Flat-File V1 ein. Darin ist jede einzelne
Amazon-Order-ID und jede einzelne Gebühr enthalten. So eine Datei kann mal schnell 40000 - 100000 Zeilen haben.
Diese einzelnen Positionen dieses Zahlungsavis ordnet Nexus dann den entsprechenden Rechnungen zu.
Die summarische Buchung eines Reports geht solange gut, wie kein Fehler auftritt.
Was machst du, wenn dein Ama-Sammeldebitor nicht aufgeht?

Braucht's das wirklich? Wo steht das?

Ich bin der Meinung es reicht, wenn im Buchungssatz die Amazon-ID steht und man gegegenfalls dann nachschaut.

Bei meiner DHL-Rechnung prüft nicht wirklich jemand welches Paket zu welchen Kunden geht. Wäre aber möglich, habe ja die Sendungsnummer in JTL. Wie halt auch die Amazon-ID.

Der Sammeldebitor geht immer auf, da ich den selben JTL-Export nehme. Amazonkunden zahlen ja immer.

Import-Export:
JTL lesen wir automatisch aus, wenn wir Zugriff auf die Datenbank haben.
Amazon muss man manuell herunterladen und einlesen.
Export in die Fibu entweder ebenfalls manuell bzw. wenn die Datev-Fibu auf dem
selben Rechner liegt, vollautomatisch.

Automatische Export geht auch mit der Ameise.

Welche Schritte spare ich mir:
Was Nexus macht und spart habe ich ja schon erläutert.
Das Thema ist sehr, sehr komplex.
Bitte ruf einfach mal bei uns an.
Bei uns gibts eine spezielle Präsentation für buchhaltungskundige, die fachlich sehr tief ist
und in der wir alle Fragen, bis hin zu Buchungschlüssel und Gegenkonto erklären.
Die Erläuterung erfolgt anhand von anonymisierten Echtdaten eines JTL Händers
oder wenn du magst sogar mit deinen eigenen Daten.

Ja, ich könnte direkt Kontakt aufnehmen. Dazu braucht es aber erstmal mehr Informationen. Lohnt es sich tatsächlich? Die Frage ist noch nicht immer positiv beantwortet.

Ich meine ich beschäftige mich ja nun nicht einen Tag mit Nexus um dann festzustellen, das es gar keine wesentliche Vorteile bringt.

GoBD
Nexus ist wie alle anderen Datenkonverter ein Vorsystem, dass unter die GoBD fällt.

Das ist gar nicht gut! Das heißt wenn es euch in 5 Jahren nicht mehr gibt und ich in 7 Jahren geprüft werde habe ich ein riesiges Problem.

Dann doch lieber nur ein System - die Buchhaltungsoftware und hier alles abbilden!

Danke für die Antworten.

 

[Simone_die_Echte]

Dann doch lieber nur ein System - die Buchhaltungsoftware und hier alles abbilden!

Na dann wäre das ja geklärt und der Thread kann geschlossen werden...

 

[dekodi]

Sehe ich auch so.
Übrigens JTL ist auch ein Vorsystem.

 

[ruth]

Übrigens ist JTL natürlich kein Vorsystem im Sinne GoBD. JTL hat eine DB an die jeder dran kann, zum Glück An die DB von Datev, Lexware usw. kommt keiner dran. Deshalb sind diese Systeme GoBD fähig.

Die Ausgangrechnungen von JTL werden bequem per PDF expotiert. Dort stehen alle notwendigen Dinge (inkl. Amazon Order-ID) drauf. Diese PDF in ein DMS fertig! Und jetzt kann auch in 10 Jahren, wenn es Nexus nicht mehr gibt (!?), jeder BS nachvollzogen werden.

Mein Fazit: Es brauchts kein Nexus und co.

Jetzt kanns geschlossen werden!

 

[Shopworker.de]

Und ich wollte gerade Popcorn rausholen

Nur meine 5 cent: Kunden von mir, welche mit Nexus oder JTL2Datev arbeiten sind dankbar für diese Tools, die sehr viel "stupide" Arbeit teilautomatisiert erledigen.
@ruth ... ich denke so viel Vorkenntnisse wie du haben die wenigsten, ich kenne einige Steuerberater, die selbst von Onlinehandel etc. kaum Ahnung haben.

Mein Fazit: Jeder muss selbst entscheiden, ob er Tools nutzt, die einem die Arbeit erleichtern; auch alle Abläufe der JTL-Wawi können grundsätzlich händisch oder anders abgebildet werden, aber die JTL-Wawi erleichtert viele Abläufe ungemein ... und Fehler macht jeder und gibt es in jeder Software und alle Abläufe sollten immer hinterfragt und optimiert werden ... einfach kann jeder

Und jetzt kann meiner Meinung nach auch geschlossen werden

 

[Rico Giesler]

Da nun alle der Meinung sind dass alles gesagt wurde mache ich hier zu.

Wenn doch noch Fragen auftauchen sollten kann gern auf das Angebot von Stefan (dekodi) zurückgegriffen und dort einfach angerufen werden.
Zumal da auch sehr spezifische Fragen viel besser und schneller beantwortet werden können.