Intern afstemmingsplatform: een case study over procesautomatisering
De meeste projecten in onze klantcases beginnen met het probleem van een klant. Dit project begon met dat van ons.
Het systeem in één oogopslag
Het probleem
Elke week moest iemand van ons team leveranciersbetalingen, energierekeningen en facturen met de hand matchen aan inkooporders, verspreid over vijf aparte betaalbronnen: twee traditionele banken, twee neobanken en PayPal. Elke bron had zijn eigen afschriftformaat, zijn eigen login en zijn eigen exporteigenaardigheden. De vijf bronnen praatten niet met elkaar.
Het proces draaide op spreadsheets. Een betaling kwam binnen op een van de vijf rekeningen, en iemand kopieerde de gegevens naar een trackingsheet, en zocht daarna de bijbehorende inkooporder op om te controleren of het bedrag, de leverancier en de datum klopten. Wanneer dat niet zo was, moest iemand uitzoeken waarom: een deelbetaling, een valutaomrekening, een dubbele afschrijving, een inkooporder die nooit was aangemaakt.
Dat werk vroeg meestal geen oordeel. Het vroeg aandacht, en aandacht is precies wat een vijfvoudige handmatige afstemming het snelst opeet. Rijen werden overgeslagen. Matches werden gemist tot het einde van de maand. De spreadsheet klopte uiteindelijk wel, maar "uiteindelijk" kostte elke week flink wat uren, en die uren kwamen uit een financeteam dat andere dingen te doen had.
Wat we bouwden
We bouwden een intern platform dat betaaldata uit alle vijf bronnen haalt (de bankrekeningen voor leveranciers en nutsvoorzieningen, de neobankrekeningen en PayPal) en elke transactie automatisch matcht aan de bijbehorende inkooporder. Dit valt onder dezelfde categorie werk die we beschrijven op onze pagina over interne tools: software gebouwd voor een workflow die al binnen een bedrijf bestaat.
Het platform doet het matchen dat de spreadsheet vroeger met de hand deed. Het haalt de transactie op, vindt de bijbehorende inkooporder, controleert het bedrag en de leverancier, en markeert alles wat niet netjes afstemt. Een schone match heeft helemaal geen mens nodig. Een uitzondering (een deelbetaling, een mismatch, een ontbrekende inkooporder) wordt naar boven gehaald zodat iemand ernaar kijkt, in plaats van begraven te liggen in een rij die iemand misschien pas nakijkt als de sheet wordt gereviewd.
We bouwden het zoals we elk project bouwen: een afgebakende eis, AI-gestuurde ontwikkeling, en menselijke review op elke wijziging voordat die met echt geld in aanraking kwam. Financiële software kent geen enkele tolerantie voor een plausibel ogende bug, dus de reviewdiscipline was hier eerder nog strakker dan gewoonlijk.
Hoe een betaling wordt afgestemd
Ophalen
De transacties komen binnen uit alle vijf de betaalbronnen.
Matchen
Het platform vindt de inkooporder en controleert het bedrag en de leverancier.
Signaleren
Alles wat niet netjes klopt, gaat naar een medewerker.
Bevestigen
Een directe match vraagt helemaal geen menselijke tussenkomst.
Wat naar een medewerker gaat
Dit zijn de gevallen die zich vroeger in een spreadsheetrij verstopten.
Deelbetaling
Er kwam minder binnen dan het factuurtotaal.
Valutaomrekening
Het bedrag wijkt af doordat de betaling van valuta wisselde.
Dubbele afschrijving
Dezelfde betaling verschijnt twee keer.
Ontbrekende inkooporder
Een betaling heeft geen inkooporder om tegen af te stemmen.
Het resultaat
Het platform bespaart ongeveer 10 uur handmatig afstemwerk per week. Die tijd ging vroeger op aan het overtikken van getallen tussen een bankafschrift en een spreadsheet. Nu gaat ze naar de uitzonderingen die echt een beslissing nodig hebben, en naar de rest van het werk van finance.
We hebben dit niet één keer gebouwd en losgelaten. Het draait nog steeds in productie, stemt nog steeds live betalingen af over alle vijf bronnen, elke week, op dit moment.
Waarom dit iets bewijst wat klantcases niet kunnen
Een klantcase vertelt je wat we voor iemand anders hebben gebouwd. Ons eigen platform vertelt je waar we ons eigen geld aan toevertrouwen.
Wij zijn onze eigen eerste en strengste klant. Niemand geeft een financetool het voordeel van de twijfel zoals een externe klant dat zou doen; als de matchinglogica een discrepantie mist, zijn wij degenen die daar door schade en schande achter komen, op onze eigen boeken. Dat is een andere lat dan een feature opleveren en doorgaan naar het volgende contract.
Dit platform zelf draaien betekent dat elke claim die we maken over AI-gestuurde ontwikkeling (de aanpak met vaste scope, de reviewdiscipline, de opleversnelheid) al is getoetst aan een use case zonder ruimte voor een schouderophalen en een patch volgende sprint. Het is dezelfde reden waarom onze pagina over ons opent met de tools die we voor ons eigen vertaalbedrijf bouwden voordat Globaprom bestond: we vragen een klant niet om een aanpak te vertrouwen die we niet al zelf hebben gedraaid, op iets wat voor ons telt.
Zo krijg je hetzelfde soort project
Als afstemming, matching of een ander handmatig financeproces nog steeds uren uit je week opeet, vertel ons dan hoe het vandaag werkt. We komen terug met een vaste scope, een vaste prijs en een opleverdatum in weken, hetzelfde proces waarmee we het platform bouwden dat we zelf nog draaien.