Straight through processing bij SEPA: betalingen zonder handwerk
2026-05-17
De maandafsluiting ziet er in een klein financieel team vaak hetzelfde uit. Iemand exporteert een spreadsheet uit het ERP. Iemand anders past kolomnamen aan, haalt lege regels weg en zoekt ontbrekende rekeningnummers. Een junior ontwikkelaar schrijft een scriptje om het bestand om te bouwen, maar één leveranciersregel breekt nog steeds de import. De bank keurt een deel van de batch af, en finance mag uitzoeken wat er misging.
Dat is het echte vertrekpunt van straight through processing (STP): geen glanzende automatiseringsplaatjes, maar rommelige Excel-bestanden, oude exportformaten en een team dat betalingen op tijd en foutloos de deur uit wil krijgen. STP vervangt herhaald handwerk door een gecontroleerde digitale stroom. Voor finance betekent dat minder correcties en een duidelijker audittrail; voor ontwikkelaars een pijplijn die imperfecte brongegevens accepteert, controleert, omzet en alleen tegenhoudt wat aandacht nodig heeft.
Van handwerk naar een automatische stroom
Een afgekeurd bankbestand komt zelden door de bank. Het komt doordat de brongegevens in drie formaten binnenkwamen, een leverancier een nieuw rekeningnummer heeft en omschrijvingen per afdeling anders worden ingetypt. Je team verstuurt dan niet alleen geld, maar is ook de vertaallaag tussen boekhoudexports, bankeisen, interne controles en last-minute correcties. Elke kopieer- en plakstap voegt risico toe.
Het echte obstakel zit ergens anders dan je denkt
STP begint zelden bij bankkoppelingen of een nieuw betaalplatform, maar bij veel minder glamoureus werk:
- exports opschonen zodat elke kolom altijd hetzelfde betekent;
- oude velden koppelen aan de vereiste betaalstructuur;
- fouten vroeg vangen voordat de bank het bestand afkeurt;
- uitzonderingen apart zetten zodat één foute regel niet de hele batch stopt.
Vuistregel: Moeten je bronbestanden elke keer door een mens worden geïnterpreteerd, dan heb je nog geen straight through processing. Dan heb je gedeeltelijke automatisering met handmatig reddingswerk eromheen.
Wat is straight through processing?
Straight through processing betekent dat een transactie van begin tot eind wordt verwerkt zonder handmatige tussenkomst. Een handmatig proces werkt als een werkplaats waar iemand elk stuk met de hand bewerkt; STP werkt als een lopende band die gestructureerde invoer ontvangt, regels toepast en het werk afmaakt, tenzij er iets echt een mens nodig heeft.
Je meet STP als het aandeel transacties dat zonder handwerk wordt afgerond: van opdracht via controle en omzetting tot aanlevering. STP is dus geen product dat je koopt, maar een eigenschap van je werkwijze. Moet iemand elke batch opnieuw opmaak herstellen, gegevens overtypen of resultaten met de hand afletteren, dan is het proces niet straight through.
Waarom finance en ontwikkeling er allebei iets aan hebben
Voor finance:
- fouten worden eerder gevonden, omdat systemen vóór het aanleveren controleren;
- betalingen gaan sneller, omdat minder transacties in een controlewachtrij staan;
- de audittrail wordt beter, omdat elke stap digitaal wordt vastgelegd;
- het werk wordt kleiner, omdat medewerkers alleen uitzonderingen behandelen.
Voor ontwikkelaars is STP een ontwerpvraag: wisselen je systemen betrouwbaar gestructureerde gegevens uit, is de koppellogica expliciet en zijn uitzonderingen zichtbaar in plaats van begraven in mailboxen?
Kernpunt: Een goede STP-workflow haalt mensen niet volledig uit het proces. Hij haalt ze weg bij het routinewerk.
SEPA is gebouwd voor gestructureerde, machineleesbare uitwisseling via ISO 20022. Zijn je brongegevens goed voorbereid, dan is de betaalketen goed te automatiseren.
De bouwstenen van een STP-architectuur
Het lastige deel is zelden de laatste stap richting bank, maar de overdracht van bedrijfsgegevens naar een formaat waar machines op kunnen vertrouwen. Vergelijk het met de beveiliging op Schiphol: niet iedereen komt in dezelfde staat aan, maar het systeem herkent wat door mag, wat gecorrigeerd moet worden en wat moet worden tegengehouden.
Begin met machineleesbare invoer. De ene spreadsheet noemt een kolom “IBAN”, de andere “Rekeningnummer”, een derde zet bankgegevens in een vrij tekstveld. Laat je al die variatie direct toe, dan wordt elke volgende stap breekbaar. De eerste ontwerpvraag is dus niet “welke API?”, maar “hoe zet ik alles wat het bedrijf aanlevert om naar één betrouwbare interne structuur?”
| Bouwsteen | Wat hij doet | Zonder deze bouwsteen |
|---|---|---|
| 1. Invoerlaag | Accepteert Excel, CSV, JSON of oudere exports en zet ze om naar één intern model | Elk bronsysteem krijgt eigen koppelregels en uitzonderingen |
| 2. Controlelaag | Controleert verplichte velden, formaten, IBAN’s en dubbele regels | Afkeur bij de bank in plaats van intern |
| 3. Koppellaag | Zet gegevens om naar de juiste SEPA XML-structuur | Handmatig herstel van structuur en velden |
| 4. Uitzonderingenwachtrij | Zet foute regels apart, de rest gaat door | Eén foute regel blokkeert de hele batch |
Verbind je ERP, boekhouding en bankkanaal, leg dan duidelijke gegevensafspraken vast. Meer daarover in een betaalplatform koppelen aan je systemen.
Een stappenplan voor STP
STP hoeft geen groot transformatieprogramma te zijn. Behandel het als een gefaseerd project met technische ondersteuning.
Fase 1: het proces in kaart brengen
Loop één betaalcyclus door, van export tot aanlevering en afletteren, en noteer elk handmatig moment: goedkeuringen per mail, aanpassingen in spreadsheets, hernoemde kolommen, afgekeurde uploads, telefoontjes om rekeningnummers te checken. Vraag:
- waar ontstaan de gegevens?
- wie past ze aan vóór het aanleveren?
- welke controles gebeuren op het oog?
- welke fouten komen steeds terug?
- wat blokkeert de hele batch in plaats van één regel?
Fase 2: standaardiseren en een tool kiezen
Veel bedrijven hebben eerst geen orkestratieplatform nodig, maar een betrouwbare manier om rommelige bestanden om te zetten naar geldige output.
Vuistregel: Begin waar het misgaat. Breekt de batch vóór het aanleveren, richt je dan eerst op omzetten en controleren, en pas daarna op goedkeuringsroutes.
Fase 3: een pilot
Kies één soort betaling, één bv of één terugkerende batch. Draai de nieuwe werkwijze een tijd parallel met de oude en vergelijk regel voor regel.
| Vraag in de pilot | Waarom het telt |
|---|---|
| Kan finance velden koppelen zonder steeds een ontwikkelaar? | Dagelijkse bruikbaarheid |
| Houden foute regels alleen zichzelf tegen? | Veerkracht |
| Ziet het team waarom een regel faalde? | Supportlast |
| Is er een spoor van bronbestand naar output? | Controle en review |
Fase 4: gecontroleerd opschalen
Breid uit naar meer bestandstypes, entiteiten of tegenpartijen zodra de pilot stabiel is. Documenteer je veldregels, bevries naamgeving waar mogelijk en spreek af wie sjablonen mag wijzigen, zodat niemand met een “kleine” aanpassing de koppeling breekt.
Controles en beveiliging in STP
Het grootste bezwaar tegen STP: “Automatisering is prima, tot er heel snel een verkeerde betaling uitgaat.” Terecht. Het antwoord is niet vertragen, maar controles in de workflow bouwen. Routinezaken met veel zekerheid gaan automatisch door; ongebruikelijke of onzekere zaken gaan naar een beoordelaar. Denk aan:
- naamcontrole van de begunstigde, die je bank doet via de IBAN-naamcheck of Verification of Payee;
- IBAN- en rekeningcontrole vóór het maken van het bestand, bijvoorbeeld met de IBAN-validator;
- goedkeuringsdrempels voor hogere of afwijkende bedragen;
- regels voor begunstigden, zoals een lijst met bekende leveranciers;
- vastleggen van uitzonderingen voor audit en geschillen.
Kernpunt: Beveiliging wordt beter als het systeem vastlegt wat er gebeurde, waarom, en wie de uitzonderingen goedkeurde.
Een veilige opzet werkt in lagen: eerst formaat en volledigheid, dan bedrijfsregels, dan uitzonderingen op basis van risico, en tot slot logs die zowel auditors als medewerkers begrijpen. Controleer ook het uiteindelijke bestand vóór het aanleveren; zie SEPA XML valideren.
STP voor SEPA met GenerateSEPA
Veel teams weten al waar hun obstakel zit: inconsistente brongegevens omzetten naar een geldig SEPA-bestand, zonder de hele financiële omgeving om te bouwen.
Zonder conversielaag: spreadsheet exporteren, kolommen opschonen, lege velden vullen, koppen hernoemen, omschrijvingen kopiëren, bestand maken, uploaden, afkeur, opnieuw beginnen.
Met een conversielaag: het bronbestand wordt geüpload of via een API aangeleverd, kolommen worden één keer gekoppeld en hergebruikt, en de controle vangt rekening- en structuurfouten voordat de bank het bestand ziet.
GenerateSEPA zet Excel, CSV en JSON om naar SEPA XML, met een kolomkoppeling die wordt onthouden, IBAN-controle vooraf en een JSON-API voor automatisering. Daarmee is het een concrete invulling van de koppellaag die STP in veel mkb-bedrijven tegenhoudt. Finance krijgt herbruikbare sjablonen en controle vóór het aanleveren; ontwikkelaars hoeven niet elke spreadsheetvariant in breekbare scripts te bouwen en kunnen zich richten op goedkeuringen en afletteren.
| Controlepunt | Hoe goed eruitziet |
|---|---|
| Invoer | Accepteert de bestanden die je bedrijf al maakt |
| Koppeling | Je bepaalt zelf welke kolom bij welk SEPA-veld hoort |
| Controle | Foute gegevens worden vóór het maken van de XML gemeld |
| Uitzonderingen | Duidelijk welke regels aandacht nodig hebben |
| Automatisering | Een API voor terugkerende stromen |
Je STP-percentage meten en verbeteren
De test is eenvoudig: hoeveel transacties gaan van bronbestand naar bankklare output zonder dat iemand iets herstelt, overtypt of omleidt? Dat percentage is je STP-percentage.
Ter vergelijking: het gemiddelde wereldwijde STP-percentage voor grensoverschrijdende betalingen is volgens IBM slechts 26%. Je hoeft geen wereldgemiddelde te halen om vooruitgang te boeken; het gaat erom dat je ziet waar handwerk je proces binnenkomt en die oorzaken één voor één wegneemt.
Houd een korte set kengetallen bij:
- STP-percentage: aandeel transacties zonder handwerk;
- uitzonderingspercentage: aandeel dat naar controle gaat;
- doorlooptijd: van ontvangst van het bestand tot klaar voor aanlevering;
- kosten per transactie in je eigen proces;
- belangrijkste foutoorzaken, zodat je ze bij de bron kunt oplossen.
Vuistregel: Komt dezelfde uitzondering elke week terug, dan is het geen uitzondering meer. Dan is het een ontwerpfout.
| Oorzaak | Symptoom | Oplossing |
|---|---|---|
| Onjuiste gegevens begunstigde | Regel faalt bij controle of wordt afgekeurd | Velden controleren bij invoer, stamgegevens consequent bijwerken |
| Verschuivende spreadsheetindeling | Een werkend sjabloon koppelt ineens verkeerd | Sjablonen vastzetten, koppelingen versioneren, waarschuwen bij gewijzigde koppen |
| Oud script of exportformaat | Bestand onvolledig of kapot | Een vaste koppellaag in plaats van losse scripts |
| Ontbrekende omschrijving | Transactie wacht op opheldering | Verplichte bronvelden vastleggen, onvolledige regels vroeg afwijzen |
| Risicoregel slaat aan | Regel wordt vastgehouden ondanks correcte opmaak | Naar een controlewachtrij met duidelijke reden en goedkeuringsroute |
Verbetering begint bijna altijd stroomopwaarts: strakkere bronsjablonen, consequent veldgebruik en koppelregels onder wijzigingsbeheer.
Bereid je SEPA-bestanden nog met de hand voor? Probeer GenerateSEPA 7 dagen gratis en zet je eigen Excel- of CSV-bestand om naar bankklare SEPA XML.
Veelgestelde vragen
- Wat is straight through processing?
- Straight through processing (STP) betekent dat een transactie van begin tot eind wordt verwerkt zonder handmatige tussenkomst. Je meet het als het aandeel transacties dat zonder handwerk van bronbestand tot bankklare opdracht komt. Het is geen product dat je koopt, maar een eigenschap van je werkwijze.
- Wat heb je nodig voor straight through processing bij SEPA?
- Vier bouwstenen: een invoerlaag die je bestaande Excel-, CSV- of JSON-bestanden accepteert, een controlelaag voor verplichte velden en IBAN's, een koppellaag die de gegevens naar SEPA XML omzet, en een uitzonderingenwachtrij voor regels die menselijke controle nodig hebben.
- Hoe meet je je STP-percentage?
- Deel het aantal transacties dat zonder handmatige correctie bankklaar werd door het totaal. Houd daarnaast het percentage uitzonderingen, de doorlooptijd en de meest voorkomende foutoorzaken bij. Komt dezelfde uitzondering elke week terug, dan is het een ontwerpfout.
- Is straight through processing niet riskant omdat fouten sneller doorgaan?
- Alleen als je blind automatiseert. Goede STP bouwt controles in: IBAN- en veldcontrole vooraf, goedkeuringsdrempels voor ongebruikelijke bedragen, regels voor begunstigden en een logboek van uitzonderingen. Routinezaken gaan automatisch door, twijfelgevallen naar een mens.
