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

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

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

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

Die Tabelle zeigt das strukturelle Problem: Dasselbe Rechnungsdatum — der 10. März — erzeugt vier verschiedene Zahlungsfälligkeitstermine, 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, verlangt aber Zahlung bis zum 10. Mai. Lieferant F schließt am 10. und möchte Zahlung bis zum 25. April. Der Kreditorenbuchhalter kann nicht auf das Kalenderdatum „10. März“ schauen und wissen, wann zu zahlen ist. Die Zahlungsbedingungszeichenfolge — im Rechnungs-PDF als Text eingebettet, nicht als strukturiertes Datenfeld — muss für jede Rechnung, jeden Monat gelesen, geparst und in ein Kalenderdatum umgewandelt werden. Bei dreißig Lieferanten führt das Kreditorenteam dreißig verschiedene Zahlungskalender gleichzeitig, und kein Kalender eines Lieferanten hat eine Beziehung zu dem Kalender 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 des 下請法 (Subunternehmergesetz). Für Unternehmen, die als Auftraggeber unter das japanische Gesetz über ordnungsgemäße Geschäfte mit kleinen und mittleren beauftragten Unternehmen fallen, beträgt die gesetzliche Zahlungsfrist 60 Tage ab Lieferung der Waren oder Erbringung der Dienstleistungen. Bei Zahlungsverzug nach dem Subunternehmergesetz fällt eine Strafe von 14,6 % pro Jahr an – mehr als das Doppelte des Satzes des Handelsgesetzbuchs – durchgesetzt von der Japan Fair Trade Commission. Eine Änderung von 2025 (wirksam ab Januar 2026) hat das Gesetz verschärft, indem sie Zahlungen per Wechsel verbietet und den Anwendungsbereich erweitert. Für ein Unternehmen, das als Auftraggeber für kleine und mittlere Subunternehmer gilt, ist das Verpassen der 60-Tage-Frist kein Problem der Lieferantenbeziehung. Es ist ein Verstoß gegen 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 von 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 manuellen Leseschritt abhängt. Jede Rechnung, jeden Monat liest der AP-Sachbearbeiter das Feld Zahlungsbedingungen, interpretiert es gedanklich und tippt ein Datum in die Tabellenkalkulation. Der Schritt ist schnell – ein kompetenter Sachbearbeiter kann eine Shimebi-Zeichenkette in Sekunden interpretieren. Die Fragilität des Schritts liegt nicht in seiner Geschwindigkeit, sondern in seiner Vollständigkeit: dreißig Rechnungen, dreißig Interpretationsvorgänge, dreißig Chancen für einen falsch gelesenen Abrechnungstag, eine falsch angewendete Zahlungsverzögerung oder ein übersehenes Feld für Zahlungsbedingungen, weil der Sachbearbeiter zwischen Rechnung 23 und Rechnung 24 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 Eingreifen 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 laufen, und die Zahlungsbedingungen existieren nur auf der Rechnungs-PDF – einem Format, auf das die Tabellenkalkulation nicht zugreifen kann.

Dieselbe 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älligkeitstermine, die das AP-Team eingegeben hat. Die Zuordnung der Verbrauchssteuerperioden durch das Steuerteam ist nur so genau wie die Abrechnungstage, die das AP-Team extrahiert hat. Die Prüfung der Zahlungsbedingungen der Lieferanten durch das Einkaufsteam ist nur so genau wie die aktuellsten Vertragsbedingungen, auf die sich das AP-Team bezogen hat. Der gesamte Zahlungskalender basiert auf menschlichem Lesen von PDFs – ein 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 getreu.

Das Problem, das die meisten Leute „Verfolgung von Zahlungsfristen“ nennen, ist eigentlich zwei miteinander verschmolzene Probleme. Das erste Problem ist das Extrahieren der Zahlungsbedingungen aus der Rechnung – das Lesen von „末日締翌々月10日払い“ aus dem PDF und das Umwandeln in strukturierte Daten. Das zweite Problem ist das Verfolgen dieser strukturierten Fälligkeitstermine über dreißig Lieferanten. Die Tabellenkalkulation kann das zweite Problem lösen. Sie kann das erste nicht lösen. Das erste Problem – das Extraktionsproblem – ist das, was das Kalenderproblem mit den Werkzeugen, die die meisten AP-Teams bereits haben, unlösbar macht. Die Schritt-für-Schritt-Anleitung zur Extraktion japanischer Rechnungsdaten deckt die vollständige Feldstruktur ab, die ein Extraktionsworkflow erfasst, einschließlich 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-Lieferung-Rechnungs-Abgleichsengpass auf der Beschaffungsseite an: Ein Abgleich erfordert, dass die drei Dokumente bei den Bedingungen übereinstimmen, und die Bedingungen leben in Textzeichenfolgen auf PDFs.

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 vorgeschlagene Fix ist normalerweise „besseres Kalendermanagement“ – ein gemeinsamer Teamkalender, automatisierte Erinnerungen, ein wöchentliches Zahlungslauf-Review-Meeting. Keiner dieser Fixes ändert die Tatsache, dass das Zahlungsfälligkeitsdatum nicht als Datum auf der Rechnung steht. Es steht als Textzeichenfolge auf der Rechnung, die geparst werden muss. Besseres Kalendermanagement macht den Kalender hübscher. Es schließt die Lücke zwischen der Textzeichenfolge auf dem PDF und dem Datum in der Kalenderzelle nicht.

Die Lösung liegt in der Extraktionsebene – dem Schritt, in dem Daten vom Rechnungs-PDF in strukturierte Form übergehen. Wenn der Extraktionsschritt nicht nur den rohen Zahlungsbedingungstext, sondern auch den geparsten Abrechnungstag und die Zahlungsverzögerung als separate strukturierte Werte produziert, kann sich der Kalender selbst befüllen. Eine Spalte wie Settlement Day (from Payment Terms: output the day number) und Payment Lag Months (from Payment Terms: output the number of months) – zwei berechnete Spalten, die die KI während der Extraktion ableitet – verwandeln „末日締翌々月10日払い“ in Abrechnungstag: 31 und Zahlungsverzögerungsmonate: 2 (mit Zahlung am 10.). Eine Tabellenkalkulationsformel kann dann das tatsächliche Fälligkeitsdatum aus dem Rechnungsdatum plus Abrechnungstag plus Zahlungsverzögerung berechnen. Der Extraktionsschritt füttert den Kalender mit der strukturierten Eingabe, die er benötigt. Der AP-Sachbearbeiter liest und parst nicht mehr. Der AP-Sachbearbeiter verifiziert.

Dies ist keine Workflow-Änderung. Es ist eine Datenpipeline-Änderung – die das Rechnungs-PDF direkt mit dem Zahlungskalender verbindet, indem die Zahlungsbedingungen als strukturierte Daten extrahiert werden, statt als undurchsichtige Textzeichenfolge, die ein Mensch interpretieren muss. Dieselbe Pipeline, die den Zahlungskalender speist, speist die Cashflow-Prognose, die Verbrauchssteuerperiodenzuordnung und die Prüfung der Lieferantenzahlungsbedingungen. Das Kalenderproblem verschwindet nicht, weil der Kalender besser wurde, sondern weil die Daten, die den Kalender speisen, nicht mehr vom Menschen abhängig sind.

Dasselbe Prinzip — die Lücke zwischen Dokument und Entscheidung durch die Extraktion strukturierter Daten zu schließen — treibt den Workflow zur Stapelverarbeitung von Rechnungen an, bei dem dreißig Rechnungen eine zahlungsfertige Tabellenkalkulation 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 Schritt der Datenerfassung, und genau dieser Schritt ist es, in 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 verarbeiten japanische Shimebi-basierte Zahlungsbedingungen durchaus — aber erst, nachdem die Bedingungen im Stammdatensatz jedes Lieferanten hinterlegt wurden. Das Japan-Lokalisierungsmodul von NetSuite ermöglicht es beispielsweise, ein Abrechnungstag-Muster und ein Zahlungsfälligkeitsdatum pro Lieferant zu definieren, und das System berechnet das Zahlungsfälligkeitsdatum für jede Transaktion automatisch. Die Lücke besteht darin, die Zahlungsbedingungen aus dem 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 dem PDF lesen und das Abrechnungstag-Muster im ERP entsprechend konfigurieren. Das ERP übernimmt die laufende Berechnung. Es übernimmt nicht die anfängliche Extraktion.

Nutzen 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 — haben begonnen, auf feste Zahlungstermine umzustellen (z. B. „Zahlung am 25. des Folgemonats“ unabhängig von individuellen Abrechnungszyklen), aber die Shimebi-Konvention bleibt das dominierende Modell. Für ein mittelständisches Unternehmen, das Rechnungen von dreißig Lieferanten erhält, ist die realistische Erwartung, dass fünfundzwanzig oder mehr Shimebi-basierte Bedingungen verwenden, und die Bedingungen jedes Lieferanten können unterschiedlich sein.

Wie interagiert die 60-Tage-Frist des Subunternehmergesetzes mit Shimebi-Zahlungsbedingungen?

Das Subunternehmergesetz verlangt, dass Auftraggeber Subunternehmer innerhalb von 60 Tagen nach Erhalt der Waren oder Dienstleistungen bezahlen. Ein Auftraggeber, der mit einem Subunternehmer, der am 1. des Monats liefert, Zahlungsbedingungen von „末日締翌々月末払い" (Monatsendabschluss, Zahlung bis Ende des übernächsten Monats) vereinbart, könnte mit einem Zahlungsfenster von etwa 60 bis 90 Tagen konfrontiert sein, abhängig davon, wann die Lieferung relativ zum Abrechnungszyklus erfolgt. 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 machen kann.

Was passiert, wenn ein Lieferant seine Zahlungsbedingungen während der Vertragslaufzeit ändert?

Ein Lieferant kann seine Zahlungsbedingungen bei Vertragsverlängerung ändern oder in einigen Fällen einseitig, 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, ist der Zahlungskalender für diesen Lieferanten falsch, bis die Abweichung entdeckt wird. Dies ist am häufigsten bei Lieferanten, die von 翌月末払い auf 翌々月払い umstellen, um ihre eigene Liquidität zu verbessern — die Kreditorenbuchhaltung zahlt nach dem alten (kürzeren) Zeitplan, was für den Lieferanten günstig ist, sodass dieser keinen Anreiz hat, die Abweichung zu melden. Die Abweichung bleibt bestehen, bis eine Prüfung oder eine Cashflow-Anomalie die Aufmerksamkeit darauf lenkt.

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, weil 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 verarbeitet die Zahlung. Der Vorfall ist abgeschlossen. Die Grundursache — dass das Zahlungsfälligkeitsdatum nie als Datum auf der Rechnung stand, sondern nur als Textzeichenfolge, die ein Mensch parsen musste, und der Mensch sie falsch geparst hat — erscheint nicht im Vorfallbericht. Sie erscheint nirgendwo, weil die Daten, die sie aufdecken würden (die Zahlungsbedingungen auf der Rechnung vs. das Fälligkeitsdatum in der Tabelle), in zwei verschiedenen Systemen liegen und niemand sie vergleicht, außer ein Fehler erzwingt den Vergleich.

Die Lücke ist strukturell: Die Rechnung trägt Zahlungsbedingungen in einem Format, das ein Computer nicht nutzen kann (eingebetteter Text in einer PDF). Die Kreditorenbuchhaltung konvertiert sie in ein Format, das ein Computer nutzen kann (ein Kalenderdatum in einer Tabelle), durch einen Schritt, der vollständig von menschlicher Aufmerksamkeit abhängt — Lesen, Parsen, Tippen. Bei dreißig Lieferanten, dreißig Rechnungen pro Monat, zwölf Monaten pro Jahr, passiert dieser Schritt 360 Mal. Die Fehlerquote ist prozentual niedrig und absolut gesehen kostspielig, weil jeder Fehler in Lieferantenbeziehungen, Cashflow-Prognosen, Steuererklärungen und Compliance-Risiken kaskadiert. Die Lösung ist kein besserer Kalender. Die Lösung ist die Schließung der Lücke — den Extraktionsschritt so zu gestalten, dass er strukturierte Zahlungsbedingungsdaten erzeugt, die ein Kalender direkt konsumieren kann, sodass der Kalender aus der Rechnung abgeleitet wird, nicht aus dem menschlichen Lesen der Rechnung.