Bouwen of integreren: de vraag die elke leverancier zich stelt
Op een gegeven moment in het bestaan van een boekhoudpakket vraagt een klant of hij een factuur als pdf kan uploaden in plaats van die opnieuw over te typen. Even later vraagt een andere klant hetzelfde voor een bankafschrift. Daarna voor een bon die met de telefoon is gefotografeerd. Elk verzoek lijkt op zichzelf een kleine extra functie — tot het technische team beseft dat een echt financieel document correct lezen, met wisselende lettertypen, scheefstaande tabellen en gefotografeerde bonnetjes, een serieus techniekprobleem is en geen vinkje dat je in één sprint afvinkt.
Deze pagina beschrijft hoe een API voor documentherkenning wordt ingebouwd in bestaande boekhoudsoftware — wat hij leest, wat hij teruggeeft, wat het per pagina kost, en waarom hosting binnen de Europese Unie geen bijzaak is als je eigen klanten Nederlandse of Europese bedrijven zijn die onder de AVG vallen.
Voor wie deze API is
Leveranciers van boekhoudsoftware
Inkoopfacturen en bankafschriften uitlezen om boekingen voor te bereiden, vóór controle door de gebruiker.
Leveranciers van ERP en bedrijfssoftware
Een ingebouwde documentmodule, zonder een eigen dedicated OCR-team op te bouwen.
Leveranciers van onkostensoftware
Met de telefoon gefotografeerde bonnen omgezet in gestructureerde onkostenregels: bedrag, datum, categorie.
Leveranciers van vastgoed- en verhuurbeheer
Kwitanties, waarborgrekeningafschriften en onderhoudsbonnen automatisch uitgelezen.
Leveranciers van loonadministratiesoftware
Loonstroken en UWV-bewijzen uitgelezen voor afstemming met de grootboekadministratie.
Accountantskantoren en concerns met een eigen tool
Een interne boekhoudtool, niet doorverkocht, met precies dezelfde behoefte aan documentherkenning als een commercieel SaaS-product.
Waarom je eigen OCR bouwen duurder is dan het lijkt
Een eerste prototype voor factuurherkenning, op een schone, goed gescande verzameling documenten, bouw je in een paar weken met opensource-OCR-bibliotheken. Het probleem zit bijna nooit in dat eerste prototype — het zit in wat erna komt: een bankafschrift van een bank die je nog nooit hebt gezien, een deels handgeschreven factuur, een gekreukt kassabonnetje dat tegen het licht in is gefotografeerd. Elke nieuwe, echte opmaak die in productie opduikt, onthult een geval dat het prototype niet dekte, en het team dat drie weken voor die module had ingepland, zit er achttien maanden later nog middenin.
De variatie in echte documenten houdt nooit op
Elke bank heeft haar eigen afschriftformaat, elke leverancier zijn eigen factuurindeling — een model dat op een beperkte steekproef is getraind, stuit voortdurend op gevallen die het nog nooit heeft gezien.
Onderhoud stopt nooit
Een opmaak die door een leverancier wordt gewijzigd, of een nieuwe bank die een klant toevoegt, breekt de extractie stilzwijgend totdat iemand het opmerkt en het model corrigeert.
Een toegewijd team aannemen is een forse investering
Kennis van computervisie en taalverwerking is lastig te werven en wordt navenant betaald, voor een product dat niet de kernactiviteit van de leverancier is.
Verwerkingsinfrastructuur heeft een vaste kostenpost
Rekenservers, wachtrijen, monitoring — infrastructuur die je continu onderhoudt en bewaakt, ook in maanden met een laag documentvolume.
Wat de API herkent
| Documenttype | Typisch gebruik |
|---|---|
| Inkoopfactuur | Boekingen voorbereiden en afstemmen op de bestelling |
| Bankafschrift | Automatische bankmatching en liquiditeitsopvolging |
| Bon / onkostennota | Gestructureerde onkostenregel: bedrag, datum, categorie, gedrukte btw |
| Loonstrook | Afstemming met loonboekingen en de sociale lasten |
| Pakbon | Controle tussen bestelling, levering en factuur |
Wat de API teruggeeft
Elk ingestuurd document komt terug als een gestructureerd JSON-object: de kopvelden (afzender, datum, documentnummer, totaalbedrag, btw), de regelniveaus wanneer het document die bevat (referentie, aantal, stukprijs), en een betrouwbaarheidsscore per veld, niet alleen voor het document als geheel. Precies die score stelt jouw software in staat om automatisch te beslissen welke velden je zonder twijfel overneemt en welke je aan een gebruiker voorlegt ter bevestiging, in plaats van elke extractie als 100% zeker te behandelen.
Prijs per pagina
De prijs wordt bepaald per succesvol verwerkte pagina — een document waarvan de extractie mislukt, wordt nooit gefactureerd. Geen verplichte contractdrempel vooraf, geen opgelegd maandminimum: de kosten volgen rechtstreeks het werkelijke volume dat jouw software verwerkt, wat de marge-berekening eenvoudig te integreren maakt in je eigen prijstabel.
| Maandelijks volume | Wat het voorstelt |
|---|---|
| Enkele honderden pagina's | Een eerste pilot met één of twee klanten om de integratie te valideren |
| Enkele duizenden pagina's | Een module die voor een deel van je klantenbestand is geactiveerd |
| Tienduizenden pagina's of meer | Een functie uitgerold over het volledige klantenbestand, met een dalend tarief per volume |
Het volledige overzicht van de staffels staat op de pagina prijzen.
Hoe de integratie werkt
Maak een API-sleutel aan
Een gratis account volstaat om een sleutel te krijgen en meteen te testen met echte documenten.
Stuur een document
Pdf, foto of scan — één API-call is genoeg om de extractie te starten.
Ontvang de gestructureerde JSON
Velden, regelniveaus en betrouwbaarheidsscores komen binnen seconden terug.
Bepaal je betrouwbaarheidsdrempel
Neem automatisch over boven een drempel, markeer voor menselijke controle eronder.
De stapsgewijze uitwerking van een volledige integratie, inclusief afhandeling van twijfelgevallen en monitoring in productie, staat in de integratiegids.
White label: jouw software, niet de onze
De integratie loopt volledig server-side. Jouw eindgebruiker uploadt een document in jouw eigen interface en ziet het resultaat verschijnen in jouw eigen software — zonder ooit een scherm, een logo of een verwijzing naar FlowParse tegen te komen. Het is jouw merk dat de functie draagt, niet het onze — hetzelfde white-label-principe dat wordt uitgewerkt op de pagina API voor ontwikkelaars van boekhoudsoftware.
AVG en hosting binnen de Europese Unie
Voor een leverancier die aan Nederlandse of Europese bedrijven verkoopt, is de locatie van de servers geen bijkomstig technisch detail — het is vaak een expliciete vraag in een aanbesteding of een beveiligingsbeoordeling van een grote klant. Documenten reizen versleuteld via TLS, worden verwerkt op servers binnen de Europese Unie en direct na de extractie verwijderd — zonder langdurige opslag van het originele document, zonder dat er ooit een model wordt getraind met de gegevens van jouw klanten.
Versleutelde overdracht van begin tot eind via TLS.
Verwerking uitsluitend op servers binnen de Europese Unie.
Directe verwijdering van het originele document na het uitlezen.
Geen enkel klantdocument wordt gebruikt om AI-modellen te trainen.
Het volledige detail staat op de pagina beveiliging.
De context van e-facturatie en UBL
Peppol en het verplichte gebruik van e-facturatie richting overheidsopdrachtgevers verschuiven een groeiend deel van het factuurverkeer naar een gestructureerd UBL-bestand in plaats van een pdf. Dat neemt de behoefte aan automatische documentherkenning niet weg: facturen die van een leverancier als pdf binnenkomen, bankafschriften en onkostenbonnen blijven ongestructureerde documenten die een boekhoudpakket moet lezen voordat die gegevens de administratie in kunnen. Het volledige detail van die overgang staat op onze pagina over e-facturatie en UBL verwerken en op de pagina over UBL-veldherkenning.
Voor een leverancier van boekhoudsoftware betekent dit dat een module voor het lezen van ongestructureerde documenten nodig blijft, ook wanneer e-facturatie breed wordt ingevoerd — niet elk document dat een klant aanlevert, is nu al, of zal ooit zijn, een reeds gestructureerde elektronische factuur.
Per type boekhoudsoftware
| Softwaretype | Wat de API toevoegt |
|---|---|
| Boekhoudsoftware | Boekingen voorbereiden op basis van facturen en bankafschriften |
| ERP / bedrijfssoftware | Automatische afstemming tussen pakbon, bestelling en factuur |
| Onkostensoftware | Gefotografeerde bonnen omgezet in onkostenregels binnen seconden |
| Vastgoedbeheer | Kwitanties en waarborgrekeningafschriften gelezen zonder opnieuw over te typen |
| Loonadministratie | Loonstroken en bewijzen afgestemd op de grootboekadministratie |
Het specifieke detail voor leveranciers van boekhoudsoftware, met de focus op grootboekrekeningen en btw, staat op de pagina API voor boekhoudsoftware.
Bouwen tegenover integreren: de volledige rekensom
Zelf bouwen
Werving van kennis op het gebied van computervisie, infrastructuur die je onderhoudt, voortdurende aanpassing aan nieuwe documentopmaken, meerdere maanden tot een eerste bruikbare module in productie.
Een API integreren
Een prijs per pagina die het werkelijke gebruik volgt, een integratie van één tot drie weken, en een computervisieteam dat nooit in je organigram hoeft te bestaan.
Betrouwbaarheid, nauwkeurigheid en twijfelgevallen
Geen enkele automatische extractie is 100% zeker over de volledige verzameling echte documenten die een klant kan uploaden — een verkleurd bonnetje, een foto bij slecht licht blijven grensgevallen voor elke engine. Het verschil zit niet in het beloven van perfecte nauwkeurigheid, maar in wat er gebeurt wanneer de extractie onzeker is: een betrouwbaarheidsscore per veld, niet alleen globaal, laat jouw software twijfelgevallen automatisch naar menselijke controle sturen in plaats van ze stilzwijgend in je gegevens op te nemen.
Een rekenvoorbeeld
Een leverancier van onkostensoftware heeft 200 actieve klanten, elk gemiddeld 40 bonnen per maand uploadend — zo'n 8.000 documenten per maand. Bij een prijs per pagina levert dat volume een voorspelbare integratiekost op, rechtstreeks door te berekenen in je eigen prijstabel per gebruiker, zonder de vaste kosten van een intern team die identiek zouden blijven als het volume verdubbelt of halveert.
| Post | Waarde |
|---|---|
| Actieve klanten | 200 |
| Bonnen per klant per maand | 40 |
| Totaal maandvolume | 8.000 documenten |
| Vergelijkbaar intern team om te onderhouden | 1 tot 2 fulltime engineers |
Beveiliging en beschikbaarheid
Een API die in productiesoftware wordt geïntegreerd, moet net zo beschikbaar en voorspelbaar zijn als elke andere dienst waarvan jouw eigen product afhankelijk is. Versleuteling onderweg, systematische verwijdering van documenten na verwerking, en een vastgelegd gedrag bij een korte onderbreking — het document blijft in een wachtrij staan in plaats van de gebruiker te blokkeren — maken vanaf het begin deel uit van de integratie, niet van een lapmiddel achteraf na een eerste incident.
Een bestaande OCR vervangen zonder alles te herschrijven
Een leverancier die al een extractie-engine gebruikt — intern of van een andere leverancier — hoeft niet de hele module te herschrijven om te migreren. De meest gangbare aanpak laat het oude en het nieuwe systeem parallel draaien op een steekproef van echte documenten, vergelijkt de geëxtraheerde velden en verplaatst pas geleidelijk het verkeer zodra het kwaliteitsverschil positief is bevestigd — zonder onderbreking voor klanten die al in productie draaien.
Wat deze API niet voor je doet
Vervangt jouw businesslogica niet
Boekhoudkundige matching, de berekening van de toepasselijke btw en het genereren van boekingen blijft logica van je eigen software.
Ontwerpt niet je gebruikersinterface
Het uploadscherm en het validatiescherm voor geëxtraheerde velden blijven nog te bouwen in je eigen product.
Bepaalt niet je betrouwbaarheidsdrempels
Het is jouw software die, naar eigen risicobereidheid, bepaalt welke scores een menselijke controle triggeren.
Vervangt geen accountant voor je eindklanten
Het zet een document om in gestructureerde gegevens; de fiscale of boekhoudkundige kwalificatie van die gegevens blijft, zoals vandaag, een zaak van de professional.
Voor wie dit precies is bedoeld
Deze API richt zich op technische teams van boekhoudsoftware-leveranciers die hun ontwikkeltijd liever aan hun eigen product besteden dan aan een documentleesengine die, voor de meesten van hen, niet de kernactiviteit is. De uitwerking van concrete scenario's, met doorgerekende voorbeelden per situatie, staat in de use case API voor ontwikkelaars van boekhoudsoftware.
Ondersteuning bij de integratie
Een API-sleutel zonder begeleiding laat het technische team alleen staan bij de eerste concrete vragen: hoe map je een bepaald veld, wat doe je met een grensgeval uit een echt document. Het supportteam antwoordt in het Nederlands, rechtstreeks op integratievragen, zonder om te leiden naar een generieke helpdesk die het detail van de extractie-engine niet kent.
Voor een integratie met veel impact — een grote klant, een migratie vanuit een bestaande leverancier — kan een intensievere begeleiding rechtstreeks met het technische team worden ingepland, in plaats van een klantenteam zelf te laten uitzoeken wat het verwachte gedrag is in specifieke gevallen.
Nauwkeurigheid, grenzen en voortdurende verbetering
Geen enkele extractie-engine haalt een perfecte nauwkeurigheid over de volledige verzameling echte documenten die een klant kan uploaden — de relevante vraag is niet 100% te beloven, maar precies te weten waar de grenzen liggen en hoe die worden opgevangen. Een betrouwbaarheidsscore per veld, in plaats van een globale belofte, laat jouw integratie een betrouwbaar resultaat onderscheiden van een resultaat dat een menselijke blik verdient — iets dat in de praktijk belangrijker is dan een nauwkeurigheidspercentage op een verkooppagina.
De engine verbetert bovendien mee met het verwerkte volume — een nieuwe documentopmaak die bij een klant wordt aangetroffen, komt na correcte verwerking ten goede aan alle integraties die dezelfde API gebruiken, zonder dat een individuele klant het probleem expliciet hoeft te melden voordat de kwaliteit globaal verbetert.
Wat er in de tijd verandert
Een geversioneerd responsschema garandeert dat een doorontwikkeling van de extractie-engine nooit stilzwijgend een integratie die al in productie draait, verandert — er kan een nieuw veld aan het antwoord worden toegevoegd zonder bestaande code te breken die daar nog niet op is voorbereid. Het is een structurele garantie, geen loze belofte, die vooral telt voor een leverancier wiens software jarenlang in productie blijft zonder volledige herschrijving.
Nieuwe ondersteunde documenttypen — een minder gangbaar loonstrookformaat, een afschrift van een recente neobank — worden geleidelijk aan de engine toegevoegd zonder enige actie van jouw kant: dezelfde API-call profiteert automatisch van die uitgebreide dekking.
Wat een technisch team in de eerste week ontdekt
De eerste stap die bijna elk team zet, is niet het schrijven van integratiecode, maar het insturen van een handvol eigen documenten om te zien hoe de respons er werkelijk uitziet — niet zoals beschreven in een verkooppagina, maar de daadwerkelijke JSON die terugkomt op een echte, niet geselecteerde factuur. Deze eerste test onthult meestal drie dingen tegelijk: hoe het datamodel van de API zich verhoudt tot het eigen datamodel, hoeveel handmatige mapping nodig is, en welk deel van de documenten die het team als "moeilijk" beschouwde eigenlijk probleemloos wordt verwerkt.
Wat teams vaak verrast, is niet de nauwkeurigheid op een schone factuur — dat wordt stilzwijgend verwacht — maar het gedrag op een grensgeval: een creditnota, een factuur in een vreemde valuta, een document met een handmatige aantekening erop. Precies die grensgevallen, niet de standaardfacturen, bepalen in de praktijk of een team na een week overtuigd verdergaat of nog twijfelt. Om die reden raadt de meeste documentatie aan om in die eerste week bewust een paar lastige documenten te kiezen in plaats van alleen de netste voorbeelden uit de eigen administratie.
Tegen het einde van die eerste week heeft een team doorgaans een duidelijk beeld van drie zaken: welke velden rechtstreeks bruikbaar zijn zonder enige aanpassing, welke velden een kleine mapping-stap nodig hebben, en welk percentage documenten een betrouwbaarheidsscore krijgt die te laag is om zonder controle te accepteren. Die laatste cijfers, meer dan een abstracte nauwkeurigheidsbelofte, vormen de echte basis voor de beslissing om verder te integreren.
Een groter platform doorgerekend
Het eerdere rekenvoorbeeld ging uit van 200 klanten en 8.000 documenten per maand — een realistisch startpunt voor een pilot of een eerste uitrol. Voor een platform dat al enkele duizenden actieve klanten bedient, verschuift de rekensom niet fundamenteel, maar de schaal maakt het verschil met een intern team veel zichtbaarder: bij 3.000 klanten die elk gemiddeld 30 documenten per maand uploaden, gaat het al om 90.000 documenten per maand — een volume waarbij een intern team van twee tot drie engineers eerder regel dan uitzondering wordt, terwijl de prijs per pagina bij een API-integratie simpelweg lineair meeschaalt zonder enige nieuwe vaste kostenpost.
Op die schaal wordt ook het verschil in staffelkorting relevant: de meeste leveranciers zien de prijs per pagina dalen naarmate het volume toeneemt, wat betekent dat de marge per document juist verbetert bij groei, in plaats van een intern team waarvan de kosten met horten en stoten toenemen — telkens een nieuwe engineer nodig is zodra het bestaande team de onderhoudslast niet meer aankan. Voor een platform dat snel groeit, is dat verschil in kostencurve vaak minstens zo belangrijk als het absolute bedrag in het eerste jaar.