Peppol-afwijzingen herstellen: van MLR en Invoice Response naar gecontroleerde vrijgave

De foutmelding is meestal het minst bruikbare deel van een Peppol-afwijzing. RE vertelt je dat iets is gestopt, maar niet automatisch of je XML fout is, je orderreferentie niet bestaat, de levering niet klopt of iemand een creditnota moet maken. Wie daarna simpelweg opnieuw verzendt, krijgt vaak dezelfde afwijzing met een tweede dossier ernaast.

Deze gids is voor de ondernemer, finance-medewerker of softwareleverancier die een afgewezen Peppol-factuur netjes wil herstellen. Je eindigt met een nieuwe poging die naar de juiste bron terug te voeren is, opnieuw is gevalideerd en pas daarna weer door de vrijgavepoort gaat.

Een Peppol-afwijzing is een signaal dat een factuur niet verder mag in de huidige vorm. Bij een MLR faalt de technische controle van bericht of standaard. Een MLS meldt naast conformance ook of de serviceprovider het bericht kon doorleveren; RE met reason code FD is failed delivery. Bij een Invoice Response stopt de zakelijke verwerking bij de klant. Het herstel bestaat uit classificeren, de bron laten corrigeren, bewijs bewaren, opnieuw valideren en gecontroleerd vrijgeven.

De eerste ontvangst is pas compleet als je de UBL-bron, uitzonderingsqueue en menselijke vrijgave hebt ingericht. Deze gids begint op het moment daarna: er ligt een afwijzing en je moet bepalen wat er werkelijk stuk is.

Eerst: welke afwijzing zie je?

Een Peppol-factuur reist door meerdere controles. Een transportbevestiging, een technisch validatiebericht en een zakelijke statusmelding zijn geen varianten van dezelfde boodschap. Ze hebben een andere eigenaar en vragen om een andere reparatie.

Lees bij een MLS RE altijd de StatusReasonCode mee. SV staat voor een schemafout, BV voor een conformance- of fatale Schematronfout, BW voor een aanvullende waarschuwing die op zichzelf geen afwijzing mag veroorzaken en FD voor failed delivery. De actuele OpenPeppol MLS-specificatie routeert FD naar herstel bij de serviceprovider of de doorleveringsroute; op basis van die code pas je de UBL dus niet aan, gecontroleerd op 9 oktober 2026.

De Message Level Response gaat over syntax, UBL-conformiteit, Schematron-regels en fatale validatiefouten. Een verkeerde orderreferentie die technisch als tekst in de UBL staat, hoort volgens de scope van MLR juist niet bij MLR. Dat is een zakelijke controle bij de koper. De officiële MLR-specificatie maakt dit onderscheid expliciet en zegt ook dat waarschuwingen op zichzelf geen afwijzing mogen veroorzaken, gecontroleerd op 9 oktober 2026.

Een Invoice Response komt pas in beeld wanneer de factuur leesbaar en technisch verwerkt kan worden. UQ betekent dat de koper aanvullende informatie nodig heeft. RE is een eindstatus voor die factuur in het proces van de koper, maar betekent niet automatisch dat de commerciële levering zelf is afgewezen. De koper kan om een creditnota en een nieuwe factuur vragen, of aangeven dat alleen een nieuwe factuur nodig is. De actuele Peppol BIS Invoice Response 3.2 noemt daarnaast een eerste statusmelding binnen drie werkdagen en maakt duidelijk dat een Invoice Response de factuurinhoud niet wijzigt, gecontroleerd op 9 oktober 2026.

Er is nog een actuele nuance. OpenPeppol vervangt MLR geleidelijk door MLS, Message Level Status. Op 9 oktober 2026 kom je MLR dus nog tegen in bestaande logs en koppelingen, maar je serviceprovider kan al MLS gebruiken. Het officiële plan noemt 1 maart 2027 als start van de verplichte MLS-ontvangst, 1 april 2027 als moment waarop MLS-verzenden verplicht wordt en 1 mei 2027 als volledige uitfasering van MLR. Het fase-outplan van OpenPeppol beschrijft de overgang en de regel dat één document maar één van beide technische statusberichten krijgt, gepubliceerd op 2 juli 2026.

Gebruik daarom deze beslisregel: staat de afwijzing bij XML, CustomizationID, Schematron of een fatal rule, behandel hem als technisch herstel. Staat de afwijzing bij order, levering, bankrekening, leverancier, betalingstermijn of een andere bedrijfsafspraak, behandel hem als zakelijk herstel. Staat er alleen een transportfout, herstel eerst adres, documenttype of access point. Pas daarna heeft opnieuw valideren zin.

Wat je nodig hebt

Een herstelproces valt of staat met de informatie die je op het moment van de afwijzing bewaart. Zonder de oorspronkelijke envelop, de exacte status en de bronwaarde ga je achteraf gokken welke versie de klant heeft gezien.

Kies daarnaast bewust een uitvoeringsroute. De onderstaande accounts, vaardigheden en inspanning zijn een indicatieve planningsorde, geen offerte.

• Het originele bericht. Bewaar de UBL of ApplicationResponse ongewijzigd, inclusief bestandshash, ontvangsttijd, verzendtijd, afzender, ontvanger, cbc:ID, envelope- of instance-ID en gebruikte documenttype- en process-ID.
• De volledige foutdetails. Sla niet alleen RE op. Bewaar de omschrijving, rule-ID, XPath of regellocatie, status reason code, action code en het antwoord van het access point. In de actuele Peppol BIS Billing 3.0-regel PEPPOL-EN16931-R003 is het fataal dat cbc:BuyerReference of cac:OrderReference/cbc:ID ontbreekt; bewaar die regel en locatie dus naast de tekst afwijzing.
• De drie bronnen. Je hebt de UBL-bron, de procesbron en de vrijgavebron nodig. De UBL bevat wat je hebt verzonden. De order, ontvangst, overeenkomst of klantkaart bevat wat had moeten worden verzonden. Je goedkeuringsbeleid bepaalt of de nieuwe poging mag doorgaan.
• Een bronhouder per fouttype. De ontwikkelaar of integratie-eigenaar bezit de mapping. Verkoop of projectadministratie bezit de orderreferentie. Inkoop of de budgethouder bezit de ontvangst en zakelijke acceptatie. Finance beslist over creditnota, boeking en betaling.
• Een test- of controlepad. Gebruik de NPa Peppol Test Tool, een validator van je access point of een gelijkwaardige testomgeving. De Nederlandse Peppolautoriteit noemt documentvalidatie, ontvanger zoeken, verstuurtest en applicatietest als aparte hulpmiddelen. De actuele technische specificaties van de NPa beschrijven die vier teststappen en de verplichte standaarden, gecontroleerd op 9 oktober 2026.
• Een herstelregister. Geef iedere poging een case_id, attempt_id, oorzaak, eigenaar, deadline, bronversie, technische status, zakelijke status en beslissing. Houd de eerste afwijzing vast wanneer je een nieuwe poging doet.
• Rechten om de bron te corrigeren. Een medewerker die alleen de uiteindelijke UBL kan aanpassen, kan een fout tijdelijk verbergen maar de bron opnieuw verkeerd laten genereren. Zorg dat de correctie op de plek gebeurt waar de fout ontstaat.
• Een expliciete vrijgavepoort. Technisch geaccepteerd is niet hetzelfde als zakelijk goedgekeurd. Leg vast welke status, welk bewijs en welke persoon nodig zijn voordat een factuur naar boeking of betaling mag.

Vink dit af voordat je aan de correctie begint:

Concrete stappen: van afwijzing naar gecontroleerde vrijgave

Met een gecontroleerde Peppol-herstelroute bepaal je eerst of transport, technische validatie, failed delivery of zakelijke beoordeling de keten stopt. Je bewaart de eerste poging, herstelt de juiste bronhouder, valideert de nieuwe UBL met BIS Billing 3.0 en geeft pas vrij wanneer technische, zakelijke en interne voorwaarden aantoonbaar kloppen.

In deze volgorde pak je het aan:

1. Bevries de eerste poging

Maak eerst een kopie voor onderzoek, maar verander het originele bericht niet. Geef de gebeurtenis een dossiernummer, bijvoorbeeld PP-2026-00481, en koppel daaraan de ontvangen MLR, MLS of Invoice Response. Noteer welke factuur en welke transportpoging erbij horen.

Bewaar ook de versie van de software of mapping die het bericht heeft gemaakt. Bij een fout in een integratie is Exact Online als systeemnaam niet genoeg. Je wilt weten welke connector, welke mappingversie en welke bronorder de waarden heeft geleverd.

Controlepunt: een tweede medewerker kan vanuit het dossier exact reconstrueren wat de ontvanger op 9 oktober 2026 heeft ontvangen. Als dat niet lukt, corrigeer je nog niets.

2. Classificeer de afwijzing op status en inhoud

Lees de statuscode pas samen met de reden. Een technische RE en een zakelijke RE hebben dezelfde korte code, maar een ander vervolg. Bij MLS is de reason code beslissend:

• RE + SV of BV: behandel dit als een conformance- of validatieprobleem en herstel de UBL, mapping of artefactkeuze. Staat er alleen BW, zoek dan eerst de fatale melding: een waarschuwing mag op zichzelf niet afwijzen.
• RE + FD: dit is failed delivery. De ontvangende serviceprovider kon het bericht niet doorgeven; open eerst herstel bij provider, access point of route en wijzig de UBL niet op basis van deze code.

Een Invoice Response UQ vraagt meestal om aanvullende informatie of overleg. Een technische RE met een validatiereason vraagt om een nieuwe, valide boodschap.

Gebruik deze volgorde:

1. Transport en providerlevering: is de ontvanger gevonden en ondersteunt hij het documenttype en proces? Bij MLS RE + FD herstel je eerst de doorlevering.
2. MLR of MLS-conformance: is de XML technisch valide en voldoet de factuur aan het gekozen Peppol-profiel? Kijk bij MLS eerst naar SV of BV; behandel BW als aanvullende waarschuwing, niet als zelfstandige reden voor UBL-correctie.
3. Invoice Response: heeft de koper de factuur in zijn eigen proces gematcht, beoordeeld en van een zakelijke status voorzien?
4. Vrijgave: zijn boeking, betaalmandaat en bewijs compleet?

De Nederlandse implementatierichtlijn voor de factuurketen tekent dezelfde volgorde uit: eerst transport, daarna technische validatie, daarna de zakelijke beoordeling. In de procesbeschrijving van de Nederlandse Peppolautoriteit staat ook dat een technisch correcte factuur nog zakelijk kan worden afgewezen op bijvoorbeeld een ongeldige orderreferentie, geraadpleegd op 9 oktober 2026.

3. Leg de fout naast de bronhouder

Maak een kleine oorzaakkaart. De eigenaar is niet degene die als eerste de foutmelding ziet, maar degene die de waarde in de bron kan herstellen.

Schrijf in het dossier één zin die het eigenaarschap vastlegt: De connector bezit de foutieve mapping van OrderReference, of De koper bezit de ontbrekende ontvangstbevestiging. Dat klinkt administratief, maar het voorkomt dat vijf mensen dezelfde factuur opnieuw verzenden.

4. Corrigeer de bron, niet het symptoom

Bij een technische afwijzing met MLR RE of MLS RE + SV of BV herstel je de gegevens die de UBL genereren. Een MLS RE + BW is alleen een aanvullende waarschuwing; zoek de bijbehorende fatale reden. Staat de orderreferentie in je order, maar verdwijnt die in de connector, herstel dan de veldmapping. Staat de referentie nergens, laat dan de bronhouder de order aanvullen volgens de instructie van de klant. Bij MLS RE + FD wijzig je de UBL niet: laat de provider of access point de failed delivery en de route herstellen.

Controleer voor Peppol BIS Billing 3.0 minimaal:

• CustomizationID en ProfileID zijn exact de waarden van het geregistreerde documenttype en proces.
• De factuur bevat een BuyerReference of een OrderReference als de profielregel dat vereist.
• Leverancier, koper, endpoint-ID en schema-ID horen bij de juiste administratie.
• Factuurtype, valuta, bedragen, btw-totalen en regeltotalen rekenen opnieuw correct uit.
• De foutieve versie blijft bewaard als bron van de herstelactie.

Bij een zakelijke afwijzing beslis je eerst wat de koper vraagt. UQ kan betekenen dat de koper de factuur nog wil herstellen na een telefoongesprek of aanvullende referentie. RE is definitief binnen de Invoice Response-keten. Als de factuur nog niet is geboekt, kan de koper vragen om een nieuwe correcte factuur zonder creditnota. Als de factuur al is verwerkt of de koper dat vraagt, maak je de creditnota en de nieuwe factuur als twee gekoppelde documenten.

5. Maak een nieuwe documentpoging

Maak geen nieuwe versie door het oorspronkelijke UBL-bestand te overschrijven. Genereer een nieuwe factuurpoging vanuit de gecorrigeerde bron. Geef de poging een nieuw technisch ID en leg een relatie naar het oude dossier.

Houd de financiële identiteit bewust bij elkaar. Een nieuw verzend- of envelope-ID is noodzakelijk voor de transportketen. Het factuurnummer blijft hetzelfde wanneer je systeem een technische herverzending ondersteunt en de ontvanger dat accepteert. Bij een zakelijke RE kan juist een nieuw factuurnummer nodig zijn, soms na een creditnota. Dat is een bedrijfsbesluit, geen keuze die je connector stil mag nemen.

Zet in de auditlog:

• welke waarde is veranderd;
• waar die waarde vandaan kwam;
• wie de wijziging goedkeurde;
• welke documentrelatie geldt tussen oud, credit en nieuw;
• welke validatie daarna is uitgevoerd;
• welke status nog ontbreekt voor vrijgave.

6. Valideer met dezelfde regels als de ontvanger

Valideer niet alleen op welgevormde XML. Een bericht kan technisch nette XML zijn en toch falen op een Peppol-regel. Gebruik de documenttype- en profielkeuze uit de productieflow, inclusief de actuele validatieartefacten van je access point of de NPa-testomgeving.

Laat bij een nieuwe poging minimaal controleren:

1. XML-schema en namespaces.
2. CustomizationID, ProfileID en documenttype.
3. Verplichte velden en buyer- of orderreferentie.
4. Leverancier, koper, endpoint en administratie.
5. Btw, afronding, totalen en regelniveau.
6. Bijlagen, bestandstype en omvang.
7. Dubbele document- of factuursleutel.

Moneybird noemt in zijn actuele probleemoplossing onder meer lege orderreferentie, afrondingsverschillen, negatieve factuurregels, gemengde btw-regels en beperkingen voor bijlagen. De helptekst is bijgewerkt in september 2026 en laat zien waarom je de fout in de vaste bronvelden moet herstellen, niet in een losse opmerking, gecontroleerd op 9 oktober 2026.

7. Verstuur opnieuw met een nieuwe statusketen

Stuur de nieuwe poging pas wanneer de technische validatie groen is. Houd de retourberichten aan de nieuwe attempt-ID vast. Een positieve technische status betekent dat de boodschap technisch is doorgekomen. Het is geen bewijs dat de koper de factuur heeft goedgekeurd.

Voor een zakelijke status volg je de keten van de koper. Dat kan AB naar UQ naar AP zijn, of AB naar RE wanneer de factuur definitief niet verder gaat. Leg een antwoord buiten Peppol, zoals een telefoongesprek over een ontbrekende order, als bewijs vast. Een mondeling akkoord zonder dossier is geen reden om de betaalpoort te openen.

8. Laat pas daarna vrijgeven

De vrijgavecontrole is de laatste poort, niet een automatisch gevolg van opnieuw verzenden. Zet de factuur pas op released wanneer:

• de nieuwe technische status positief is;
• de zakelijke status bij de gewenste uitkomst past;
• de order, ontvangst, overeenkomst of correctie is gekoppeld;
• creditnota en nieuwe factuur financieel op elkaar aansluiten als dat nodig is;
• een bevoegde persoon de beslissing, reden en tijd vastlegt.

Houd technisch ontvangen, zakelijk geaccepteerd, vrijgegeven voor boeking en vrijgegeven voor betaling als vier aparte statussen. Vooral die laatste twee worden in kleine pakketten snel samengevoegd. Dat maakt een fout later duurder, omdat niemand meer weet of een factuur alleen mag worden geboekt of ook al in een betaalrun zat.

Valkuilen die herstel onbetrouwbaar maken

• Opnieuw verzenden zonder classificatie. Je maakt een tweede poging voordat je weet of het om transport, techniek of business gaat. Maak eerst de statuslaag en reden expliciet.
• Een MLS RE + FD behandelen als XML-fout. FD betekent failed delivery door de providerketen. Open eerst een herstelitem bij serviceprovider of access point en controleer de route; corrigeer de UBL alleen als een aparte MLR- of MLS-validatiereason dat vraagt.
• Een zakelijke RE behandelen als XML-fout. Een order die niet bestaat in het ERP van de koper is geen Schematronprobleem. De bronhouder moet de orderreferentie of de commerciële afspraak herstellen.
• Alleen de korte code bewaren. RE zonder rule-ID, status reason, XPath, tijd en envelope-ID is later niet reproduceerbaar. Bewaar de volledige response.
• Een vrije tekst als orderreferentie gebruiken. Als je klant een vast UBL-veld verwacht, zet de waarde in dat veld. Een omschrijving, notitie of extra veld reist niet altijd mee naar de ontvanger.
• De oorspronkelijke factuur overschrijven. Dat vernietigt bewijs. Bewaar de eerste bron en leg iedere correctie als nieuwe poging vast.
• Een creditnota automatisch maken bij elke afwijzing. Een technische afwijzing of een nog niet geboekte factuur vraagt niet altijd om een creditnota. Volg de status, de instructie van de koper en je financiële proces.
• De bankrekening uit de nieuwe factuur als waarheid nemen. Een wijziging van betaalgegevens moet onafhankelijk worden geverifieerd. De Nederlandse factuurprocesrichtlijn noemt dit expliciet als frauderisico.
• De vrijgave koppelen aan AP of MLS AP. Dat bevestigt een technische of zakelijke stap, maar niet automatisch je interne mandaat. Controleer de order, ontvangst en bevoegdheid opnieuw.
• De MLR naar één hardgecodeerde ontvanger sturen. Tijdens de MLS-overgang kunnen providerregistratie en routing veranderen. Laat je access point de actuele capability en route gebruiken.
• Een workflowtool als boekhoudproces behandelen. n8n kan berichten ophalen, transformeren en doorzetten, maar bezit niet vanzelf je fiscale bron, mandaat of auditlog. Bouw die onderdelen bewust.

Het beslis-kader: pakket, integratielaag of maatwerk?

De juiste aanpak hangt minder af van het aantal facturen dan van het aantal bronnen en beslissers. Een klein volume met meerdere entiteiten kan zwaarder zijn dan 500 facturen uit één nette orderstroom.

Kant-en-klaar pakket past wanneer je één administratie hebt, je order- en leveranciersdata betrouwbaar zijn en je uitzonderingsqueue klein blijft. Moneybird biedt Peppol-verzenden en ontvangen in het pakket; Exact meldt dat e-facturatie via Peppol standaard beschikbaar is in zijn oplossingen en zowel verzenden als ontvangen ondersteunt. De huidige Exact-pagina noemt daarnaast automatische verwerking van in- en verkoopfacturen, gecontroleerd op 9 oktober 2026. Gebruik zo’n pakket wanneer de ingebouwde statusinformatie en handmatige herstelstap voldoende zijn.

Een integratielaag past wanneer je facturen in een order-, project- of abonnementssysteem ontstaan en je de Peppol-status terug wilt schrijven. n8n is hiervoor een bruikbare orkestratielaag: de actuele Cloud Starter kost €20 per maand bij jaarlijkse betaling voor 2.500 volledige workflowuitvoeringen; Pro kost €50 per maand voor 10.000. De self-hosted Community Edition is gratis, maar je beheert dan zelf opslag, updates, beveiliging en monitoring. De actuele n8n-prijspagina rekent per volledige uitvoering, niet per losse stap, prijzen gecontroleerd op 9 oktober 2026.

Maatwerk is passend als je meerdere entiteiten, verschillende ERP’s, eigen orderreferenties, complexe statusroutes of een harde auditplicht hebt. Bouw dan niet alleen een zender. Je hebt een bronregister, UBL-versies, idempotente pogingen, statusnormalisatie, een uitzonderingsqueue, rollen en een vrijgavescherm nodig. Dat is meer werk dan een webhook tussen twee systemen, maar het voorkomt dat een afwijzing alsnog eindigt in een gedeelde mailbox.

Gebruik deze keuzehulp als snelle route door hetzelfde kader:

De simpele keuze is vaak de beste: één pakket, weinig uitzonderingen en een menselijke herstelstap. Zodra dezelfde afwijzing door meerdere bronnen of teams moet worden opgelost, verdwijnt de winst van alleen een extra connector. Dan moet je de status- en bewijslaag ontwerpen.

Uitgewerkt voorbeeld: twee verschillende afwijzingen in één keten

Dit is een rekenvoorbeeld, geen klantcase. Een installatiebedrijf maakt in Exact Online een factuur voor twaalf uur onderhoud tegen €145 per uur. De netto waarde is €1.740,00, de btw bij 21 procent is €365,40 en het totaal is €2.105,40. De order is PO-2026-7787. Het team heeft een vaste mapping tussen order en Peppol-factuur.

Poging 1: technische afwijzing

De connector zet de orderreferentie per ongeluk in een vrij tekstveld. In de UBL ontbreekt daardoor zowel BuyerReference als OrderReference. De bedragen kloppen wel. De ontvangende serviceprovider stuurt een technische RE terug in een MLR, of in de huidige overgang via MLS met reason code BV voor de conformancefout. FD zou hier niet naar UBL-herstel verwijzen, maar naar failed delivery en providerherstel. De fout verwijst naar de actuele regel dat een buyer reference of purchase order reference verplicht is.

Het team doet vier dingen:

1. Het bewaart de UBL, de technische response, envelope-ID en mappingversie onder PP-2026-00481, poging 1.
2. Het zet de oorzaak op missing_routing_reference en wijst de connector-eigenaar aan.
3. Het herstelt de mapping zodat PO-2026-7787 in cac:OrderReference/cbc:ID terechtkomt.
4. Het genereert een nieuwe UBL, controleert de bedragen opnieuw en valideert het bestand met de NPa-testtool voordat het opnieuw wordt verzonden.

De eerste factuur wordt niet verwijderd en de nieuwe poging krijgt een eigen envelope-ID. De positieve technische status betekent nu alleen dat de factuur de technische poort heeft gepasseerd.

Poging 2: zakelijke afwijzing

Na de technische acceptatie ziet de koper dat de order in zijn ERP PO-2026-7781 heet. De leverancier heeft een verouderde kopie uit het projectpakket gebruikt. De UBL is geldig, maar de orderreferentie kan niet worden gematcht. De koper stuurt eerst Invoice Response UQ met reden REF en vraagt om een correcte referentie. De leverancier controleert de order bij de projectadministratie. Die bevestigt dat PO-2026-7781 de juiste bronwaarde is.

De koper besluit de oorspronkelijke factuur niet te boeken en stuurt Invoice Response RE met de instructie om een nieuwe factuur te sturen. Er is in dit scenario geen creditnota nodig, omdat de factuur niet in de administratie is geboekt. De leverancier laat Exact Online opnieuw genereren vanuit de gecorrigeerde orderbron, nu met dezelfde twaalf uur en hetzelfde totaal, maar met het juiste ordernummer. De nieuwe factuur krijgt een nieuwe documentpoging en verwijst in het herstelregister naar PP-2026-00481.

De koper ontvangt de nieuwe factuur. De technische status is positief. Daarna volgt Invoice Response AB en, na controle van order en prestatie, AP. De finance-medewerker legt vast:

Pas nu gaat de factuur naar de boekings- en betaalstap. Als de eerste factuur al was geboekt, zou de route anders zijn: eerst de afwijzing en creditnota koppelen, daarna de nieuwe factuur controleren. Hetzelfde bedrag opnieuw sturen zonder die financiële correctie zou een dubbel dossier maken.

Vergelijkingstabel: welke route past bij herstel?

Een kant-en-klaar pakket bespaart je bouwtijd, maar neemt het eigenaarschap van de bron niet over. Een integratielaag bespaart handwerk, maar maakt zonder statusmodel vooral een snellere herhaling van dezelfde fout. De maatstaf is daarom niet of de factuur opnieuw is verzonden. De maatstaf is of je kunt bewijzen waarom deze versie wél door de volgende poort mag.

Een Peppol-afwijzing is pas opgelost wanneer de foutsoort klopt, de juiste bronhouder heeft gecorrigeerd, de nieuwe boodschap technisch is gevalideerd en de zakelijke vrijgave opnieuw is genomen. Wie die vier momenten uit elkaar houdt, kan fouten herstellen zonder geschiedenis te wissen en zonder een groen technisch vinkje te verwarren met toestemming om geld te boeken of te betalen.