Waar ERP-agents ophouden

De groepscontroller had in het ene venster de release notes open en in het andere de checklist voor de maandafsluiting. Twee markten van de groep draaien op Business Central. De derde gebruikt nog het lokale grootboek van voor de overname, en ontvangsten komen binnen als afschriftbestanden van vier banken. Haar vraag was kort: nu Microsoft agents levert voor facturen en afstemming, welk deel van het geplande werk hebben we nog nodig?

Een deel van het geplande werk was net overbodig geworden. Het grootste deel van het moeilijke stuk was niet verschoven.

Wat er is geleverd, in de woorden van de leverancier

Business Central heeft nu een Payables Agent, vermeld als algemeen beschikbaar. Microsoft beschrijft hem als een agent die "monitors mailboxes for incoming vendor invoices, uses AI to analyze invoice content, and shows invoice drafts to agent supervisors for review." Hij bewaakt dus mailboxen op binnenkomende leveranciersfacturen, analyseert de inhoud en legt de concepten ter beoordeling voor aan de verantwoordelijke medewerkers. Hij leest pdf-facturen uit een Microsoft 365-mailbox, herkent de leverancier, stelt regels voor, matcht die met inkooporderregels en maakt van een goedgekeurd concept een inkoopfactuur.

Daarnaast zijn er een Sales Order Agent en een Expense Agent. De tabel hieronder zet de vier naast elkaar.

Dynamics 365 Finance heeft een Account Reconciliation Agent, ook in preview. Hij "evaluates exceptions and provides a recommended action for each one", beoordeelt dus uitzonderingen en geeft voor elke uitzondering een aanbevolen actie, voor verschillen tussen subadministraties en het grootboek. De eerste releases dekken crediteuren, debiteuren, btw en bank.

Niets hiervan is een demonstratie. Het draait in de producten, onder het beveiligingsmodel van die producten, en elke agent handelt als eigen gebruiker. Zijn werk verschijnt daardoor in dezelfde velden "Gemaakt door" en "Gewijzigd door" als dat van een mens.

Wat ze bewust aan mensen overlaten

De nuttigste zinnen in de documentatie zijn de zinnen die zeggen wat de agents niet doen.

De Payables Agent "doesn't post purchase invoices": hij boekt geen inkoopfacturen. Een eigen goedkeuringsflow heeft hij niet. Een leverancier die hij aanmaakt, blijft geblokkeerd tot iemand hem vrijgeeft, en de documentatie is duidelijk dat bankgegevens van leveranciers worden bevestigd zoals altijd: met een telefoontje naar de leverancier. De Sales Order Agent maakt eerst een offerte, ook als de klant om een order vraagt. De afstemmingsagent beveelt per uitzondering een correctie aan. Een mens accepteert die, draait die terug, koppelt de transacties of accepteert het verschil.

Dat leest minder als een gat dan als een ontwerpkeuze: de agent bereidt voor, een mens legt vast, en de registratie laat zien wie wat deed. Precies daar zou een zorgvuldig financeteam de grens trekken, en het is de moeite waard die te houden, ook als een latere release toestaat dat u hem verschuift.

Waar ze ophouden

Voor de controller was de grens die ertoe deed de rand van elk ERP.

Deze agents werken in Business Central online of in Dynamics 365 Finance, op de gegevens die die systemen bevatten. Facturen komen binnen via een bewaakte Microsoft 365-mailbox, als pdf. Er is één Payables Agent per bedrijf. Over andere ERP-systemen, over een lokaal grootboek dat na een overname is aangehouden en over bankafschriftbestanden zegt de documentatie niets, en die stilte is de grens. De agents beweren niet dat ze daar werken, dus u moet ze ook niet zo inplannen.

In haar groep bleven de agents daarmee nuttig voor het merendeel van de leveranciersfacturen en voor de afstemming van de subadministraties in de twee Business Central-markten. Onaangeroerd bleef het werk dat werkelijk bepaalde wanneer de afsluiting klaar was: de intercompanysaldi tussen de drie vennootschappen, de afschriftregels van vier banken tegen openstaande posten in drie grootboeken, en de uitleg waarom de cijfers van de groep op de laatste dag sloten.

De rekening komt per actie

De agents worden gefactureerd in Copilot Credits, per actie. Microsofts eigen voorbeeld voor de Payables Agent rekent 50 credits voor het verwerken van een factuur en 5 voor elke regel, dus 100 facturen van drie regels per maand komen uit op 6.500 credits. Als de credits op zijn, verwerkt de agent geen nieuwe facturen meer en pakt hij de achterstand op zodra er weer capaciteit is.

Daar volgen twee ontwerpgevolgen uit, en geen van beide gaat over de prijs, die we aan het licentiegesprek overlaten. Ten eerste horen routinecontroles die puur rekenwerk zijn, een hoeveelheid tegen een ontvangst of een totaal tegen een controlecijfer, thuis in gewone code, waar ze per run niets kosten. Ten tweede hoort het creditsaldo op de afsluitkalender. Een agent die op de negenentwintigste pauzeert omdat de capaciteit van de maand op is, is een risico voor de afsluiting, en zo moet u het ook plannen.

Ontwerp eromheen, niet ertegenin

Het plan dat we de controller gaven, had drie delen.

Gebruik de native agent binnen elk ERP. Waar de agent van Business Central het werk dekt, zet u hem aan en laat u hem de routinematige facturen en offertes dragen. De leverancier onderhoudt hem, hij volgt de rechten van het product, en niemand in de groep hoeft eigenaar te zijn van zijn code.

Bouw alleen de laag die zij niet zien. Eén systeemoverstijgende laag leest de drie grootboeken en de afschriftbestanden van de vier banken, bevat de intercompanyregels die het financeteam van de groep al toepast, en bereidt de matches en de uitzonderingen voor een mens voor. Ze herhaalt niet wat de native agents doen. Ze begint waar hun documentatie stil wordt.

Houd één bewijsspoor aan. Elke native agent schrijft zijn acties al onder zijn eigen gebruikers-ID. De systeemoverstijgende laag schrijft haar voorstellen en de beslissingen van de beoordelaar in dezelfde termen, gekoppeld aan dezelfde documenten. Aan het eind van de maand kan de controller een bedrag volgen van de bankregel tot de grootboekboeking, langs elke agent of mens die eraan heeft gezeten, in één spoor in plaats van drie. De goedkeuring zelf blijft in het ERP, bij de mensen die er nu al eigenaar van zijn.

De eerste maand

We stelden voor klein te beginnen, en met haar eigen cijfers. De Payables Agent heeft een proefmodus die tot 50 facturen verwerkt zonder factureerbare credits te gebruiken, dus de eerste stap kostte niets: laat hem de facturen van één bedrijf uit een al afgesloten maand verwerken en vergelijk zijn concepten met wat het team heeft geboekt. Waar de concepten overeenkomen, kunnen de routinefacturen van dat bedrijf naar de agent. Waar ze dat niet doen, laten de redenen zien welke leveranciers of factuurlay-outs nog een mens nodig hebben.

De tweede stap was de systeemoverstijgende laag, afgebakend tot één taak: de intercompanysaldi tussen de drie vennootschappen. Die bepaalden het vaakst de laatste dag van de afsluiting, dus daar leverde engineeringtijd het meest op. De bankafschriften kwamen daarna, toen de laag een afsluiting lang had standgehouden.