GPT ruimt de facturen op zolang de boekhouder meekijkt
Sam Altman (archieffoto, 2025-04-11). Foto: Steve Jurvetson / Wikimedia Commons / CC BY 2.0; uitsnede door DenisMironov1. Beeldbron · Gebruiksrecht
In het kort
Een taalmodel kan een rommelige factuur omzetten in overzichtelijke gegevens voor de administratie. GPT-6.1 Sol ondersteunt daarvoor gestructureerde uitvoer, waarbij de software vooraf vastlegt welke velden het antwoord moet bevatten. De aantrekkelijke toepassing zit in minder overtypen en sneller controleren, met de boekhouding als laatste controlepunt. Een eenvoudige rekensom laat zien waarom de inrichting van het proces meestal meer aandacht verdient dan de prijs van één antwoord.
Op een factuur staat een bedrag, een datum en een leverancier. Voor een mens lijkt dat overzichtelijk. Wie iedere maand honderden documenten verwerkt, weet hoeveel uitzonderingen er toch langskomen. Een creditnota gebruikt een minteken. Een leverancier schrijft de datum Amerikaans. Een bestelnummer lijkt op een factuurnummer. En ergens onderaan staat nog een tweede bankrekening.
Daar kan een taalmodel nuttig werk doen. Het leest de informatie in samenhang en maakt een voorstel voor de administratie. De interessante stap is wat daarna gebeurt: krijgt een medewerker een lang verhaal te zien, of verschijnen de gevonden gegevens direct op de juiste plaats, met het oorspronkelijke document ernaast?
Een antwoord in een vast formulier
Bij gestructureerde uitvoer krijgt GPT als het ware een formulier mee. Daarin staat dat het antwoord bijvoorbeeld een leveranciersnaam, factuurdatum, valuta en totaalbedrag moet bevatten. Software kan dat formulier vervolgens uitlezen. Programmeurs noemen zo'n afspraak een schema; JSON is een gebruikelijke notatie voor de ingevulde gegevens.
OpenAI beschrijft Structured Outputs als een manier om antwoorden aan een opgegeven schema te laten voldoen. De documentatie vermeldt ook dat de inhoud nog fouten kan bevatten. De modelpagina van GPT-6.1 Sol bevestigt ondersteuning. Het gaat om gebruik via de API, de aansluiting waarmee eigen software het model aanroept. Toegang tot ChatGPT en het gebruiksbudget van deze API zijn afzonderlijke zaken.
Voor de administratie betekent dit dat de invoer alvast netjes klaar kan staan. Het boekhoudpakket moet daarna bijvoorbeeld nagaan of het factuurnummer al bestaat en of de opgegeven leverancier bekend is. Bij een onbekende bankrekening is een menselijke controle verstandig. Zulke controles zijn vaak eenvoudige, vaste regels die goed passen bij gewone software.
Een concreet voorbeeld maakt dat duidelijk. Stel dat GPT een factuur leest met €1.000 aan werkzaamheden en €210 btw. Het systeem kan zelf narekenen of het totaal €1.210 is. Voor die optelling is geen nieuw AI-antwoord nodig. Zo ontstaat een prettige taakverdeling: GPT helpt bij het lezen, de software rekent en vergelijkt, de medewerker behandelt de uitzonderingen.
Een ontbrekend gegeven mag leeg blijven
De inrichting begint bij de vraag wat de administratie werkelijk nodig heeft. Wie twintig velden verplicht laat invullen terwijl er maar twaalf op de factuur staan, maakt het proces onnodig moeilijk. Een veld voor een onbekende waarde helpt om onzekerheid zichtbaar te houden. Een toelichting kan aangeven op welke pagina het model het bedrag heeft aangetroffen.
Ook de betekenis van een veld hoort duidelijk te zijn. Betekent factuurdatum de datum waarop de leverancier het document maakte, of de dag waarop de administratie het ontving? Hoort een bedrag inclusief of exclusief belasting in het totaalveld? Deze afspraken lijken klein. Bij duizenden documenten bepalen ze of de verwerking voorspelbaar verloopt.
De beste proef bevat daarom gewone facturen én lastige gevallen: verschillende talen, creditnota's, meerdere valuta's, onleesbare scans en documenten zonder btw. Een mens legt vooraf vast wat het juiste antwoord is. Daarna kan het team per veld zien waar correcties nodig blijven. Een hoge score voor leveranciersnamen is weinig waard als juist de betaalbedragen regelmatig verkeerd gaan.
Deze aanpak maakt ook een vergelijking tussen GPT-6.1 Sol, GPT-6 Luna en GPT-6 Astra zinvol. Het zijn commerciële modellen uit dezelfde actuele familie, met verschillende prijzen. Het geschikte model is degene die het vereiste werk in deze administratie betrouwbaar genoeg uitvoert. Daarvoor moet dezelfde documentenverzameling onder dezelfde omstandigheden worden gebruikt. Zelf hebben we die modellen niet op facturen getest.
Wat de modelrekening ongeveer doet
Op 13 oktober 2026 vermeldt de standaardprijslijst voor GPT-6.1 Sol bij korte context $2 per miljoen invoertokens en $10 per miljoen uitvoertokens. Tokens zijn de kleine teksteenheden die een model verwerkt. Voor ons rekenvoorbeeld nemen we per factuur 2.000 invoertokens en 300 gefactureerde uitvoertokens. Die uitvoer moet eventuele meegerekende redeneertokens omvatten.
Dat geeft $0,004 voor het lezen en $0,003 voor de uitvoer, samen $0,007 per poging. Duizend pogingen kosten onder die aannames $7. Bij 10% extra, even grote pogingen wordt dat $7,70. Dit is een berekening van modelverbruik, zonder belastingen, beeldverwerking, opslag, regionale toeslagen of andere gereedschappen. We rekenen geen cache- of batchkorting mee. Grote contextaanvragen en snellere servicestanden kennen andere tarieven.
Het voorbeeld gebruikt tekst die al uit de factuur is gehaald. Een scan moet eerst worden gelezen of als afbeelding worden verwerkt. Dat kan extra kosten en fouten opleveren. Een eurobegroting voor een complete toepassing moet daarnaast de wisselkoers, leverancierstoeslagen en het beheer meenemen. Daarom staat de dollarberekening apart van de onderstaande economische scenario's.
Waar de meeste waarde ontstaat
Een medewerker die eerder drie minuten nodig had en nu na controle nog één minuut besteedt, wint twee minuten. Tegen een economische uurwaarde van €45 is dat €1,50 per document. Dat bedrag maakt duidelijk waarom een iets duurdere modelaanroep aantrekkelijk kan zijn als hij de controle daadwerkelijk eenvoudiger maakt.
De winst kan op verschillende plekken terechtkomen. Een klein kantoor houdt tijd over voor klanten. Een administratie met veel overwerk kan mogelijk directe kosten verlagen. Een groeiend bedrijf kan meer facturen verwerken met hetzelfde team. Dat zijn allemaal bruikbare uitkomsten, maar ze horen op een andere manier in de begroting.
De beslissende vergelijking is met het bestaande proces, inclusief bestaande automatisering. Veel facturen komen al digitaal en gestructureerd binnen. Daar voegt een taalmodel misschien weinig toe. De interessante verzameling bestaat dan uit de resterende documenten waarvoor mensen nog handmatig gegevens zoeken. Alleen die extra verbetering telt mee.
Hoeveel facturen dragen de investering
De economische rekensom gebruikt een eenmalige investering van €3.000, jaarlijks €600 voor beheer en €0,03 variabele kosten per factuur. Dat laatste is een begrotingsaanname voor het volledige gebruik, inclusief modelverbruik en herhaalpogingen, geen omgerekende prijslijst. Een productief uur waarderen we op €45. De netto tijdwinst is al verminderd met controle en herstel. Bespaarde uren worden pas kasbesparing wanneer bijvoorbeeld inhuur of overwerk werkelijk vervalt; anders vertegenwoordigen ze beschikbare capaciteit. Alle bedragen zijn exclusief aftrekbare btw, vóór belasting en zonder financiering.
Voor 2027 rekenen we in laag, midden en hoog met respectievelijk 1.500, 5.000, 10.000 facturen en 0,5, 1,5, 2,5 netto minuten winst per stuk. Het volume groeit in ieder scenario jaarlijks met 10%; tijdwinst, uurtarief en kosten per stuk blijven gelijk. Dit zijn onze aannames per 13 oktober 2026, geen voorspelde modelprestaties of toekomstige tarieven. Het middenvoorbeeld levert in 2027 €4.875 op na lopende kosten.
Teruggerekend moet de toepassing bij gelijkblijvend jaarvolume minstens 1.612 facturen per jaar verwerken om de investering over drie jaar te dragen bij 8% rendementseis en zonder restwaarde. De formule is: benodigde jaaromvang = (investering / 2,5771 + vaste jaarkosten) / (netto minuten × uurwaarde / 60 − variabele kosten). De driejaarswaarde is de som van de jaarlijkse uitkomsten gedeeld door 1,08, 1,08² en 1,08³, minus de investering. De scenario’s laten zien hoe sterk de uitkomst afhangt van werkelijk gebruik.
De lage uitkomst kan ontstaan doordat weinig geschikte documenten overblijven na bestaande automatisering. Het middenpad past bij een team dat een terugkerende stroom uitzonderingen beter verwerkt. In het hoge pad is de toepassing breed bruikbaar en blijft de nacontrole kort. De berekening veronderstelt in alle gevallen dat het werk beschikbaar is en de vrijgekomen tijd nuttig kan worden ingezet.
De boekhoudsoftware blijft belangrijk
Voor softwarebedrijven is dit een aantrekkelijke uitbreiding van hun bestaande positie. Het boekhoudpakket kent de klanten, de leveranciers en de interne afspraken al. Een taalmodel kan het lastige leeswerk toevoegen, terwijl de bestaande software de verwerking afhandelt. Dat sluit aan bij onze eerdere analyse over AI-gebruik en de stap naar productiviteit.
OpenAI verdient in dit voorbeeld aan verbruik. De softwareleverancier kan waarde toevoegen met de koppeling, de controle en de gebruikerservaring. De klant profiteert wanneer er aantoonbaar minder werk overblijft. Hoe die waarde tussen de drie wordt verdeeld, hangt af van de prijsafspraak en van de alternatieven die de klant heeft.
De nuttigste vraag voor een proef is daardoor heel concreet: hoeveel documenten komen met de juiste gegevens door het proces, en hoeveel minuten vraagt dat nog van een medewerker? Wie die twee getallen kent, kan een besluit nemen dat ook buiten een indrukwekkende demonstratie overeind blijft.
Opmerkingen