Waar ERP-agents ophouden

De groepscontroller had in het ene venster de release notes van Microsoft open en in het andere de checklist voor de maandafsluiting. Twee landen van de groep draaien op Business Central, een ERP van Microsoft: het bedrijfssysteem met de orders, facturen en boekhouding van een bedrijf. Het derde voert zijn boekhouding nog in het lokale systeem van voor de overname, en betalingen komen van vier banken binnen als afschriftbestanden, de lijsten van de bank met geld in en uit. Haar vraag was kort: nu Microsoft AI-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 leveranciersfacturen, analyseert ze en legt de concepten ter beoordeling voor. Hij leest pdf-facturen uit een Microsoft 365-mailbox, herkent de leverancier, stelt de factuurregels voor, legt ze naast wat er besteld is en maakt van een goedgekeurd concept een leveranciersfactuur in het systeem.

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

Dynamics 365 Finance, het andere financiële ERP van Microsoft, heeft een Account Reconciliation Agent, ook in preview. Afstemmen betekent controleren of de detaillijsten, zoals wat elke leverancier en klant toekomt, optellen tot de totalen in de hoofdadministratie. De agent "evaluates exceptions and provides a recommended action for each one", beoordeelt dus verschillen en geeft voor elk een aanbevolen actie. De eerste releases dekken saldi van leveranciers en klanten, btw en bank.

Niets hiervan is een demonstratie. Het draait in de producten, onder hun beveiligingsregels, en elke agent werkt 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 zeggen wat de agents niet doen.

De Payables Agent "doesn't post purchase invoices": hij boekt geen factuur, legt die dus nooit definitief vast in de administratie, de stap die haar bindend en betaalbaar maakt. 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 belletje naar de leverancier. De Sales Order Agent maakt eerst een offerte, ook als de klant om een order vraagt. De afstemmingsagent beveelt per verschil 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 systeem.

Deze agents werken in Business Central online of in Dynamics 365 Finance, op de gegevens die die systemen bevatten. Facturen komen binnen als pdf via een bewaakte Microsoft 365-mailbox. Er is één Payables Agent per bedrijf. Over systemen van andere leveranciers, over een lokale administratie die 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 in de twee Business Central-landen. Onaangeroerd bleef het werk dat werkelijk bepaalde wanneer de maandafsluiting, het afronden en controleren van de maandcijfers, klaar was: de bedragen die de drie bedrijven elkaar verschuldigd zijn, de afschriftregels van vier banken naast openstaande facturen in drie administraties, 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, de verbruikseenheden van Microsoft, 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, neemt de agent geen nieuwe facturen meer aan 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 levering of een totaal tegen een verwacht bedrag, 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 ingebouwde agent binnen elk systeem. 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 laag over de systemen heen leest de drie administraties en de afschriftbestanden van de vier banken, bevat de regels die het financeteam nu al toepast op geld tussen de eigen bedrijven, en bereidt de koppelingen en de uitzonderingen voor een mens voor. Ze herhaalt niet wat de ingebouwde agents doen. Ze begint waar hun documentatie stil wordt.

Houd één bewijsspoor aan. Elke ingebouwde agent legt zijn acties al vast onder zijn eigen gebruikersnaam. De systeemoverstijgende laag legt haar voorstellen en de beslissingen van de beoordelaar op dezelfde manier vast, gekoppeld aan dezelfde documenten. Aan het eind van de maand kan de controller een bedrag volgen van de bankregel tot de boeking in de administratie, langs elke agent of mens die eraan heeft gezeten, in één spoor in plaats van drie. De goedkeuring zelf blijft in het bedrijfssysteem, bij de mensen die er nu al eigenaar van zijn.

De eerste maand

We stelden voor klein te beginnen, 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 werkelijk heeft geboekt. Waar de concepten overeenkomen, kunnen de routinefacturen van dat bedrijf naar de agent. Waar niet, 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 bedragen die de drie bedrijven elkaar verschuldigd zijn. 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.