PrestaShop aan AFAS koppelen: betalingen, payouts en gecontroleerde vrijgave

Je hebt een order die in PrestaShop betaald staat, een betaalprovider die het geld pas later bundelt en een AFAS-administratie waarin iemand op Vrijgeven moet klikken. Als je die drie momenten als één gebeurtenis behandelt, boek je een fee als omzet, zie je een refund te laat of geef je een order vrij zonder te weten of de betaling echt is aangekomen.

De veilige route is een geldstroom met tussenstappen: order, betaalbevestiging, payout, fee, refund of chargeback, match en pas daarna een AFAS-vrijgave. Bij een deelrefund blijven oorspronkelijke orderregel, refund, creditnota en aflettering afzonderlijk traceerbaar. Deze gids is voor een webshop-eigenaar of financeverantwoordelijke met PrestaShop en AFAS Profit die die route zelf wil inrichten, laten bouwen of inhoudelijk wil controleren. De bedragen, productdetails en documentatie in deze gids zijn gecontroleerd op 5 oktober 2026.

Een gecontroleerde PrestaShop-AFAS-vrijgave is een boekingsstroom waarin ordergegevens, betaalstatus, PSP-uitbetaling, kosten, refunds en chargebacks eerst aan vaste bron-ID’s worden gekoppeld. Alleen een complete en unieke set krijgt een AFAS-boeking of vrijgave. Een onvolledige match blijft zichtbaar in een uitzonderingsqueue met eigenaar, bewijs en deadline.

Wat je nodig hebt voordat je één euro naar AFAS vrijgeeft

Begin met de vraag welk systeem welk feit bezit. PrestaShop bezit de order, de orderregels en de status die je klant in de shop ziet. De betaalprovider bezit de betaalpoging, het transactie-ID, de refund, de chargeback en de payout. AFAS bezit de vrijgegeven order of financiële boeking. Een systeem mag de ontbrekende waarheid van een ander systeem niet invullen op basis van alleen een bedrag.

Toegang en rechten

Aan de PrestaShop-kant heb je een aparte Webservice-sleutel nodig. PrestaShop staat de Webservice standaard uit en laat je per sleutel lees- en schrijfrechten per resource instellen in de actuele toegangsdocumentatie. Geef voor deze geldstroom in eerste instantie alleen leesrechten op orders, order_details, order_payments, order_invoices, order_slips en order_histories. Een sleutel die ook producten, klanten en instellingen mag wijzigen, is geen gemak maar een groter foutoppervlak.

Lees voor de betaling minstens orderreferentie, bedrag, valuta, betaalmethode, conversiekoers en transaction_id uit order_payments. De PrestaShop 9-resource voor orderbetalingen bevat precies die velden. De betaalprovider blijft de bron voor de feitelijke status en payout.

Aan de AFAS-kant laat je een aparte App connector maken met alleen de benodigde Get- en UpdateConnectoren. Gebruik voor een geplande machine-naar-machinekoppeling de OAuth Client credentials flow. AFAS meldt dat access-tokens één uur geldig zijn en dat classic tokens uiterlijk 31 augustus 2027 moeten wijken voor OAuth in de actuele handleiding voor eigen App connectoren. Bewaar het client secret in een geheimenkluis, nooit in een n8n-workflow, script of webshopconfiguratie die meerdere mensen kunnen lezen.

Koppel voor de AFAS-orderroute minimaal FbSales om verkooporders toe te voegen, te wijzigen of te verwijderen en FbFreeOrder om geblokkeerde verkooporders vrij te geven. AFAS documenteert dat FbFreeOrder geen order kan vrijgeven waaraan twee gebruikers tegelijk werken. Dat is een reden om vóór iedere vrijgave een lockcontrole en een menselijke eigenaar te bewaren, geen reden om die connector onbeheerd te laten draaien.

Beslis wat je precies vrijgeeft

Er zijn twee verschillende uitkomsten die vaak door elkaar lopen:

1. Operationele ordervrijgave. AFAS mag de verkooporder verder verwerken richting pakbon of facturatie. Gebruik FbSales en eventueel FbFreeOrder. De betaalbevestiging is hier het relevante moment. Wacht niet op de payout als dat je levering onnodig vertraagt.
2. Financiële batchvrijgave. De omzet, fee, refund, chargeback en payout zijn gematcht en mogen als financiële boeking worden verwerkt. Gebruik de financiële connector of de sales-invoice-route die je accountant heeft goedgekeurd. De payout is hier controle-informatie, niet de bron van de omzet.

Als je accountant een AFAS-verkoopfactuur wil laten maken, leg dan vast of je de Classic sales invoicing-route gebruikt. Twinfield is een ander voorbeeld van waarom dat vooraf moet: de officiële documentatie maakt onderscheid tussen sales invoices en sales transactions en beperkt de webservice voor facturen tot de Classic sales invoicing-module in de actuele API-uitleg. Het patroon is algemeen: leg het financiële object vast voordat je een connector bouwt.

Wat er minimaal klaar moet staan

• Een PrestaShop 9-omgeving met een aparte lees-sleutel en een testorder met meerdere orderregels.
• Een AFAS Profit-test- of acceptatieomgeving, een systeemgebruiker, een App connector en de gekozen Get- en UpdateConnectoren.
• Een PSP-account. In de voorbeelden gebruik ik Mollie, omdat de documentatie een Settlement Report met betalingen, refunds, chargebacks en verschillende fee-soorten biedt. Bij Stripe, Adyen of een andere PSP gebruik je dezelfde velden met de namen van die provider.
• Een duurzame opslaglaag voor bron-snapshots, statussen, sleutelvelden, retries, foutmeldingen en beslissingen. Een workflowgeschiedenis is geen audit trail.
• Een uitzonderingsqueue met exception_id, ordernummer, reden, bedrag, bron-ID’s, eigenaar, deadline, bewijs, voorgestelde actie, beslisser en eindstatus.
• Een bevoegdhedenmatrix. De medewerker die een retour inspecteert, hoeft niet automatisch de refund, de creditnota of de AFAS-vrijgave te mogen doen.
• Een testset met een volledige betaling, een pending betaling, een fee, een deelrefund, een volledige refund, een chargeback, een dubbele webhook, een time-out na een schrijfactie, een onbekende betaling en een gesloten boekingsperiode.

Concrete stappen: van orderstatus tot gecontroleerde AFAS-boeking

1. Kies de AFAS-route vóór je een status koppelt

Schrijf eerst in één pagina op wat AFAS moet ontvangen. Kies tussen een verkooporder die later wordt vrijgegeven, een directe financiële boeking of beide. Voeg toe wie de factuur maakt, welk verkoopdagboek of financieel dagboek wordt gebruikt, welke btw-codes horen bij Nederlandse en buitenlandse verkopen, en of fees op een aparte kostenrekening komen. Laat de accountant dit schema goedkeuren.

Mijn praktische voorkeur is een geblokkeerde AFAS-order voor de operationele route en een aparte financiële vrijgave voor de geldstroom. Zo hoeft een payout die pas de volgende werkdag komt niet je magazijn te stoppen. De financiële boeking blijft wel geblokkeerd totdat de payout, fee en eventuele refund of chargeback volgens het beleid zijn verwerkt.

Controlepunt: je kunt voor één voorbeeldorder aanwijzen welk AFAS-object wordt aangemaakt, wie het vrijgeeft, welk dagboek wordt gebruikt en welke status de order krijgt als de payout ontbreekt.

2. Maak één sleutelset voor de hele keten

Maak per order een onveranderlijk geldstroomrecord. Gebruik niet alleen het PrestaShop-ordernummer. Dat nummer is leesbaar, maar een payout bevat meerdere orders en een klant kan meerdere betalingen hebben.

Leg unieke beperkingen aan op provider-ID’s en AFAS-ID’s. Eén refund_id mag maar één refundrecord hebben. Eén afas_order_id mag maar één bronorder vertegenwoordigen. Als een webhook nogmaals binnenkomt, verander je de status of registreer je een ontvangstpoging. Je maakt geen tweede financieel object.

Controlepunt: je kunt vanuit een AFAS-boeking terugzoeken naar de payout en vanuit de payout terugklikken naar de order, betaling en oorspronkelijke orderregel.

3. Richt beperkte connectoren en accounts in

Maak aan de AFAS-kant bij voorkeur twee App connectoren of twee duidelijk gescheiden profielen:

• prestashop-ingest: mag alleen de afgesproken order- of financiële UpdateConnector aanroepen en de benodigde GetConnectoren lezen.
• afas-release: mag alleen de vrijgaveactie uitvoeren nadat de interne gate approved_for_afas op groen staat.

Gebruik afzonderlijke systeemgebruikers en leg vast welke connector bij welk proces hoort. Een token dat tegelijk orders aanmaakt, blokkades vrijgeeft en financiële mutaties schrijft, maakt een fout moeilijk terug te vinden. De Autoriteit Persoonsgegevens adviseert passende autorisaties en logging van toegang tot persoonsgegevens in de actuele uitleg over toegang tot persoonsgegevens. Dat principe geldt hier ook voor order-, klant- en betaalgegevens.

Aan de PrestaShop-kant laat je schrijven uitstaan. Alleen als je bewust een orderstatus terugzet, voeg je precies die ene schrijfrecht toe en test je de gevolgen. Aan de PSP-kant bewaart de verwerkingslaag de geheime sleutel. De webhook zelf is een signaal, geen bewijs dat een bedrag is betaald.

4. Laat betaalbevestiging het ordermoment bepalen

Maak een order niet AFAS-klaar zodra hij in PrestaShop is aangemaakt. Een order kan nog wachten op betaling, mislukken of door een PSP worden geannuleerd. Gebruik één expliciete betaalstatus, bijvoorbeeld paid bij Mollie, en leg vast welke PrestaShop-status daarbij hoort.

Mollie stuurt bij een webhook alleen het ID van het gewijzigde object. Je moet daarna de actuele status ophalen. De webhook kan ook komen voor refundstatussen en chargebacks. Mollie beschrijft deze volgorde, inclusief de statusgevallen en de retryperiode van webhooks. Verwerk een webhook daarom zo:

1. Sla het ontvangen ID en tijdstip op.
2. Haal het betaal-, refund- of chargebackobject opnieuw op bij de provider.
3. Vergelijk de providerstatus met je laatste bekende status.
4. Maak of wijzig alleen het bijbehorende domeinrecord.
5. Laat de order naar staging gaan zodra betaling en ordergegevens uniek matchen.

Een betaalbevestiging is dus voldoende om een operationele order vrij te geven als je beleid dat toestaat. Voor de financiële batch ga je verder met payout en kosten.

5. Reconcileer payout en fee op componentniveau

Een payout is nooit de omzetregel van één order. Bij maandafsluiting moeten bankregel, payout, refund, chargeback en fee elk hun eigen bron en periode houden in een controleerbare period-close-keten. Haal bij Mollie het Settlement Report op. Dat rapport bevat de transacties, fees en inhoudingen die in één payout zitten. Mollie onderscheidt onder meer betalingen, refunds, chargebacks, betaalmethode-fees, refund-fees en chargeback-fees in de actuele rapportage-uitleg.

Leg per settlement een berekening vast:

netto payout = betalingen + positieve correcties - refunds - chargebacks - fees - negatieve correcties

Match daarna in deze volgorde:

1. Payout-ID of settlementreferentie aan de bankregel of AFAS-clearingrekening.
2. Provider payment-ID aan orderreferentie en bedrag.
3. Refund- en chargeback-ID aan de oorspronkelijke betaling.
4. Fee-ID aan de aparte kostenrekening.
5. Som van alle componenten aan het payoutbedrag.

Een verschil gaat naar de queue. Boek een ontbrekende fee niet als afronding omdat het bedrag klein is. Boek een onbekende payment niet rechtstreeks op omzet. Je wilt na de maandafsluiting kunnen uitleggen waarom een payout afwijkt en wie dat heeft vrijgegeven.

Controlepunt: voor de financiële batch staat payout_match = exact, fee_match = exact en unexplained_value = 0 of er ligt een expliciete goedkeuring voor het resterende risico.

6. Houd refund en chargeback uit elkaar

Een refund is een bewuste terugbetaling door jou. Een chargeback is een betwisting via de bank van de klant. Beide verminderen de PSP-balance, maar de bewijsroute, eigenaar en boekingsbehandeling verschillen.

Gebruik aparte statussen: requested, processing, succeeded, failed, chargeback_received, chargeback_evidence_due en closed. Laat requested of processing nooit tellen als geld dat werkelijk is teruggestuurd. Bewaar bij een refund het oorspronkelijke payment-ID, het orderregel-ID, het bedrag, de btw-context en de creditnota. Bewaar bij een chargeback ook reden, bewijsdeadline en verantwoordelijke.

Voor een deelrefund gebruik je een vaste actiessleutel. Mollie waarschuwt expliciet dat een dubbele retry bij gedeeltelijke refunds twee aparte refunds kan veroorzaken. De API ondersteunt daarom een Idempotency-Key; dezelfde sleutel levert binnen één uur een herhaalde respons op in plaats van een nieuwe aanvraag in de actuele uitleg over idempotentie. Sla de sleutel ook buiten Mollie op, want de interne boeking en de creditnota moeten dezelfde actie herkennen.

Zet voor iedere nog niet afgesloten refund of chargeback afas_release = blocked. Een order die al operationeel is vrijgegeven kan financieel nog steeds wachten. Komt er na een refund een chargeback op dezelfde betaling, dan pauzeer je de automatische route en laat je één bevoegde medewerker bepalen welke compensatie werkelijk hoort.

7. Bouw staging en een proefbatch

Staging is een eigen tabel of kleine applicatie waarin je de volledige geldstroom vastlegt vóór je naar AFAS schrijft. Bewaar bron-snapshot, genormaliseerde waarden, matchresultaat, payload, validatiefouten, vrijgavebesluit en de uiteindelijke AFAS-respons. Laat een retry nooit direct opnieuw schrijven zonder eerst te zoeken naar een bestaand AFAS-object.

Draai als proefbatch twintig echte orders of, bij een kleiner volume, de eerste volledige werkdag. Neem bewust deze gevallen mee: een gewone betaalde order, een order met korting, een late betaalbevestiging, een payout met fee, een refund, een chargeback, een dubbele webhook en een time-out na de AFAS-aanroep. Gebruik geen automatische productie-vrijgave in deze batch.

Meet per regel vier dingen:

• matchpercentage = uniek gematchte geldregels / geldregels die voor de batch verwacht waren × 100;
• uitzonderingsduur = gesloten_at - aangemaakt_at per queue-item;
• goedkeuringsduur = afas_approved_at - batch_ready_at;
• dubbele_schrijvingen = aantal tweede AFAS-objecten voor dezelfde idempotente sleutel.

Mijn minimale productiedrempel voor deze route is 100% unieke order- en payment-matches, nul dubbele AFAS-objecten en een zichtbare eigenaar voor iedere uitzondering. Kies zelf een grens voor uitzonderingsduur en goedkeuringsduur. Zet die grens in het proces, niet alleen in een dashboard.

8. Geef de batch gecontroleerd vrij naar AFAS

De vrijgever controleert per batch:

1. orderreferentie, orderregels en btw-code;
2. betaalstatus en payment-ID;
3. payoutreferentie, fee en netto bedrag;
4. refund- en chargebackstatus;
5. ontbrekende of dubbele sleutelvelden;
6. AFAS-doelobject, dagboek en periode;
7. wie de vrijgave uitvoert en welke rechten die gebruiker heeft.

Daarna zet je approved_for_afas = true en laat je de beperkte uitvoerder de payload schrijven. Gebruik je AFAS-verkooporders, dan maakt FbSales de order aan en gebruik je FbFreeOrder pas voor een geblokkeerde order die alle controles heeft doorstaan. Test bij iedere proefbatch dat de vrijgave niet mislukt doordat een andere gebruiker de order nog open heeft.

Als de API-aanroep time-out, is de uitkomst onbekend. Zoek eerst naar de order of boeking met de externe orderreferentie en idempotente sleutel. Bestaat het object al, sla de tweede schrijfactie over en registreer de gevonden AFAS-ID. Bestaat het object niet, herhaal dan dezelfde payload met dezelfde sleutel. Een nieuwe sleutel betekent een nieuwe financiële actie.

Valkuilen die je vrijgave onbetrouwbaar maken

Je gebruikt orderaanmaak als betaalbewijs

Een order kan in PrestaShop bestaan zonder geslaagde betaling. Mitigatie: wacht op de expliciete betaalstatus, haal de actuele status bij de PSP op en sla payment-ID plus orderreferentie op. Een orderstatus zonder payment-ID gaat naar de queue.

Je gebruikt de payout als verzendtrigger

Een payout is een bundel die later komt en fees, refunds en chargebacks bevat. Mitigatie: laat operationele levering op betaalbevestiging lopen en gebruik de payout als controle voor de financiële batch. Alleen als je risicobeleid dat echt vereist, maak je payout een extra voorwaarde voor vrijgave.

Je boekt het netto payoutbedrag als omzet

Daarmee verdwijnen fees en refunds in de omzet en is de bankregel niet meer terug te rekenen. Mitigatie: gebruik een PSP-clearingrekening en boek betaling, fee, refund, chargeback en payout als aparte componenten.

Je vertrouwt op één providerstatus

paid, refunded, processing en chargeback zijn gebeurtenissen in verschillende objecten. Mitigatie: bewaar de parent payment, de actuele providerstatus, de statusdatum en de bron van de wijziging. processing is geen ontvangen refund.

Je geeft te brede AFAS-rechten

Een connector die orders kan wijzigen en tegelijk vrijgeven, kan een fout automatisch groter maken. Mitigatie: scheid ingest, verrijking en release in profielen, connectoren en gebruikers. Test met een account dat precies de bedoelde actie mag uitvoeren.

Je maakt bij een time-out een nieuwe sleutel

De eerste schrijfactie kan al zijn uitgevoerd. Een nieuwe poging met een nieuwe sleutel kan dus een tweede order, boeking of refund maken. Mitigatie: zoek eerst op externe sleutel en provider-ID, sla request en response op en herhaal alleen met dezelfde sleutel.

Je behandelt chargeback als refund

Bij een refund bepaalt de verkoper het bedrag. Bij een chargeback komt de beslissing van de bank of kaarthouder en ontstaat vaak een bewijsdeadline. Mitigatie: aparte redencode, eigenaar, status, grootboekbehandeling en opvolging.

Je bewaart alleen de eindstatus

Een groen AFAS-record vertelt niet welke payout, fee of refund de beslissing onderbouwde. Mitigatie: bewaar snapshots, bronversies, waarden vóór en na, beslisser, tijdstip en uiteindelijke AFAS-ID. NIST beschrijft logbeheer als een combinatie van infrastructuur en robuuste processen, niet als één los logbestand in SP 800-92, gepubliceerd in september 2006.

Je laat de queue verdwijnen na de maandafsluiting

Een onbekende betaling of open chargeback blijft een financieel dossier nadat de maand is gesloten. Mitigatie: archiveer de queuekaart met bewijs, eigenaar, deadline en heropeningsregel. Verwijder geen bronregel om een dashboard groen te krijgen.

Beslis-kader: connector, n8n of maatwerk?

Kies op je zwaarste uitzondering, niet op je gemiddelde ordervolume. Een standaardconnector past bij één PrestaShop-shop, één AFAS-administratie, één PSP, vaste btw-regels en vooral volledige betalingen. Een eigen tussenlaag wordt nodig zodra je per orderregel wilt kunnen herstellen, meerdere PSP’s hebt of de financiële vrijgave losstaat van de operationele order.

Wanneer kant-en-klaar genoeg is

Een kant-en-klare PrestaShop-AFAS-koppeling kan een goede eerste route zijn als je vooral orders naar financiële boekingen of verkooporders wilt sturen. Controleer wel de grenzen vóór aanschaf. De actuele handleiding van Webwinkelfacturen voor PrestaShop en AFAS, gewijzigd op 14 april 2026, noemt de koppeling financieel en niet logistiek, haalt nieuwe orders minimaal ieder uur op en zet fouten in een aparte foutweergave. Dezelfde handleiding zegt dat betaalmethoden worden doorgegeven, maar dat betaalkosten niet in de PrestaShop-order zitten en dus niet worden doorgestuurd in de productdocumentatie. Dat is precies het gat waar payout- en fee-reconciliatie begint.

Kies deze route als de leverancier schriftelijk bevestigt dat jouw AFAS-doelobject, btw-codes, deelrefunds, chargebacks, dubbele events en uitzonderingsbeheer passen. Een productpagina met het woord refund is geen bewijs dat een gedeeltelijke refund aan de juiste orderregel en creditnota wordt gekoppeld.

Wanneer n8n volstaat

n8n is bruikbaar als orkestratielaag voor webhooks, geplande rapporten, meldingen en een kleine queue. De actuele Cloud-prijs is €20 per maand bij jaarlijkse betaling voor Starter met 2.500 workflowuitvoeringen en onbeperkte stappen. Pro kost €50 per maand bij jaarlijkse betaling en bevat 10.000 uitvoeringen. n8n rekent per volledige workflowuitvoering, niet per losse stap volgens de actuele prijspagina. De prijs vervangt geen duurzame database, secretsbeheer, monitoring of financiële controle.

Kies n8n als de regels stabiel zijn en je een technische beheerder hebt. Zet provider-ID’s en idempotente sleutels in een eigen opslaglaag. Laat n8n een queue-item aanmaken en meldingen versturen, maar laat een financiële vrijgave pas door als de batch een expliciet besluit heeft.

Wanneer maatwerk de eerlijke keuze is

Kies maatwerk bij meerdere administraties, verschillende valuta, meerdere PSP’s, veel deelrefunds, afzonderlijke bevoegdheden voor refund en boeking, of een verplicht herstelpad na een onbekende schrijfuitkomst. Dan bouw je geen doorgeefluik maar een klein transactiesysteem met bron-snapshots, statusmodel, sleutelbeperkingen, staging, replay, queue en vrijgavescherm.

Maatwerk is niet automatisch duurder in totaal. Een goedkope connector die elke week uitzonderingen op een spreadsheet zet, verschuift de rekening naar finance en maakt herstel afhankelijk van geheugen. Reken daarom drie posten mee: bouw, beheer en de kosten van een foutieve of dubbele boeking.

Vergelijkingstabel: drie manieren om de keten te bouwen

Prijzen en productdetails hieronder zijn gecontroleerd op 5 oktober 2026. De prijs van een standaardconnector verschilt per leverancier en dekking; daarom zet ik daar geen verzonnen bedrag naast.

Uitgewerkt voorbeeld: een batch van twintig orders in Mollie en AFAS Profit

Dit is een herkenbaar rekenvoorbeeld met oefendata, geen gepubliceerde klantcase. De webshop gebruikt PrestaShop, Mollie als betaalprovider en AFAS Profit voor de administratie. De operationele verkooporder mag na betaalbevestiging verder, maar de financiële batchvrijgave wacht op een volledige payoutcontrole.

De batch

Op 5 oktober 2026 staan twintig betaalde orders klaar. De orderlaag bevat twintig unieke PrestaShop-order-ID’s en twintig payment-ID’s. Het bruto bedrag is €2.480,00. Mollie toont in het Settlement Report €18,40 aan betaalmethode-fees en één refund van €44,00. Er zijn geen chargebacks. De verwachte payout is daarom:

€2.480,00 - €18,40 - €44,00 = €2.417,60

De verwerkingslaag heeft voor iedere order order_reference, transaction_id, bedrag, btw-code en AFAS-doelobject vastgelegd. De fee krijgt een aparte rekening. De refund hoort bij payment tr_abc123, order 10482, regel 7811 en actiessleutel refund-10482-7811-1. De oorspronkelijke order blijft €215,95; de refund verandert alleen de vastgelegde orderregel en de bijbehorende creditnota.

Wat er goed en fout gaat

Negentien Mollie-webhooks komen op tijd binnen. Voor order 10482 komt dezelfde webhook drie keer binnen door een tijdelijke storing. De verwerkingslaag haalt drie keer de actuele paymentstatus op, maar vindt iedere keer dezelfde transaction_id. De unieke sleutel maakt één paymentrecord en drie ontvangstlogs. Er ontstaat geen tweede AFAS-order.

De refund staat eerst op processing. De financiële vrijgavepoort blijft daarom blocked_for_refund. Zodra Mollie refunded meldt, wordt het refund-ID opgeslagen, wordt de creditnota gekoppeld en kan de batch verder. Een tweede poging met dezelfde idempotentiesleutel levert geen tweede refund op.

De payoutcontrole loopt daarna zo:

1. De Settlement Report-referentie wordt gekoppeld aan de verwachte payout.
2. Twintig paymentregels worden aan twintig orderreferenties gematcht.
3. De fee van €18,40 gaat naar de fee-rekening, niet naar omzet.
4. De refund van €44,00 gaat naar de oorspronkelijke betaling en creditnota.
5. De som sluit op €2.417,60 en de onverklaarde waarde is €0,00.
6. Finance ziet dat de payout niet als één omzetregel is verwerkt.
7. De batch krijgt approved_for_afas = true.

De meetwaarden zijn op batchniveau eenvoudig:

• matchpercentage: 20 van 20 orders, dus 100%;
• dubbele financiële objecten: 0;
• uitzonderingsduur van de refund: 1 uur en 42 minuten;
• goedkeuringsduur na batch_ready: 18 minuten;
• payoutafwijking: €0,00.

Daarna schrijft de beperkte AFAS-uitvoerder de afgesproken financiële batch of zet hij de geblokkeerde AFAS-orders vrij. De releaseactie gebeurt één keer, met de opgeslagen batchreferentie en de naam van de vrijgever. De operationele ordervrijgave en de financiële batchvrijgave blijven in het log twee verschillende beslissingen. Een AFAS-blokkade vraagt daarom een aparte financiële en logistieke beoordeling.

De hersteltest

Na de eerste geslaagde AFAS-aanroep geeft de netwerklaag een time-out. De verwerkingslaag markeert de call als unknown, niet als mislukt. Hij zoekt AFAS op order_reference en de interne sleutel. Het object bestaat al. De bestaande AFAS-ID wordt opgeslagen en de tweede schrijfactie wordt overgeslagen. De batch blijft één keer geboekt.

Als het object niet bestond, zou dezelfde payload opnieuw worden aangeboden met dezelfde idempotente sleutel. De queue bewaart de time-out, de zoekactie en de uiteindelijke uitkomst. Dat is het verschil tussen herstel en opnieuw gokken.

Slot: de vrijgave moet uitlegbaar blijven

De goedkoopste route is niet degene met de laagste maandprijs. Het is de route die je geldstroom uitlegbaar houdt nadat de eerste refund, fee of chargeback afwijkt. Een connector mag orders snel doorzetten, maar je moet vooraf weten of hij ook de financiële uitzonderingen kan verklaren.

Een veilige AFAS-vrijgave is geen groen vinkje. Het is een besluit met een bronorder, payment-ID, payoutreferentie, fee, refund- of chargebackstatus, bevoegdheid, tijdstip en herstelpad. Ontbreekt één van die onderdelen, dan hoort de regel in de queue.

De grens is eenvoudig te testen: als een medewerker vanuit de AFAS-boeking niet binnen een paar klikken kan terugvinden welke order, betaling en payout het bedrag verklaren, is de koppeling nog niet klaar voor automatische vrijgave.

De geldstroom moet kunnen terugpraten naar de order, en de order moet kunnen uitleggen waarom hij wel of niet is vrijgegeven. Pas wanneer die twee richtingen met dezelfde sleutel, hetzelfde bewijs en een benoemde beslisser sluiten, is automatisering ook beheersing.