Samenvatting
Een Nederlandse financiële dienstverlener ontvangt elke maand provisie van verzekeraars en banken, en bijna elke partij levert haar overzicht anders aan: Excel, pdf's met en zonder tekstlaag, per post ontvangen scans, zips met een wachtwoord, branchebestanden van miljoenen regels. Die verwerking liep via een PowerShell-applicatie op stored procedures en een backofficepakket dat wordt uitgefaseerd, en veel van de regels erachter zat in het hoofd van een of twee mensen. De nieuwe applicatie leest elk formaat via een eigen profiel, legt de levering naast het rekening-courantoverzicht en de bankontvangst, koppelt elke regel aan de juiste vestiging en zet wat is goedgekeurd klaar voor het datawarehouse, dat er de journaalpost voor het boekhoudpakket van maakt. Het project begon eind juni bewust smal, met één stroom van begin tot eind: vier dagen na de eerste regel code liep een volledige maand van die stroom door de inleesmotor, 110 batches en 40.639 regels, alle gevalideerd. Daarna groeide het in overleg met de klant naar vrijwel alle omzetgroepen.
De vraag
Vervang de oude provisieverwerking voordat het backofficepakket per 1 januari 2027 stopt. De opzegging daarvan moest rond 1 oktober de deur uit, en tegen die tijd moest er genoeg vertrouwen zijn dat de nieuwe applicatie het overneemt. Harde requirements lagen er bij de start niet, ook niet af te leiden uit de oude applicatie. De verwachting binnen het financeteam was voorzichtig: begin augustus werd in een teamoverleg betwijfeld of proefdraaien in het vierde kwartaal zou lukken, en een eigen inschatting binnen het team legde de overstap ongeveer een jaar later.
Wat ik heb gebouwd
- Een inleesmotor met per aanleverformaat een geversioneerd YAML-profiel voor herkenning, extractie en validatie; 45 profielen voor Excel (ook het oude .xls-formaat), CSV, digitale en gescande pdf's, wachtwoordbeveiligde bestanden, zips, Outlook-berichten en ADN-branchebestanden
- Deterministische extractie zonder taalmodel in de maandverwerking, een eis vanuit het controleraamwerk: elke leesregel staat in het profiel en een profielwijziging krijgt een nieuwe versie
- OCR voor per post ontvangen en ingescande overzichten met een vastgepinde modelversie, een nakijkscherm voor gescande bronnen en leescorrecties die aan de hash van het bestand hangen, zodat een correctie nooit stil op een andere levering terechtkomt
- Lezers die zuinig met geheugen omgaan: de ADN-lezer leest streamend uit de zip en houdt alleen de velden vast die het profiel noemt, de pdf-lezer sluit elke pagina na gebruik (bij één levering ging de piek van 573 naar 57 MB)
- Afstemming per betaalstroom en maand op drie totalen: de som van de specificaties, het rekening-courantoverzicht en de bankontvangst
- Koppeling van het agentnummer dat elke maatschappij voor dezelfde vestiging anders hanteert aan het interne vestigingsnummer, via een append-only koppeltabel waarin elke herkoppeling wordt gelogd
- Een server-rendered webinterface (FastAPI, Jinja2, htmx) met een dashboard en genummerde stations van upload tot akkoord, met een klikbare procesdemo in HTML als eerste toets bij de gebruikers
- Een append-only datalaag in SQL Server met 40 genummerde, idempotente migraties, leesviews per maatschappij, periode en stroom als koppelvlak naar het datawarehouse, en ruim 2.400 automatische tests
- Hosting op Azure App Service in hetzelfde netwerk als de datawarehouse-server, met aanmelding via Entra ID, het databasewachtwoord in Key Vault en een deployrecept met nameting
In detail
- Eén uploadknop voor alle aanleveringen: de applicatie herkent het bestand op naam, kolomkoppen of inhoud, leest op de achtergrond en toont per bestand wat ermee gebeurde
- Kolommen worden op naam gelezen, niet op positie: een extra kolom verstoort niets, en een hernoemde kolom die nodig is stopt de verwerking voordat er één regel in de database staat
- Verkeerd aangeleverde bestanden worden geweigerd, zoals een bestand dat al eerder is ingelezen of een levering voor een maand die al is goedgekeurd; een levering is in te trekken en opnieuw aan te bieden
- Een verschil blokkeert niet: de verwerker legt het vast met een reden uit een vaste lijst en een omschrijving die in het omschrijvingsveld van de boeking past, en het verschil reist mee naar het datawarehouse
- Per maatschappij een werkblad met de bijzonderheden van die bron, zodat kennis die bij een of twee mensen zat in de applicatie staat
- Gescheiden rollen via Entra ID-groepen: een verwerker geeft een betaalstroom per maand vrij en een goedkeurder geeft akkoord. Een goedgekeurde maand gaat niet meer open; een correctie loopt mee in de volgende maand
- Volledige herleidbaarheid: wie wanneer welk bestand heeft ingelezen, vrijgegeven of goedgekeurd, inclusief pogingen die mislukten
Resultaat
Ruim drie weken na dat teamoverleg, op 31 augustus, werkte het financeteam met echte maandbestanden in de applicatie; mei, juni en juli zijn inmiddels verwerkt en goedgekeurd. Bij het testen ging een levering zonder afwijkingen voor één omzetgroep in tien minuten door de applicatie. Volgens de procesverantwoordelijke kost die verwerking nu ongeveer drie dagen, en scheelt het drie tot vier dagen per maand voor die groep alleen. Het financeteam wilde die groep daarop meteen via de applicatie laten lopen; dat is bewust uitgesteld om de rest van het project niet te vertragen. Half september stelde de projectleider vast dat het sneller ging dan eerst gedacht. Nog niet bewezen is de laatste stap: de keten via het datawarehouse naar het boekhoudpakket heeft nog geen echte boeking opgeleverd.