Neu JTL Wawi und die Fibuschnittstelle JTL2DATEV von Jerasoft

[scoutladen]

Wir nutzen die Wawi in Verbindung mit der Fibuschnittstelle von Jerasoft JTL2WAWI, um möglichst alle unserer Prozesse an die Datev zu übermitteln. Dennoch beziffert unser Steuerberater den monatlichen Aufwand auf etwas 14 h je Monat. Und entsprechend rechnet er hohe Gebühren ab. Noch habe ich niocht verstanden, wofür dieser Aufwand entsteht. Mein Ziel ist, durch die direkte Anbindung den Aufwand des Steuerberaters gegen Null zu bringen. Wie finde ich nun heraus, wo hier mein Optimierungspotential ist? Wer von euch arbeitet in ähnlicher Konstellation? Welche Inhalte übermittelt ihr auf welchem Weg an den Steuerberater?

Die Belge aus dem Verkauf übermitteln wir direkt aus JTL2DATEV an DUO.
Die Belege aus Paypal und Amazon exportieren wir aus JTL2DATEV als Datev-Export und mailen diesen an den Steuerberater. Der muss dies dann importieren, hat dazu aber inzwischen wohl entsprechende Routinen. Würde dies auch direkt in DUO einzuspielen sein?
Den Kassenbericht mir sehr wenigen Buchungen bekommen wir nur als einfachen Export aus L-POS von Luwosoft. Ich denke, hier hat der Steuerberater Handarbeit zu verrichten.
Zusätzlich erwarter er von uns einen Auszug der Debitoren und Kreditoren aus JTL2DATEV, da diese Informationen wohl nicht mit dem Import direkt zu DUO übermittelt würde.

Bei diesen Prozessen gibt es ein paar Stolpersteine.

So bekommen wir beim Amazon-Export via JTL2DATEV tatsächlich einige Buchungen, bzw. Fehlermeldungen, die nicht sauber zu verarbeiten sind. Das ist mir bisher nicht gelungen, dies zu bereinigen.

Und es bleiben laut Steuerberatung jeden Monat etliche offene Posten in unserer Buchhaltung, die ich mir nicht erklären kann.

Für Tipps, wie ich meine Prozesse verbessern kann bin ich dankbar.

Schöne Grüße
Ralph

 

[forumjtlolshopag]

Wir nutzen auch JTL2Datev und wir machen größtenteils alles selbst, was die Buchungen betrifft. unser Steuerberater wird dann nur zu Rate gezogen, wenn wir bestimmte Situationen haben, wo wir nicht weiter wissen.
Eingangsrechnung spielen wir auch selbst über DUO mit dem Belegtransfer ein und verbuchen es selbst. Eventuell solltest du deinen Steuerberater fragen, was in den 14 Stunden genau gemacht wird und wo du Erleichterungen bringen kannst.

 

[scoutladen]

Danke, eben jenes Gespäch steht aus und dafür benötige ich Futter...

Was bucht ihr konkret in DUO ein? Unsere Eingangsrechungen erfassen wir ebenfalls selbst, meist direkt nach den Buchungsvorschlägen aus DUO.

 

[forumjtlolshopag]

Eingangsrechungen von Lieferanten, die wir eingescannt oder als PDF bekommen. Das OCR von Datev erkannt dann schon vieles aus den PDFs. Über JTL2Datev alle Ausgangsrechnungen und Gutschriften von Amazon (inkl. FBA), eBay und unseren Shops, sowie manuell angelegten Aufträgen. Da kommt am meisten was zusammen. Bei JTL2Datev gibts bei uns noch Stolpersteine, was die Steuer von außerhalb Deutschland betrifft die Privat bestellen. Da müssen wir aktuell noch die Steuer "manuell" auswählen. Etwas was wir noch korrigieren müssen. Hängt wohl mit der Datev XML Version ab, wo wir aktuell v3 nutzen.

 

[recent.digital]

Oft werden die von JTL2Datev erzeugten Daten direkt an den Steuerberater übermittelt, welcher diese dann einspielt. Also nicht direkt über UO hochgeladen.
Bearbeitet ihr die Fehler, die angezeigt werden bevor ihr die Daten weiter versendet? LS POS hat einen Datev-Export, der reicht vielen Steuerberatern zum automatisierten Einspielen.

 

[Verkäuferlein]

@scoutladen

Erfahrungsgemäß sind folgende Punkte problematisch:
- Datev ist seltsam (Datev UO und Datev Kanzlei Rechnungswesen arbeiten nicht sauber zusammen)
- Der Steuerberater macht es "wie immer", für Ihn ist es ja auch egal, lieber 14 Stunden bezahlt, als in 1 Stunde erledigt.
- Es wird in der Vorbereitung nicht sauber gearbeitet

Du kannst mir gerne mal per PN schreiben, was Euer Steuerberater Euch da so in Rechnung stellt, ich trete meinem auch regelmäßig auf die Füße und gebe Infos, wie sich der Prozess vereinfachen lässt, häufig ist aber Datev das Problem.

Die Belege aus Paypal und Amazon exportieren wir aus JTL2DATEV als Datev-Export und mailen diesen an den Steuerberater. Der muss dies dann importieren, hat dazu aber inzwischen wohl entsprechende Routinen. Würde dies auch direkt in DUO einzuspielen sein?

Du setzt vermutlich JTL2Datev UO ein, korrekt?

Dann kannst Du in Datev UO auch eine Kasse für die Zahlungsarten (also PP und Amazon bzw. ggf. ebay Payment) anlegen. Mit JTL2Datev UO kannst Du die Daten in das Kassenbuch übertragen und der StB kann diese direkt über Datev bei sich laden. In dem Fall dient das Kassenbuch aber nur als Datenumschlagsplatz, ist eigentlich ähnlich, wie wenn Du eine Datei sendest. Laut Jera soll man das eigentlich nicht machen, auf meine Frage "Wie dann?" gab es leider nie eine Antwort und im Wiki von Jera ist es so beschrieben.

Den Kassenbericht mir sehr wenigen Buchungen bekommen wir nur als einfachen Export aus L-POS von Luwosoft. Ich denke, hier hat der Steuerberater Handarbeit zu verrichten.

Da kann ich Dir leider nichts zu sagen, da wir keine Computer-Kasse haben.

Zusätzlich erwarter er von uns einen Auszug der Debitoren und Kreditoren aus JTL2DATEV, da diese Informationen wohl nicht mit dem Import direkt zu DUO übermittelt würde.

Pflegst Du die Debitoren in der Wawi oder wo und wie werden die Debitoren erzeugt?

Welche Kreditoren sind denn gemeint? In der Regel habt Ihr doch einen festen Lieferantenstamm + ein paar Ausnahmen. Wenn Du die Eingangsrechnungen in Datev UO hochlädst und von dort auch vorerfasst und bezahlst, hast Du einen einmaligen Erfassungsaufwand (ähnlich wie beim Online-Banking) und der StB muss eigentlich nur noch prüfen und eine Kreditorennummer vergeben und das in Datev UO zurückspielen. Bei dem nächsten Beleg des gleichen Lieferanten erkennt Datev UO eigentlich automatisch die Stammdaten inkl. Kreditor.

Und es bleiben laut Steuerberatung jeden Monat etliche offene Posten in unserer Buchhaltung, die ich mir nicht erklären kann.

Welche Art von Posten sind das?

Häufig liegt es an der fehlenden (automatischen) Kommunikation zwischen Datev UO und Datev Kanzlei Rechnungswesen. Die Daten sind oft in Datev UO vorhanden, werden aber vom Kanzlei-Programm nicht übernommen / genutzt. Dies muss dann häufig einmalig manuell korrekt konfiguriert werden, damit dann alle Daten auch korrekt genutzt werden. Wir spielen z.B. unsere Bankkonten über den Rechenzentrums-Transfer in Datev / Datev UO und ordnen in Datev UO Belege und Zahlungen zu, davon sieht der Steuerberater aber bei sich im Programm nichts, wenn er dies nicht explizit konfiguriert. Ist uns dadurch aufgefallen, dass von uns immer eine Exportdatei der Bankzahlungen aus JTL2Datev vom Steuerberater angefordert wurde und auf Nachfrage dann die Info kam, dass da dann die Kontierungen hinterlegt sind, die eigentlich auch im Belegbild vorhanden sind und von uns den Bankzahlungen in Datev UO zugeordnet werden (sofern dies nicht automatisch passiert).

Manchmal sind es auch Unklarheiten zwischen Wawi und JTL2Datev und manchmal sind es einfach außergewöhnliche Geschäftsvorfälle.

 

[scoutladen]

- Der Steuerberater macht es "wie immer", für Ihn ist es ja auch egal, lieber 14 Stunden bezahlt, als in 1 Stunde erledigt.

Das ist meine größe Befürchtung, zumal die zuständige Sachbearbeiterin noch vom alten Eisen geschitzt ist und Anfangs noch unsere Ordner mit Belegen händisch bearbeitet hat. Das war alleine schon ein Prozess, bis DUO soweit es bisher geht dann auch funktioniert hat. Wir hatten da schon viele Reingungsverluste mit unserer Kanzlei.

- Es wird in der Vorbereitung nicht sauber gearbeitet

Das versuche ist zu verbessern, aber nicht mal der Steuerberater kann mich da beraten, wie meine Prozesse sauber aufgestellt werden

Du kannst mir gerne mal per PN schreiben, was Euer Steuerberater Euch da so in Rechnung stellt, ich trete meinem auch regelmäßig auf die Füße und gebe Infos, wie sich der Prozess vereinfachen lässt, häufig ist aber Datev das Problem.

Ich melde mich gerne, sobald ich das besser benennen kann

Du setzt vermutlich JTL2Datev UO ein, korrekt?

Korrekt

Dann kannst Du in Datev UO auch eine Kasse für die Zahlungsarten (also PP und Amazon bzw. ggf. ebay Payment) anlegen. Mit JTL2Datev UO kannst Du die Daten in das Kassenbuch übertragen und der StB kann diese direkt über Datev bei sich laden. In dem Fall dient das Kassenbuch aber nur als Datenumschlagsplatz, ist eigentlich ähnlich, wie wenn Du eine Datei sendest. Laut Jera soll man das eigentlich nicht machen, auf meine Frage "Wie dann?" gab es leider nie eine Antwort und im Wiki von Jera ist es so beschrieben.

Ich gehe bisher davon aus, dass Papypal nicht das Thema ist. Ich glauvbe, das bekommen sie sauber importiert

Pflegst Du die Debitoren in der Wawi oder wo und wie werden die Debitoren erzeugt?

Welche Kreditoren sind denn gemeint? In der Regel habt Ihr doch einen festen Lieferantenstamm + ein paar Ausnahmen. Wenn Du die Eingangsrechnungen in Datev UO hochlädst und von dort auch vorerfasst und bezahlst, hast Du einen einmaligen Erfassungsaufwand (ähnlich wie beim Online-Banking) und der StB muss eigentlich nur noch prüfen und eine Kreditorennummer vergeben und das in Datev UO zurückspielen. Bei dem nächsten Beleg des gleichen Lieferanten erkennt Datev UO eigentlich automatisch die Stammdaten inkl. Kreditor.

So funktioniert das auch bei uns. Nur wollte der Steuerrater neben dem Import nach DUO auch noch die Datei EXTF_Stamm_DEbKred... die du aus dem Datev Export erzeugen konntest.
Wobei dieser Export in der aktuellen Version von JTL2DATEV gar nicht mehr erzeugt wird. Ein Ersatz dafür habe ich noch nicht gefunden.

Welche Art von Posten sind das?

Z.b. fällige Ausgangsrechnungen, die noch nicht bezahlt sind.

Häufig liegt es an der fehlenden (automatischen) Kommunikation zwischen Datev UO und Datev Kanzlei Rechnungswesen. Die Daten sind oft in Datev UO vorhanden, werden aber vom Kanzlei-Programm nicht übernommen / genutzt. Dies muss dann häufig einmalig manuell korrekt konfiguriert werden, damit dann alle Daten auch korrekt genutzt werden. Wir spielen z.B. unsere Bankkonten über den Rechenzentrums-Transfer in Datev / Datev UO und ordnen in Datev UO Belege und Zahlungen zu,

So machen wir das auch...

davon sieht der Steuerberater aber bei sich im Programm nichts, wenn er dies nicht explizit konfiguriert.

Ich gehe davon aus, dass er das sieht, war aber auch ein längerer Weg.

Ist uns dadurch aufgefallen, dass von uns immer eine Exportdatei der Bankzahlungen aus JTL2Datev vom Steuerberater angefordert wurde und auf Nachfrage dann die Info kam, dass da dann die Kontierungen hinterlegt sind, die eigentlich auch im Belegbild vorhanden sind und von uns den Bankzahlungen in Datev UO zugeordnet werden (sofern dies nicht automatisch passiert).

Manchmal sind es auch Unklarheiten zwischen Wawi und JTL2Datev und manchmal sind es einfach außergewöhnliche Geschäftsvorfälle.

So viele außergeöhnliche Geschäftsvorfälle habe ich hoffentlich nicht

 

[Verkäuferlein]

Das ist meine größe Befürchtung, zumal die zuständige Sachbearbeiterin noch vom alten Eisen geschitzt ist und Anfangs noch unsere Ordner mit Belegen händisch bearbeitet hat. Das war alleine schon ein Prozess, bis DUO soweit es bisher geht dann auch funktioniert hat. Wir hatten da schon viele Reingungsverluste mit unserer Kanzlei.

Kenne ich.

Das versuche ist zu verbessern, aber nicht mal der Steuerberater kann mich da beraten, wie meine Prozesse sauber aufgestellt werden

Kenne ich auch, eigentlich habe ich da mehr meinen Steuerberater beraten, als umgekehrt, war auch einer der ersten Mandanten, die auf digitale Buchführung umgestellt wurden.

Bin mir allerdings auch immer nicht so ganz sicher, ob das immer Unwissenheit beim Steuerberater ist oder manchmal vielleicht auch fehlendes Interesse an der Prozessoptimierung, weil diese (kurzfristig) eher zur eigenen Last ist, als nutzt.

Z.b. fällige Ausgangsrechnungen, die noch nicht bezahlt sind.

Sind die tatsächlich nicht bezahlt oder klappt nur die Zuordnung nicht?
Was genau ist dabei das Problem des Steuerberaters bzw. der Zeitfresser?
Eine unbezahlte Rechnung lässt sich genauso schnell erfassen, wie eine bezahlte.

Werden Kontierungen händisch auf den Belegen vermerkt?

So funktioniert das auch bei uns. Nur wollte der Steuerrater neben dem Import nach DUO auch noch die Datei EXTF_Stamm_DEbKred... die du aus dem Datev Export erzeugen konntest.
Wobei dieser Export in der aktuellen Version von JTL2DATEV gar nicht mehr erzeugt wird. Ein Ersatz dafür habe ich noch nicht gefunden.

Meines Wissens sind alle Kundendaten inkl. Debitorennummern in den Rechnungs-XML-Daten enthalten, die in Datev UO eingespielt werden.


Ansonsten:
Die benannten Punkte müsstest Du einmal mit dem Steuerberater klären.

Also:
Welche Daten sieht er und welche fehlen ihm für eine schnelle Bearbeitung?
Welche Daten würde er noch erwarten?
Wo sind die Zeitfresser?

So wie Du das beschreibst, habt Ihr entweder ein extrem hohes Belegaufkommen mit immer wieder auftretenden Kleinigkeiten, die das ganze ausbremsen oder da läuft irgendwas nicht optimal in der Automatisierung, weil im Prinzip alle Daten digital vorhanden sein müssten.

Arbeitet Ihr denn mit Sammeldebitoren oder hat jeder Kunde eine eigene Debitorennummer?

 

[scoutladen]

Sind die tatsächlich nicht bezahlt oder klappt nur die Zuordnung nicht?

Tatsächlich nicht bezahlt

Was genau ist dabei das Problem des Steuerberaters bzw. der Zeitfresser?

Das versuche ich raus zu bekommen. Ich hab schon vorgeschlagen, einen Tag in der Kanzlei zu hospitieren, sobald alle Daten von mir da sind.

Werden Kontierungen händisch auf den Belegen vermerkt?

Nein

Meines Wissens sind alle Kundendaten inkl. Debitorennummern in den Rechnungs-XML-Daten enthalten, die in Datev UO eingespielt werden.

OK, das werde ich mal diskutieren

Arbeitet Ihr denn mit Sammeldebitoren oder hat jeder Kunde eine eigene Debitorennummer?

Jeder Kunde ist sein eigener Debitor.

 

[Verkäuferlein]

Tatsächlich nicht bezahlt

Dann reicht ja eigentlich eine Übersicht / Info, welche noch offen sind und sonst braucht der StB ja nur zu warten, bis die Zahlung auftaucht.

Das versuche ich raus zu bekommen. Ich hab schon vorgeschlagen, einen Tag in der Kanzlei zu hospitieren, sobald alle Daten von mir da sind.

Hihihi, die Überlegung hatte ich bei meinem StB auch schonmal.
Für nach Corona....

Jeder Kunde ist sein eigener Debitor.

Sprich mal an, ob nicht Sammeldebitoren Sinn machen (z.B. nach Anfangsbuchstaben des Nachnamens). Du wirst ja wahrscheinlich eher viele 1x Kunden als viele Mehrfachkunden haben!?

 

[scoutladen]

Sprich mal an, ob nicht Sammeldebitoren Sinn machen (z.B. nach Anfangsbuchstaben des Nachnamens). Du wirst ja wahrscheinlich eher viele 1x Kunden als viele Mehrfachkunden haben!?

Was wäre der Vorteil?

 

[Verkäuferlein]

Was wäre der Vorteil?

Das ist eine gute Frage, am ehesten ein technischer. Da Datev mit 5-stelligen Debitorennummern arbeitet, sind die sonst irgendwann ausgeschöpft. Ob es dort buchhalterisch einen Vorteil gibt, kann ich Dir nicht sagen.

Man hat halt möglicherweise schneller einen Überblick, welche Konten nicht ausgeglichen sind und man kann sich Debitoren leichter einprägen und zuordnen, wenn eine Logik dahinter steckt.

 

[Xantiva]

Wir nutzen auch nur einen Sammeldebitor für die normalen Kunden (wird per Workflow bei "Kunde erstellt" gesetzt). Wenn es mal größere Stammkunden (B2B) gibt, bekommen die eine eigene Debitorennummer. Wie Verkäuferlein schon beschrieben hat - Du kannst ja mal hochrechnen, wann der 5-Stellige Nummernkreis bei Dir ausgeschöpft ist.

Ich nutze Datev UO für die Eingangsrechnungen und lese die dann in Datev Mittelstand ein. Mit JTL2Datev werden die Ausgangsrechnungen, PayPal, Amazon, Amazon Pay, eBay und Bankkonten eingelesen und dann als Stapel ausgegeben, die ich nur noch importieren muss. Die meiste Arbeit habe ich dabei noch mit den Bankkonten, um die Eingangsbuchungen zuzuordnen bzw. die Rechnungsnummer für das Belegfeld1 zu identifizieren. Da habe ich aber auf der JTL Connect noch von JERA gelernt: möglichst alle Bankverbindungen bei den Lieferanten in der Wawi anlegen, damit JTL2Datev darauf zur Identifikation zurückgreifen.

Innerhalb von Datev Mittelstand ist das Ausziffern der Amazon Buchungen an nervigsten. Durch die Rechnungskaufoption mit x Wochen Zahlungsziel, kann ich immer nur Monate in der Vergangenheit ausziffern. Also mache ich z.B. die Buchhaltung für den September, dann kann ich bei Amazon maximal den August ausziffern. Wenn es "schlecht" läuft, dann kann ich den Vormonat nicht ausziffern und muss einen Monat damit warten, bis das die Rechnungszahlungen auch eingegangen sind. Das macht die Arbeit mit den OPOS Listen nicht einfacher. (Viel Scrollen.)

 

[scoutladen]

Da Datev mit 5-stelligen Debitorennummern arbeitet, sind die sonst irgendwann ausgeschöpft.

Ich arbeite hier mit 6-stelligen Debitoren

 

[scoutladen]

Da habe ich aber auf der JTL Connect noch von JERA gelernt: möglichst alle Bankverbindungen bei den Lieferanten in der Wawi anlegen, damit JTL2Datev darauf zur Identifikation zurückgreifen.

Wir pflegen die Lieferrantenrechnungen nicht in der Wawi, sondern erfassen diese in DUO.
Grundsätzlich ist von JERA zu lernen nicht einfach. Jede Frage über deren Support zu klären ist mühsam. Gibt es da auch irgendwo eine rege Community?

 

[mh1]

Das ist eine gute Frage, am ehesten ein technischer. Da Datev mit 5-stelligen Debitorennummern arbeitet, sind die sonst irgendwann ausgeschöpft. Ob es dort buchhalterisch einen Vorteil gibt, kann ich Dir nicht sagen.

Die Aussage wiederholen die meisten Steuerberater gebetsmühlenartig.
Es ist aber so, dass die Personenkonten einfach eine Stelle mehr haben, als die Sachkonten. Und bei der Neuanlage eines Mandanten in den Datev Programmen ist die Standardeinstellung für die Sachkonnten vierstellig, also kriegen Personenkonten fünf Stellen.
Die Sachkonten können aber auf max. acht Stellen erhöht werden. Also neun stellige Personenkonten.

 

[scoutladen]

Also neun stellige Personenkonten.

So ist es. Und das lässt sich auch in der Fibu-Schnittstelle JTL2DATEV entsprechend abbilden.
Und bis ich die 9. Stelle erreiche bin ich bestimmt schon längst zu Staub verfallen

 

[Xantiva]

Wir pflegen die Lieferrantenrechnungen nicht in der Wawi, sondern erfassen diese in DUO.
Grundsätzlich ist von JERA zu lernen nicht einfach. Jede Frage über deren Support zu klären ist mühsam. Gibt es da auch irgendwo eine rege Community?

Ich trage die Eingangsrechnungen auch immer in die Wawi mit ein. So fallen wenigsten Inkonsistenzen sehr schnell auf. Dann wurden auf ein mal Preise wieder angezogen ohne dass es kommuniziert wurde, usw.

 

[Verkäuferlein]

Ich arbeite hier mit 6-stelligen Debitoren

Die Aussage wiederholen die meisten Steuerberater gebetsmühlenartig.
Es ist aber so, dass die Personenkonten einfach eine Stelle mehr haben, als die Sachkonten. Und bei der Neuanlage eines Mandanten in den Datev Programmen ist die Standardeinstellung für die Sachkonnten vierstellig, also kriegen Personenkonten fünf Stellen.
Die Sachkonten können aber auf max. acht Stellen erhöht werden. Also neun stellige Personenkonten.

So ist es. Und das lässt sich auch in der Fibu-Schnittstelle JTL2DATEV entsprechend abbilden.
Und bis ich die 9. Stelle erreiche bin ich bestimmt schon längst zu Staub verfallen

Man lernt ja nie aus, nichtsdestotrotz stellt sich natürlich die Frage, welchen Vorteil bietet es, dass jeder Kunde eine eigene Debitorennummer hat, auch wenn er nie im Leben wieder bei einem kauft? Er bekommt ja zusätzlich noch eine Kundennummer in der Wawi.

Und dann muss man sich natürlich die Frage stellen, ob nicht auch die Länge der Konten eine Rolle bei der Geschwindigkeit der Buchhaltung spielt.
Ich kenne unsere Sammeldebitoren fast auswendig, ohne jemals auch nur irgendwas darauf gebucht zu haben.
Eine 4-stellige Nummer für Sachkonten und eine 5-stellige Nummer für Debitoren ist auch deutlich schneller eingegeben als bei 8 und 9 Stellen.

Wenn dann noch jemand bucht, der an 4- und 5-stellig gewöhnt ist, ist vermutlich auch die Fehlerwahrscheinlichkeit deutlich höher, wenn jetzt die Kontennummern verlängert werden und da Sach- und Personenkonten immer zusammenhängen, ist der Rückweg auch versperrt.

 

[mh1]

Man lernt ja nie aus, nichtsdestotrotz stellt sich natürlich die Frage, welchen Vorteil bietet es, dass jeder Kunde eine eigene Debitorennummer hat, auch wenn er nie im Leben wieder bei einem kauft? Er bekommt ja zusätzlich noch eine Kundennummer in der Wawi.

Und dann muss man sich natürlich die Frage stellen, ob nicht auch die Länge der Konten eine Rolle bei der Geschwindigkeit der Buchhaltung spielt.
Ich kenne unsere Sammeldebitoren fast auswendig, ohne jemals auch nur irgendwas darauf gebucht zu haben.
Eine 4-stellige Nummer für Sachkonten und eine 5-stellige Nummer für Debitoren ist auch deutlich schneller eingegeben als bei 8 und 9 Stellen.

Wenn dann noch jemand bucht, der an 4- und 5-stellig gewöhnt ist, ist vermutlich auch die Fehlerwahrscheinlichkeit deutlich höher, wenn jetzt die Kontennummern verlängert werden und da Sach- und Personenkonten immer zusammenhängen, ist der Rückweg auch versperrt.

Genau so, wie du das schreibst, ist es.
Und ich könnte mir vorstellen, dass die angesprochenen Gründe (Fehlerwahrscheinlichkeit, Gewohnheiten...) auch die Hauptgründe dafür sind, das ein Steuerberater die Stellenanzahl nicht für jeden Mandant anpasst.
Ich wollte auch nur darauf hinweisen, dass die Beschränkung auf fünf Stellen bei den Personenkonten eben keinen technischen Grund haben.