Facturen en e-mails verwerken met AI

Waarom de inbox en de facturenstroom vertragen

In de meeste kmo's zit de rem op dezelfde twee plaatsen. De eerste is een gedeelde mailbox waar alles binnenkomt: vragen van klanten, leveringsberichten, facturen van leveranciers, een uitnodiging voor een beurs. Iemand moet dat elke ochtend uit elkaar halen en doorsturen naar wie het aangaat. De tweede is de stapel inkomende facturen die overgetikt moet worden voor ze in de boekhouding staan.

Geen van beide is moeilijk werk. Ze zijn wel voortdurend, ze onderbreken en ze komen altijd terecht bij iemand die op dat moment iets anders aan het doen was. Wanneer die persoon er een dag niet is, blijft alles gewoon liggen. Dat is het soort werk waar een taalmodel goed in is, op voorwaarde dat het resultaat door mensenhanden gaat voor er iets vertrekt.

Wat er binnenkomt en wat eruit gaat

Twee dingen draaien vandaag bij ons in productie en zijn allebei op deze manier gebouwd.

Het eerste leest de binnenkomende e-mail. Elk bericht wordt gelezen, gerangschikt en samengevat tot een actiepunt met een voorstel: wie het best antwoordt, waarover het gaat en wat er verwacht wordt. Hangt er een inkoopfactuur aan, dan wordt die eruit gehaald en herkend, met leverancier, bedrag, datum en referentie. Het actiepunt komt op een lijst te staan waar het opgevolgd kan worden. Niets wordt verstuurd, niets wordt geboekt.

Het tweede volgt een document over zijn hele weg: van offerte naar factuur naar de boekhouding. De gegevens die in de offerte stonden, worden hergebruikt in de factuur en gaan mee naar het boekhoudpakket. Wat vroeger drie keer werd ingetikt, wordt één keer ingegeven en daarna doorgegeven.

Wat u aan uw kant ziet, is een lijst met voorstellen. Elk voorstel toont waarvandaan het komt en waarop het gebaseerd is. U opent er één, kijkt na en klikt.

Belangrijk daarbij: uw mailbox en uw boekhoudpakket blijven staan waar ze staan. Wij vervangen ze niet en wij vragen niet aan uw team om ergens anders te gaan werken. Het systeem leest mee aan de ingang en zet klaar aan de uitgang. Wie vandaag in het boekhoudpakket werkt, blijft dat morgen doen, met dat verschil dat de velden al ingevuld staan.

Waarom er altijd een menselijke klik blijft

Die klik is geen tussenstap die we later wegnemen. Ze is de reden waarom het systeem in productie mag draaien.

Een taalmodel kan een leveranciersnaam verkeerd lezen. Het kan een bedrag van een creditnota aanzien voor een gewoon factuurbedrag. Het kan een mail van een advocaat rangschikken bij de leveranciersberichten omdat de vorm daarop lijkt. Die fouten zijn zeldzaam en ze zijn niet weg te krijgen. Wie belooft dat ze verdwijnen, verkoopt iets anders dan wat er is.

Dus zetten wij het model op de plaats waar het sterk is: lezen, herkennen, rangschikken en voorstellen. De beslissing blijft waar ze thuishoort. Doorsturen naar de klant, inboeken, betalen: dat gebeurt op uw klik, niet op die van een model. Die klik is één handeling, tegenover het volledige document overtikken.

Er is nog een reden. Elke klik legt vast wie de beslissing genomen heeft. Komt er later een vraag van de boekhouder of een discussie met een leverancier, dan gaat het over wie iets heeft laten doorgaan. Zolang die stap bij een mens ligt, is dat een vraag met een antwoord. Wordt ze weggeautomatiseerd, dan blijft de vraag staan en verdwijnt het antwoord.

Wij rekenen op de scope van één proces, en die scope stopt bewust bij het voorstel. Dat is geen technische beperking. Het is een keuze die bepaalt wie aansprakelijk blijft voor wat er buitengaat, en die vraag wordt alleen maar belangrijker naarmate meer bedrijven met deze modellen werken.

Wat er niet zonder controle gebeurt

Wat er niet automatisch vertrekt, zetten wij er liever expliciet bij.

Er gaat geen antwoord naar een klant zonder dat een mens het gelezen heeft. Er wordt geen factuur geboekt zonder dat iemand het voorstel bevestigt. Betalingen zetten wij niet klaar en wij verwijderen niets. Een bericht dat het model niet met voldoende zekerheid kan plaatsen, verdwijnt niet en wordt niet geraden: het komt op de lijst met de vermelding dat het onduidelijk is, zodat het gegarandeerd bij een mens belandt.

Alles wat het systeem doet, staat in een activiteitenlogboek: welk bericht binnenkwam, wat er uitgehaald werd, welk voorstel eruit volgde en wie het bevestigd heeft. Dat logboek is er niet om ons in te dekken. Het is er omdat een bedrijf dat vandaag met AI werkt, moet kunnen aantonen wie wat beslist heeft. Uw boekhouder vraagt dat vroeg of laat, en uw verzekeraar mogelijk ook.

Waar dit vandaag al draait

De twee toepassingen hierboven draaien elke werkdag bij ons in productie, op onze eigen mailbox en ons eigen boekhoudpakket. Wij noemen hier geen namen en geen aantallen. Cijfers over verwerkte volumes zeggen weinig over uw situatie, en een klantnaam op een webpagina is niet iets wat wij weggeven.

Wat wel overdraagbaar is, is de vorm. Eén bron die binnenkomt, één lijst met voorstellen, één menselijke klik en een logboek dat achteraf uitlegt wat er gebeurd is. Die vorm past op een offertestroom evengoed als op een facturenstroom, en het is de vorm waarmee wij elk nieuw proces beginnen.

Welke van de twee bij u als eerste aan de beurt is, hangt af van waar het vastloopt. Zit de rem in de mailbox, dan begint het daar. Ligt de stapel facturen te wachten, dan is dat de eerste. In beide gevallen blijft het bij één proces, met een scope die op voorhand beschreven staat. Dat is dezelfde logica als bij elk ander traject dat wij aanvatten: twee stromen tegelijk aannemen maakt het achteraf moeilijk om te zien welke van de twee effectief werkt, en die vraag wilt u wel beantwoord zien.

Wilt u weten of uw eigen mailbox of facturenstroom daarvoor in aanmerking komt, dan is één proces genoeg om mee te starten.