Start · Lösungen · Weitere Lösungen
Lösung · Weitere LösungenEine Einmalkarte nach schriftlichen Regeln, geschlossen mit dem Ende des Zwecks
Virtuelle Karte oder Limitänderung binnen einer Stunde
Karten- und Limitanträge entstehen in Teams, werden gegen Ihre schriftliche Kartenrichtlinie geprüft, über die API der Kartenplattform ausgeführt und zum Enddatum geschlossen.
Kurzfassung für die Geschäftsführung
Limits steigen für eine Veranstaltung und sinken nie wieder, und Firmenkäufe zahlen Beschäftigte vom eigenen Konto.
Der Antrag beginnt dort, wo ohnehin gearbeitet wird.
Richtlinienkonforme Anträge werden binnen einer Stunde bedient, weil Prüfung und Portalarbeit nicht mehr auf eine anderweitig beschäftigte Person…
die Kartenplattform der Bank über ihre Ausstellungs-API; das Kartenregister; SAP für Kostenstellen
Geschäftsproblem
Ausgabensteuerung
Das Kartenprogramm hat eine Richtlinie. Sie regelt, wer eine Karte führen darf, welches Limit je Stufe gilt und welche Händlerkategorien gesperrt sind. Was der Richtlinie fehlt, ist ein Prozess, den jemand findet. Anträge auf eine virtuelle Karte oder ein befristetes Limit kommen als E-Mail an das Treasury-Postfach, als Teams-Nachricht an die Person, die zuletzt geholfen hat, oder als Anruf vom Flur.
Das Treasury macht danach jedes Mal dasselbe: klären, wer fragt, die Kostenstelle raten, eine Führungskraft um Zustimmung bitten, sich im Bankportal anmelden, die Karte anlegen, die Daten zurückschicken, eine Zeile im Register ergänzen und hoffen, an das Schließen zu denken. Die antragstellende Person wartet ein bis zwei Tage auf eine Fünf-Minuten-Handlung, also wird die Karte einer Kollegin oder das eigene Geld zum schnellsten Weg. Die Kontrolle verlässt die Kartenplattform und landet im Auslagenprozess, der den Kauf erst nachträglich sieht.
Der Grund, warum sich nichts ändert, ist die Größe der Einzelsache. Jeder Antrag ist klein, keiner rechtfertigt ein Projekt, und zusammen gehören sie niemandem. Derweil steigen Limits für eine Veranstaltung und bleiben oben, für einen Lieferanten ausgestellte Karten bleiben aktiv, und das Excel-Register entfernt sich Zeile für Zeile vom Kontoauszug.
Wie es heute läuft
- MenschJemand muss heute einen Lieferanten bezahlen und schreibt das Treasury an oder fragt eine Kollegin mit Karte
- MenschDas Treasury prüft, wer fragt, welche Kostenstelle gilt und ob der Betrag plausibel wirkt
- WartezeitEine Führungskraft wird per E-Mail um Bestätigung gebeten und antwortet zwischen Terminen, manchmal am nächsten Tag
- SystemDas Treasury meldet sich im Bankportal an und legt die virtuelle Karte an oder hebt das Limit von Hand an
- FehlerrisikoDie Kartendaten gehen per E-Mail oder Chat zurück, wo Zahlungsdaten im Verlauf stehen bleiben
- MenschIm Excel-Register entsteht eine Zeile mit dem Zweck, den die antragstellende Person geschrieben hat
- FehlerrisikoDas Limit bleibt angehoben und die Karte offen, bis es jemandem auffällt, oft erst bei der Jahresprüfung
Warum der heutige Prozess mehr kostet, als es aussieht
Diese Arbeit hat niemand geplant, sie ist entstanden.
- Die Treasury-Minuten sind hier der kleinste Teil. Der größere Posten ist das Obligo: Jedes für eine Veranstaltung angehobene und nie gesenkte Limit ist offener Kredit, den eine Phishing-Mail oder ein unachtsamer Klick ausgeben kann.
- Karten außerhalb eines Regelwerks sind Richtlinienabweichungen, die niemand freigegeben hat, unsichtbar, bis eine Prüfung Register und Kontoauszug nebeneinanderlegt und zwei verschiedene Unternehmen findet.
- Wer privat zahlt, finanziert das Unternehmen einen Monat lang vom eigenen Konto und erzeugt danach eine Erstattung, die geprüft, freigegeben, ausgezahlt und abgelegt werden muss. Sie existiert nur, weil die Karte langsam war.
- In einen Chat kopierte Kartendaten sind Zahlungsdaten in einem Kollaborationswerkzeug, aufbewahrt so lange, wie die Aufbewahrungsrichtlinie sagt, und für alle Beteiligten durchsuchbar.
- Fehlt die Fachkraft, die das Register führt, entstehen gar keine Karten, und jede solche Woche vergrößert die Umgehungswirtschaft, die die Richtlinie verhindern sollte.
Kosten des Nichthandelns
Der offene Kredit wächst hier durch Anhäufung und nicht durch Entscheidung. Niemand beschließt jemals, dass das Unternehmen ein größeres Kartenobligo tragen soll; es wächst einfach, Veranstaltungslimit für Veranstaltungslimit, weil das Anheben ein Antrag und das Absenken ein Gefallen ist. Kartenanträge folgen Veranstaltungen, Kampagnen, Freiberuflern und Abonnements, und alle vier wachsen schneller als ein Treasury-Team, sodass die Warteschlange länger wird und die Gewohnheit der Privatzahlung mit ihr.
Die Zeilen oben sind der Gehaltsanteil und der am wenigsten interessante. Ein einziger Phishing-Vorfall auf einer Karte, deren Limit für eine Messe angehoben und nie gesenkt wurde, kann mehr kosten als ein Jahr dieses Ablaufs, während sich die Prüfungsfeststellungen wiederholen: Das Register passt nicht zum Auszug, Freigaben von Abweichungen sind nicht dokumentiert, Karten werden nicht geschlossen. Nichts davon ist an einem einzelnen Tag dramatisch, und genau deshalb überlebt es.
Eine plausible Organisation mit realistischen Größenordnungen. Die Zahlen sind zum Nachrechnen mit Ihren Daten gedacht, kein Kundenergebnis.
Ein Medien- und Veranstaltungsunternehmen mit 900 Beschäftigten in Polen, Deutschland und Tschechien, mit einem Firmenkartenprogramm bei einer Bank, deren Kartenplattform eine API für virtuelle Karten und Limits bereitstellt. Auslagen laufen über SAP Concur, das Hauptbuch ist SAP.
Rund 380 Karten- und Limitanträge im Monat, überwiegend für Veranstaltungsanzahlungen, Werbekonten, Software-Abonnements und Reisebuchungen, bearbeitet von drei Treasury-Beschäftigten neben ihren übrigen Aufgaben. Etwa 140 Auslagenerstattungen im Monat betreffen Käufe, die auf eine Firmenkarte gehört hätten.
Anträge kommen per E-Mail, Chat und Telefon. Das Treasury prüft, fragt eine Führungskraft, arbeitet im Bankportal, schickt die Daten zurück und pflegt ein Excel-Register, das niemand abstimmt.
Rund 26 Minuten Treasury-Bearbeitung je Antrag, dazu ein bis zwei Tage Wartezeit für eine Fünf-Minuten-Handlung und kein verlässlicher Schließungsschritt; niemand kann sagen, wie viele virtuelle Karten heute offen sind.
Der Antrag entsteht in Teams, wird gegen die schriftliche Kartenrichtlinie geprüft, innerhalb der Richtlinie automatisch und außerhalb durch die Budgetverantwortung freigegeben, dann von einem Roboter über die API der Kartenplattform ausgeführt, mit Enddatum im Register erfasst und mit dem Ende des Zwecks automatisch geschlossen.
Im modellierten Fall werden richtlinienkonforme Anträge binnen einer Stunde bedient, jede Karte trägt ein Enddatum, das durchgesetzt und nicht erinnert wird, und das Register stimmt monatlich mit dem Kontoauszug überein. Das sind modellierte Größen, kein Kundenergebnis.
Vorgeschlagene Lösung
Der Antrag beginnt dort, wo ohnehin gearbeitet wird. Eine Adaptive Card in Microsoft Teams, bereitgestellt über die Workflows-App, fragt nach Zweck, Betrag, Lieferant, Kostenstelle, Dauer und danach, ob eine einmalige Nutzung reicht. Regeln aus Ihrer eigenen Kartenrichtlinie prüfen den Antrag gegen Limits je Stufe, gesperrte Händlerkategorien, Höchstdauern und die Rolle der antragstellenden Person. Innerhalb der Richtlinie wird sofort freigegeben. Außerhalb legt die Microsoft Teams Approvals-App den Antrag der Budgetverantwortung vor, oberhalb einer Schwelle zusätzlich dem Treasury, mit dem Grund der Abweichung auf der Karte.
Die Portalarbeit übernimmt ein UiPath-Roboter. Er ruft die Ausstellungs-API der Kartenplattform über einen Konnektor auf, den wir mit UiPath Integration Service Connector Builder bauen, legt die Einmalkarte mit dem freigegebenen Limit und Ablaufdatum an oder setzt das befristete Limit und schreibt den Datensatz in das Kartenregister in UiPath Data Fabric: Zweck, Verantwortung, Kostenstelle, Limit, Enddatum, Freigabereferenz. Die Karte erhält die antragstellende Person in der App des Ausstellers. Kartennummern laufen nie durch Teams oder E-Mail, und der Roboter muss sie nicht lesen.
Was heute vom Gedächtnis abhängt, wird ein geplanter Job. Zum Enddatum oder nach der einmaligen Nutzung schließt der Roboter die Karte oder stellt das ursprüngliche Limit wieder her, informiert die Verantwortlichen und aktualisiert das Register. Ein monatlicher Auszug speist Power BI und den Abgleich mit dem Kontoauszug, sodass das offene Obligo eine ablesbare Zahl ist. KI kommt hier nirgends vor: Die Regeln sind die Richtlinie, ausformuliert und versioniert.
Adaptive Cards über die Workflows-App in Microsoft Teams (Power Automate); Microsoft Teams Approvals-App mit Purview-Audit; Warteschlangen, Zeit-Trigger, Credential Store und Job-Audit in UiPath Orchestrator; Entitäten in UiPath Data Fabric für das Kartenregister; UiPath Integration Service Connector Builder
Die Antragskarte und ihre Prüfungen, das Regelwerk der Richtlinie mit Limits, Dauern, Kategorien und Schwellen, die Ausstellungs- und Limitroboter, den Ablauf- und Wiederherstellungsjob, das Modell des Kartenregisters, den Abstimmungsauszug, die Power BI-Sicht auf das Obligo und das Betriebshandbuch für das Treasury
Die Ausstellungs-API der Kartenplattform über einen mit UiPath Integration Service Connector Builder gebauten Konnektor, beschränkt auf Anlegen, Limit setzen und Schließen; Kostenstellenabfragen aus SAP; der monatliche Kontoauszug für den Abgleich
So läuft der automatisierte Prozess
- MenschDie antragstellende Person füllt den Kartenantrag auf einer Adaptive Card in Teams aus: Zweck, Betrag, Lieferant, Kostenstelle, Dauer
- AutomatisierungRegeln prüfen den Antrag gegen die Kartenrichtlinie: Limit je Stufe, Händlerkategorie, Höchstdauer, Rolle
- MenschAnträge außerhalb der Richtlinie gehen an die Budgetverantwortung in der Microsoft Teams Approvals-App, oberhalb der Schwelle an das Treasury
- AutomatisierungEin Roboter stellt die virtuelle Karte aus oder setzt das befristete Limit über die API der Kartenplattform
- AutomatisierungDas Register erhält Zweck, Verantwortung, Kostenstelle, Limit, Enddatum und Freigabereferenz
- SystemDie antragstellende Person wird benachrichtigt und holt die Karte in der App des Ausstellers; keine Kartennummer läuft durch Teams
- AutomatisierungZum Enddatum oder nach der einmaligen Nutzung schließt der Roboter die Karte oder stellt das ursprüngliche Limit wieder her
- AutomatisierungEin monatlicher Auszug stimmt das Register gegen den Kontoauszug ab und speist die Power BI-Sicht auf das Obligo
Zusammenspiel von Mensch und Automatisierung
Die Automatisierung übernimmt
- Prüfungen zu Limit, Dauer, Händlerkategorie und Rolle der antragstellenden Person
- Die Freigabe von Anträgen innerhalb der schriftlichen Richtlinie, mit Vermerk der angewandten Regel
- Ausstellung, Limitänderung, Schließung und Limitwiederherstellung über die API der Kartenplattform
- Das Register, die Benachrichtigung und den monatlichen Abstimmungsauszug
Menschen entscheiden
- Jeden Antrag, den die Richtlinie nicht abdeckt, auf Ebene Budgetverantwortung und Treasury
- Änderungen an den Regeln selbst: Limits, Dauern, gesperrte Kategorien, Schwellen
- Den Widerruf bei Missbrauchsverdacht, jederzeit und ohne Roboter
- Die Ausnahmen, die der monatliche Abgleich aufwirft
Vorher und nachher
Systeme und Integrationen
Wo eine Regel reicht, nutzen wir kein Modell. Wo Urteilsvermögen nötig ist, entscheidet ein Mensch.
Eingänge
- die Antragskarte in Microsoft Teams
- das gemeinsame Treasury-Postfach in Exchange Online für weiterhin per E-Mail eingehende Anträge
- Kartenrichtlinie und Kostenstellenliste
Automatisierungsschicht
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service (Connector Builder)
- UiPath Data Fabric
Zielsysteme
- die Kartenplattform der Bank über ihre Ausstellungs-API
- das Kartenregister
- SAP für Kostenstellen
- SAP Concur auf der Auslagenseite
Berührungspunkte für Menschen: die Microsoft Teams Approvals-App für Abweichungen; der Widerruf durch das Treasury aus dem Register; die monatliche Prüfung des Abgleichs
Eingesetzte Technologien
Antragsformular, Regelantwort und Statusmeldungen
AEntscheidungen von Budgetverantwortung und Treasury zu Anträgen außerhalb der Richtlinie, auditiert in Microsoft Purview
Ader Konnektor zur Ausstellungs-API der Kartenplattform, beschränkt auf Anlegen, Limit und Schließen
AAusstellungs- und Ablaufjobs, Warteschlangen, Wiederholungen, Credential Store und Job-Protokoll
Adas Kartenregister: Zweck, Verantwortung, Kostenstelle, Limit, Enddatum, Freigabereferenz
Aoffene Karten, offener Kredit, Abweichungen je Abteilung und die Lücke zwischen Register und Auszug
ALimits je Stufe, Höchstdauern, gesperrte Händlerkategorien, Freigabeschwellen
CIllustratives Wirtschaftlichkeitsmodell
Beginnen Sie damit, die Annahmen zu hinterfragen.
Die Rechnung unten ist eine Untergrenze und nicht der Nutzenfall, denn Obligo, vermiedene Missbrauchsschäden und Wartezeit der Beschäftigten bleiben außen vor; keines davon lässt sich ohne Ihre eigene Schadenhistorie ehrlich bepreisen. Der Rechner zählt nur Treasury-Minuten, und sein Volumen ist der automatisierbare Anteil von 0,7 aus 380 Anträgen und nicht die ganze Warteschlange, zu je 26 Minuten und 41 € Vollkosten je Stunde. Daneben stehen vermiedene Auslagen: 140 Erstattungen × 14 Minuten × 0,6 ergeben rund 20 Stunden Buchhaltungsarbeit im Monat zu 33 €, etwa 7.900 € im Jahr, womit der gesamte Pool bei rund 64.500 € liegt. 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
- Richtlinienkonforme Anträge werden binnen einer Stunde bedient, weil Prüfung und Portalarbeit nicht mehr auf eine anderweitig beschäftigte Person warten
- Der offene Kredit sinkt und bleibt bekannt, denn jede Karte trägt ein Enddatum und jedes befristete Limit stellt ein Job wieder her, nicht das Gedächtnis
- Auslagenerstattungen gehen zurück, weil die Firmenkarte zum schnellsten statt zum langsamsten Zahlweg wird
- Zahlungsdaten verlassen E-Mail und Chat vollständig: Die Karte kommt über die App des Ausstellers, das Register führt nur Kennungen
- Freigaben von Abweichungen werden zu Nachweisen, festgehalten am Antrag mit der gebrochenen Regel und der Person, die sie akzeptiert hat
- Das Treasury ist nicht länger die menschliche Schnittstelle zwischen Beschäftigten und Bank und kann sich um Liquidität statt um Kartenverwaltung kümmern
Sicht der Geschäftsleitung
- Das offene Obligo ist in einer Minute beantwortbar: wie viele Karten leben, wem sie gehören, was sie ausgeben dürfen und wann sie ablaufen
- Nach Abteilung und Zweck gezählte Anträge zeigen, wo die Richtlinie zur Wirklichkeit passt und wo sie umgangen wird
- Register und Kontoauszug nähern sich an, sodass der monatliche Abgleich von der Ermittlung zur Kontrolle wird
- Die Verantwortung ist ausgesprochen: Das Treasury besitzt die Regeln, die Budgetverantwortung besitzt die Abweichungen, und der Roboter macht unter beiden die Portalarbeit
KPIs für die Geschäftsführung
Sicherheit und Governance
Ein Prüfer sollte jede Entscheidung nachvollziehen können.
- Kartennummern verlassen die Plattform des Ausstellers nie. Der Roboter arbeitet mit einer Kartenkennung und den letzten vier Ziffern, und die Karte wird in der App des Ausstellers abgeholt
- Die API-Zugangsdaten liegen im Credential Store des Orchestrators oder in Azure Key Vault, beschränkt auf Anlegen, Limit setzen und Schließen, ohne Recht auf vollständige Kartendaten
- Niemand kann den eigenen Antrag freigeben, und das Treasury kann jede Karte aus dem Register heraus jederzeit widerrufen, ohne auf einen Job zu warten
- Jede Regeländerung ist versioniert, und jede Ausstellung, Limitänderung und Schließung steht mit der zugehörigen Freigabereferenz im Protokoll des Orchestrators
- Die Verarbeitung läuft in der EU-Region der UiPath Automation Cloud und innerhalb der Microsoft 365 EU Data Boundary; personenbezogene Daten beschränken sich auf Identität und Kostenstelle
Warum jetzt
Kartenplattformen, die früher nur ein Portal boten, stellen heute Ausstellungs-APIs bereit, und erst das macht den Weg vom Antrag zur Karte automatisierbar; klären Sie das zuerst mit Ihrer Bank
Prüferinnen und Prüfer verlangen zunehmend das Kartenregister neben dem Kontoauszug, und ein in Excel geführtes Register beantwortet diese Frage in keine Richtung
Allein die Treasury-Bearbeitung kostet im Modell rund 4.700 € im Monat und ist der unwichtigste Teil des Falls; schwerer wiegt das Obligo, das sich währenddessen aufbaut
Relevante Führungsrollen
Kartenausgaben folgen Regeln, das offene Obligo ist jederzeit bekannt, und Erstattungen für Firmenkäufe hören auf, normal zu sein
Das Team macht keine Portalarbeit mehr, das Register stimmt mit der Bank überein, und jedes Limit hat ein Enddatum, das sich selbst durchsetzt
Kleine Käufe wandern auf einen kontrollierten Kartenweg, statt dem Einkauf vollständig aus dem Blick zu geraten
Häufige Fragen und Einwände
Das tut es, für das Treasury-Team. Die Lücke ist alles darum herum: Antrag, Richtlinienprüfung, Freigabe, Register und Schließung. Das Portal leistet nichts davon, also geschieht es von Hand oder gar nicht.
Automatisch freigegeben werden nur Anträge innerhalb einer schriftlichen Richtlinie, mit denselben Limits, die das Treasury von Hand setzen würde. Jeder wird mit der zulassenden Regel protokolliert, und jede Karte ist im Moment widerrufbar.
Wir auch nicht. Teams trägt den Antrag und die Freigabe. Die Karte selbst kommt über die App des Ausstellers und erscheint nie in einem Chat, was eine Verbesserung gegenüber heute ist.
Wann diese Lösung nicht passt
- Die Kartenplattform bietet keine Ausstellungs-API; die Portalarbeit müsste über die Oberfläche laufen, was möglich, aber weniger stabil und gegenüber einer Prüfung schwerer zu vertreten ist
- Eine Ausgabenplattform mit eigenem Antragsworkflow ist bereits lizenziert und im Einsatz; die Arbeit liegt dort bei der Akzeptanz, nicht bei einem zweiten Workflow
- Weniger als ein paar Dutzend Anträge im Monat, wo eine schriftliche Richtlinie und ein einfaches Teams-Formular den Großteil der Wartezeit bereits nehmen
Eine Frage für die nächste Sitzung
Würde dieses Unternehmen eine virtuelle Karte bemerken, die ihren Zweck überlebt hat, und wenn ja, in welchem Monat und durch wessen Bericht?
Vorgehen bei der Umsetzung
Wir starten mit einem Ausschnitt und erweitern erst nach dem Nachweis.
Wir liefern
- Die Kartenrichtlinie als testbares Regelwerk, Zeile für Zeile mit dem Treasury abgestimmt
- Einen Konnektor zur Ausstellungs-API Ihrer Kartenplattform, gebaut und gegen deren Sandbox getestet
- Die Antragskarte in Teams, ihre Prüfungen und den Abweichungsweg in die Approvals-App
- Die Roboter für Ausstellung, Limitänderung und Ablauf, mit Wiederholungen und Fehlerbehandlung
- Das Modell des Kartenregisters, den monatlichen Abstimmungsauszug und die Power BI-Sicht auf das Obligo
- Einen Pilot in der Abteilung mit den meisten Anträgen, danach Ausweitung über Regeln statt über Code
Wir brauchen von Ihnen
- Die Kartenrichtlinie schriftlich und eine Treasury-Verantwortung, die Regelfragen entscheidet
- API-Zugang von Ihrer Bank, mit Sandbox-Zugangsdaten und den Berechtigungen, die der Roboter braucht
- Die Kartenanträge eines Monats und das heutige Register
- Die Kostenstellenliste und die Freigabeschwellen, die oberhalb der Richtlinie gelten sollen
Etappen
Analyse
Die Richtlinie und ein Monat Anträge; die meisten erweisen sich als Varianten von fünf Zwecken
Regeln
Limits je Stufe, Höchstdauern, gesperrte Kategorien, Schwellen und die Grenze der automatischen Freigabe
Aufbau
Konnektor, Antragskarte, Ausstellungs- und Ablaufroboter, Register, Abstimmungsauszug
Validierung
Sandbox-Tests für Ausstellung, Limitänderung und Schließung, danach Abnahme durch das Treasury
Pilot
Eine Abteilung mit hohem Volumen parallel zum alten Weg
Rollout
Weitere Abteilungen und Länder, durch zusätzliche Regeln statt zusätzlicher Workflows
Quick Win. Der Aufwand hängt fast ausschließlich an der API der Kartenplattform und ihrer Sandbox; der Teams- und Regelteil ist klein, und am längsten dauert meist die Diskussion über die Richtlinie.
Das Limit für die Messe im vergangenen Frühjahr ist bis heute angehoben.
Senden Sie uns Ihre Kartenrichtlinie und die Kartenanträge des letzten Monats. Sie erhalten den Anteil zurück, der nach Ihren eigenen Regeln binnen einer Stunde ausgestellt worden wäre, und die Anträge, die Ihre Richtlinie gestoppt hätte.
Karten benennen, die heute zu schließen wärenDer Nachbarprozess hat meist dasselbe Problem
Kartenausgaben werden Wochen nach der Buchung abgeglichen, kontiert und geprüft, und Belegen läuft man ewig hinterher.
Lösung ansehen Weitere LösungenBedarf in Teams gemeldet, Bestellung noch am selben TagDer vorgeschriebene Weg ist langsamer als eine Chat-Nachricht, also wird zuerst bestellt und danach dokumentiert.
Lösung ansehen Weitere LösungenSpesenfreigaben in Teams samt fertiger RichtlinienprüfungFreigaben warten bis zum Monatsende in der Mailbox, und die Richtlinienfrage wird erst nach dem Klick beantwortet.
Lösung ansehenBranchen, in denen wir das am häufigsten umsetzenProduktion & IndustrieDienstleistungen & IT