Start · Lösungen · Weitere Lösungen
Lösung · Weitere LösungenEine tägliche Regel entscheidet, wo Skonto sich lohnt und wo einfach pünktlich gezahlt wird
Skonto ziehen, wenn es die Kapitalkosten übersteigt
Ein Roboter liest jeden Morgen die offenen Posten, wendet die von CFO und Treasurer vereinbarte Regel an und schlägt dem Treasury den Zahlungslauf mit Begründung je Position vor.
Kurzfassung für die Geschäftsführung
Ihre Lieferanten bieten Skonto. Ihr Zahlungskalender entscheidet, ob Sie es ziehen.
Wir bauen eine Zahlungsterminierung, die jeden Morgen auf SAP und auf der Treasury-Planung in ihrer heutigen Form läuft.
Skontofenster werden eingehalten, weil der Termin das Zahldatum bestimmt und nicht der Kalender.
SAP S/4HANA Zahlungsvorschlag; Stammdatenkorrekturen im SAP-Lieferantenstamm; semantisches Power-BI-Modell
Geschäftliches Problem
Treasury
Über Zahlungszeitpunkte entscheiden drei Personen mit drei Sichtweisen und ohne gemeinsame Regel. Die Kreditorenbuchhaltung sieht Fälligkeiten und den Druck der Lieferanten. Das Treasury sieht den Bankstand und eine Planung. Der Einkauf hat die Konditionen verhandelt und niemandem gesagt, dass es überhaupt Skonto gibt.
Konkret wird das im Lieferantenstamm. Die dort hinterlegten Zahlungsbedingungen sind häufig falsch, enthalten das Skonto selten und werden nie mit dem verglichen, was auf der Rechnung steht. Skonto wird also gezogen, wenn eine Rechnung zufällig früh freigegeben wird, und geht in allen übrigen Fällen verloren. Verspätete Zahlungen entstehen aus dem umgekehrten Grund: eine Rechnung, die bis nach dem Fälligkeitstag gesperrt oder verlegt war und dann mit Zinsen, einer Gebühr oder einem Anruf beglichen wird, der die Beziehung kostet.
Die Gewohnheit hält sich, weil der Zahlungslauf eine Routine ist und keine Entscheidung. Niemand erzeugt die eine Zahl, die das ändern würde: angebotenes Skonto in diesem Monat, gezogenes Skonto, die Differenz. Ohne diese Zahl gibt es nichts für eine Tagesordnung, also geht der Lauf weiter am Donnerstag hinaus und die Fenster schließen weiter am Mittwoch.
Wie es heute läuft
So sieht es in den meisten Unternehmen mit Wochenlauf aus, unabhängig vom ERP.
- SystemDer Wochenlauf ist terminiert, die Kreditorenbuchhaltung wählt alles aus, was bis zum nächsten fällig wird
- MenschEskalationen von Lieferanten werden nach Anrufen und Mahn-Mails von Hand ergänzt
- WartezeitDer Treasurer sieht die Summe am Morgen des Laufs und schiebt Positionen gegen den Bankstand
- FehlerrisikoSkonto fällt nur dort auf, wo die Bedingung zufällig korrekt im Lieferantenstamm steht
- SystemDie Zahlungsdatei wird freigegeben; ein Teil geht ohne Skonto zu früh, ein anderer nach Fälligkeit
- MenschVerzugszinsen und Gebühren kommen als Lieferantenbelastung und werden ohne Rückfrage gebucht
- FehlerrisikoAuf der Rechnung gedruckte Skontobedingungen fließen nie in den Lieferantenstamm zurück
- MenschDer Monatsbericht zeigt die Kreditorenlaufzeit und schweigt über Skonto
Warum der heutige Prozess mehr kostet, als er scheint
Hinter jeder Ausnahme steht eine Stunde, die niemand erfasst hat.
- 2 % Skonto für eine um zwanzig Tage vorgezogene Zahlung decken 5,48 % eines Jahres ab, der Jahreswert liegt damit um ein Vielfaches über den hier angenommenen 4,5 % Kapitalkosten. Finanzteams wissen das in der Theorie und verlieren es in der Praxis, weil nichts in der Wochenroutine es prüft.
- Verzugsgebühren sind einzeln klein und werden als Lieferantenbelastung gebucht statt als Prozesskosten, deshalb addiert sie niemand.
- Zu früh ohne Skonto zu zahlen ist ein zinsloser Kredit an den Lieferanten; zu spät zu zahlen verbraucht Wohlwollen, das als härtere Konditionen zurückkommt. Beides steht in keinem Bericht.
- Das Treasury hält einen Puffer, der auf Unsicherheit ausgelegt ist statt auf einen Plan, weil der Plan erst am Morgen des Laufs vorliegt.
- Die Drift der Stammdaten summiert sich. Eine einmal falsch erfasste Zahlungsbedingung bleibt auf jeder weiteren Rechnung dieses Lieferanten falsch, und niemand hat das Nachsehen im Kalender.
Kosten des Nichtstuns
Nicht die ganze erste Zeile ist erreichbar, und der Fall wird stärker, wenn man das sagt. Die Regel qualifiziert etwa neun Zehntel des Angebotenen, und 11.880.000 € Volumen zwanzig Tage früher zu zahlen kostet 29.300 € an Liquidität. Übrig bleiben rund 237.600 € Skonto plus die Gebühren, verteilt in Bruchstücken auf neunhundert Lieferanten, und genau deshalb hat es nie ein Bericht gezeigt.
Darunter bewegen sich die Zinsen. Sie haben die richtige Antwort in den vergangenen Jahren zweimal verändert, die Zahlungskalender sind nicht mitgezogen; ein Unternehmen, das das so lässt, zahlt je nach Jahr entweder zu viel für Liquidität oder lässt Skonto liegen. Zugleich driftet der Lieferantenstamm weiter, und der Einkauf verhandelt weiter Skonto, das die Finanzabteilung nicht zieht, was vor der nächsten Verlängerung eine schwache Position ist.
Eine plausible Organisation mit realistischen Größenordnungen. Die Zahlen sind zum Nachrechnen mit Ihren Daten gedacht, kein Kundenergebnis.
Ein Distributor für Unterhaltungselektronik in Deutschland, Österreich und der Schweiz; rund 180.000.000 € im Jahr über die Kreditorenbuchhaltung an etwa 900 Lieferanten auf SAP S/4HANA, ein wöchentlicher Zahlungslauf, ein Treasury aus zwei Personen.
Etwa 1.300 offene Lieferantenposten im Monat erreichen den Lauf. Rund 12 % des Volumens, 21.600.000 € im Jahr, entfallen auf Lieferanten mit Skonto, meist 2 % bei Zahlung innerhalb von zehn Tagen gegen dreißig Tage netto.
Die Kreditorenbuchhaltung wählt fällige Posten aus, ergänzt Eskalationen von Hand, und der Treasurer vergleicht die Summe am Morgen des Laufs mit dem Bankstand. Skonto wird dort gezogen, wo die Bedingung im SAP korrekt ist, also in einer Minderheit der Fälle.
Niemand vergleicht den Skontotermin mit dem Laufkalender, und niemand vergleicht die Rechnungskonditionen mit dem Lieferantenstamm. Sechs Minuten Prüfen und Umsortieren je Posten beantworten keine der beiden Fragen.
Ein Roboter liest jeden Morgen offene Posten, Konditionen, Termine, Sperren und Freigabestatus, vergleicht die Rechnungskonditionen mit dem Stamm, wendet eine von CFO und Treasurer vereinbarte Regel an und schlägt den Lauf in Microsoft Teams mit Begründung je Position vor. Das Treasury gibt frei oder korrigiert; der Roboter bereitet den SAP-Zahlungsvorschlag vor.
Von 432.000 € jährlich angebotenem Skonto werden heute 151.200 € gezogen; die Regel qualifiziert rund 90 %, also 388.800 €, ein Zuwachs von 237.600 €. Ein um zwanzig Tage vorgezogenes Zahlen von 11.880.000 € Volumen kostet bei 4,5 % Kapitalkosten 29.300 €, und 16.800 € Verzugsgebühren entfallen. Der modellierte Nettowert liegt bei etwa 225.000 € im Jahr auf den genannten Anteilen, also Arithmetik und kein Kundenergebnis.
Vorgeschlagene Lösung
Wir bauen eine Zahlungsterminierung, die jeden Morgen auf SAP und auf der Treasury-Planung in ihrer heutigen Form läuft. Ein Roboter liest offene Lieferantenposten mit Konditionen, Skontoterminen, Sperren und Freigabestatus und vergleicht dann die auf der Rechnung gedruckten Konditionen mit denen im Lieferantenstamm. Weichen sie ab, legt er eine Stammdatenaufgabe an, statt das Skonto stillschweigend zu übergehen; die Bedingung wird im SAP korrekt und bleibt es für jede weitere Rechnung dieses Lieferanten.
Die Entscheidung selbst ist eine niedergeschriebene Regel und kein Modell. Ziehen Sie das Skonto, wenn sein Jahreswert Ihre Kapitalkosten übersteigt; sonst zahlen Sie zum Fälligkeitstag, nie später und nie früher ohne Grund. Ist die Liquidität knapp, greift die vom Treasurer festgelegte Priorität der Reihe nach: gesetzliche und lohnbezogene Posten, Strafen, Skonto nach Wert, strategische Lieferanten, der Rest. Jede Verschiebung bleibt mit ihrem Grund im Lauf, und genau das macht sie gegenüber einem Lieferanten und einem Prüfer vertretbar.
Das Treasury sieht das Ergebnis dort, wo es ohnehin arbeitet. Der vorgeschlagene Lauf kommt als Action-Center-Aufgabe in Microsoft Teams an, mit Summe, Valutadaten, gezogenem Skonto, verschobenen Posten und der Begründung je Ausnahme. Der Treasurer gibt frei oder korrigiert, der Roboter bereitet den SAP-Zahlungsvorschlag vor, und die Freigabe bleibt genau dort, wo sie heute liegt. Power BI führt das laufende Bild: Skonto angeboten, gezogen und verloren, Verzugsgebühren, Kreditorenlaufzeit und der Liquiditätsbedarf der kommenden Wochen.
SAP-Zahlungsbedingungen, offene Posten und Zahlungsvorschlag; UiPath Orchestrator mit Zeitplänen, Assets für die Regelparameter, Credential Store und Prüfpfad; UiPath Action Center Aufgaben, die in Microsoft Teams erledigt werden; Power BI mit semantischem Modell, Abonnements und Datenwarnungen
Den Konditionsvergleich und die daraus entstehende Stammdatenaufgabe; das Regelwerk zur Terminierung mit Priorität und Liquiditätsgrenzen; die Zusammenstellung des Vorschlags mit Begründung je Position; das Power-BI-Modell für Skonto, Gebühren, Kreditorenlaufzeit und wöchentlichen Liquiditätsbedarf
Offene Posten, Konditionen, Sperren und Vorbereitung des Zahlungsvorschlags in SAP S/4HANA über UiPath SAP activities (BAPI und OData); die Treasury-Planungsdatei über den UiPath Integration Service Connector für Microsoft OneDrive & SharePoint
So läuft der automatisierte Prozess
- AutomatisierungJeden Morgen liest ein Roboter offene Lieferantenposten aus SAP mit Konditionen, Terminen, Sperren und Freigabestatus
- AutomatisierungDie Rechnungskonditionen werden mit dem Lieferantenstamm verglichen; eine Abweichung erzeugt eine Stammdatenaufgabe, statt zu verschwinden
- SystemDie Regel entscheidet je Position: zahlen bis zum Skontotermin, wenn der Jahreswert des Skontos die Kapitalkosten übersteigt, sonst zum Fälligkeitstag und nie danach
- AutomatisierungBei knapper Liquidität greift die Priorität des Treasurers, und jede Verschiebung wird mit ihrem Grund aufgeführt
- MenschDer Vorschlag erreicht das Treasury als Action-Center-Aufgabe in Microsoft Teams: Summe, Termine, gezogenes Skonto, verschobene Posten, Begründung der Ausnahmen
- AutomatisierungNach der Freigabe bereitet der Roboter den SAP-Zahlungsvorschlag vor; die Freigabe selbst bleibt im Treasury unter der bestehenden Doppelkontrolle
- AutomatisierungPower BI aktualisiert Skonto angeboten, gezogen und verloren, Verzugsgebühren, Kreditorenlaufzeit und den künftigen Liquiditätsbedarf
Modell der menschlichen Beteiligung
Die Automatisierung übernimmt
- Das tägliche Lesen offener Posten, Konditionen, Termine, Sperren und Freigabestatus
- Den Vergleich der Rechnungskonditionen mit dem Lieferantenstamm und die daraus folgenden Korrekturen
- Die Anwendung der Regel Skonto gegen Kapitalkosten und der Priorität auf jede Position
- Die Zusammenstellung des Vorschlags mit Begründung und die Vorbereitung des SAP-Vorschlags nach Freigabe
Menschen entscheiden
- Über die Regel selbst: Kapitalkostensatz, Skontoschwelle und Reihenfolge der Prioritäten
- Über die Freigabe jedes Laufs und darüber, welche Posten bei knapper Liquidität verschoben werden
- Über Gespräche mit Lieferanten zu Konditionen, Eskalationen und strittigen Gebühren
- Ob eine vom Roboter gemeldete Stammdatenkorrektur richtig ist, bevor sich der Lieferantensatz ändert
Vorher und nachher
Systeme und Integrationen
Wo eine Regel reicht, nutzen wir kein Modell. Wo Urteilsvermögen nötig ist, entscheidet ein Mensch.
Eingaben
- offene Lieferantenposten und Zahlungsbedingungen in SAP
- der Lieferantenstamm
- die Treasury-Planungsdatei auf SharePoint
- Zins- und Gebührenbelege der Lieferanten
Automatisierungsebene
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Zielsysteme
- SAP S/4HANA Zahlungsvorschlag
- Stammdatenkorrekturen im SAP-Lieferantenstamm
- semantisches Power-BI-Modell
Menschliche Berührungspunkte: der Laufvorschlag als Action-Center-Aufgabe in Microsoft Teams; Stammdatenkorrekturen; die vierteljährliche Regelprüfung
Eingesetzte Technologien
tägliche Lesevorgänge und Regelausführung; Zeitpläne, Assets mit den Regelparametern, Credential Store, Prüfpfad
Aoffene Posten, Zahlungsbedingungen, Sperren und Vorbereitung des Zahlungsvorschlags
Ader Laufvorschlag als Aufgabe, die der Treasurer in Microsoft Teams erledigt, mit Entscheidungsnachweis
Adort gibt das Treasury frei, korrigiert, fragt zu einer Verschiebung nach und liest den Liquiditätsbedarf
Aliest die Treasury-Planungsdatei dort, wo sie heute liegt
ASkonto angeboten, gezogen und verloren, Verzugsgebühren, Kreditorenlaufzeit, künftiger Liquiditätsbedarf
Aunser Entwurf, abgestimmt mit CFO und Treasurer, versioniert als Orchestrator-Assets
CIllustratives Wirtschaftlichkeitsmodell
Beginnen Sie damit, die Annahmen zu hinterfragen.
Ein Rechner je Position kann Schreibtischarbeit bewerten und sonst nichts, also bewertet er hier genau diese: 1.300 offene Posten im Monat, die vor den vier Wochenläufen von Hand geprüft, hinterfragt und umsortiert werden, je sechs Minuten, gemischt über Kreditorenbuchhaltung und Treasury, zu 48 € Vollkosten je Stunde in diesem Markt. Der Skontotopf ist die größere Zahl und wird aus den in Abschnitt 05 genannten Anteilen modelliert: 432.000 € jährlich angeboten, 151.200 € heute gezogen, 237.600 € erreichbar gegen 29.300 € Kapitalkosten. Nichts davon wurde bei einem Kunden gemessen.
Rechnen Sie mit Ihren Zahlen
Eine illustrative Schätzung aus Ihren Eingaben. Sie modelliert freigesetzte Kapazität und verspricht keine Einsparung.
Geschäftlicher Nutzen
- Skontofenster werden eingehalten, weil der Termin das Zahldatum bestimmt und nicht der Kalender
- Verzugszinsen und Gebühren enden, weil nichts nach Fälligkeit gezahlt wird, sofern es niemand bewusst verschoben hat
- Das Treasury sieht jeden Morgen den Liquiditätsbedarf der kommenden Wochen, der Puffer lässt sich also an einem Plan bemessen
- Zahlungsbedingungen im Lieferantenstamm werden korrekt, sobald Abweichungen auffallen, was jede weitere Rechnung dieses Lieferanten repariert
- Der zinslose Kredit an Lieferanten endet: früh gezahlt wird dort, wo es etwas einbringt, und sonst nirgends
- Der Leiter der Kreditorenbuchhaltung verteidigt nicht mehr die Liste, sondern arbeitet an den Ausnahmen, die die Regel sichtbar macht
Die Sicht des Managements
- Die Zahl, die es nicht gab, wird zum Monatsbericht: Skonto angeboten, gezogen und verloren, je Lieferant und Buchungskreis
- Die Kreditorenlaufzeit wird zum gesteuerten Ergebnis einer niedergeschriebenen Regel statt zum Zufall des Laufkalenders
- Eine Änderung der Politik bei bewegten Zinsen ist eine Parameteränderung mit Freigabe dahinter und kein Projekt
- Jede Verschiebung hinterlässt einen Grund, den man einem Lieferanten, einem Prüfer oder dem Aufsichtsgremium zeigen kann
KPIs für die Geschäftsführung
Sicherheit und Governance
Wo die Daten liegen und wer sie sieht.
- Der Roboter schlägt vor und bereitet vor. Er gibt nie frei: die Freigabe bleibt im Treasury unter der Doppelkontrolle, die es in SAP und bei der Bank bereits gibt
- Jeder Vorschlag, jede Freigabe, jede Korrektur und jede Verschiebung wird mit Benutzer, Zeitstempel und Grund in den Action-Center-Nachweis geschrieben, also mit dem, wonach ein Prüfer fragt, wenn ein Lieferant zu spät bezahlt wurde
- Die Regelparameter, darunter Kapitalkostensatz und Priorität, liegen als Orchestrator-Assets mit Änderungshistorie; eine Änderung braucht die Freigabe des Treasurers und nicht den Nachmittag eines Entwicklers
- Das SAP-Servicekonto ist auf Kreditorenlesevorgänge und die Vorbereitung des Vorschlags begrenzt, sein Geheimnis liegt in einem externen Credential Store wie Azure Key Vault; Zugangsdaten von Personen werden mit keinem Roboter geteilt
- Bankdaten liegen außerhalb dieses Prozesses, der Lieferanten und offene Posten referenziert, nie Kontonummern; die Verarbeitung läuft in der EU-Region der UiPath Automation Cloud und in Ihrem Microsoft-365-Tenant
Warum jetzt
Die Zinsen haben sich in den vergangenen Jahren so bewegt, dass sich die richtige Antwort zweimal geändert hat, während die meisten Zahlungskalender aus einer Zeit stammen, in der sie anders lautete
Alles, was die Regel braucht, liegt bereits in SAP und in der Treasury-Planung; es fehlt etwas, das es jeden Morgen liest statt einmal pro Woche, während sich die modellierten 280.800 € an Skontofenstern in gleichmäßigem Tempo schließen
Die Freigabe im Treasury braucht weder Termin noch Postfach: eine in Microsoft Teams erledigte Aufgabe trägt Summe, Verschiebungen und Begründung
Relevante Führungsrollen
Verlorenes Skonto ist nicht länger unsichtbar, sondern eine berichtete Zahl, mit den Kapitalkosten daneben
Der Liquiditätsbedarf ist Tage im Voraus bekannt und jeder Lauf kommt bereits nach einer vereinbarten Regel geformt an, die Freigabe ist damit eine Durchsicht und keine Ermittlung
Die Zahlungsliste ist kein Streitfall mehr, und der Lieferantenstamm wird nebenbei korrekt
Häufige Fragen und Einwände
Die Regel zieht ein Skonto nur, wenn es Ihre eigenen Kapitalkosten übersteigt, und Liquiditätsgrenzen greifen in der von Ihnen gesetzten Priorität. Verschiebungen werden zu Entscheidungen mit Grund statt zum Standardergebnis eines vollen Donnerstags.
Ja, wenn die Bedingung im Lieferantenstamm gepflegt ist. Die Discovery zeigt meist, dass viele es nicht sind, und der Wochenkalender ignoriert Skontotermine ohnehin.
Er entscheidet auch nicht. Er schlägt mit angehängter Begründung vor, das Treasury gibt jeden Lauf frei wie heute, und die Freigabe bleibt unter derselben Doppelkontrolle.
Wann diese Lösung nicht passt
- Nur wenige Ihrer Lieferanten bieten Skonto und Verzugsgebühren sind selten, dann hat die Regel kaum etwas zu tun; die Discovery sagt das, bevor jemand etwas baut
- Ein Treasury-Management-System optimiert die Zahlungsterminierung bereits gegen die Planung und wird bei jedem Lauf tatsächlich genutzt
- Die Liquidität ist so knapp, dass jede Zahlung unabhängig vom Skonto verschoben wird; dann ist zuerst die Liquidität das Problem
Eine Frage für die nächste Sitzung
Der Einkauf hat in diesem Jahr Skontokonditionen im sechsstelligen Bereich verhandelt: Kann hier jemand sagen, wie viel davon die Finanzabteilung tatsächlich gezogen hat, und den Nachweis bis Freitag vorlegen?
Vorgehen bei der Umsetzung
Wir starten mit einem Ausschnitt und erweitern erst nach dem Nachweis.
Wir liefern
- Einen Vergleich aus der Discovery: zwölf Monate Rechnungskonditionen gegen den Lieferantenstamm, also Skonto angeboten, gezogen und verloren sowie gezahlte Verzugsgebühren
- Das Regelwerk zur Terminierung und die Priorität, niedergeschrieben und mit CFO und Treasurer abgestimmt
- Tägliche Lesevorgänge zu offenen Posten, Konditionen, Sperren und Freigabestatus sowie die Stammdatenaufgabe, wo Rechnung und Stamm auseinandergehen
- Die Zusammenstellung des Vorschlags mit Begründung je Position, geliefert als Action-Center-Aufgabe in Microsoft Teams
- Die Vorbereitung des SAP-Zahlungsvorschlags, an vergangenen Läufen getestet, bevor sie einen echten berührt
- Das Power-BI-Modell für Skonto, Gebühren, Kreditorenlaufzeit und wöchentlichen Liquiditätsbedarf
- Den Schattenbetrieb und danach die Übergabe mit Runbook und fester Regelprüfung
Wir benötigen von Ihnen
- Zwölf Monate gezahlter Posten mit Zahlungsbedingungen, Skontobedingungen und tatsächlichen Zahldaten
- Einen Treasurer als Eigentümer der Regel und einen benannten Prozessverantwortlichen in der Kreditorenbuchhaltung für Stammdatenkorrekturen
- Ein SAP-Servicekonto für Kreditorenlesevorgänge und die Vorbereitung des Vorschlags, in Test und Produktion
- Die Treasury-Planung in ihrer heutigen Form, die Excel-Datei eingeschlossen
Etappen
Discovery
Rechnungskonditionen mit dem Lieferantenstamm vergleichen, Skonto angeboten, gezogen und verloren beziffern, Verzugsgebühren zählen
Regelentwurf
Kapitalkostensatz, Skontoschwelle, Priorität bei knapper Liquidität, zulässige Verschiebungsgründe
Aufbau
Tägliche Lesevorgänge und Vergleiche, Vorschlagszusammenstellung, SAP-Vorbereitung, Teams-Aufgabe, Dashboard
Schattenbetrieb
Die Engine schlägt vor, das Treasury vergleicht mit dem eigenen Vorgehen, die Regel wird nachjustiert
Go-live
Der Vorschlag wird zur Arbeitsliste, freigegeben in Teams, begleitet über die ersten Läufe
Zinsprüfung
Eine feste Durchsicht von Kapitalkostensatz, Priorität und Lieferanten, deren Konditionen driften
Quick Win. Der Aufwand hängt davon ab, wie viele Buchungskreise und Währungen der Lauf umfasst, wie verlässlich die Zahlungsbedingungen im Lieferantenstamm sind und ob die Treasury-Planung in maschinenlesbarer Form vorliegt.
Ein am Mittwoch verfallenes Skonto ist mehr wert als die Woche bis zum Auffallen.
Schicken Sie uns zwölf Monate gezahlter Posten mit Zahlungsbedingungen und Zahldaten. Wir liefern Skonto angeboten, gezogen und verloren sowie die Verzugsgebühren zurück, als Ausgangswert, dem Sie widersprechen können.
Skonto-Basisanalyse anfordernDer Nachbarprozess hat meist dasselbe Problem
Schluss damit, die tägliche Cash-Zahl aus vier Bankportalen von Hand zu bauen; sie kommt spät und niemand traut ihr.
Lösung ansehen Weitere LösungenRechnungen gelesen, kontiert und automatisch weitergeleitetJemand tippt das PDF weiterhin ins ERP, rät die Kostenstelle und jagt dem Freigebenden hinterher.
Lösung ansehen Weitere LösungenPreis- und Mengenabweichungen am selben Tag geklärtEine unter Zahllaufdruck freigegebene Abweichung wird zum Preis des nächsten Quartals, verhandelt hat sie niemand.
Lösung ansehen Weitere LösungenLieferantenauszüge am Tag ihres Eingangs abgestimmtIhre Lieferanten schreiben monatlich, was sie zu bekommen glauben. Die meisten dieser Briefe liest niemand.
Lösung ansehen Case StudyRechnungsstreit ohne Eskalation — Case StudyEine strittige Rechnung ist keine Einzelaufgabe — sie ist eine Ermittlung: Bestellung, Lieferung, Vertrag, Korrespondenz.
Case Study ansehen Case StudyAutomatische Bearbeitung von P2P-AnfragenRechnungskopien, Status und Übersichten sofort geliefert — rund um die Uhr.
Case Study ansehenBranchen, in denen wir das am häufigsten umsetzenProduktion & IndustrieHandel & E-CommerceDienstleistungen & ITShared Services