Wat zijn agenttransacties? AI-agents die zelfstandig betalen

Een agenttransactie is een financiële handeling die door een AI-agent wordt voorbereid of uitgevoerd, zonder dat een mens elke afzonderlijke stap aanstuurt. De handeling zelf is niet nieuw; nieuw is de softwarelaag ertussen die zelf keuzes maakt.

Het onderscheid tussen voorbereiden en uitvoeren is bepalend. Bereidt de agent alleen voor, dan blijft er een menselijk akkoordmoment dat u kunt vastleggen. Voert de agent zelf uit, dan verschuift het bewijs naar het mandaat: wie gaf welke bevoegdheid, binnen welke grenzen en voor welke periode.

Software is geen rechtssubject. De gevolgen van een agenttransactie slaan neer bij de opdrachtgever of de rechtspersoon namens wie is gehandeld. 'De agent deed het' is geen verklaring die richting Belastingdienst, bank of accountant standhoudt.

Binnen een BV betekent dat: de BV is wederpartij en de bestuurder blijft verantwoordelijk voor de opzet van het mandaat en de beheersmaatregelen. Betaalt een agent per abuis vanuit een privéwallet, dan ontstaat direct een vraag over de verhouding tussen privé en zakelijk.

Boekhoudkundig is een agenttransactie gewoon een transactie: een prestatie, een tegenpartij, een bedrag en een moment. Het verschil zit in de onderbouwing — vaker geen factuur op naam, betaling via een wallet en een tegenpartij die alleen als adres bekend is.

Koppel elke agentbetaling aan een onderliggende verplichting of levering, leg de waarde op transactiemoment in euro's vast met een verantwoorde koersbron en zorg dat het saldo op balansdatum aansluit op de onderliggende transacties.

Het aantal geautomatiseerde betalingen groeit sneller dan de administratieve inrichting eromheen. Wie vooraf vastlegt hoe mandaten worden verleend, begrensd en beëindigd, voorkomt dat er achteraf een reconstructie nodig is van iets wat nooit is gelogd.

Dit onderwerp wordt verder verkend op het onafhankelijke platform Agenttransacties.nl.

De eerste vraag bij elke agenttransactie is eenvoudig en wordt zelden gesteld: van wie is de wallet waaruit betaald wordt? Van de onderneming, van de bestuurder privé, of van de leverancier van het agentplatform?

Dat antwoord bepaalt of een uitgave een zakelijke kostenpost is, een privéopname, een rekening-courantmutatie of een vordering op een derde. Een agent die per abuis uit een privéwallet betaalt, veroorzaakt geen technisch probleem maar een fiscaal probleem.

Leg daarom per wallet vast: de eigenaar, de beheerder, het doel, het maximale werksaldo, welke agent er toegang toe heeft en hoe die toegang wordt ingetrokken. Scheid agentwallets van de wallets waarin overig vermogen staat.

Verantwoordelijkheid is niet delegeerbaar aan software. Wat wél verschuift, is het moment waarop verantwoordelijkheid wordt genomen: van goedkeuring per transactie naar het inrichten en bewaken van het mandaat.

Dat vraagt om functiescheiding: degene die het mandaat verleent is bij voorkeur niet degene die de agent technisch beheert, en er is een periodieke controle op wat er binnen het mandaat is gebeurd.

Een agenttransactie is pas verantwoord als de hele keten navolgbaar is. Gebruik deze keten als toets: opdracht → AI-agent → beslissing → autorisatie → leverancier → betaling → transactie → bewijsstuk → boeking.

Opdracht: wat vroeg de organisatie, wanneer en door wie geformuleerd. AI-agent: welke agent en welke versie of configuratie handelde. Beslissing: welke keuze maakte de agent en op grond van welke informatie.

Autorisatie: welk mandaat gold, met welke grenzen en welke geldigheidsduur, en welk adres of welke sleutel tekende. Leverancier: wie is de tegenpartij en hoe is die identificeerbaar. Betaling: bedrag, munt, tijdstip, netwerk en transactiehash.

Transactie: de on-chain vastlegging en de bevestiging van levering. Bewijsstuk: factuur, orderbevestiging, API-log of contract. Boeking: de journaalpost met euro-waarde en koersbron.

Elke schakel die ontbreekt, is een gat dat een accountant of controlerende instantie later zal aanwijzen. De keten is bovendien de enige manier om aan te tonen dat een betaling geautoriseerd wás, en niet het gevolg van een fout of een compromittering.

Bij machine-to-machinebetalingen betaalt het ene systeem het andere zonder dat er een mens in de lus zit: een agent die per API-aanroep afrekent, een apparaat dat verbruik afrekent, of twee agents die onderling een prestatie verrekenen.

Kenmerkend zijn de omvang en de frequentie: zeer veel zeer kleine bedragen. Dat maakt individuele boeking onwerkbaar en aggregatie noodzakelijk. Bepaal vooraf op welk niveau u aggregeert (per tegenpartij, per dag, per contract) en bewaar de onderliggende detaildata zodat specificatie mogelijk blijft.

Let op de btw-kant: bij grensoverschrijdende digitale diensten kan de plaats van dienst en de verleggingsregeling relevant zijn, ook bij microbedragen.

1. Een register van agents: welke agents actief zijn, wat zij mogen en wie de eigenaar is.

2. Een mandaatdocument per agent, met grenzen, looptijd en intrekkingsprocedure.

3. Een walletregister met eigenaar, doel, saldolimiet en toegang.

4. Een transactielog dat de volledige auditketen dekt.

5. Een waarderingsbeleid: welke koersbron, welk tijdstip, welk aggregatieniveau.

6. Een periodieke aansluiting tussen walletsaldi, transactielog en grootboek.

7. Een beschrijving van de beheersmaatregelen, zodat een accountant kan toetsen of het stelsel werkt in plaats van alleen steekproeven te nemen.

Agenttransacties raken ook de bredere vraag hoe werk en verantwoordelijkheid verschuiven wanneer software zelfstandig handelt. Dat is een relevant gesprek, maar het is niet het gesprek dat uw administratie oplost.

De praktische vraag blijft dezelfde als bij elke andere betaling: wie wilde dit, wat is ervoor geleverd, wat heeft het gekost en waar staat dat vastgelegd.