SEPA incasso API: zo koppel je incasso's aan je eigen systeem

2026-04-27

Grote kans dat je financiële afdeling de incassogegevens al heeft. Ze staan in Excel, in een CSV-export uit het ERP-pakket of in een oud bestand dat maar één collega echt begrijpt. Het probleem zit niet in de gegevens zelf. Het probleem is ze omzetten naar iets wat de bank accepteert, zonder een halve dag kolommen, formaten, machtigingskenmerken en datums te controleren.

Daar komt een SEPA incasso API van pas. De bedrijfslogica verdwijnt niet: je hebt nog steeds geldige machtigingen, de juiste incassodatums en schone debiteurgegevens nodig. Wat verdwijnt, is de foutgevoelige handmatige stap tussen “we hebben de lijst” en “we hebben een geldig incassobestand”.

In deze gids lees je hoe je een incasso API aansluit: van authenticatie en het omzetten van je gegevens naar JSON tot statusverwerking, testen en de overstap van handwerk naar volledige automatisering.

Van spreadsheet naar SEPA incasso API

Handmatige SEPA-voorbereiding gaat op alledaagse punten mis. Een kolomkop verandert. Iemand plakt een IBAN met spaties. Een bedrag wordt als tekst geëxporteerd in plaats van als getal. Een machtigingskenmerk dat er in Excel prima uitzag, past niet in het XML-schema.

Werkplek met twee monitoren met software voor het beheren van SEPA-incasso via een API.

De financiële afdeling ziet dat als een bestandsprobleem, ontwikkelaars als een datastructuurprobleem. Beide hebben gelijk. De oplossing: behandel je spreadsheet-exports als invoer, niet als het uiteindelijke betaalbestand.

Waar het schuurt

Een typische route van spreadsheet naar bank heeft drie zwakke plekken:

  • Verschuivende kolommen. “Klantnaam” wordt “Relatie”, “Incassodatum” wordt “Vervaldatum”, en je import gaat gokken.
  • Gaten in de validatie. Spreadsheets dwingen de SEPA-regels voor IBAN’s, machtigingskenmerken en incassogegevens niet af.
  • Starre uitvoer. De bank maakt het niet uit dat je CSV leesbaar was. Alleen het uiteindelijke XML-bestand telt.

Vuistregel: Excel is de plek waar je administratie vastlegt wat er moet gebeuren, niet de plek waar SEPA-regels worden gecontroleerd.

Een goede incasso API geeft beide teams een duidelijk contract. Finance werkt met vertrouwde kolommen, ontwikkelaars zetten die om naar JSON en de API maakt er een geldig pain.008-bestand van.

De brug tussen administratie en integratie

Die tussenlaag slaan de meeste handleidingen over. Bankspecificaties vertellen hoe geldige XML eruitziet, maar niet hoe je een export met “Machtiging”, “IBAN klant”, “Bedrag” en “Incassodatum” omzet naar een voorspelbaar verzoek. De route ziet er meestal zo uit:

  1. Exporteer de incassoregels uit Excel, CSV of je boekhoudpakket.
  2. Schoon de velden op en standaardiseer ze.
  3. Zet de regels om naar een JSON-payload.
  4. Stuur die payload naar de API.
  5. Ontvang het gegenereerde incassobestand of de validatiefouten.

Wie nog met de hand werkt, kan eerst kijken hoe CSV naar SEPA XML omzetten in de praktijk gaat. De winst zit vooral in herhaalbaarheid: zodra de koppeling stabiel is, hangt de maandafsluiting niet meer af van die ene collega die weet welke macro’s hij moet draaien.

GenerateSEPA past precies in dat gat: het neemt Excel, CSV en JSON aan en zet die om in geldige SEPA XML, ook via een REST API. Dat is handig als je project geen nieuwbouw is, maar een overstap van handmatige batches. Denk bijvoorbeeld aan bedrijven die ooit van ClieOp03 overstapten en sindsdien met Excel-lijsten werken.

Authenticatie en je eerste API-verzoek

Voordat je incassogegevens gaat koppelen, zorg je dat één ding werkt: je applicatie kan zich aanmelden en een eenvoudig verzoek doen. Teams die deze stap overslaan, debuggen urenlang payloads terwijl het probleem een ontbrekende header of de verkeerde sleutel is.

Persoon achter een laptop die de toegangsinstellingen van een API beheert.

Wat authenticatie doet

In deze fase bewijst je applicatie alleen wie ze is. Meestal gebeurt dat met een API-sleutel als bearer token in de Authorization-header en Content-Type: application/json. Houd het eerste verzoek saai: een verbindingstest, geen echte batch. Welke endpoints en velden precies gelden, lees je in de API-documentatie.

Bewaar sleutels vanaf dag één buiten je code. Omgevingsvariabelen volstaan in het begin. Geheimen hard in scripts zetten is een gewoonte die je bij deployment en audits duur komt te staan.

Wat je controleert voor je verder gaat

  • Gescheiden omgevingen. Test- en productiesleutels mogen niet per ongeluk door elkaar lopen.
  • Zichtbare fouten. Log HTTP-statuscodes en de foutmeldingen in de respons. Stille fouten kosten tijd.
  • Idempotentie. Bouw het patroon nu al in, ook als je eerste endpoint het nog niet vereist.
  • Eigenaarschap. Spreek af welk team sleutels vernieuwt en hoe dat wordt getest.

Wil je eerst zien wat de API straks vervangt? Probeer de handmatige route via de webinterface en vergelijk die met de API-route voordat je iets aan je ERP koppelt.

Incassogegevens omzetten naar een JSON-payload

Hier wordt een SEPA-project onderhoudbaar of pijnlijk. Het XML-schema is niet het moeilijke deel als een machine het genereert. Het moeilijke deel is consequent bepalen hoe je bedrijfsgegevens op velden worden gezet, zodat finance en IT elkaar geen screenshots meer hoeven te sturen.

Schema van drie stappen om oude incassogegevens om te zetten naar een gestructureerde JSON-payload.

Begin bij de brongegevens, niet bij het schema

Stel dat je CSV er zo uitziet:

Klantnaam IBAN Bedrag Machtigingskenmerk Incassodatum Volgorde
Bakkerij De Molen BV NL91ABNA0417164300 1250.00 MACHT-0001 2026-05-15 FRST
Fietsenwinkel Oost NL20INGB0001234567 89.99 MACHT-0002 2026-05-15 RCUR

Voor je administratie is dat begrijpelijk, maar het is nog geen veilige payload. Leg per veld de regels vast:

  • Klantnaam wordt de naam van de debiteur.
  • IBAN wordt genormaliseerd: hoofdletters, geen spaties.
  • Bedrag is een decimaal getal met punt, geen tekst met komma. € 1.250,00 wordt 1250.00.
  • Machtigingskenmerk is exact gelijk aan het kenmerk op de getekende machtiging.
  • Incassodatum gebruikt overal hetzelfde formaat: JJJJ-MM-DD.
  • Volgorde (sequence type) wordt expliciet meegegeven, nooit geraden.

Een praktische JSON-structuur

Een incasso API verwacht meestal iets in deze vorm. De veldnamen verschillen per leverancier; het principe niet.

{
  "creditor": {
    "name": "Voorbeeld BV",
    "creditorId": "NL69ZZZ123456780000",
    "iban": "NL44RABO0123456789"
  },
  "collection": {
    "requestedCollectionDate": "2026-05-15",
    "sequenceType": "RCUR",
    "scheme": "CORE"
  },
  "debtors": [
    {
      "name": "Fietsenwinkel Oost",
      "iban": "NL20INGB0001234567",
      "amount": "89.99",
      "mandateId": "MACHT-0002",
      "mandateDate": "2025-11-03",
      "remittanceInformation": "Abonnement mei"
    }
  ]
}

Kernpunt: de beste integraties bewaren de bedrijfsbetekenis in JSON en laten de XML-acrobatiek over aan de API.

Het veld dat het vaakst misgaat

Het sequence type lijkt een klein veld, maar het is een stuurveld met echte gevolgen. “Vaste klant” is niet genoeg context; je systeem heeft een betrouwbare regel nodig:

  • FRST: de eerste incasso op een machtiging.
  • RCUR: elke volgende incasso op dezelfde machtiging.
  • OOFF: een eenmalige incasso.

Neemt de API dit als eenvoudig JSON-veld aan en zet hij het juiste XML-element neer, dan heb je precies de abstractie die je zoekt.

Een tussenlaag die de praktijk overleeft

Zet geüploade kolommen niet direct om naar de uiteindelijke payload. Bouw een transformatiestap, al is het een klein script:

def map_row_to_debtor(row):
    return {
        "name": row["Klantnaam"].strip(),
        "iban": row["IBAN"].replace(" ", "").upper(),
        "amount": f"{float(row['Bedrag'].replace(',', '.')):.2f}",
        "mandateId": row["Machtigingskenmerk"].strip(),
        "remittanceInformation": row.get("Omschrijving", "").strip()
    }

Daar handel je spaties, lege velden, datumconversie en eigen bedrijfsregels af. Het is ook de plek om foute records te weigeren voordat ze de hele batch besmetten. Wil je finance eerst de koppeling laten valideren, dan is Excel naar SEPA XML via de webinterface een goede tussenstap terwijl ontwikkelaars de automatische versie bouwen.

Antwoorden en statusupdates verwerken

Het versturen van de payload is pas de helft. Een betrouwbare integratie doet twee dingen goed: de directe API-respons afhandelen én reageren op statussen die later binnenkomen.

Grafiek met verbonden bollen en pijlen voor het verwerken van resultaten.

De directe respons

Respons Betekenis Wat je systeem doet
Geaccepteerd De payload is door de eerste validatie Batch-ID en bestand opslaan, status “aangemaakt”
Validatiefout Het verzoek is onvolledig of onjuist Batch weigeren en per veld een bruikbare foutmelding tonen
In verwerking Het eindresultaat volgt later Wachten op de statusupdate

Waar teams de mist ingaan: “geaccepteerd” behandelen als “betaald”. Dat zijn verschillende momenten. Bij acceptatie weet je dat het bestand of de opdracht technisch klopt, niet wat de bank ermee doet.

Waar de betaalwerkelijkheid binnenkomt

Hoe je die latere status ontvangt, hangt af van je opzet. Genereer je het incassobestand en upload je het zelf bij je bank, dan komt de uitkomst via je bank: afgewezen bestanden, storneringen met een redencode en bijschrijvingen op je rekeningafschrift. Werk je met een partij die de incasso ook verwerkt, dan krijg je statussen vaak via webhooks: server-naar-servermeldingen naar een endpoint van jouw applicatie.

In beide gevallen doet je verwerking hetzelfde:

  1. Controleer de herkomst (bijvoorbeeld de handtekening van een webhook).
  2. Lees het type gebeurtenis en de gegevens.
  3. Koppel die aan je interne machtiging, incasso of batch.
  4. Werk de status idempotent bij, zodat een herhaalde melding geen dubbele boeking oplevert.

Houd je interne model eenvoudig, bijvoorbeeld: ingediend, betaald, afgewezen, gestorneerd en nieuwe machtiging nodig. Dat geeft finance, support en IT een gedeelde taal.

Kernpunt: onvoldoende saldo (AM04) en een ongeldige machtiging (MD01) vragen om een andere opvolging. Bij de eerste plan je een nieuwe poging; bij de tweede vraag je een nieuwe machtiging en incasseer je niet opnieuw.

Wat werkt: ruwe meldingen bewaren voor audit, herstelbare en definitieve fouten scheiden en statussen terugschrijven naar je ERP of CRM. Wat niet werkt: alle fouten hetzelfde behandelen, e-mail als belangrijkste herstelmechanisme gebruiken en gecorrigeerde gegevens handmatig laten overtypen. De toets is simpel: als een incasso op vrijdag mislukt, ziet finance dan op maandag de juiste status zonder dat iemand het plaatje handmatig reconstrueert?

Testen, validatie en beveiliging

Een incasso-integratie gaat niet live omdat het ideale pad één keer werkte in een testomgeving. Ze gaat live als je team vertrouwen heeft in foutafhandeling, validatie en beheer.

Stel een testset samen met:

  • een schone batch met geldige machtiging, gegevens en sequence type;
  • een record met een foute IBAN, om te zien of de fout duidelijk terugkomt;
  • een machtigingskenmerk dat niet klopt;
  • een dubbel afgeleverde statusmelding, om idempotentie te bewijzen;
  • een batch met gemengde geldigheid, zodat je weet of het hele bestand of alleen de foute regels worden geweigerd.

Valideer twee keer: bij binnenkomst van de export en vlak voor het indienen. Controleer dan of de machtiging actief is, de incassodatum past bij de run, alle verplichte velden gevuld zijn, het sequence type expliciet is en bedragen overeenkomen met het bronsysteem. Het gegenereerde bestand kun je los controleren met de gratis SEPA-incasso XML-validator.

Beveiliging blijft jouw verantwoordelijkheid: HTTPS voor al het verkeer, beperkte toegang tot incassogegevens, geen volledige IBAN-lijsten in platte logbestanden, gecontroleerd vernieuwen van sleutels en testgegevens gescheiden van productie.

Volledige automatisering van je SEPA incasso via de API

De echte winst is niet één geldig bestand, maar het verdwijnen van de maandelijkse haast. Een volwassen opzet maakt van incasseren een geplande, controleerbare stap die finance vertrouwt en ontwikkelaars niet hoeven te bewaken.

Bouw vanuit je facturatiesysteem naar buiten:

  1. Exporteer goedgekeurde vorderingen uit het bronsysteem.
  2. Zet ze om naar je interne incassomodel.
  3. Valideer en verrijk de gegevens.
  4. Stuur ze volgens schema naar de API.
  5. Leg het batch-ID vast en upload het bestand (of laat dat je eigen proces doen).
  6. Schrijf de eindstatussen terug naar je administratie.

Stap gefaseerd over. Laat de oude spreadsheetroute eerst parallel draaien, vergelijk een beperkte set uitkomsten, leg kolomdefinities vast, zet één incassostroom of bedrijfsonderdeel om en breid pas uit als statusverwerking en afletteren stabiel zijn. Oude exports bevatten vaak ongedocumenteerde aannames in kenmerkvelden, datums of rekeningformaten. Haal die tijdens de overstap boven water, anders komen ze later terug als onverklaarbare afwijzingen.

Kringloop Goed resultaat
Invoer Schone regels komen binnen in één standaardmodel
Indienen Batches worden consequent en op tijd aangemaakt
Herstel Fouten leiden tot de juiste vervolgactie
Afletteren Eindstatussen komen terug in de financiële administratie

Een SEPA incasso API werkt het best als niemand er nog aan denkt. De factuurcyclus draait, uitzonderingen zijn zichtbaar en storneringen komen in de juiste wachtrij.

Wil je de stap van Excel en handgemaakte XML naar een geautomatiseerde koppeling zetten? Bekijk de GenerateSEPA API en genereer je incassobestanden rechtstreeks vanuit je eigen systeem.


Veelgestelde vragen

Hoe werkt authenticatie bij een SEPA incasso API?
Meestal met een API-sleutel of bearer token in de header van elk verzoek. Bewaar sleutels in omgevingsvariabelen in plaats van in je code, houd test- en productiesleutels strikt gescheiden en controleer eerst de verbinding voordat je echte incasso's verstuurt.
Welk gegevensformaat verwacht een incasso API?
De meeste incasso API's nemen een JSON-payload aan met de gegevens van de incassant, de incassodatum en het sequence type, en per debiteur naam, IBAN, bedrag en machtigingskenmerk. De API maakt daar zelf het pain.008-bestand van, zodat je team met JSON werkt in plaats van met ruwe XML.
Hoe verwerk je mislukte incasso's bij een API-koppeling?
Deel mislukte incasso's in op redencode en koppel aan elk type een vaste vervolgactie. Bij onvoldoende saldo plan je een nieuwe poging, bij een ongeldige machtiging vraag je eerst een nieuwe machtiging aan. Schrijf de status altijd terug naar je administratie.
Kan ik SEPA-incasso's automatiseren vanuit Excel of CSV?
Ja. Exporteer de vorderingen uit je spreadsheet of ERP, zet de regels via een transformatiestap om naar een gestandaardiseerde JSON-payload en stuur die volgens schema naar de API. Zo verdwijnt de handmatige stap tussen de betaallijst en een geldig SEPA XML-bestand.

Gerelateerde artikelen