Treasury-management-software laten maken
Appfront bouwt maatwerk treasury-software voor organisaties die hun kaspositie niet in één beeld krijgen: meerdere entiteiten, meerdere banken, soms meerdere valuta. Meestal bouwen we niet het complete treasurypakket maar de laag eromheen: een consolidatiebeeld over systemen die elkaar niet kennen, een prognose die op uw bedrijfsvoering is toegesneden, en een betaalproces waarin functiescheiding is afgedwongen. Past een standaardpakket beter, dan zeggen we dat.
Het probleem is zelden geld, het is overzicht
Treasury management gaat over het geld en de financiële risico's van een organisatie: de liquiditeitspositie over alle rekeningen en entiteiten, de prognose van in- en uitgaande stromen, het betalingsverkeer en het beheersen van valuta- en renterisico.
De beperking is zelden het bedrag op de rekening, maar het tijdstip waarop dat bekend is. Wie zeven rekeningen aanhoudt bij drie banken, hoort pas de volgende ochtend wat de stand van gisteren was, omdat het dagafschrift 's nachts wordt aangeleverd. Zolang dat zo is, kunt u niet sturen maar alleen achteraf vaststellen. Het beeld is telkens hetzelfde: bij de ene entiteit staat geld ongebruikt te wachten terwijl een andere diezelfde week op haar rekening-courantfaciliteit staat en daar rente over betaalt. Geen financieringsvraagstuk dus, maar een informatievraagstuk.
Deze pagina gaat over uw eigen geld: posities, prognose, betalingen en risico. Gaat het om klantbetalingen aannemen en transactieafstemming, dan hebt u eerder een payment platform nodig. Ze raken elkaar bij de afstemming, maar het toezichtkader verschilt wezenlijk.
Eén positie, alle rekeningen
Saldi en boekingen van elke bank in dezelfde structuur, met per rekening zichtbaar hoe oud de gegevens zijn. Kent u het uur niet, dan is het een schatting.
Prognose die u kunt narekenen
Een prognose wordt pas beter als de afwijking met de realisatie wordt teruggekoppeld. Zonder die lus blijft de aanlevering jaar na jaar even grof.
Betalen met beheersing
Wie een betaling klaarzet, keurt hem niet zelf goed. Dat vier-ogenprincipe hoort in de software te zitten, niet in het procesboek.
Wat er in de praktijk misgaat
Vier situaties die we bij vrijwel elke treasury-opdracht tegenkomen. Herkent u er geen enkele, dan volstaat uw inrichting waarschijnlijk.
De ochtendpositie is al achterhaald
Het dagafschrift van gisteren komt vannacht binnen. Om negen uur kent u dus de stand van vóór de salarisrun en vóór de grote leveranciersbatch. Wie de dag door wil sturen, heeft tussentijdse rapportage nodig, en die is doorgaans een aparte bankdienst die niet elke dochter levert. Wij tonen daarom per rekening hoe actueel de gegevens zijn.
Een prognose die niemand naloopt
De prognose komt per entiteit uit een spreadsheet, met verschillende peildata, verschillende aannames over debiteurenbetaalgedrag en een controller die zijn cijfer bewust voorzichtig houdt. De afwijking met de realisatie gaat nooit terug naar de indiener. Een model wordt pas beter als het zichzelf corrigeert op historische betaalpatronen per debiteur en per seizoen. Daar levert een predictive analytics dashboard meer op dan een extra kolom.
Het rekeningnummer dat stilletjes veranderde
Een leverancier meldt per mail een nieuw rekeningnummer, met geloofwaardige reden en bestaand dossiernummer. De crediteurenadministratie past het aan. Weken later loopt een volstrekt normale betaling naar een rekening die niet van die leverancier is. Het lek zit niet in het betaalmoment maar in het wijzigingsmoment, en juist die mutatie verloopt vaak zonder tweede paar ogen.
De intercompany-post die niemand kan verklaren
Zodra entiteiten onderling verrekenen, ontstaat feitelijk een in-house bank: de holding houdt de externe bankrelatie aan, de dochters krijgen een interne rekening-courant. Dat concentreert liquiditeit, maar administratief is het taai. Elke entiteit heeft een eigen grootboek en niet zelden een eigen ERP, omrekening gebeurt op verschillende koersdata, rente moet zakelijk worden toegerekend, en aan het eind van het kwartaal blijft een verschil staan dat niemand terugvindt. Een verrekenmodel dat per mutatie koers, rentevoet en tegenboeking vastlegt, is meestal waar maatwerk het meest oplevert.
De koppelingen waar het echt op vastloopt
Treasury-software staat of valt bij de verbinding met de bank, en die loopt over standaarden die u niet zelf bepaalt. Rekeninginformatie en betaalopdrachten gaan via de ISO 20022-berichtenstandaard, volgens Betaalvereniging Nederland de internationale standaard voor digitale gegevensuitwisseling in het betalingsverkeer. SWIFT gebruikt die sinds eind 2025 voor alle berichten tussen financiële instellingen.
Twee berichten doen het meeste werk. Het dagafschrift komt binnen als camt.053, het Bank to Customer Statement, volgens Betaalvereniging Nederland de opvolger van het oudere MT940-bericht en met rijkere, beter gestructureerde gegevens. Betaalopdrachten gaan de andere kant op als pain.001, de SEPA Credit Transfer Initiation, met pain.008 voor incasso's en pain.002 als statusterugkoppeling met de afgekeurde posten. Binnen die standaarden maken banken eigen invulkeuzes: hetzelfde veld wordt anders gevuld, legacysystemen vragen nog om MT940 en een buitenlandse dochter levert net een andere variant. Reken op mapping per bankrelatie en op onderhoud bij elke formaatwijziging.
Rekeninginformatie via PSD2 ophalen kan een goede route zijn, maar er hoort een vergunning bij. Een rekeninginformatiedienst is volgens de Wet op het financieel toezicht een betaaldienst, en artikel 2:3a verbiedt het bedrijf van betaaldienstverlener uit te oefenen zonder vergunning van De Nederlandsche Bank. Die hebben wij niet. PSD2-koppelingen lopen dus via een vergunninghouder: een bewuste keuze, met eigen kosten en een eigen afhankelijkheid.
Sinds oktober 2025 verplicht de Instant Payments Verordening banken tot verificatie van de begunstigde: de bank van de ontvanger controleert de tenaamstelling bij het IBAN en meldt terug of die goed, bijna goed, niet goed of niet controleerbaar is. Voor uw systeem is dat een extra uitkomst om te tonen, vast te leggen en te kunnen overrulen.
Wie klaarzet, keurt niet goed
Functiescheiding is geen bureaucratische luxe maar de belangrijkste beheersmaatregel die u hebt: wie een betaling of batch klaarzet, mag hem niet zelf vrijgeven. Bij de gewone betaalrun wordt dat zelden doorbroken. Het gaat mis bij de uitzondering: de spoedbetaling op vrijdagmiddag, de vakantieperiode waarin één persoon beide rollen krijgt, of het beheerderaccount dat toevallig ook mag goedkeuren.
Software kan die uitzonderingen dichtzetten op een manier die een procedure niet kan. Rollen hangen aan functies en niet aan personen, een tweede rol op hetzelfde account telt niet als tweede paar ogen, en een spoedprocedure verlaagt de drempel niet maar registreert extra.
Bij fraude met een gewijzigd leveranciersrekeningnummer geldt dezelfde logica één stap eerder: behandel de mutatie op het crediteurenbestand als een eigen handeling met eigen goedkeuring, bewaar de uitkomst van de begunstigdecontrole bij de betaalopdracht en markeer een eerste betaling naar een nieuw IBAN als uitzondering. Werkt u in een gereguleerde sector, dan sluit DORA-compliance-software hierop aan.
- Vier-ogenprincipe op elke uitgaande batch, ook bij spoed
- Klaarzetten en goedkeuren gescheiden in rollen, niet in personen
- Autorisatiegrenzen per bedrag, valuta en tegenrekening
- Crediteur-IBAN wijzigen als apart goed te keuren proces
- Uitkomst begunstigdecontrole vastgelegd bij de betaalopdracht
- Eerste betaling naar een nieuw IBAN als bewuste uitzondering
- Auditlog die achteraf niet aanpasbaar is
- Statusterugkoppeling van de bank automatisch afgestemd
- Beheerrechten gescheiden van betaalrechten
Test je idee eerst — werkend prototype in 1 dag
Met OneDayBuild maken we je idee in één dag tastbaar voor €950, zodat je weet of verdere ontwikkeling de investering waard is. Besluit je door te gaan met de volledige bouw? Dan verrekenen we de kosten volledig.
Bekijk OneDayBuild →Wanneer u dit niet bij ons moet laten bouwen
Er bestaan volwassen treasurypakketten: Kyriba, Nomentia en TIS, en de treasurymodules van de grote ERP-leveranciers. Voor een organisatie met een gangbare structuur, een handvol entiteiten, een of twee bankrelaties en de euro als hoofdvaluta is zo'n pakket vrijwel altijd de betere keuze. De reden is niet functionaliteit maar infrastructuur: de bankkoppelingen liggen er, de formaatverschillen per bank zijn opgevangen, het sleutelbeheer is ingericht en de beveiliging rond betaalopdrachten is uitontwikkeld, en dat blijft onderhouden als een standaard wijzigt. Opnieuw bouwen kost veel en levert niets onderscheidends op.
Maatwerk loont in een beperkt aantal situaties. De eerste is de schil erbovenop: een consolidatiebeeld over systemen die elkaar niet kennen, bijvoorbeeld drie ERP's uit drie overnames plus een projectadministratie, waarbij niet het pakket het probleem is maar de herkomst van de gegevens. De tweede is een prognosemodel waarin projectfasen of contractuele mijlpalen de kasstroom bepalen op een manier die een standaardmodel niet kent. De derde is een structuur die pakketten niet verwachten, zoals vennootschappen die per project ontstaan en verdwijnen.
Weeg mee wat u binnenhaalt. Zodra u zelf betaalopdrachten aanmaakt en beveiligde bankverbindingen onderhoudt, komt het beheer van certificaten, sleutels en toegangsrechten bij u te liggen, inclusief de vraag wie dat overneemt als degene die het inrichtte vertrekt. Bent u een financiële entiteit, dan valt een zelfgebouwd systeem onder DORA, Verordening (EU) 2022/2554, van toepassing sinds 17 januari 2025. Vaak is de verstandige uitkomst een combinatie: het pakket houdt de bankkoppeling en de betaaluitvoering, het maatwerk levert het overzicht en het model.
Veelgestelde vragen over treasury-software op maat
De vragen die iemand stelt vlak voordat hij tekent, inclusief de ongemakkelijke.
Vaak moet u dat ook doen. Pakketten als Kyriba, Nomentia en TIS en de treasurymodules van de grote ERP-leveranciers hebben de bankkoppelingen, het sleutelbeheer en de beveiliging rond betaalopdrachten al ingericht en onderhouden die. Bij een handvol entiteiten, een of twee banken en de euro als hoofdvaluta is een pakket vrijwel altijd beter. Maatwerk telt pas als u structureel iets nodig hebt wat het pakket niet doet.
Niet op eigen naam. Een rekeninginformatiedienst is volgens de Wet op het financieel toezicht een betaaldienst, en artikel 2:3a verbiedt het uitoefenen van het bedrijf van betaaldienstverlener zonder vergunning van De Nederlandsche Bank. Die vergunning hebben wij niet. We koppelen daarom via een partij die hem wel heeft, of we halen de gegevens op via het zakelijke kanaal van uw bank met camt-berichten.
Door functiescheiding af te dwingen in de software in plaats van te beschrijven in een procedure. Wie een batch klaarzet, kan die niet zelf goedkeuren, ook niet met een spoedstatus en ook niet via een tweede rol op hetzelfde account. Daarnaast gelden autorisatiegrenzen per bedrag, valuta en tegenrekening, en registreert een auditlog elke stap onveranderlijk.
Gedeeltelijk, en het is eerlijker om de grens te benoemen. Sinds oktober 2025 verplicht de Instant Payments Verordening banken tot verificatie van de begunstigde: de bank van de ontvanger controleert de tenaamstelling bij het IBAN en meldt terug of die goed, bijna goed, niet goed of niet controleerbaar is. Dat helpt bij de overboeking. De fraude begint eerder, bij de wijziging in uw crediteurenbestand, en juist daar leggen wij goedkeuring en vastlegging op.
De broncode, documentatie en infrastructuurdefinities zijn van u, vastgelegd in de overeenkomst en ondergebracht in een repository waar u zelf toegang toe hebt. We bouwen op algemeen gangbare technologie zodat een andere partij het kan overnemen. Vraag die afspraken bij elke leverancier expliciet op voordat u tekent, ook bij ons.
Uw accountant wil vaststellen dat betalingen alleen langs een goedgekeurde route ontstaan. Dat vraagt een auditlog die per betaling toont wie hem aanmaakte, wie goedkeurde en welke status de bank terugmeldde, aansluiting tussen wat het systeem verstuurde en wat het bankafschrift toont, en een gedocumenteerd rechtenmodel. Bent u een financiële entiteit, dan komen de DORA-verplichtingen daarbovenop.
Gerelateerde diensten
Drie aangrenzende vraagstukken. Zit uw vraag daar dichter bij, begin dan daar.
Payment platform laten bouwen
Niet uw eigen kaspositie, maar klantbetalingen aannemen, uitbetalen aan aangesloten partijen en transacties afstemmen.
Predictive analytics dashboard
Zit de kern in de kwaliteit van de prognose, dan is dat eerder een voorspellend model dan een treasurysysteem.
DORA-compliance-software
Bent u een financiële entiteit, dan brengt zelfbouw registratie- en testverplichtingen mee.
Eerst uitzoeken of u dit wel moet bouwen
Vertel ons hoeveel entiteiten en bankrelaties u hebt, hoe de positie nu tot stand komt en waar het schuurt: de actualiteit van de cijfers, de prognose, het betaalproces of de onderlinge verrekening. We zeggen ook wanneer een standaardpakket de betere keuze is.