Warum der japanische Shimebi-Zahlungskalender
schwieriger ist, als die meisten AP-Teams glauben

Das Shimebi-System: Ein Zahlungskalender, entworfen von dreißig verschiedenen Personen

Japans Abrechnungszyklus-System – die Shimebi-Konvention (締日) – ist kein einheitliches System. Es besteht aus dreißig Systemen, die jeweils durch einen Vertrag zwischen einem Käufer und einem Lieferanten definiert sind. Der Vertrag legt zwei Dinge fest: den Tag des Monats, an dem der Abrechnungszeitraum endet (den Abrechnungstag, 締日), und wie viele Monate später die Zahlung erfolgen muss (die Zahlungsverzögerung, ausgedrückt in einer kompakten Syntax wie 翌月末払い oder 翌々月10日払い). Ein Unternehmen, das von dreißig Lieferanten einkauft, hat bis zu dreißig verschiedene Kombinationen aus Abrechnungstag und Zahlungsverzögerung, da jeder Lieferant zu Beginn der Geschäftsbeziehung seine eigenen Bedingungen ausgehandelt hat und diese im Kaufvertrag verankert sind – nicht standardisiert durch eine Branchenorganisation oder Plattform.

Die häufigsten Kombinationen bilden eine kleine Menge, aber diese kleine Menge ist immer noch größer als ein einzelner Kalender:

Die Tabelle zeigt das strukturelle Problem: Das gleiche Rechnungsdatum – der 10. März – führt zu vier verschiedenen Zahlungsfälligkeiten, je nachdem, welcher Lieferant die Rechnung ausgestellt hat. Lieferant A und B schließen am 15. bzw. 20. ab, beide verlangen Zahlung bis Ende April. Lieferant C schließt am Monatsende ab, verlangt aber Zahlung bis zum 10. Mai. Lieferant F schließt am 10. ab und möchte die Zahlung bis zum 25. April. Der Kreditorenbuchhalter kann nicht anhand des Kalenderdatums „10. März“ erkennen, wann er zahlen muss. Die Zahlungsbedingungszeichenfolge – als Text in der Rechnungs-PDF eingebettet, nicht als strukturiertes Datenfeld – muss für jede Rechnung jeden Monat gelesen, analysiert und in ein Kalenderdatum umgewandelt werden. Bei dreißig Lieferanten führt das AP-Team gleichzeitig dreißig verschiedene Zahlungskalender, und kein Kalender eines Lieferanten hat eine Beziehung zu dem eines anderen Lieferanten.

Dies ist keine japanische Eigenart. Es ist eine direkte Folge eines Abrechnungssystems, bei dem jeder bilaterale Vertrag seine eigenen Bedingungen definiert. Die meisten Länder verwenden Netto 30, Netto 60 oder Netto 90 – Rechnungsdatum plus eine feste Anzahl von Tagen. Japan verwendet ein zweiteiliges System: Abrechnungstag plus Zahlungsverzug, wobei der Zahlungsverzug in Monaten und nicht in Tagen ausgedrückt wird und die tatsächliche Anzahl der Tage je nach Monatslänge variiert. Der April hat 30 Tage; der Mai hat 31; der Februar hat 28 oder 29. Das Fälligkeitsdatum der Zahlung unter der Bedingung „Monatsende-Abrechnung, Zahlung am Ende des Folgemonats“ für eine Rechnung vom 10. März ist der 30. April – ein Verzug von 20 Tagen ab dem Abrechnungstag (31. März bis 30. April). Für eine Rechnung vom 25. März unter denselben Bedingungen beträgt der Verzug ebenfalls bis zum 30. April – ein Verzug von 30 Tagen ab dem Abrechnungstag, da der Abrechnungstag selbst je nach Monatslänge variiert. Ein Netto-30-System würde beiden Rechnungen dasselbe Zahlungsdatum relativ zum Rechnungsdatum geben. Das Shimebi-System gibt ihnen dasselbe Zahlungsdatum relativ zum Abrechnungstag. Der Kreditorenbuchhalter muss beide verfolgen.

Die NetSuite Japan-Lokalisierungsdokumentation erklärt dies klar: „Unternehmen vereinbaren vor Geschäftsbeginn einen Abrechnungstag mit ihren Kunden. Das Zahlungsfälligkeitsdatum ist festgelegt, was bedeutet, dass die Anzahl der Tage zwischen dem Abrechnungstag und dem Zahlungsfälligkeitsdatum variiert, je nachdem, wie viele Tage der jeweilige Monat hat.“ Große ERP-Systeme verarbeiten die Shimebi-Logik nativ – vorausgesetzt, jemand hat den Abrechnungstag und das Zahlungsfälligkeitsdatum für jeden Lieferanten im Lieferantenstamm hinterlegt. Die Lücke liegt im Schritt vor dem ERP: die Zahlungsbedingungen von der Rechnungs-PDF zu erfassen und überhaupt erst ins System zu bekommen.

Dreißig Lieferanten, dreißig Kalender, eine Frist, die niemandem gehört

Das Kreditorenbuchhaltungsteam, das dreißig Lieferantenbeziehungen verwaltet, steht nicht vor einer Zahlungsfrist pro Monat. Es steht vor dreißig Zahlungsfristen, verteilt auf zwei oder drei Kalenderdaten pro Monat, jede ausgelöst durch einen anderen Abrechnungstag, der an einem anderen Tag des Monats endet. Die praktische Konsequenz ist keine rechnerische Schwierigkeit – ein kompetenter Kreditorenbuchhalter kann „Monatsende-Abrechnung, Zahlung am 10. des übernächsten Monats“ in Sekunden analysieren. Die praktische Konsequenz ist, dass der Kalender unsichtbar ist, bis jemand jede Rechnung einzeln betrachtet.

Ein in den USA ansässiges Kreditorenbuchhaltungsteam kann eine Liste von Rechnungsdaten überfliegen und gedanklich dreißig Tage hinzufügen. Ein in Japan ansässiges Kreditorenbuchhaltungsteam kann eine Liste von Rechnungsdaten überhaupt nicht überfliegen – das Rechnungsdatum ist eine unzureichende Information. Der einzige Weg, das Zahlungsfälligkeitsdatum zu kennen, ist das Lesen des Feldes „Zahlungsbedingungen“ auf jeder Rechnung. Wenn dreißig Rechnungen eingehen, liest das Kreditorenbuchhaltungsteam dreißig Felder mit Zahlungsbedingungen und berechnet dreißig Fälligkeitsdaten. Wenn die Zahlungsbedingungen einer Rechnung falsch gelesen werden – wenn „Abrechnung am 20., Zahlung am Ende des Folgemonats“ mit „Monatsende-Abrechnung, Zahlung am Ende des Folgemonats“ verwechselt wird, weil der Abrechnungstag um zehn Tage differiert – kann das Fälligkeitsdatum zwar dasselbe sein (beide am Ende des Folgemonats), aber die Klassifizierung der Abrechnungsperiode kann falsch sein. Die Ausgabe gehört im Hauptbuch zu einem anderen Monat, was sich auf die vierteljährlichen Finanzberichte und die Umsatzsteuererklärung auswirkt.

Die Kalenderfragmentierung verstärkt sich abteilungsübergreifend. Das Treasury-Team muss den gesamten Mittelabfluss nach Datum kennen, um das Working Capital zu steuern. Das Beschaffungsteam muss wissen, ob sich die Zahlungsbedingungen eines Lieferanten seit der letzten Vertragsverlängerung geändert haben. Das Steuerteam muss wissen, welche Rechnungen in welchen Umsatzsteuer-Meldezeitraum fallen. Jedes Team fragt das Kreditorenbuchhaltungsteam nach einem anderen Ausschnitt derselben Daten – nach Datum, nach Lieferant, nach Steuerperiode – und das Kreditorenbuchhaltungsteam, das dreißig einzelne Rechnungen mit eingebetteten Zahlungsbedingungen betrachtet, die einzeln analysiert werden müssen, kann keine dieser Ansichten erstellen, ohne zuerst alle dreißig Rechnungen in eine Tabelle einzugeben und diese Tabelle dann zu bearbeiten. Der Dateneingabeschritt ist der Engpass. Das Kalenderproblem liegt nachgelagert zum Datenextraktionsproblem.

Was eine versäumte Frist tatsächlich kostet – jenseits der Verzugszinsen

Die sichtbaren Kosten einer versäumten Zahlungsfrist an einen Lieferanten sind die gesetzlichen Verzugszinsen (遅延損害金, chien songaikin). Gemäß Artikel 514 des japanischen Handelsgesetzbuchs (商法) beträgt der gesetzliche Zinssatz für Handelsgeschäfte zwischen Unternehmen 6 % pro Jahr. Eine Rechnung über 500.000 Yen, die 30 Tage zu spät bezahlt wird, verursacht Verzugsschäden in Höhe von rund 2.466 Yen – ein Betrag, der klein genug ist, dass die meisten AP-Teams lieber einen Verzicht aushandeln, als die Zinsen zu berechnen, aber groß genug, dass das aggregierte Risiko über dreißig Lieferanten und zwölf Monate hinweg zu einer Position in der Jahresprüfung wird.

Doch die gesetzliche Vertragsstrafe sind die Kosten, die die Buchhaltung sehen kann. Die Kosten, die sie nicht sehen kann, sind größer und schwerer zu messen:

Erosion der Lieferantenbeziehung. Ein Lieferant, der am 31. des Monats bezahlt wird, obwohl der Vertrag den 10. vorsieht, ergreift nicht sofort rechtliche Schritte. Er sendet eine höfliche Erinnerung. Die zweite verspätete Zahlung führt zu einem Telefonat mit dem Einkaufsleiter. Die dritte verspätete Zahlung ändert das Verhalten des Lieferanten: Er beginnt möglicherweise, Vorauszahlungen zu verlangen, die Zahlungsziele einseitig zu verkürzen, die Aufträge des Käufers in der Hochsaison nachrangig zu behandeln oder die Stückpreise in der nächsten Vertragsverhandlung anzuheben, um die Kosten des Working Capitals für die Forderungen des Käufers zu kompensieren. Diese Anpassungen werden nicht als „Reaktion auf Zahlungsverzug“ ausgewiesen. Sie sind im Stückpreis der nächsten Bestellung versteckt und für das AP-Team, das sie ausgelöst hat, unsichtbar.

Fehler in der Cashflow-Prognose. Wenn der Zahlungskalender falsch ist – wenn sechs am 10. Mai fällige Rechnungen fälschlicherweise als am 31. Mai fällig erfasst wurden – weist die Cashflow-Prognose des Treasury-Teams für die 21-tägige Lücke einen um die Summe dieser sechs Rechnungen zu hohen verfügbaren Bestand aus. Das Unternehmen könnte Ausgabenentscheidungen auf der Grundlage einer ungenauen Liquiditätsposition treffen. Der Fehler wird erst am 11. Mai entdeckt, wenn sich sechs Lieferanten nach dem Zahlungsstatus erkundigen – zu diesem Zeitpunkt ist das Geld bereits anderweitig verplant, und das Treasury-Team muss hektisch die Deckungslücke schließen. Die Kosten dieser Hektik – Überziehungszinsen, verspätete Zahlungen an andere Lieferanten oder der interne Zeitaufwand für die Überarbeitung der Cashflow-Prognose – werden nicht als Kosten des Zahlungsverzugs verbucht.

Doppelte Quellensteuerbelastung. Bei einer Lieferantenrechnung mit 源泉徴収 (gensen chōshū)-Klassifizierung müssen vor der Zahlung 10,21 % einbehalten werden. Wenn das AP-Team sowohl die Zahlungsfrist als auch den Steuerabzug versäumt – ein häufiger kombinierter Fehler bei schneller Bearbeitung – zahlt das Unternehmen den vollen Betrag an den Lieferanten (eine Überzahlung von 10,21 %) und schuldet dem Finanzamt den einbehaltenen Betrag dennoch als separate Einzahlung. Die verspätete Zahlung der Quellensteuer an das Finanzamt zieht eigene Verzugszinsen nach sich, getrennt von den kommerziellen Verzugszinsen an den Lieferanten. Eine einzige versäumte Zahlungsfrist bei einer quellensteuerpflichtigen Rechnung kann zwei separate Verzugsströme auslösen.

Das Compliance-Risiko nach dem 下請法 (Subunternehmergesetz). Für Unternehmen, die als Auftraggeber im Sinne des japanischen Gesetzes über ordnungsgemäße Transaktionen mit kleinen und mittleren Subunternehmern gelten, beträgt die gesetzliche Zahlungsfrist 60 Tage ab Lieferung der Ware oder Erbringung der Dienstleistung. Bei Zahlungsverzug nach dem Subunternehmergesetz fällt eine Vertragsstrafe von 14,6 % pro Jahr an – mehr als das Doppelte des Handelsgesetzbuch-Satzes –, durchgesetzt von der Japan Fair Trade Commission. Eine Novelle von 2025 (wirksam ab Januar 2026) hat das Gesetz verschärft, indem sie Zahlungen durch Wechsel verbietet und den Anwendungsbereich erweitert. Für ein Unternehmen, das als Auftraggeber für kleine und mittlere Subunternehmer gilt, ist die Nichteinhaltung der 60-Tage-Frist kein Lieferantenbeziehungsproblem. Es handelt sich um einen Verstoß gegen gesetzliche Vorschriften, den die Fair Trade Commission untersuchen kann.

Warum die Tabellenkalkulation das Kernproblem nicht lösen kann

Die Tabellenkalkulation ist das Werkzeug, mit dem AP-Teams den Kalender verwalten. Sie ist auch das Werkzeug, das am deutlichsten zeigt, warum das Kalenderproblem nicht mit besserer Kalenderdisziplin lösbar ist. Die Tabellenkalkulation hat eine Spalte für das Zahlungsfälligkeitsdatum. Diese Spalte muss von einem Menschen ausgefüllt werden, der die Zahlungsbedingungen aus jeder Rechnungs-PDF liest und „末日締翌々月10日払い“ in ein Kalenderdatum umwandelt. Die Tabellenkalkulation kann das Ergebnis dieser Umwandlung speichern. Sie kann die Umwandlung selbst nicht durchführen, weil die Tabellenkalkulation die Rechnung nicht lesen kann.

Das bedeutet, dass die Genauigkeit der Tabellenkalkulation vollständig vom menschlichen Leseschritt abhängt. Jede Rechnung, jeden Monat liest der AP-Sachbearbeiter das Feld Zahlungsbedingungen, analysiert es gedanklich und gibt ein Datum in die Tabellenkalkulation ein. Der Schritt ist schnell – ein kompetenter Sachbearbeiter kann einen Shimebi-String in Sekunden analysieren. Die Fragilität des Schrittes liegt nicht in seiner Geschwindigkeit, sondern in seiner Vollständigkeit: dreißig Rechnungen, dreißig Analysevorgänge, dreißig Chancen für einen falsch gelesenen Abrechnungstag, eine falsch angewandte Zahlungsverzögerung oder ein übersehenes Feld Zahlungsbedingungen, weil der Sachbearbeiter zwischen Rechnung dreiundzwanzig und Rechnung vierundzwanzig durch einen Telefonanruf unterbrochen wurde. In einem Netto-30-System ist eine Rechnung vom 10. März immer am 9. April fällig – eine Formel kann das Datum ohne menschliches Zutun generieren. Im Shimebi-System ist eine Rechnung vom 10. März mit den Zahlungsbedingungen „末日締翌々月10日払い“ am 10. Mai fällig. Das Datum „10. März“ allein ist nutzlos. Die Formel kann ohne die Zahlungsbedingungen als Eingabe nicht ausgeführt werden, und die Zahlungsbedingungen existieren nur auf der Rechnungs-PDF – einem Format, auf das die Tabellenkalkulation nicht zugreifen kann.

Die gleiche strukturelle Lücke gilt für jeden nachgelagerten Prozess, der vom Zahlungskalender abhängt. Die Cashflow-Prognose des Treasury-Teams ist nur so genau wie die Fälligkeitsdaten, die das AP-Team eingegeben hat. Die Zuordnung der Verbrauchssteuerperioden durch das Steuerteam ist nur so genau wie die Abrechnungstage, die das AP-Team analysiert hat. Die Prüfung der Lieferantenzahlungsbedingungen durch das Beschaffungsteam ist nur so genau wie die aktuellsten Vertragsbedingungen, die das AP-Team herangezogen hat. Der gesamte Zahlungskalender ruht auf einem Fundament des menschlichen Lesens von PDFs – einem Fundament, das keine Tabellenkalkulationsfunktion verstärken kann, weil die Tabellenkalkulation an dem Punkt beginnt, an dem das Lesen bereits stattgefunden hat. Wenn der Leseschritt einen Fehler produziert, speichert und verbreitet die Tabellenkalkulation ihn getreulich.

Das Problem, das die meisten Menschen „Verfolgung von Zahlungsfristen“ nennen, besteht eigentlich aus zwei miteinander verbundenen Problemen. Das erste Problem ist das Extrahieren der Zahlungsbedingungen aus der Rechnung – das Lesen von „末日締翌々月10日払い“ aus der PDF-Datei und die Umwandlung in strukturierte Daten. Das zweite Problem ist die Verfolgung dieser strukturierten Fälligkeitsdaten über dreißig Lieferanten hinweg. Die Tabellenkalkulation kann das zweite Problem lösen. Das erste kann sie nicht. Das erste Problem – das Extraktionsproblem – macht das Kalenderproblem mit den Werkzeugen, die den meisten AP-Teams bereits zur Verfügung stehen, unlösbar. Der Schritt-für-Schritt-Leitfaden zur Extraktion japanischer Rechnungsdaten behandelt die vollständige Feldstruktur, die ein Extraktionsworkflow erfasst, einschließlich der Zahlungsbedingungen und ihrer berechneten Abrechnungstage – die strukturierten Daten, die ein Kalender als Eingabe benötigt. Dieselbe Lücke zwischen den Zahlungsbedingungen auf der Rechnung und dem Zahlungsdatum im ERP treibt den Bestell-Lieferungs-Rechnungs-Abgleichs-Engpass auf der Beschaffungsseite an: Ein Abgleich erfordert, dass die drei Dokumente hinsichtlich der Bedingungen übereinstimmen, und die Bedingungen liegen als Textstrings in PDFs vor.

Wo die Lösung tatsächlich liegt – und warum es keine Workflow-Änderung ist

Das Kalenderproblem in der japanischen Kreditorenbuchhaltung wird routinemäßig als Planungsproblem fehldiagnostiziert. Der übliche Lösungsvorschlag ist „besseres Kalendermanagement“ – ein gemeinsamer Teamkalender, automatisierte Erinnerungen, ein wöchentliches Zahlungslauf-Review-Meeting. Keine dieser Lösungen ändert die Tatsache, dass das Zahlungsfälligkeitsdatum nicht als Datum auf der Rechnung steht. Es steht als Textstring auf der Rechnung, der geparst werden muss. Besseres Kalendermanagement macht den Kalender hübscher. Es schließt nicht die Lücke zwischen dem Textstring in der PDF und dem Datum in der Kalenderzelle.

Die Lösung liegt auf der Extraktionsebene – dem Schritt, bei dem Daten aus der Rechnungs-PDF in eine strukturierte Form überführt werden. Wenn der Extraktionsschritt nicht nur den rohen Text der Zahlungsbedingungen, sondern auch den geparsten Abrechnungstag und den Zahlungsverzug als separate strukturierte Werte liefert, kann sich der Kalender selbst befüllen. Eine Spalte wie Abrechnungstag (aus Zahlungsbedingungen: Tagesnummer ausgeben) und Zahlungsverzug in Monaten (aus Zahlungsbedingungen: Anzahl Monate ausgeben) – zwei berechnete Spalten, die die KI während der Extraktion ableitet – verwandeln „末日締翌々月10日払い“ in Abrechnungstag: 31 und Zahlungsverzug in Monaten: 2 (mit Zahlung am 10.). Eine Tabellenkalkulationsformel kann dann das tatsächliche Fälligkeitsdatum aus Rechnungsdatum plus Abrechnungstag plus Zahlungsverzug berechnen. Der Extraktionsschritt versorgt den Kalender mit der strukturierten Eingabe, die er benötigt. Der AP-Sachbearbeiter liest und parst nicht mehr. Der AP-Sachbearbeiter prüft.

Dies ist keine Workflow-Änderung. Es ist eine Datenpipeline-Änderung – die direkte Verbindung der Rechnungs-PDF mit dem Zahlungskalender, indem die Zahlungsbedingungen als strukturierte Daten extrahiert werden, anstatt als undurchsichtiger Textstring, den ein Mensch interpretieren muss. Dieselbe Pipeline, die den Zahlungskalender speist, versorgt auch die Liquiditätsvorschau, die Zuordnung des Umsatzsteuerzeitraums und das Audit der Lieferantenzahlungsbedingungen. Das Kalenderproblem verschwindet nicht, weil der Kalender besser geworden ist, sondern weil die Daten, die den Kalender speisen, nicht mehr vom Menschen abhängig sind.

Das gleiche Prinzip – die Lücke zwischen Dokument und Entscheidung durch Extraktion strukturierter Daten zu schließen – treibt den Batch-Rechnungsverarbeitungs-Workflow an, bei dem dreißig Rechnungen eine zahlungsbereite Tabelle mit Banküberweisungsdaten, Quellensteuerberechnungen und Zahlungsplan, gruppiert nach Abrechnungstag, ergeben. Und es spiegelt die strukturelle Erkenntnis aus der Analyse der australischen BAS-Einreichung wider: Das Formular dauert neunzig Sekunden; die Zusammenstellung dauert Tage. In beiden Fällen verbirgt die sichtbare Frist den unsichtbaren Datensammlungsschritt, und genau dieser Sammlungsschritt ist der Punkt, an dem die Extraktionsebene die Lücke schließt.

FAQ

Warum kann das ERP-System Shimebi-Zahlungsbedingungen nicht automatisch verarbeiten?

ERP-Systeme wie NetSuite, SAP und Oracle E-Business Suite können japanische Shimebi-basierte Zahlungsbedingungen verarbeiten – allerdings erst, nachdem die Bedingungen im Stammdatensatz jedes Lieferanten hinterlegt wurden. Das Japan-Lokalisierungsmodul von NetSuite ermöglicht es beispielsweise, pro Lieferant ein Abrechnungstag-Muster und ein Zahlungsfälligkeitsdatum zu definieren; das System berechnet dann automatisch das Fälligkeitsdatum für jede Transaktion. Die Lücke besteht darin, die Zahlungsbedingungen aus der Rechnungs-PDF des Lieferanten überhaupt erst in den Lieferantenstamm zu übernehmen. Wenn ein neuer Lieferant seine erste Rechnung mit den Zahlungsbedingungen „20日締翌月末払い“ sendet, muss jemand diesen Text aus der PDF auslesen und das Abrechnungstag-Muster im ERP entsprechend konfigurieren. Das ERP übernimmt die laufende Berechnung. Die anfängliche Extraktion übernimmt es nicht.

Verwenden alle japanischen Unternehmen Shimebi-Zahlungsbedingungen?

Die meisten tun dies bei inländischen B2B-Transaktionen. Das System ist tief in der japanischen Geschäftspraxis verankert. Einige Branchen – insbesondere große Einzelhändler mit vielen kleinen Lieferanten – beginnen, auf feste Zahlungstermine umzustellen (z. B. „Zahlung am 25. des Folgemonats“ unabhängig vom individuellen Abrechnungszyklus), aber die Shimebi-Konvention bleibt das dominierende Modell. Für ein mittelständisches Unternehmen, das Rechnungen von dreißig Lieferanten erhält, ist realistisch zu erwarten, dass fünfundzwanzig oder mehr Shimebi-basierte Bedingungen verwenden – und die Bedingungen jedes Lieferanten können unterschiedlich sein.

Wie wirkt sich die 60-Tage-Frist des Subunternehmergesetzes auf Shimebi-Zahlungsbedingungen aus?

Das Subunternehmergesetz verlangt, dass auftraggebende Unternehmen Subunternehmer innerhalb von 60 Tagen nach Erhalt der Waren oder Dienstleistungen bezahlen. Ein auftraggebendes Unternehmen, das mit einem Subunternehmer, der am 1. des Monats liefert, Zahlungsbedingungen von „末日締翌々月末払い“ (Monatsende-Abrechnung, Zahlung bis zum Ende des übernächsten Monats) aushandelt, könnte je nachdem, wann die Lieferung in den Abrechnungszyklus fällt, auf ein Zahlungsfenster von etwa 60 bis 90 Tagen stoßen. Diese Kombination – eine lange Shimebi-Verzögerung plus die gesetzliche 60-Tage-Frist – schafft ein Compliance-Risiko, das aktives Monitoring erfordert. Die Verzugszinsen von 14,6 % gemäß Subunternehmergesetz machen dies zum teuersten Kalenderfehler, den ein Unternehmen begehen kann.

Was passiert, wenn ein Lieferant seine Zahlungsbedingungen mitten im Vertrag ändert?

Ein Lieferant kann seine Zahlungsbedingungen bei Vertragsverlängerung oder in manchen Fällen einseitig ändern, indem er die auf seinen Rechnungen aufgedruckten Bedingungen aktualisiert. Wenn die Kreditorenbuchhaltung Rechnungen mit den alten Bedingungen aus dem Lieferantenstamm verarbeitet, während der Lieferant bereits auf neue Bedingungen umgestellt hat, stimmt der Zahlungskalender für diesen Lieferanten nicht mehr, bis die Abweichung entdeckt wird. Dies tritt am häufigsten bei Lieferanten auf, die von „Zahlung bis Ende des Folgemonats“ auf „Zahlung bis Ende des übernächsten Monats“ umstellen, um ihre eigene Liquidität zu verbessern – die Kreditorenbuchhaltung zahlt nach dem alten (kürzeren) Zeitplan, was für den Lieferanten vorteilhaft ist, sodass dieser keinen Anreiz hat, die Diskrepanz zu melden. Die Abweichung bleibt bestehen, bis eine Prüfung oder eine Anomalie im Cashflow darauf aufmerksam macht.

Das Kalenderproblem, für das niemand ein Dashboard erstellt

Die Verwaltung des Zahlungskalenders in der japanischen Kreditorenbuchhaltung ist ein Problem, das kein eigenes Dashboard generiert, da das Symptom – eine versäumte Zahlungsfrist – wie ein einmaliger Fehler aussieht, nicht wie ein systemisches Versagen. Der Lieferant sendet eine Erinnerung. Die Kreditorenbuchhaltung entschuldigt sich und führt die Zahlung aus. Der Vorfall wird abgeschlossen. Die Ursache – dass das Zahlungsziel nie als Datum auf der Rechnung stand, sondern nur als Textzeichenfolge, die ein Mensch interpretieren musste, und der Mensch sie falsch interpretiert hat – taucht im Vorfallsbericht nicht auf. Sie taucht nirgendwo auf, weil die Daten, die sie offenlegen würden (die Zahlungsbedingungen auf der Rechnung im Vergleich zum Fälligkeitsdatum in der Tabelle), in zwei verschiedenen Systemen leben und niemand sie vergleicht, es sei denn, ein Fehler erzwingt den Vergleich.

Die Lücke ist strukturell bedingt: Die Rechnung enthält Zahlungsbedingungen in einem Format, das ein Computer nicht nutzen kann (eingebetteter Text in einer PDF). Die Kreditorenbuchhaltung wandelt sie in ein Format um, das ein Computer nutzen kann (ein Kalenderdatum in einer Tabelle), und zwar durch einen Schritt, der vollständig von menschlicher Aufmerksamkeit abhängt – Lesen, Interpretieren, Tippen. Bei dreißig Lieferanten, dreißig Rechnungen pro Monat, zwölf Monaten im Jahr, findet dieser Schritt 360 Mal statt. Die Fehlerquote ist prozentual niedrig und in absoluten Zahlen kostspielig, da jeder Fehler auf die Lieferantenbeziehungen, Cashflow-Prognosen, Steuererklärungen und Compliance-Risiken durchschlägt. Die Lösung ist kein besserer Kalender. Die Lösung ist, die Lücke zu schließen – den Extraktionsschritt so zu gestalten, dass er strukturierte Zahlungsbedingungsdaten produziert, die ein Kalender direkt verarbeiten kann, sodass der Kalender von der Rechnung abgeleitet wird und nicht von der menschlichen Interpretation der Rechnung.