Finance Function i drä Era vo Agentic AI

Stell dir vor, dis Finance-Team isch grad am Month-End Close. D Zahle sind scho im ERP, aber es gid no Entitäte, wo ihri Date nöd gschickt händ, Kontene mit Varianze, wo no nöd erkläärt sind, und en Mail-Bärg, wo me d Status vo verschidene Controller verfolge muess. Das isch es Bild, wo i vilne Firme bekannt isch. De Prozess widerholt sich, d Deadline sind knapp, d Kontrolle sind formell, und d Uswirkig uf d Qualität vom Betrieb isch sofort spürbar. Bisher isch d Lösig e Teilautomatisierig gsi: Workflow-Engine, RPA, Dashboard und es bitzeli Copilot zum Entwürf mache. Das hät ghulffe, aber s het d Art, wie Finance schafft, nöd grundlegend veränderet.

Jetz fangt d Frog a, sich z verschiebe. Nümm "Wie mache mer Finance-Ufgabe schnäller?", sondern "Wie gstalte mer d Finance-Operatione neu, dass digitali Arbeiter de Close, d Reconciliation, s Invoice-Handling und s Reporting chönd mache, ohni d Kontrolle kabutt zmache?" Das isch wichtig, wil Finance kei Gebiet isch für wildi Experiment. En Agent im Finance dörf kei "gschider Assischtänt" sii, wo überzügendi Antworte git, aber nöd prüefbar isch. Wenn me ne i dere Funktion bruucht, muess de Agent als Teil vo eme disziplinierte Operating Model schaffe: verbunde mit em ERP und andere System, underworfe vo Policy und Thresholds, wo en Evidence Pack produziert, und de Mönsch a de richtige Stell für s Urteil laht.

Wiso Finance en starchi Kandidatin isch

Finance isch eins vo dene Enterprise-Domän, wo am beste für en agentische Aasatz passt, grad wil s strukturiert isch, aber nöd ganz eifach. Uf de einte Site hät Finance vil Wiederholigsarbeit: Transaktione abgliche, Dokumänt uf Vollständigkeit prüefe, d Ursach vo Mismatch finde, Varianze erkläre, Prozess-Owner erinnere und Usnahme a die richtige Lüt wiiterleite. Uf de andere Site isch Finance voll vo Kontrolle: es gid en Approval-Matrix, Segregation of Duties, Materiality-Thresholds, en Audit-Trail und es Bedürfnis nach Dokumentation, wo vil höcher isch als i vilne andere Funktion.

Die Kombination macht Finance interessant. Vil vo sine Aktivitäte sind klar gnue, dass en Agent chönt hälfe, aber si müend nöd sofort voll automatisiert werde. Das nennt me bounded autonomy: de Agent cha läse, vergliche, Empfählige vorbereite und d Nochverfolgig orchestriere, während de Mönch s Urteil, d Genehmigung und d letscht Verantwortig bhaltet.

Wenn mer gnauer lueget, isch vil vo de Finance-Arbeit eigentli nöd "Zähle usrächne", sondern Usnahme und Kontext manage. Beim Close-Prozess sind d Zahle scho im System, aber s Team muess no prüefe, weli Iigäng fähle, nach verspötete Entitäte sueche, verstah, weli Kontene abwiiche, Erklärige vom Business Controller verlange und denn e Gschicht zämmestelle, wo starch gnue isch für d Prüefig. Bi de Reconciliation cha s System d Mismatch zeige, aber öpper muess d Ursach finde, d Transaktionsquelle vergliche, de Timing-Unterschiid prüefe und en Vorschlag für en Journal oder d Nochverfolgig vorbereite. Beim Invoice-Processing händ OCR und alte Workflow vilicht scho en Teil gmacht, aber d Usnahme sind immer no hoch, wenn es Mismatch bim PO, Goods Receipt, Steuerproblem, Vendor-Anomalie oder Policy-Abwiichig git.

All das sind Beriich, wo Agentic AI nützlicher isch als statischi Automatisierig. En Agent cha Date us mehrere System hole, Policy und Fallhistorie läse, d Ursach vo Usnahme dänne, en Entwurf für d Aktion vorbereite und nur denn eskalieren, wenns nötig isch.

Wiso Finance nöd uf "volli Autonomii" warte muess

Vili Finance-Füehrigslüt sind skeptisch, wil si denke, Agentic AI heisst, d Entscheidig de Maschine z überlah. Das isch en falsche Rahme. Für Finance chunt de gröschti Wert am Afang vo eme konservativere Modell: de Agent als Close-Überwacher, als Mismatch-Untersuecher, als Vorbereiter vo Evidence und Entwürf, nöd als Endentscheider. Die Aasatz passt besser zur Realität vo de Finance-Funktion. D Kontrolle vom Mönsch verschwindet nöd, aber di manuell, repetitiv Schwerarbeit wird weniger. S Finance-Team cha sich vo administrative und sich widerholende Nochverfolgige wegbewege zu Analyse, Kontroll-Urteil, Root-Cause-Lösige und Business Partnering.

Au wenns verspricht, sind nöd all Finance-Beriich würdig als Startpunkt. En agentische Muster isch weniger passend, wenn de Grundprozess sälber no nöd stabil isch, d Chart of Accounts und d Date-Definitione no duränand sind, d Accounting-Policy nöd guet dokumentiert isch, oder d Organisation kei disziplinierti Approval- und Audit-Trail-Kultur hät. I so eme Fall wird de Agent nur d Verwirrig beschlünige, wo scho da isch. Finance brucht e gnueg riifi Prozess- und Date-Grundlag, bevor me em Agent e operativi Rolle git.

Drei Haupt-Use-Cases: Close, Reconciliation und Invoice

Für vili Firme sind die drei Use-Cases am sinnvollste als Startpunkt: Close Agent, Reconciliation Agent und Invoice Agent. Alli drei händ en reale Arbeits-Umfang, en klare Business-Value und gnueg Ruum für bounded autonomy.

1. Close Agent: vom Close-Kalender zur Close-Orchestrierig

I vilne Organisatione isch de Month-End Close no starch uf manuelli Koordination aagwise: Spreadsheet-Tracker, Mail-Nochverfolgig, Status-Meetings und s Nachjage vo Iigäng vo verschiedene Entitäte oder Funktion. En Close Agent cha als operativ Orchestrator für dä Prozess diene.

Praktisch gsee cha de Close Agent d Close-Tasks und Friste überwache, prüefe, weli Iigäng us em ERP, Subledger oder Konsolidierigstool no fähle, Kontene oder Entitäte mit unübliche Varianze markiere, verspöteti Prozess-Owner erinnere, unterstützendi Evidence sammle und en Entwurf für de Kommentar für de Reviewer vorbereite. Zum Bischpil: e Gruppe mit mehrere Entitäte hät en Close-Prozess, wo AP, AR, Inventory, Payroll und Accrual umfasst. De Close Agent prüeft, ob alli Feed igange sind, entdeckt, dass ei Entität d Intercompany-Eliminierig no nöd abgschlosse hät, und eskaliert de Bottleneck zum regionale Controller. Gliichzitig bereitet de Agent e Liste vo de Kontene mit de grösste Varianze vor und zieht d Kommentar-Historie vom letschte Monet als erschte Kontext.

De Hauptwert vom Close Agent isch nöd eifach "de Close automatisch mache", sondern d Zit z reduziere, wo für s Nachjage verlore goht, Blind Spots bi Bottlenecks z verringere, d Qualität vo de Varianz-Erklärige z verbessere und d Prüefig meh ufs Urteil z konzentriere, statt uf s Date-Sammle. De Close Agent isch aber für d Überwachig, d Evidence-Zämmestellig und d Entwürf geeignet. Er isch nöd geeignet, um materielli Accounting-Entscheidige autonom z treffe. Wenn es um Sache wie Revenue Recognition, Impairment, Reserve-Urteil oder wichtigi Accounting-Interpretatione goht, muess de Mönsch de Entscheider blibe.

2. Reconciliation Agent: vo de Mismatch-Erkennig zur Root-Cause-Vorbereitig

Reconciliation isch es klassischs Gebiet, wo oft voll manuelli Arbet isch. Es System cha zeige, dass zwei Quelle nöd zämmepassed, aber d Ursach vom Mismatch z finde, brucht immer no Zit. Da bringt de Reconciliation Agent sin Wert.

Dä Agent cha Transaktione zwüsched Quelle vergliche, Mismatch nach Muster gruppiere, Timing-Differenze vo echte Fähler unterscheide, mögliche Ursache sueche wie fählendi Buechige, Doppelbuechige, Währigsproblem oder Mapping-Fähler, und denn en Vorschlag für en Journal oder e korrektivi Massnahm vorbereite, wo de Mönsch aluegt. Bi de Bank-Reconciliation verglicht de Agent d Cash-Bewegige im ERP mit em Bank-Statement, findet es paar Poste, wo no nöd klar sind, und gruppiert si, weli woorschinli usstehendi Timing-Differenze sind und weli wie en Buechigsfähler usgsehn. Für bestimmti Poste bereitet de Agent en Journal-Vorschlag vor, komplett mit Referenz uf d Quelltransaktion. Es anders Bischpil isch d Intercompany-Reconciliation: de Agent verglicht AR/AP zwüsched Entitäte, markiert Mismatch wäge Unterschied bim Cut-Off, und bereitet e Liste vo Usnahme vor, wo würkli vom Controllership-Team müend besproche werde.

Reconciliation isch nöd nume s Abgliche. Es goht au drum, Muster z läse, d Historie z verfolge, mehreri Quelle z verbinde und Hypothesen über d Ursach vorzbereite. Statischi Automatisierig hört oft bi "Match / No Match" uf. En agentische Muster cha wiiter goh zur Usnahme-Untersuechig. Je grösser d Autonomii vom Agent bim Vorbereite vo Journal-Vorschläg isch, desto wichtiger isch d Kontrolle über d Quell-Date, de Confidence-Level, d Materiality und de Approval-Pfad. Für Mismatch mit nidrigem Wert und sehr klarem Muster isch de Agent vilicht sicher gnue, um en Korrektur-Entwurf z mache. Für materielli Poste oder mehrdütigi Muster sött de Agent bi de Empfählig und de Evidence stoppe.

3. Invoice Agent: vom Capture zum Policy-bewusste Processing

Vili Organisatione bruuche scho OCR oder Invoice-Workflow. Aber d Usnahme sind immer no e grossi Lascht, vor allem im AP. En Invoice Agent cha über d Dokumänt-Extraktion usegoh.

Dä Agent cha d Rächnig läse, wichtigi Fälder extrahiere, d Rächnig mit PO und Goods Receipt abgliche, de Vendor, d Steuer und d Zahligs-Policy validiere, prüefe, ob es Abwiichige vom Vertrag oder Threshold git, und denn d passendi Genehmigung oder Eskalation vorbereite. Zum Bischpil: e Rächnig vomene chunt ohni klar PO-Referänz. De Agent prüeft d Vendor-Historie, aktivi Verträg und d Uusgabekategorie und folgeret, dass d Rächnig woorschinli zu eme wiederkehrende Service ghört, wo en bestimmte Vertrag brucht. De Agent markiert d Policy-Abwiichig, bereitet e Zämmefassig vom Fall vor und leitet si a de richtige Approver wiiter. I eme andere Fall stimmt d Rächnig mit PO und Goods Receipt überii, de Wert isch nidrig, de Vendor isch nidrigs Risiko, und es git kei Anomalie. I eme riifere Design cha de Agent en Straight-Through-Weg mit vorher festgleite Kontrolle vorbereite.

Wenn de Vendor-Master schlecht isch, d PO-Disziplin nidrig isch, oder vil Chäuf usserhalb vom offizielle Prozess gmacht werde, wird de Invoice Agent immer wider mit strukturelle Usnahme konfrontiert. I so eme Fall isch de Agent immer no nützlich für s Triage, aber me sött nöd uf en höche Touchless-Processing hoffe, bevor d Prozess-Disziplin im Procurement und AP verbesseret isch.

Kontrolle und Audit: Hauptbedingig, nöd en Zuesatz

Im Finance wird d Qualität vom Agent nöd gnueg dermit gmesse, wie oft er "rächt" hät. Wichtiger isch, ob jedi Empfählig oder Aktion verantwortet werde cha. Drum müend Finance Agents mit Kontrolle und Auditability als Kern-Design baut werde.

Evidence Pack für jedi Empfählig

Jedes Mal, wenn en Agent e Empfählig git oder e Aktion vorbereitet, sött er en Evidence Pack produziere, wo gnueg isch, dass en Mönsch oder en interne Prüfer en aluege cha. De Inhalt vom Evidence Pack umfasst normalerwis d Quell-Date, wo bruucht worde sind, s Referenz-Dokumänt oder d Referenz-Transaktion, d Policy oder d Regle, wo prüeft worde sind, e Zämmefassig vom Grund für d Empfählig, de Confidence-Level oder d Sicherheit, und de Status vo de nötige Genehmigung. Bi de Reconciliation, wenn de Agent en Journal-Vorschlag macht, sött de Reviewer d Quell-Transaktion, d Mismatch-Logik, d betroffene Kontene und de Grund gseh, wiso de Vorschlag entstanden isch. Bi de Rächnig, wenn de Agent e Rächnig als verarbeitbar markiert, sött de Approver s Ergebnis vom Three-Way Match, de Vendor-Status, d Policy-Prüefig und de Grund gseh, wiso de Fall als nidrigs Risiko oder Usnahm gilt. Ohni Evidence Pack wird de Agent nume en Suggestion-Generator. Das isch nöd gnueg für Finance.

Approval Threshold müend uf Risiko basiere

D Genehmigung für Finance Agents sött nöd nume vo "erlaubt oder nöd erlaubt" abhänge. Passender isch en Threshold, wo uf mehrere Faktore basiert: de Transaktionswert, de Confidence vom Agent, s Vendor-Risiko, d Materiality, d Art vom Konto oder Prozess, und ob es Muster vom Fall scho bekannt isch oder neu. Es gsunds Design-Bischpil: e Rächnig mit nidrigem Wert, eme vertrauenswürdige Vendor, eme vollständige Three-Way Match und höchem Confidence cha uf eme leichte Genehmigigsweg laufe; e Rächnig mit höchem Wert oder eme neue Vendor muess voll vom Mönsch prüeft werde; en Journal-Vorschlag für es nidrig-materiells Konto cha vo eme Analyst prüeft werde; en Vorschlag, wo es materiells Konto oder es Urteilsgebiet betrifft, muess zum Controller ufe. Die Aasatz isch realistischer, als alli Fäll gliich z behandle.

Audit Trail muess di ganz Entscheidigskette verbinde

De Audit Trail für en Finance Agent sött nöd nume s End-Ergebnis speichere. Er muess d Quell-Date, d Schritt vom Tool/API, wo ufgruefe worde sind, d Policy-Prüefig, e Zämmefassig vo de Überlegige, d Genehmigung oder s Override vom Mönsch, und s End-Ergebnis, wo is System cho isch, verbinde. Das isch us drei Gründ wichtig. Erstens, interni Kontrolle: s Finance-Team muess chönne verfolge, wiso e bestimmti Aktion passiert isch. Zweitens, Auditability: de interni Audit oder de externi Prüfer muess gseh, dass de Agent innert prüefbare Grenze schafft. Drittens, kontinuierlichi Verbesserig: wenn de Agent en Fähler macht, muess d Organisation chönne verstah, ob s Problem bi de Date, de Policy, de Integration oder em Workflow-Design liit.

En hüfige Fähler isch, mit de Ambition vom "Touchless Finance" aazfange, ohni delegated Authority, Segregation of Duties, en Policy Engine und Observability vorbereitet z ha. Für Finance isch en gsündere Ablauf: mit Läse, Überwache und Entwürf aafange, denn zu Empfählige mit Evidence ufstige, und nur i bestimmte Beriich zu "Execute with Approval" oder "Execute with Monitoring" übergoo. Wenn me d Räiefolg umchehrt, bricht s Vertraue schnäll zäme.

Realistischi Ergebnis: Nöd Finance ohni Mönsch

Di wenig hilfrichsti Gschicht für d Finance-Funktion isch, dass Agentic AI "s Finance-Team ersetze" wird. Realistischer und nützlicher isch, d Veränderig vo de Ergebnis und d Veränderig vo de Rolle aluege.

En realistische Ziilwert für en Finance-Pilot umfasst normalerwis en schnällere Cycle Time bim Close, en chlinere Backlog vo Usnahme, weniger manuelli Nochverfolgig, besseri Qualität vo de Varianz-Erklärige und e Prüefig, wo sich meh uf materielli Poste konzentriert. Das sind Ergebnis, wo s Controllership, d Shared Services und s Business Finance direkt spüre. Beim Close verbringt de Controller nümm vil Zit mit Status-Jage und Evidence-Sammle, sondern konzentriert sich uf d Kontene, wo würkli es Urteil bruuche. Im AP versinkt de Analyst nümm i eifache Invoice-Usnahme, sondern behandlet Fäll, wo würkli e Policy-Interpretation oder Koordination mit Procurement und Vendor bruuche. Bi de Reconciliation fangt s Team nümm mit ere rohe Mismatch-Liste a, sondern mit Usnahme, wo scho gruppiert sind und en Hypothes über d Ursach händ.

Wenn de Agent rächt igsetzt wird, verschiebt sich d Rolle vom Mönsch im Finance uf drei Hauptberiich. Erstens, Analyse: meh Zit, um d Business-Treiber z verstah, nöd nume Date vorzbereite. Zweitens, Kontroll-Urteil: meh Fokus uf Entscheidige, wo würkli en professionelli Abwäigig bruuche. Drittens, Business Partnering: meh Kapazität, um mit de Business-Einheite über d Bedütig vo Zahle, Risike und Verbesserigs-Massnahme z rede. Das passt zur Richtig vo de Finance-Transformation, wo vili CFOs scho lang wünsched: di transaktionali Lascht reduziere und de analytisch Beitrag erhöhe. Agentic AI git en neue Weg, das z erreiche, aber nur wenn d Kontrolle starch blibed.

Roadmap 90 Täg für en Finance Agent Pilot

De bescht Aasatz für Finance isch nöd, mit eme grosse Platform aazfange, sondern mit eme enge, aber operative Pilot.

Am Tag 1–30, wähl ei Use Case us mit ere gsunde Kombination vo Wert und Risiko, zum Bischpil Close-Task-Überwachig, AP-Invoice-Exception-Triage oder Reconciliation-Vorbereitig. Zeichne d Quellsystem, d Date und Dokumänt, wo nötig sind, di relevante Policy, d Approval-Thresholds und d Punkt, wo de Mönsch d Entscheidig muess bhalte. De Output vo dere Phase sött kei Demo sii, sondern es Design vom Workflow und vom Control-Modell.

Am Tag 31–60, bau de Agent im Draft- oder Recommend-Modus. Verbind de Agent mit de nötige Date und Tools, aber schränk d Autonomii ii. Fokussier uf Evidence Pack, Audit Trail, es Exception-Dashboard und regelmässigi Prüefige mit de Finance-User (täglich oder wüchentlich). I dere Phase wird de Erfolg nöd a de volle Automatisierig gmesse, sondern dra, ob d Uusgab vom Agent würkli vom Finance-Team bruucht werde cha.

Am Tag 61–90, füehr en beschränkte Pilot uf eme Teil vo Entitäte, Vendor, Kontene oder Fallarte dure. Miss d gsparti Zit, d Akzeptanzrate vo de Empfählige, d Korrekturrate, de Exception-Backlog und d Qualität vo de Evidence. Am End vo de 90 Täg sött d Entscheidig nöd sii "Isch AI guet?", sondern ob de Use Case würdig isch, uswiitet z werde, ob de Grad vo Autonomii cha erhöht werde, oder ob d Date-/Prozess-Grundlag zerscht verbesseret werde muess.

Checkliste Praktisch

Entscheidige, wo jetz müend troffe werde

1. Wähl de richtigi Finance-Use Case für de Afang. Fang mit Close-Monitoring, Reconciliation-Vorbereitig oder Invoice-Exception-Handling a – nöd mit ere materiälle Accounting-Entscheidig.
2. Leg d Grenze vo de Agent-Autonomii fescht. Entscheid explizit, ob de Agent nume list, Entwürf macht, Empfählige git oder bestimmti Aktionene mit Genehmigung usfüere darf.
3. Plan de Evidence Pack und de Audit Trail vo Afang a. Wart nöd, bis de Audit oder d interni Kontroll froget, denn über d Dokumentation nadenke.
4. Setz Approval-Thresholds uf Risiko-Basis fescht. Bruuch e Kombination us Transaktionswert, Confidence, Vendor-Risiko und Materiality, nöd ei einheitlichi Regle.
5. Bereit d Veränderig vo de Finance-Rolle vor. Stell sicher, dass de Pilot nöd nume uf Effizienz zilt, sondern au d Kapazität vom Team zu Analyse, Kontroll-Urteil und Business Partnering verschiebt.

Churzi Readiness-Checkliste

• De usgwählt Finance-Prozess isch stabil und dokumentiert.
• D Quell-Date us em ERP, Subledger oder andere System sind vertrauenswürdig.
• Di relevante Policy und SOP sind verfüegbar und chönd als Source of Truth diene.
• D Approval-Matrix und d delegated Authority sind klar.
• S Finance-Team isch bereit, d Uusgab vom Agent z prüefe und strukturierts Feedback z geh.
• Es gid en Business-Owner und en Technical-Owner für de Pilot-Use-Case.
• Audit Trail, Logging und Evidence Pack sind vor de Produktion entworfe.
• De Pilot-Umfang isch uf bestimmti Entitäte, Kontene, Vendor oder Fallarte beschränkt.
• D Erfolgsmetrike umfasse Cycle Time, Backlog, Akzeptanzrate, Korrekturrate und d Qualität vo de Erklärige.
• Interni Kontrolle, Risk oder de interni Audit sind vo Afang a iibezoge.

Gfahresignal vor de Skalierig

• D Organisation wett em Agent sofort witi Exekutionsrächt im Finance geh.
• D Date-Master, d Policy oder d Chart of Accounts sind immer no inkonsistent.
• Es isch nöd klar, wer d Empfählige vom Agent genehmigt.
• De Agent produziert Vorschläg, aber es gid nöd gnueg Evidence für d Prüefig.
• De Pilot wird nume a de Anzahl Automatisierige gmesse, nöd a de Qualität vo de Kontrolle und de Ergebnis.
• S Finance-Team gseht de Agent nume als Bedrohig für d Rolle, nöd als es Mittel, d Arbet neu z gstalte.

Reflektivi Frage für CIO, COO, CFO und Transformation Leader

Wenn d Finance-Funktion i öierem Undernäme immer no zviel Zit mit Nachjage, Abgliche, Nochverfolgige und em Vorbereite vo Erklärige vo Null verbringt – isch s Problem würkli es Fähle vo Tool, oder isch s Operating Model vom Finance nöd druf usgleit, digitali Arbeiter kontrolliert z nutze? Das isch d Frog, wo beantwortet werde muess, bevor me Agentic AI wiiter i d Finance-Funktion bringt.