Zahlungsverkehr

Aus iDempiere de
Zur Navigation springen Zur Suche springen

Grundsätzlicher Ablauf des Zahlungsverkehrs

Welche Programmteile decken den Zahlungsverkehr ab?

Oft stellt sich für Einsteiger die Frage, wie denn nun all die Programmteile so zusammenarbeiten, das am Ende alle Rechnungen bezahlt sind und alles richtig verbucht ist. Diese Seite soll die Abläufe hierzu erklären. Der gesamte Ablauf der Buchungen in iDempiere beginnt mit Materialbuchungen und kann von einer Reservierung über eine Bestellung, Lieferung bis zu einer Rechnung gehen. Die Buchungen vor der Rechnung beschäftigen sich vor allem mit Lagerbeständen, deren Reservierung, etc. Ab der Rechnung geht es nun auch um Geld, das wir vom Kunden haben wollen. Wir betreten also den Bereich der klassischen Finanzbuchhaltung. Dennoch sollte man sich immer vor Augen halten, das auch die vorherigen Buchungen zum Lagerbestand gleichrangige Buchungszeilen in iDempiere sind.

Für diese Beschreibung hier liegt der Fokus auf den Buchungen zwischen der fertigen Rechnung an den Kunden (die der Ausgangspunkt der Buchungen ist, die mit Geld zu tun haben) und dem Eingang des Geldes auf dem Konto.


Dualität von Buchungen und Offenen Posten

Grundsätzlich erzeugt jeder Beleg in iDempiere mehrere Buchungszeilen, die alle in eine grosse Tabelle geschrieben werden. Aus diesen Buchungszeilen ergeben sich alle Auswertungen und Informationen, die die Finanzbuchhaltung bietet. Ein Kontoauszug dieser Buchungszeilen bietet z.B. einen Überblick über alle in Zusammenhang mit einem Kunden getätigten Vorgänge.

Für die Betrachtung des Zahlungsverkehrs ist dabei insbesondere das Konto "Forderungen aus Lieferungen und Leistungen" (Konto 1200 im SKR04) interessant. Hier werden die Rechnungen hingebucht und stehen dann als Saldo auf diesem Konto. Das bedeutet, das dieser Saldo immer genau die Summe ist, die ich vom Kunden zu bekommen habe.

Diese Sichtweise auf das Konto hat jedoch einen Nachteil. Ich sehe alle Eingänge und Ausgänge und den Saldo, aber bei einem Konto, auf dem viele Buchungen sind, wird das schnell sehr unübersichtlich. Wenn ein Kunde z.B. nicht genau den richtigen Rechnungsbetrag bezahlt, stimmt zwar der Saldo seiner Schuld immer noch, aber man weiss nicht, warum er eine andere Summe gezahlt hat und welche Rechnung er damit jetzt gemeint hat etc. Möchte man sich einen Überblick verschaffen (z.B. um mit dem Kunden hierüber zu sprechen) hat man einen Wust von Ein- und Ausgängen, ohne so richtig zu wissen, wo es jetzt genau gehakt hat.

Für den Zahlungsverkehr ausschlaggebend sind daher nicht nur die Buchungszeilen, sondern auch die sogenannten offenen Posten. Wie funktionieren die nun? Da alle Buchungen in iDempiere immer von einem Beleg ausgehen, gibt es natürlich auch im Zahlungsverkehr wichtige Belege. Dies ist auf der einen Seite die Rechnung (Invoice) sowie die Gutschrift (Credit Memo) und auf der anderen Seite die Zahlung (Payment). Die Gutschrift ist eigentlich nur eine Art "umgedrehte Rechnung" und wird deshalb weitgehend wie diese behandelt. Es bleibt also eine Liste von Rechnungen und eine Liste von Zahlungen.

Diese beiden können nun miteinander in Beziehung gesetzt und miteinander verrechnet werden. Im einfachsten Fall wird eine Rechnung mit einer Zahlung bezahlt. Leider gibt es im Geschäftsleben aber auch viel kompliziertere Fälle, so wie Teilzahlungen oder eine Überzahlung, die auf eine andere Rechnung als Teilzahlung angerechnet wird etc. Um das alles abbilden zu können gibt es in iDempiere die Zuordnung. Diese wird leicht unterschätzt, weil sie im einfachsten Fall nur als die Tatsache daherkommt, das ich bei der Eingabe der Zahlung eine Rechnung mit angebe. Sie ist aber ein eigenständiger Belegtyp und erzeugt damit auch eigene Buchungszeilen.

Aus den Rechnungen, Zahlungen und Zuordnungen ergibt sich nun die sogenannte "Offene-Posten-Liste". Hier kann man sehen, welche Rechnungen aktuell wirklich offen stehen und welche evtl. nur teilweise bezahlt sind etc.

Grundsätzlich muss der Saldo der Offenen-Posten-Liste immer gleich dem Saldo des Forderungskonto sein. Differenzen können unter Umständen durch verschiedene Abstufungen der Verrechung entstehen (z.B. noch keine Zuordnung erstellt).


Welche Abläufe sind möglich

Grundsätzlich ist es möglich, die Buchungen in unterschiedlichen Reihenfolgen vorzunehmen. Das hängt damit zusammen, das je nach Organisation des Unternehmens der Ablauf und der Fokus der Arbeit ein anderer sein kann. Ich möchte zuerst einmal zwei verschiede Abläufe schildern. Sie erklären die gleichen Vorgänge, die im Prinzip auch gleich bearbeitet werden. Lediglich die Reihenfolge und der Punkt der Abstimmung ist anders gelagert.


klassischer Arbeitsablauf: Von der Rechnung her

Dieser Ablauf wird in den meisten Dokumentationen zu Compiere/ADempiere/iDempiere benutzt. Er betrachtet den Arbeitsablauf aus Sicht der offenen Rechnungen. Die computerlose Analogie ist ein Kaufmann, der alle Rechnungen, die er schreibt, als Kopie in einen Ordner "offene Posten" ablegt. Kommt ein Kunde bezahlen, nimmt er die Rechnung dort raus und betrachtet sie als erledigt. Er fokussiert sich darauf, immer alle offenen Rechnungen zur Hand zu haben.

Der Kunde kauft etwas. Ich erstelle hieraus (ggf. über Umwege wie Bestellung, Lieferschein, etc, die wir hier nicht näher ausführen) eine Rechnung. Diese Rechnung wird verbucht und stellt damit einen offenen Posten dar.

Nun kommt der Kunde und bezahlt. Das kann eine Bareinzahlung oder eine Buchung auf dem Konto sein. Ich erstelle nun sofort eine neue Zahlung. In dieser Zahlung trage ich direkt die Rechnung ein, die bezahlt wird. (Hierdurch wird beim Abschliessen des Zahlungsbeleges automatisch eine Zuordnung zu dieser Rechnung erstellt). Bei Teilzahlungen oder anderen nicht-trivialen Fällen erstelle ich im entsprechenden Register manuell die entsprechenden Zuordnungen. Die iDempiere-Zahlung kann ich ausdrucken und z.B. als Quittungsformular benutzen.

Am Abend möchte ich nun meine Kasse abschliessen. Ich übertrage alle Zahlungen aus dem Kassenbuch (oder die Bons meiner Kasse) in das Fenster für einen Bankauszug. (Analog geht das natürlich auch mit dem Kontoauszug eines Bankkontos). Dazu erzeuge ich einen Bankauszug, in den ich eine nach der anderen alle Zahlungen aufnehme. Am Ende ergibt sich im Fenster des Bankauszuges ein Saldo.

Nun schaue ich in die Kasse und zähle mein Geld (bzw. ich schaue auf meinen Bankauszug). Das ist der wichtigste Moment an allen Buchungen - das ist nämlich der Moment der Abstimmung mit der Realität. Stimmen die Summen überein, ist alles gut.

Da diese Sichtweise "von der Rechnung her" oft auch gerne von kleinen Unternehmen gewählt wird, die an einem gewissen Punkt die Dinge nicht zu genau nehmen, ist es durchaus üblich, bei dieser Abstimmung eine Differenz einfach auszubuchen. Dies geschieht, indem ich am Ende des Kontoauszugs/Kassenbuchs eine Sonderbuchung mache. iDempiere erlaubt hier, eine Zeile in den Bankauszug aufzunehmen, die keiner Zahlung zugeordnet ist, sondern einer Direktbuchung/Kostenbuchung entspricht. Die Differenz wird also, wenn man ihren Ursprung nicht finden kann, auf ein Differenzkonto ausgebucht und fertig.


Onlinebanking-Arbeitsablauf: vom Zahlungsverkehr her

Dieser Ablauf fokussiert sich auf das Kassenbuch und die Kontoauszüge und bucht von diesen her alle Zahlungen. Die Zahlung wird nicht erzeugt, wenn der Kunde eine Quittung bekommt. Insbesondere bei viel bargeldlosem Verkehr bietet sich dieser Ablauf an. Zum einen besteht keine Notwendigkeit, Zahlungsformulare als Quittungen zu erzeugen und zum anderen ist es ja so, das die Zahlungen im allgemeinen ja im Kontoauszug als Liste vorliegen.

Der Kunde ruft an und bestellt etwas. Ich erstelle hieraus (ggf. über Umwege wie Bestellung, Lieferschein, etc, die wir hier nicht näher ausführen) eine Rechnung. Diese Rechnung wird verbucht und stellt damit einen offenen Posten dar.

Die Zahlungen des Unternehmens werden über einen bestimmten Zeitraum (z.B. den Tag über) gesammelt und dann in einem Durchgang verbucht. Ich schreibe also den Tag über alle Einnahmen in ein Kassenbuch und gebe dem Kunden Quittungen, die nicht aus iDempiere stammen. Das können Quittungsformulare aus dem Schreibwarenhandel sein, es kann aber auch ein Kassensystem sein, das den ganzen Tag autonom Geldeingänge bucht und Kassenbons schreibt.

Zu bestimmten Zeiten (z.B. einmal am Tag aber in kleinen Unternehmen vielleicht nur einmal im Monat) werden die eingehenden Kontoauszüge abgearbeitet und verbucht. Hierzu muss ein Kontoauszug erstellt werden. Diesen arbeite ich dabei Zeile für Zeile ab.

Am besten macht man das in der Importtabelle im Fenster "Import Kontoauszug". Hier kann man am allerbesten einen direkten Import vom Konto machen (per Bank Statement Loader z.B. per HBCI). Man kann aber auch eine CSV-Tabelle einlesen oder sein Kassenbuch auch direkt eintippen, wenn man das möchte.

TODO: Werden beim Import auch Zahlungen neu angelegt? Muss der Matcher das machen?

Eventuell kann man diesen Schritt auch überspringen und die Zeilen direkt im Fenster "Kontoauszug" erstellen (was evtl. für ein Kassenbuch eine Lösung sein kann), aber die Importtabelle bietet eine bessere Gelegenheit, die Einträge nochmals zu kontrollieren und zu korrigieren, bis man sicher ist, das man den Auszug übernehmen will.

Die Auszugszeilen im Fenster "Kontoauszug" können nicht erzeugt werden ohne das ich ein Buchungsziel angebe (eine Zahlung oder eine Direktbuchung/Kostenbuchung). Ich bin also gezwungen, eine Zahlung zuzuordnen oder neu anzulegen. Falls ich die Importtabelle benutze, können die Zahlungen zu diesem Zweck automatisch zugeordnet (mit Hilfe eines Bank Statement Matcher) oder erzeugt werden, während die Tabelle importiert wird. Falls ich den Kontoauszug manuell erstelle, gibt es auf der Registerseite der Buchungszeile zwei Prozesse ("Kontoauszüge abgleichen" und "Zahlung erzeugen"), die mir dabei helfen können.

Bin ich mit dem Kontoauszug durch, vergleiche ich den Endsaldo mit meinem Kassenbuch (oder mit dem Auszug meiner Bank). Das ist in dem Sinne kein Abgleich, weil ich ja nach diesem gearbeitet habe. Im Grunde kann da ja nun gar keine Differenz entstanden sein.

Als Ergebnis dieser Verbuchungen habe ich nun drei Kategorien von Buchungen erzeugt:

  • Zahlungen, die komplett zugeordnet sind und damit erledigt sind und gar nicht erst in der OP-Liste auftauchen.
  • Zahlungen, die (z.B. vom Matcher) einem Kunden aber keiner Rechnung zugeordnet werden konnten. Diese hängen noch in der OP-Liste und können dort ggf. manuell zugeordnet werden. Wer mit dem automatischen Matcher arbeitet, wird an dieser Stelle noch einige Arbeit investieren müssen, um "die Reste aufzuräumen".
  • Zahlungen, die direkt verbucht wurden (Direktbuchung/Kosten). Diese sind auch direkt verbucht und damit erledigt.

Der Vorteil dieses Arbeitsablaufs "Vom Zahlungsverkehr her" ist, das im Grunde gar keine Differenz entstehen kann. Wenn ich die Basisdaten meines Kontos per Onlinebanking/HBCI hole, sind alle Daten da und müssen gnadenlos irgendwie zugeordnet werden. Der Import wird erst gelingen, wenn ich alles zugeordnet habe. Das ist der Moment der "Abstimmung" der Buchungen. In den späteren Schritten kann dann eigentlich nichts mehr falsch gemacht werden.

zusätzlicher Arbeitsablauf: Selbst ausgelöste Zahlungen

Neben den Zahlungen, die von aussen an uns herangetragen werden (als Einzahlung im ersten Ablaufschema, als Kontoauszug im zweiten) gibt es auch Zahlungen, die wir auslösen. Das sind z.B. Überweisungen und Lastschriften. Wie werden diese nun in den Arbeitsablauf integriert?

Man betrachtet seine offenen Posten in der Offene-Posten-Liste und entscheidet nun, welche hiervon man gerne anschubsen möchte. Da wir uns hier mit dem Bereich der Kundenkontakte (und nicht Lieferanten) beschäftigen, kann eine Zahlung entweder durch ein Guthaben aufgrund einer Gutschrift begründet sein (Überweisung) oder durch eine Rechnung (Lastschrift).

Auswahl

Jede Rechnung und Gutschrift enthält eine Angabe der Zahlungsweise, die man auf "Lastschrift" oder "Überweisung" setzen kann. Die Grundeinstellung hierzu steht in den Geschäftspartner-Stammdaten (TODO - glaube ich zumindest). Außerdem gibt es in jeder Rechnung eine Angabe zur Zahlungsbedingung und damit zur Fälligkeit. Hieraus ergibt sich die Möglichkeit, aus den Rechnungen heraus automatisch Zahlungen zu erzeugen. Dies geht für den Bereich der Eingangsrechnungen z.B. mit dem Programm "Payment Selection" (TODO: das geht aber nicht für Ausgangsrechnungen, was unbedingt verbessert werden muss).

TODO: Es gibt ein Fenster "Zahlungssatz", das ich noch nicht ganz verstehe und noch nicht ausprobiert habe. Hier kann man keine Zeilen direkt eingeben. Ist das das Ergebnis der "Payment Selection"?!? Hier gibt man ein "Zahlungsprogramm" (Payment Processor) an, der dann die Zahlungen zur Bank gibt. Ich denke, an dieser Stelle wird dann eine Zahlung und eine Zuordnung erzeugt, so das dann alles gut wird.

Nachverarbeitung

Nach der Weitergabe der Zahlungen an die Bank sind die entsprechenden Zahlungen in iDempiere bereits erzeugt und verbucht. Wenn wir nun am nächsten Tag den Kontoauszug erhalten, stehen diese Zahlungen natürlich wieder auf dem Auszug. Diese müssen jetzt vom Matcher bei der Verarbeitung des eingehenden HBCI-Auszugs automatisch zugeordnet werden. (TODO Hierzu sollte der Matcher erkennen können, welche Zahlungen von uns in Auftrag gegeben wurden.)

TODO: Wie geht man mit Sammlern um? Da steht nur eine grosse Summe auf dem Auszug, die nicht einer einzelnen Zahlung zugeordnet werden kann.

Buchungen

In der Übersicht werden die folgenden Konten beim Zahlungsverkehr von den angebenenen Belegtypen berührt:

Die Grundlegende Reihenfolge ist (die angegebenen Kontonummern sind dem SKR04 entnommen):

 1800 ---Kontoauszug---> 1801 ---Zuordnung---> 1803 ---Zahlung---> 1200 ---Rechnung---> 4400

1800 Bank

Dieses Konto ist im Fenster "Bank" bei den Daten des eigenen Bankkontos hinterlegt. Wer mehrere Konten hat, nimmt normalerweise hierfür einzelne Konten und trägt diese dann entsprechend im Fenster "Bank" ein. So kann das verwendete Konto also "1810 Girokonto Sparkasse" oder "1820 Girokonto Volksbank" sein.

Eine Buchung auf dieses Konto entsteht durch den Abschluss des Kontoauszugs. Das bedeutet, der Kontoauszug sorgt immer dafür, das dieses Konto exakt dem Wert entspricht, den die Bank uns auf Ihrem Papierauszug mitgeteilt hat.

Welches Konto exakt benutzt wird, ergibt sich aus der Eintragung im Buchführungs-Register im Fenster "Bank", in dem wir unser eigenes Bankkonto angelegt haben.

1801 Bankbewegungen noch nicht abgeglichen

Auf diesem Konto stehen Zahlungen, die wir auf dem Kontoauszug schon mitgeteilt bekommen aber noch nicht verbucht und zugeordnet haben oder andersherum. Dies sind insbesondere

  • Lastschriften (z.B. während der SEPA-Fälligkeitsfristen) und Überweisungen
  • Bankauszugszeilen, die noch keiner Rechnung zugeordnet wurden

Das Konto stellt also die Differenz zwischen dem Kontoauszug der Bank und den von uns verrechneten Rechnungsbelegen dar.

Eine Buchung auf dieses Konto entsteht einerseits durch den Kontoauszug und andererseits durch die Zahlungszuordnung. Alle Buchungen auf dieses Konto sollten im Gleichgewicht und das Konto daher im Endeffekt ausgeglichen sein.

Welches Konto exakt benutzt wird, ergibt sich aus der Eintragung im Buchführungs-Register im Fenster "Bank", in dem wir unser eigenes Bankkonto angelegt haben (die Vorgabe für neue Konten steht im Buchführungsschema).

1803 nicht zugeordnete Eingangszahlungen Bank

Auf diesem Konto stehen Zahlungen, die auf einem Bankkonto (oder der Kasse) gebucht wurden, die aber noch keiner Rechnung zugeordnet wurden.

Eine Buchung auf dieses Konto entsteht einerseits durch eine Zahlung und andererseits durch eine Zuordnung. Falls man "triviale" Zahlungen erzeugt, bei denen direkt die entsprechende Rechnung angegeben ist, entstehen also direkt zwei Buchungen auf dieses Konto hier, die sich ausgleichen.

Steht auf diesem Konto ein Saldo bedeutet das, das wir Zahlungen haben, die wir noch keiner Rechnung zugeordnet haben. Prinzipiell ist denkbar, das man auf diese Art z.B. Teil- oder Überzahlungen "stehenlässt", bis alles bezahlt ist. Genauso ist denkbar, das man immer bestrebt ist, dieses Konto auszugleichen und Zuordnungen für jede Zahlung zu erzeugen.

Welches Konto exakt benutzt wird, ergibt sich aus der Eintragung im Buchführungs-Register im Fenster "Bank", in dem wir unser eigenes Bankkonto angelegt haben (die Vorgabe für neue Konten steht im Buchführungsschema).

Der Saldo der Konten 1800, 1801, 1803 ist etwas, das wir "tatsächliches Bankguthaben" nennen können. Es beschreibt nicht die Summe, die auf dem Auszug steht, sondern die Summe auf dem Auszug zuzüglich aller Zahlungen, die bereits veranlasst sind (aber noch nicht auf dem Auszug der Bank stehen).

1200 Forderungen aus Lieferungen und Leistungen

Dieses Konto enthält die Summe, die mein Kunde mir aus Warenlieferungen schuldet.

Eine Buchung auf dieses Konto entsteht einerseits durch eine Rechung (oder eine Gutschrift) und andererseits durch die Zuordnung zu einer Zahlung.

Möchte man wirklich wissen, was der Kunde einem schuldet und möchte man insbesondere die Offenen Posten abgleichen, so sollte man zum Saldo dieses Kontos ggf. noch den Saldo des Konto 1803 hinzurechnen.

Welches Konto exakt benutzt wird, ergibt sich aus der Eintragung im Buchführungs-Register des Geschäftspartners (die Vorgabe für neue Geschäftspartner ergibt sich aus der Geschäftspartnergruppe und deren Vorgabe steht im Buchführungsschema).

4400 Warenverkauf Erlöse 19%

Das ist das Ertragskonto, auf dem letztlich unser Umsatz steht. Bei Dienstleistungsartikeln ist das dann direkt der Gewinn, bei Waren fängt hier der Bereich der Einkaufs- und Herstellkalkulation an, den wir hier nicht betrachten wollen.

Welches Konto exakt benutzt wird, ergibt sich aus der Eintragung im Buchführungs-Register des Artikels (die Vorgabe für neue Artikel ergibt sich aus der Artikelgruppe und deren Vorgabe steht im Buchführungsschema).

Abkürzung

Wem das Buchen über mehrere Schritte zu kompliziert ist, kann scheinbar auch eine Abkürzung wählen, indem er für die Zwischenschritte identische Konten angibt. Die Zwischenbuchungen entfallen dann, wenn sie sich direkt ausgleichen können. Selber probiert habe ich das aber nicht. Mehr dazu unter http://sourceforge.net/p/adempiere/feature-requests/272/

einzelne Arbeitsschritte

Zu den folgenden Arbeitsschritten gibt es noch detailliertere Erklärungen:

  • hbci
  • matcher
  • zahlungen auswählen

TODO