Hoe bouw ik cloud software om automatisch facturen in te boeken?

"We krijgen elke maand een paar honderd facturen binnen. Iemand opent ze, typt ze over, en zoekt uit wie ze moet betalen. Kan dat niet gewoon vanzelf?"

Ja. En sinds dit jaar is het bovendien een pak eenvoudiger geworden dan het jaren was, al is dat niet de reden die je verwacht.

Dit artikel is het ontwerp achter zo'n systeem: waar facturen binnenkomen, hoe je ze uitleest, hoe je beslist op welke grootboekrekening ze horen, en (het stuk dat vaak vergeten wordt) hoe je bepaalt of er nog iemand iets moet doen. Geen code, wel de architectuur en de keuzes die er echt toe doen.

En meteen een eerlijke waarschuwing vooraf: automatisering werkt alleen als het proces eronder klopt. Wie vandaag geen afspraak heeft over wie facturen goedkeurt, heeft straks diezelfde onduidelijkheid, maar dan sneller. Meer daarover in wanneer AI niet de oplossing is.

Eerst dit: e-facturatie maakt dit wat gemakkelijker

Sinds 1 januari 2026 zijn gestructureerde e-facturen verplicht voor zo goed als alle binnenlandse B2B-transacties tussen btw-plichtige bedrijven in België. Een PDF doormailen volstaat niet meer. Facturen gaan via het Peppol-netwerk, in een gestructureerd formaat volgens de Europese norm EN 16931 (in de praktijk Peppol BIS 3.0, dat UBL-XML gebruikt). De tolerantieperiode liep tot 31 maart 2026; daarna gelden er boetes.

Dat is geen randbemerking. Het verandert het ontwerp fundamenteel.

Een Peppol-factuur is al gestructureerde data. Leveranciersnaam, btw-nummer, factuurnummer, vervaldatum, btw-uitsplitsing per tarief, IBAN, gestructureerde mededeling: het staat er allemaal in, machineleesbaar, exact. Daar hoef je geen AI op los te laten. Een parser volstaat, en die heeft 100% gelijk.

Hoe langer je wacht, hoe kleiner het stuk "AI leest een PDF" wordt. De echte waarde van je software zit niet meer in het document lezen, maar in beslissen wat ermee moet gebeuren. Dat is een veel interessanter en veel duurzamer probleem.

Waar komen facturen binnen?

In de praktijk zijn dat drie deuren, en je hebt ze alle drie nodig:

1. Peppol. De hoofdweg voor Belgische B2B. Je sluit hiervoor aan op een access point. Zelf een gecertificeerd access point worden is een apart product dat je aankoopt (Billit, Unifiedpost, Storecove en anderen leveren een API).
2. E-mail. Een eigen postbus, bijvoorbeeld facturen@jouwbedrijf.be. Nodig voor buitenlandse leveranciers, voor B2C-achtige documenten en voor iedereen die de omslag nog niet gemaakt heeft. Werk hier met webhooks (Microsoft Graph, Gmail API) in plaats van IMAP te pollen als het kan.
3. Handmatige upload. Een simpel sleep-en-neerzetscherm. Voor de bonnetjes, de scans, en de leverancier die het per post blijft doen.

Drie deuren, één trechter. Alles wat binnenkomt, gaat door exact dezelfde pijplijn.

Hoe lees je een factuur uit?

Twee paden, en je kiest ze automatisch per document.

Het gestructureerde pad. Komt er UBL of Factur-X binnen, dan parse je die rechtstreeks. Deterministisch, gratis, foutloos. Dit wordt met de maand je grootste kanaal.

Het ongestructureerde pad. PDF's en scans gaan naar een AI-model dat de velden eruit haalt in een strak vastgelegd JSON-schema, met OCR als tussenstap bij slechte scans. Dat is dezelfde aanpak die we beschreven in documenten verwerken met AI, alleen met een strenger schema omdat het hier over bedragen gaat. Laat het model per veld een zekerheidsscore teruggeven. Die score is later de motor achter je hele beslislogica.

De velden die je hoe dan ook nodig hebt: leverancier en btw-nummer, factuurnummer, factuurdatum en vervaldatum, netto/btw/bruto met de uitsplitsing per tarief, IBAN, gestructureerde mededeling, munteenheid, en de factuurlijnen als je op kostenplaats wil kunnen splitsen.

En dan volgt het stuk waar je vertrouwen wint of verliest: de controles. Die zijn saai, deterministisch en goedkoop.

• Tellen de lijnen op tot het subtotaal, en klopt het totaal?
• Zijn de btw-tarieven geldige Belgische tarieven (0, 6, 12 of 21%)?
• Bestaat het btw-nummer echt? (VIES-controle)
• Klopt het IBAN-controlegetal, en is het hetzelfde IBAN als de vorige keer bij deze leverancier?
• Hebben we deze factuur al gezien? Dedupliceren op btw-nummer plus factuurnummer plus bedrag, en op een hash van het originele bestand.

Die vierde controle is de belangrijkste van allemaal. Factuurfraude, waarbij iemand een bekende leverancier nabootst met een ander rekeningnummer, is de duurste fout die een KMO met dit soort software kan maken. Een gewijzigd IBAN bij een vertrouwde leverancier is precies het signaal dat een mens over het hoofd ziet en software niet.

Hoe weet de software op welke rekening het moet?

Hier is de verleiding groot om alles aan een taalmodel te vragen. Doe dat niet. Een cascade van drie stappen is goedkoper, sneller en preciezer:

1. Expliciete regels. "Leverancier X gaat altijd naar 613000." Dit dekt na een paar maanden het grootste deel van je volume, want de meeste KMO's hebben een vaste kern leveranciers.
2. Gelijkenis met eerdere boekingen. Zoek de dichtstbijzijnde historische boekingen van deze klant op basis van leverancier en omschrijving. Wat vorige keer klopte, klopt meestal opnieuw.
3. Het AI-model, als vangnet. Alleen wanneer stap 1 en 2 twijfelen. Geef het model dan wel het échte rekeningschema van de klant mee en een handvol vergelijkbare boekingen als voorbeeld, anders verzint het iets plausibels dat niet bestaat.

En dan de leerlus: elke correctie van de gebruiker schrijft terug. Wie een voorstel aanpast, maakt zonder het te beseffen een nieuwe regel of een nieuw voorbeeld. Na een paar weken kent het systeem de gewoontes van dat ene bedrijf. Dat is waarom maatwerk hier wint van een generieke tool: de gewoontes van jouw boekhouding zijn niet die van je buurman.

Naar het boekhoudpakket schrijf je altijd als voorstel, nooit als definitieve boeking. Geen enkele boekhouder aanvaardt een zwarte doos die ongevraagd in het grootboek schrijft. Bouw per pakket een aparte adapter achter één interne interface. Exact Online, Yuki, Octopus en Odoo zijn de realistische eerste doelen voor de Vlaamse markt. Elke push krijgt een idempotency key, want een retry die dubbel boekt is erger dan een mislukking.

Wanneer moet jij zelf nog iets doen?

Dit is het deel dat de software écht nuttig maakt, en het is opvallend genoeg zelden AI. Het is gewone, expliciete logica.

Stil afhandelen als er een lopende domiciliëring of SEPA-mandaat is, als de betaling al gematcht is, of als het een creditnota is die tegen een bestaande factuur wegvalt. Niets doen is ook een uitkomst.

Nakijken bij een veld met lage zekerheid, een leverancier die het systeem nog nooit zag, een voorgestelde rekening die nieuw is, of een totaal dat niet klopt.

Actie nodig bij: geen mandaat en een vervaldatum binnen X dagen, een bedrag boven een drempel die de klant zelf instelt, een gewijzigd IBAN, een btw-nummer dat niet valideert, een vermoedelijk dubbele factuur, of geen match met een bestelbon.

En dan de e-mail

Twee kanalen, bewust gescheiden:

• Een dagelijkse digest op een vast uur: "6 facturen geboekt, 2 vragen je aandacht, €4.320 vervalt voor vrijdag."
• Een los alarm, en dat houd je heilig. Alleen fraudesignalen en echt dringende vervaldatums.

Als alles onmiddellijk verstuurt, stopt iedereen na twee weken met lezen. De waarde van een alarm zit volledig in het feit dat het zeldzaam is. Elke mail linkt met één klik door naar het juiste scherm, en wat blijft liggen komt terug, luider naarmate de vervaldag nadert.

Optioneel, en verrassend goedkoop om te bouwen: genereer een SEPA-betaalbestand (pain.001) voor de goedgekeurde facturen. De klant laadt dat één keer op bij de bank in plaats van tien keer een IBAN over te typen.

Waarom event sourcing hier de juiste keuze is

Bij de meeste software is event sourcing een overweging. Bij facturen is het bijna vanzelfsprekend, en dat komt door de wettelijke context: de bewaartermijn voor facturen in België is zeven jaar, en je moet kunnen aantonen wie wat wanneer deed.

We schreven er eerder een apart stuk over, event sourcing voor KMO-software, maar de kern is eenvoudig. In plaats van één rij in een tabel die je telkens overschrijft, schrijf je elke gebeurtenis weg: ontvangen, uitgelezen, gecontroleerd, ingedeeld, goedgekeurd, geboekt. Die log wordt nooit aangepast, alleen aangevuld.

Wat dat oplevert:

• Het auditspoor is altijd ingebouwd. Je hoeft geen apart logsysteem te bouwen; het is het gewoon systeem.
• Elk overzicht is een projectie. Openstaand saldo, cashflow deze week, statistieken per leverancier: allemaal afgeleid, allemaal herbouwbaar. En dit kan allemaal eenvoudig in een dashboard getoond worden, in plaats van het maandelijkse Excel-rondje.
• Je kan de geschiedenis opnieuw afspelen. Verbeter je de categorisatielogica, dan laat je ze los op alle oude events en zie je meteen wat er veranderd zou zijn. Dat is bij AI-componenten goud waard.
• Elke stap is idempotent en herstartbaar. Ging het uitlezen fout omdat de AI-provider plat lag? Je herstart één stap, niet het hele document.

Het origineel bewaar je hoe dan ook onaangeroerd in object storage, met een hash. Dat bestand is het wettelijke document; al de rest is afgeleide data die je desnoods opnieuw opbouwt.

Voor wie het technisch wil weten

Zo zouden wij dit bouwen:

Alles binnen de stippellijn is van jou en draait op jouw infrastructuur. Wat erbuiten staat, koop je aan of sluit je op aan. Dat onderscheid is belangrijker dan het lijkt: het bepaalt waar je data staat, wie er aan kan, en wat er gebeurt als een leverancier morgen zijn prijzen verdubbelt.

• Go voor de verwerkingspijplijn. Dit is een systeem van veel kleine, gelijktijdige stappen die op externe API's wachten, precies waar Go's concurrency-model voor gemaakt is. Eén statisch gelinkte binary in een kleine container, weinig geheugen, snel opstarten.
• Vue.js voor het nakijkscherm. De enige interface die er echt toe doet: factuur links, voorgestelde boeking rechts, alles wijzigbaar, goedkeuren in één toets. Zo'n scherm gebruikt iemand elke dag; het moet snel aanvoelen en toetsenbordvriendelijk zijn.
• PostgreSQL voor alles: de event log, de projecties én de wachtrij. Postgres is prima als message queue op dit volume, en dat scheelt je een hele component in productie. Geen aparte Redis of Kafka voor een KMO die vijfhonderd facturen per maand verwerkt.
• Object storage voor de originele documenten, met versleuteling en een bewaarbeleid van zeven jaar.
• Docker Compose achter Traefik, gedeployed op Europese cloud. Wij draaien onze eigen infrastructuur al jaren bij Scaleway, en waarom we die keuze maakten, staat in Europese cloud versus Amerikaanse alternatieven.

Eén keuze verdient extra aandacht: welk AI-model je gebruikt voor extractie en categorisatie. Facturen bevatten leveranciersgegevens, bedragen en soms persoonsgegevens. Die naar een Amerikaanse API sturen is een beslissing, geen detail. Europese modellen zoals die van Mistral zijn hier een volwaardig alternatief, en "je facturen verlaten Europa niet" is niet alleen principieel juist, het verkoopt ook. Wie onder NIS2 valt of levert aan iemand die eronder valt, krijgt die vraag sowieso op tafel.

Hoe weet je of de AI goed genoeg werkt?

Dit is de vraag die in dit soort projecten het langst onbeantwoord blijft, en het is de gevaarlijkste. Klassieke software crasht als er iets misgaat. Een taalmodel geeft altijd een antwoord, en dat antwoord klinkt even overtuigend of het nu juist is of niet. Een verkeerd ingedeelde factuur ziet er precies hetzelfde uit als een juiste, tot iemand bij de btw-aangifte begint te zoeken.

Daarom hoort bij dit soort systemen een testset: een paar honderd echte facturen, met de hand nagekeken, met vooraf vastgelegde drempels. Saai werk van enkele dagen, en meteen het beste wat je in zo'n project kan investeren. Een prompt herschrijf je op een namiddag; een geverifieerde testset niet.

Wat je concreet meet, is per stap verschillend:

• Extractie: klopt elk veld precies? Dit is objectief te scoren, want er is maar één juist factuurnummer en één juist bedrag.
• Indeling: stelt het systeem dezelfde grootboekrekening voor als de boekhouder gekozen zou hebben? Hier zijn twee cijfers belangrijker dan één totaalpercentage: hoe vaak stelt het iets fout voor, en hoe vaak durft het niets voor te stellen. Dat tweede is meestal het goedkopere probleem.
• De regels rond actie: hier meet je niet de AI maar je eigen logica, en die hoort deterministisch te zijn en dus honderd procent voorspelbaar.

Het moment waarop dit zich echt terugbetaalt, is de dag dat je AI-provider een nieuwe modelversie uitrolt of je zelf een prompt aanpast om één klacht op te lossen. Zonder testset weet je niet wat die wijziging elders stukmaakte. Met testset draai je de hele set opnieuw en zie je het meteen. Pin daarom de modelversie vast op een concrete snapshot in plaats van op "het nieuwste model", en test een nieuwe versie eerst in de schaduw voor je overschakelt.

De leerlus uit de vorige sectie is hier trouwens gratis brandstof: elke correctie die een gebruiker maakt, is een geverifieerd testgeval dat je kan bewaren.

Hoe je zo'n evaluatie praktisch opzet, welke cijfers er echt toe doen en waar de AI Act erbij komt kijken, staat in ons artikel AI testen en evalueren.

Waar gaat het meestal mis?

Een paar valkuilen die in de praktijk het vaakst opduiken:

• Dubbels. Dezelfde factuur komt binnen via Peppol én als "kopietje" per mail. Zonder ontdubbeling boek je alles twee keer.
• Te veel automatiseren in fase één. Wie meteen definitief boekt zonder nakijkscherm, verliest het vertrouwen van de boekhouder bij de eerste fout. En dat vertrouwen krijg je niet terug.
• Te veel notificaties. Ruis is erger dan stilte.
• Creditnota's, voorschotfacturen en deelbetalingen. Die breken elk naïef datamodel. Ontwerp er van bij het begin voor.
• Denken dat het AI-probleem het moeilijkste is. Dat is het niet. De aansluiting op het boekhoudpakket en de omgang met randgevallen kosten meer tijd dan de extractie.

Hoe wij dit bij Tandem Studio aanpakken

Wij bouwen dit soort systemen in fasen, met een vaste prijs per fase, zodat je na elke stap kan beslissen of de volgende de moeite waard is.

Fase 1: het minimum dat al werkt. Upload en e-mail input, extractie, nakijkscherm, één boekhoudkoppeling, dagelijkse digest. Meer niet. Je meet hier of de tijdswinst er echt is. Dat is exact de aanpak uit AI in je bedrijf: begin klein, denk groot.

Fase 2: de rest van de realiteit. Peppol-input, de fraude- en IBAN-controles, de feedback lus, een tweede boekhoudkoppeling.

Fase 3: verder dan inboeken. SEPA-betaalbestanden, matching met bestelbonnen, een dashboard voor boekhoudkantoren.

Die laatste fase is trouwens de interessantste vraag van allemaal: wie is de koper? Een KMO wil "laat mij geen betaling missen". Een boekhoudkantoor wil "laat mijn klanten stoppen met mij PDF's te mailen". Dezelfde pijplijn, een heel andere interface en een heel ander prijsmodel. Die vraag beantwoord je best vóór de eerste regel code.

En alles wat we bouwen draait op Europese servers, zonder vendor lock-in, met de code, de data en de infrastructuur in handen van de klant.

Veelgestelde vragen

Kan ik facturen automatisch laten inboeken zonder ze nog na te kijken?

Technisch wel, maar begin er niet mee. Boek automatisch wat het systeem met hoge zekerheid herkent en van een bekende leverancier komt, en laat de rest via een nakijkscherm lopen. Naarmate het systeem jouw gewoontes leert, verschuift die grens vanzelf.

Hoe weet ik of de AI betrouwbaar genoeg is om op te vertrouwen?

Door het te meten in plaats van het aan te voelen. Je legt een testset aan van echte facturen met het juiste antwoord erbij, spreekt vooraf af welk foutpercentage aanvaardbaar is, en draait die set opnieuw bij elke wijziging aan prompt of model. Zonder die meting is elke aanpassing een gok.

Heb ik hiervoor AI nodig nu e-facturatie verplicht is?

Steeds minder. Peppol-facturen zijn al gestructureerd en hebben geen AI nodig om uitgelezen te worden. AI blijft nuttig voor buitenlandse facturen, bonnetjes en scans, en vooral voor het voorstellen van de juiste grootboekrekening en categorieën.

Werkt zo'n systeem samen met mijn bestaand boekhoudpakket?

Ja, en dat is ook de bedoeling. De software vervangt je boekhoudpakket niet, ze vult het aan: ze levert kant-en-klare boekingsvoorstellen aan via de API van Exact Online, Yuki, Clearfacts, Odoo, Invoice Ninja of een ander pakket.

Hoe lang bewaart zo'n systeem mijn facturen?

Minstens zeven jaar, want dat is de wettelijke bewaartermijn in België. Het originele bestand blijft ongewijzigd bewaard; alle afgeleide data kan je desnoods opnieuw opbouwen.

Wat kost het om dit te laten bouwen?

Dat hangt volledig af van hoeveel koppelingen en randgevallen je nodig hebt. Daarom werken wij per fase met een vaste prijs: je start klein, meet de tijdswinst, en beslist daarna pas over de volgende stap.

Facturen overtypen is typisch werk dat software beter kan dan mensen: repetitief, foutgevoelig en volledig regelgestuurd. Zit jouw team er elke maand een paar dagen aan vast?

Vertel ons hoe jullie facturen nu binnenkomen, dan schetsen we samen wat er in fase één zou zitten.