01
De variatie
Twintig vaste leveranciers is een dag. Honderden leveranciers die elk anders factureren, is oefenen op de meest voorkomende en de rest handmatig laten.
OneDayBuild, het bouwdagmerk van Appfront
Wat bepaalt de kosten van facturen automatisch uitlezen?
Een factuur uitlezen is goedkoop; een model haalt leverancier, factuurnummer, bedragen en btw uit vrijwel elke pdf of foto. Wat de kosten bepaalt, is de stap erna: op welke grootboekrekening en kostenplaats de regel moet, of hij matcht met een inkooporder, en wie het controleert voordat het in de boekhouding staat. Die drie vragen bepalen of het een dag is of een traject.
- Eén werkdag
- Werkend prototype
- Code in je eigen repository
01/06
Wat de kosten bepaalt
Niet het lezen, maar het coderen en het boeken.
Inkoopfacturen komen binnen per mail, als pdf, soms nog als scan. Iemand opent ze, tikt leverancier, datum, bedrag en btw over in het boekhoudpakket, kiest een grootboekrekening en een kostenplaats en stuurt hem door voor akkoord. Bij honderd facturen per maand is dat een dagdeel per week, en het is werk waar fouten in sluipen: een verkeerde btw-code, een bedrag met een punt in plaats van een komma.
Het uitlezen is het goedkope deel. Een model haalt uit vrijwel elke factuur de kopgegevens en de regels, ook uit een foto van een kassabon. Duurder is het coderen: op welke rekening hoort deze regel, is het een kostenpost of een investering, welke afdeling betaalt. Dat weet het model niet uit zichzelf, maar het kan het leren van jullie eerdere boekingen, en dat is waar de bouwdag op inzet.
De derde post is de koppeling. Blijft het bij een controlescherm waar een medewerker de boeking bevestigt en overneemt, dan is dat een dag. Moet de factuur rechtstreeks in Exact, AFAS, Twinfield of een ander pakket landen, met fiattering door een budgethouder en betaling in een batch, dan bouw je een integratie met een eigen testtraject. Begin bij het controlescherm; dat laat al zien of de codering goed genoeg is.
02
Het coderen
Van factuurregel naar grootboekrekening en kostenplaats, geleerd van jullie eerdere boekingen. Dit is de post die het verschil maakt.
03
De koppeling
Een controlescherm is een dag. Rechtstreeks je boekhoudpakket in, met fiattering en betaling, is een traject.
04
Wat je pakket al kan
Veel boekhoudpakketten hebben zelf een scan-en-herken-functie. Vraag dat eerst na; bouw alleen wat die functie niet doet.
02/06
Wat valt binnen en buiten de bouwdag
Binnen scope
- Facturen inlezen uit mail, pdf of foto, met kopgegevens, regels en btw uitgelezen.
- Een voorstel per regel voor grootboekrekening en kostenplaats op basis van jullie eerdere boekingen.
- Een controlescherm waarin een medewerker de boeking bevestigt of corrigeert.
- Export in het formaat dat je pakket importeert, en de code in je eigen repository.
Buiten scope
- Een rechtstreekse koppeling die boekingen in je boekhoudpakket aanmaakt.
- Fiattering door budgethouders, betaalbatches en aanmaningen.
- Matchen met inkooporders en ontvangsten (three-way match).
- E-facturatie via Peppol; dat vraagt een aansluiting bij een accesspoint.
03/06
Hoe de bouwdag verloopt
- Stap 1
Facturen verzamelen
Vijftig echte facturen van verschillende leveranciers, met hoe ze destijds zijn geboekt.
- Stap 2
Het rekeningschema
Een export van je grootboekrekeningen en kostenplaatsen, met wat er waar hoort.
- Stap 3
Uitlezen bouwen
Het model leest kopgegevens, regels en btw en geeft ze gestructureerd terug.
- Stap 4
Coderen bouwen
Per regel een voorstel voor rekening en kostenplaats, met hoe zeker het model is.
- Stap 5
Het controlescherm
Factuur links, boeking rechts, bevestigen of aanpassen en exporteren.
- Stap 6
Opleveren
Draaiend op een live URL, code in je eigen repository, met de trefkans per leverancier op papier.
Volgende stap
Wil je weten wat het in jouw situatie wordt?
Stuur ons een paar facturen zoals ze binnenkomen en vertel welk boekhoudpakket je gebruikt en wie nu codeert. Met die drie dingen is te zeggen welk deel in één dag past.
04/06
Eerlijk over de kosten hiervan
- Je pakket kan misschien al genoeg. Scan-en-herken zit in de meeste boekhoudpakketten. Die functies lezen de kop goed, maar coderen slecht. Bouw alleen als dat coderen jullie echte tijdvreter is.
- Coderen is nooit honderd procent. Een nieuwe leverancier of een ongebruikelijke kostenpost gaat mis. Daarom is het controlescherm het product, niet een tussenstap.
- Je historie bepaalt de kwaliteit. Het model leert van hoe jullie eerder hebben geboekt. Als dat inconsequent was, wordt het voorstel dat ook. Dat is geen fout van het model.
- De winst zit in minuten en fouten. Meet nu hoeveel minuten een factuur kost en hoe vaak er een correctie nodig is. Anders weet je straks niet wat je hebt gewonnen.
05/06
Twee manieren om verder te gaan
De bouwdag maakt je idee aantoonbaar. Wil je daarna doorbouwen naar een volwaardige applicatie, dan doet Appfront dat traject.
Eén bouwdag, OneDayBuild
- Je wilt weten of uitlezen en coderen bij jullie facturen het overtikken kan vervangen.
- Aan het eind van de dag werkt de keten tot en met het controlescherm, op jullie eigen facturen.
- Één dag, vaste prijs, code in je eigen repository.
Volledig traject, Appfront
- Het werkt en je wilt facturen rechtstreeks je pakket in, met fiattering en betaalbatches.
- Three-way match met inkooporders, Peppol-aansluiting en beheer van uitzonderingen.
- Een traject bij Appfront, met beheer en doorontwikkeling.
06/06
Veelgestelde vragen
Wat kost facturen automatisch uitlezen en boeken?
Dat hangt af van drie dingen: hoe verschillend de facturen binnenkomen, hoe goed het coderen naar grootboek en kostenplaats te leren is uit jullie historie, en of de boeking in een controlescherm mag landen of rechtstreeks je pakket in moet. Uitlezen met codering en een controlescherm is een bouwdag. Een koppeling met fiattering is een traject.
Haalt AI genoeg velden goed om handmatig invoeren te schrappen?
De kopgegevens en bedragen wel; daar is de herkenning betrouwbaar. Het coderen is minder zeker, en daarom blijft er een mens die bevestigt. De winst zit in het verschil tussen overtikken en controleren: een medewerker die een voorstel goedkeurt, is sneller klaar en maakt minder fouten.
Ons boekhoudpakket heeft al scan-en-herken. Waarom dan bouwen?
Vraag dat eerst na, want soms is het genoeg. Die functies lezen meestal de kop goed en laten het coderen aan jou. Als het coderen jullie tijdvreter is, of als je facturen op regelniveau naar verschillende kostenplaatsen wilt, dan is dat het moment waarop een eigen oplossing zin heeft.
Kunnen we ook facturen per mail inlezen?
Ja. Een vaste mailbox waar facturen binnenkomen is de gebruikelijke bron. Het model leest de bijlage, en als de factuur in de mailtekst zelf staat leest het die. Mails die geen factuur zijn, zoals herinneringen of vragen, komen apart in het controlescherm te staan.
Wat als een factuur van een onbekende leverancier komt?
Dan doet het model een voorstel op basis van de omschrijving en zegt erbij dat het onzeker is. De medewerker kiest de rekening, en de volgende factuur van die leverancier gaat beter. Zo groeit de trefkans met het gebruik, zonder dat iemand regels hoeft te programmeren.
Hoe zit het met e-facturen en Peppol?
Een e-factuur via Peppol is al gestructureerd en hoeft niet uitgelezen te worden; die is juist eenvoudiger. De aansluiting op het Peppol-netwerk loopt via een accesspoint en valt buiten een bouwdag. Voor de facturen die nog als pdf komen, en dat zijn er in de praktijk de meeste, geldt wat hierboven staat.
