AFAS SB koppelen aan webshop of CRM met herstelbare sync

Een order die in je webshop betaald is, is nog geen boekhoudkundig feit. Een CRM-contact met een mooi ingevuld e-mailadres is nog geen unieke relatie in AFAS SB. Zet je beide systemen rechtstreeks door, dan automatiseer je vooral de snelheid waarmee een verkeerde klant, btw-code of omzetrekening in je administratie belandt.

De betrouwbare route begint bij de vraag wie welk veld bezit. Daarna leg je OAuth-toegang aan, haal je de juiste AFAS-identifiers op, bouw je een vaste mapping en schrijf je pas na een controleerbare beslissing. Een time-out maakt een write niet mislukt. Hij maakt de uitkomst onbekend totdat je die hebt teruggevonden.

De grens tussen commercieel signaal en financiële vrijgave staat ook scherp bij een gewonnen CRM-deal die eerst naar een gecontroleerde conceptfactuur gaat: de status is een kandidaat, geen boekhoudkundige waarheid.

Een herstelbare AFAS SB-sync is een koppeling waarin elke wijziging een bron, zakelijke sleutel, doeladministratie en bewijsrecord heeft. Bij een dubbele webhook of time-out zoek je eerst de bestaande verwerking op, gebruik je dezelfde tracking identifier en lees je daarna terug welke factuur, journaalpost en openstaande post werkelijk in AFAS SB staan.

Deze gids is voor een webshop- of CRM-eigenaar die AFAS SB wil koppelen zonder iedere uitzondering handmatig uit te zoeken. De voorbeelden en prijzen zijn gecontroleerd op 21 oktober 2026.

Eerst de route kiezen

Een AFAS SB-koppeling is geen enkele API-call. Je kiest eerst wat je in AFAS wilt vastleggen en hoeveel controle je nodig hebt als de data niet netjes past.

• Standaardkoppeling: kies dit als je webshop één bekend orderpatroon heeft, de verkoopgegevens rechtstreeks naar een verkoopjournaalpost mogen en de uitzonderingen klein zijn. AFAS SB noemt gecertificeerde koppelingen getest, onderhouden en gecertificeerd. Controleer wel of de connector jouw CRM-velden, refunds, buitenlandse btw en herstelproces ondersteunt.
• n8n of Make: kies een orkestratielaag als je webshop, CRM en AFAS SB met elkaar moet laten praten, maar de regels overzichtelijk blijven. Bouw de stagingtabel en uitzonderingsqueue zelf. De uitvoeringslog van de workflowtool is geen boekhoudkundig bewijs.
• Eigen API-koppeling: kies maatwerk bij meerdere webshops, meerdere administraties, afwijkende factuurregels, veel retouren of een proces waarin een mens eerst moet vrijgeven. Dan kun je OAuth, mapping, herhaalgedrag, reconciliatie en read-back als één geheel ontwerpen.

Mijn korte regel: als de koppeling alleen een afgeronde order als omzetboeking doorgeeft, kan een standaardroute volstaan. Zodra je klant, adres, product, btw, betaling of factuurstatus over meerdere systemen moet verklaren, heb je een eigen bewijslaag nodig.

Wat je nodig hebt voordat je koppelt

Leg eerst het gegevenscontract vast. Een ontwikkelaar kan een endpoint aanroepen, maar geen onduidelijke afspraak oplossen over de vraag of de webshop of het CRM de klantnaam mag overschrijven.

• Een AFAS SB-omgeving en doeladministratie. Een klantomgeving kan meerdere administraties bevatten. Leg de gekozen AdministrationId vast in de configuratie van die klant en laat hem niet per run uit een vrije tekstveld komen.
• OAuth-inloggegevens. Voor AFAS SB krijg je een client_id en client_secret. De OAuth-flow gebruikt PKCE, een consent-endpoint en een token-endpoint. Bewaar het geheim in een secret manager, niet in een webshop-plugin of JavaScript in de browser.
• Rechten op de juiste bundels. Je hebt leesrechten nodig voor administraties, relaties, producten of grootboekrekeningen en betaalcondities. Voor writes heb je precies het gekozen endpoint nodig, bijvoorbeeld salesinvoice of salesjournalentry. Geef geen algemene schrijfrechten omdat een test sneller gaat.
• Een bronregister. Leg per veld vast of de webshop, het CRM, AFAS SB of een menselijke vrijgever de bronhouder is. Bewaar ook de bronversie en het moment waarop je de waarde las.
• Een relatie- en productmapping. Gebruik stabiele externe IDs. E-mail, naam en SKU zijn zoekvelden. Ze zijn pas een sleutel als jij dat expliciet afdwingt en dubbele waarden afwijst.
• Een stagingtabel. Bewaar de bronpayload, genormaliseerde payload, payloadhash, zakelijke sleutel, tracking identifier, AFAS-resultaat, status, eigenaar, foutreden en tijdstippen.
• Een uitzonderingsqueue. Een onbekende klant, dubbele match, btw-afwijking, niet-bestaand product en onduidelijke write krijgen elk een reden, eigenaar en uiterste datum.
• Een testset. Neem een gewone order, een order met korting, twee btw-tarieven, een buitenlandse klant, een retour, een gedeeltelijke betaling, een onbekende relatie en een dubbele webhook op.

De minimale startcheck is kort. De beslissing erachter is dat niet.

0/9

• OAuth client_id, client_secret, redirect_uri en PKCE-flow zijn ingericht
• Eén AFAS SB AdministrationId is per klantconfiguratie vastgelegd
• Bronhouder en eigenaar zijn per veldgroep afgesproken
• Relaties, producten, grootboekrekeningen en betaalcondities hebben een vaste mapping
• Staging bewaart payloadhash, zakelijke sleutel en Tracking-Identifier
• `pending_approval` bewaart approver, gecontroleerde payload/mapping, auditmoment en vrijgavebesluit
• De uitzonderingsqueue heeft reden, eigenaar, deadline en volgende actie
• De testset bevat btw, korting, retour, onbekende relatie en dubbele aflevering
• Read-back controleert de werkelijke factuur- en betaalstatus in AFAS SB

Concrete stappen: van OAuth naar gecontroleerde write

De route hieronder maakt eerst een kandidaat, daarna een financieel record. De volgorde is belangrijk. Je schrijft niet naar AFAS SB om later te ontdekken welk bedrag je eigenlijk had willen boeken.

1. Richt OAuth in met een vaste eigenaar

Voor een eigen AFAS SB-koppeling vraag je eerst de client_id en client_secret aan. De gebruiker geeft toestemming via APIserverUrl/klantomgeving/app/auth. Daarna wissel je de code via APIserverUrl/klantomgeving/app/token in voor een bearer-token. De SB-documentatie gebruikt PKCE met S256, een state-waarde en een redirect_uri die vooraf geregistreerd is. Het access-token is volgens de actuele SB-documentatie 1.800 seconden geldig. Ververs dus op tijd en sla de nieuwste refresh-token op. De OAuth-flow, endpoints en tokenlevensduur staan in de actuele AFAS SB-authenticatiedocumentatie, geraadpleegd op 21 oktober 2026.

Gebruik voor een unattended koppeling een eenmalige consent door de bevoegde AFAS-gebruiker. Daarna draait de server met de opgeslagen refresh-token. Log geen tokens, authorization codes of volledige Authorization-headers. Leg wel vast welke connectorversie, omgeving en gebruiker de verwerking uitvoerde.

De token is toegang, geen bedrijfsbesluit. De gebruiker die de app toestemming geeft, bepaalt niet automatisch welke klant of omzetrekening bij een order hoort. Dat leg je later vast in je mapping.

2. Haal de AFAS-structuur op voordat je velden mapt

Lees eerst de beschikbare administraties op via GET /api/administrations. Sla de gekozen ID op naast de klantconfiguratie. Haal daarna relaties op via GET /api/persons en GET /api/organisations. Voor een verkoopjournaalpost zijn relatie en grootboekrekening verplichte onderdelen. Gebruik GET /api/ledgeraccounts om toegestane rekeningen op te halen. Een afwijkende betaaltermijn kun je met GET /api/paymentconditions controleren.

Maak één mappingbestand met de technische ID, leesbare naam, administratie en datum van controle. Bijvoorbeeld:

Een naam die er hetzelfde uitziet is geen bewijs dat het dezelfde relatie is. Leg de externe ID terug in het CRM of de webshop vast zodra de match door een mens is bevestigd.

3. Wijs per veld één bronhouder aan

Een sync wordt onbetrouwbaar wanneer drie systemen tegelijk gelijk willen hebben. Maak daarom een bronhoudermatrix voordat je de eerste webhook activeert. Voor een gebruikelijke orderflow werkt dit vaak als volgt:

• De webshop bezit ordernummer, orderregels, aantallen, betaalpoging en retourstatus.
• Het CRM bezit commerciële eigenaar, klantsegment en contactvoorkeur.
• AFAS SB bezit de boekhoudkundige relatie-ID, administratie, grootboekrekening, btw-beslissing na controle en openstaande factuurstatus.
• De betalingsprovider bezit de transactie- en payoutstatus.

Een CRM-update mag dus een contactnaam wijzigen, maar niet stilletjes de financiële relatie-ID vervangen. Een orderupdate mag een retour kandidaat maken, maar niet zelf een correctieboeking uitvoeren. Als de bronhouder ontbreekt, is de route geen automatisering maar een overschrijfwedstrijd.

Bewaar bij elke kandidaat source_system, source_id, source_version of updated_at en snapshot_at. Een latere update wordt een nieuwe versie. Hij verandert het oude bewijsrecord niet. Een Shopify-route met shadow-read, reconciliatie en ringgewijze vrijgave laat dezelfde logica zien wanneer een broncontract verandert.

4. Kies tussen verkoopfactuur en verkoopjournaalpost

Gebruik salesinvoice wanneer AFAS SB de factuurinhoud moet bewaren, de factuur vanuit AFAS SB moet worden verstuurd of je productregels, adressen en factuurbijlagen in AFAS nodig hebt. De AFAS SB-how-to over verkoopfacturen haalt hiervoor administratie, relatie, producten, adressen en eventueel bijlagen op en maakt daarna de verkoopfactuur aan. AFAS gebruikt het factuuradres bij de btw-berekening.

Gebruik salesjournalentry wanneer de webshop of een ander facturatiesysteem de factuur al heeft gemaakt en je in AFAS SB vooral het financiële feit wilt vastleggen. De payload bevat onder meer factuurnummer, factuurdatum, administratie, relatie, betaalmethode en regels met grootboekrekening, bedrag exclusief btw en btw-behandeling. De AFAS SB-how-to’s beschrijven het verschil tussen een verkoopfactuur en een verkoopjournaalpost en noemen de benodigde relaties, administratie en regels, geraadpleegd op 21 oktober 2026.

Meng beide routes niet voor dezelfde order. Een verkoopfactuur plus een losse verkoopjournaalpost voor één betaling kan dezelfde omzet twee keer vastleggen. Zet daarom in je business key ook write_mode=salesinvoice of write_mode=salesjournalentry.

5. Maak vóór de write een zakelijke sleutel

Maak een sleutel die de economische handeling beschrijft, niet de aflevering van een webhook. Voor een verkoopjournaalpost kan dat zijn:

afas-sb:{administration_id}:{source_system}:{order_id}:sale:v1

Voor een retour krijgt de handeling een nieuwe zakelijke sleutel, bijvoorbeeld ...:refund:v1. Een dubbele aflevering van dezelfde order gebruikt dus dezelfde sleutel. Een echte correctie krijgt een nieuwe versie en een nieuwe reden.

Sla vóór de API-call een stagingrecord op met business_key, payload_hash, tracking_identifier, source_snapshot_at, status=pending_approval, owner en next_action. Gebruik op de AFAS SB-request de Tracking-Identifier-header met een vaste GUID. AFAS gebruikt deze identifier om een al verwerkte POST of PUT opnieuw uit cache te beantwoorden zonder de request nogmaals aan de server aan te bieden. De eigen staginglaag blijft nodig, omdat je daar ook bronversie, eigenaar en beslissing bewaart.

Een POST is van nature niet idempotent. De Nederlandse overheidsrichtlijn maakt dat onderscheid expliciet en beschrijft Idempotency-Key als mechanisme om herhaalde writes dezelfde uitkomst te laten houden. Bij AFAS SB vertaal je dat naar de AFAS-specifieke Tracking-Identifier plus je eigen unieke bedrijfsrecord. De overheidsrichtlijn over veilige retries legt uit waarom een herhaalde POST zonder sleutel een duplicaat kan maken, geraadpleegd op 21 oktober 2026.

5a. Laat een mens de financiële write vrijgeven

Een kandidaat die mapping en bedragen doorstaat, is nog niet vrijgegeven. Zet de stagingstatus vóór stap 6 op pending_approval en blokkeer de worker totdat een bevoegde approver het exacte financiële voorstel heeft beoordeeld. De vrijgavekaart bewaart minstens:

• approver: de persoon of finance-rol die mag vrijgeven
• checked_payload_hash: de hash van de payload die daadwerkelijk klaarstaat
• mapping_version: de gecontroleerde versie van administratie, relatie, rekening en btw-mapping
• audited_at: het auditmoment waarop de controle is uitgevoerd
• approval_decision: approved of rejected, met een korte reden

De approver vergelijkt de payload met de bron-snapshot, controleert de mapping en legt de beslissing vast in hetzelfde bewijsrecord. Alleen bij approval_decision=approved gaat de status naar ready; bij afwijzen of een wijziging blijft de financiële write geblokkeerd en gaat de kandidaat naar de uitzonderingsqueue. Een latere wijziging van payload of mapping maakt de vrijgave ongeldig en start opnieuw bij pending_approval.

6. Schrijf beperkt en classificeer de response

Stuur alleen wanneer de stagingrecord status=ready heeft en approval_decision=approved naar POST /api/salesjournalentry of POST /api/salesinvoice. Beperk de API-gebruiker tot de gekozen write. Bewaar de volledige response voordat je de stagingstatus bijwerkt. Let op result, aangemaakte IDs, factuurnummer, traceId en errors.

Maak minimaal deze statussen:

AFAS SB waarschuwt dat een dubbel aangeboden request dubbel verwerkt kan worden. Een time-out is daarom geen uitnodiging om een nieuwe GUID te maken. Zoek eerst dezelfde stagingrecord, controleer of je response al is opgeslagen, gebruik dezelfde Tracking-Identifier en voer daarna read-back uit. Een partial-response is ook geen gewone fout. Je moet de verwerkte delen koppelen en de rest apart herstellen. De AFAS-documentatie over responses en errors beschrijft ook dat een dubbel aangeboden request dubbel kan worden verwerkt. Bij API-capaciteit die bepaalt welke actie wacht, stopt of met dezelfde sleutel hervat hoort die keuze in je bedrijfsregels te staan, niet in de retry-teller van een worker.

7. Reconcileer ook buiten webhooks

Gebruik een webhook of event uit de webshop als trigger om een kandidaat in de queue te zetten. Vertrouw niet op de volgorde of volledigheid van events. Maak een periodieke controle die openstaande bronrecords opnieuw ophaalt met een cursor, updated_at-venster of AFAS Tracking Token. AFAS SB ondersteunt een TrackingToken om wijzigingen in een dataset op te halen. De eerste volledige read sla je op; volgende reads gebruiken de vorige token. Niet ieder endpoint levert zo’n token, dus leg per dataset een terugvalroute vast.

Gebruik bij grotere reads skip, take en een vaste sort. Zonder vaste sortering kan een pagina tussen twee requests verschuiven. Bewaar last_cursor of de combinatie van token, sortering en moment. De AFAS SB-documentatie beschrijft Tracking Tokens voor wijzigingen, geraadpleegd op 21 oktober 2026. De pagineringsdocumentatie legt skip, take en sort uit voor reproduceerbare pagina’s, geraadpleegd op 21 oktober 2026.

Vergelijk per zakelijke handeling:

1. Is de order of CRM-wijziging aanwezig in de bron?
2. Is dezelfde business key één keer in staging aanwezig?
3. Is de AFAS-administratie en relatie gelijk aan de goedgekeurde mapping?
4. Zijn netto, btw, totaal en factuurnummer gelijk?
5. Is de betaling nog open, gedeeltelijk betaald of volledig betaald?
6. Is de huidige AFAS-status verklaard door een read-back?

8. Lees de werkelijk opgeslagen boekhoudstatus terug

Een positieve POST-response zegt dat AFAS SB de aanvraag heeft verwerkt. Hij zegt nog niet dat de klant, administratie en betaalstatus zijn wat je verwachtte. Haal bij een factuurflow de sales invoice terug via de actuele Get /api/salesinvoices-specificatie en controleer SalesInvoiceId, SalesInvoiceNumber, AdministrationId, RelationId, bedragen en Status. Voor de geldstatus lees je de openstaande debiteurenbalans terug. Leg OutstandingAmount, PaidAmount, TotalAmount, DueDate, InvoiceId en InvoiceNumber naast de oorspronkelijke kandidaat.

Bij een verkoopjournaalpost is het financiële feit vastgelegd, maar betaling blijft een aparte gebeurtenis. Zet dus niet automatisch paid=true omdat de write Succeeded is. Succeeded betekent verwerkt. PaidAmount=TotalAmount betekent dat de openstaande post volgens de teruggelezen balans volledig betaald is.

Een read-back die alleen controleert of een ID bestaat is te dun. Controleer de doeladministratie, relatie, bedragen, btw-uitkomst, factuurnummer, status en de koppeling met je business key. Als je geen uniek doelrecord kunt terugvinden, blijft de status unknown of exception.

Valkuilen die je administratie vervuilen

Je gebruikt e-mail als klant-ID

Een e-mailadres kan veranderen, gedeeld worden door een team of bij meerdere rechtspersonen horen. Gebruik e-mail om een kandidaat te vinden. Laat de definitieve match lopen via een opgeslagen externe ID of een combinatie van juridische naam, btw-nummer en menselijke bevestiging. Bij twee matches gaat de order naar de queue.

Je maakt één brede Update-flow

Een flow die relaties, producten, journaalposten en betalingen met dezelfde sleutel mag wijzigen, is moeilijk te testen en lastig te stoppen. Splits leesrechten, relatiebeheer en financiële writes. Geef de financiële route een aparte queue en eigenaar.

Je laat een CRM de boekhoudkundige waarheid overschrijven

Een CRM is een goede bron voor commerciële context. Het is niet vanzelf de bron voor grootboekrekening, btw-behandeling of openstaand bedrag. Zet die velden in AFAS-beheer of een expliciete mappingtabel.

Je verwart Succeeded met betaald

Een geslaagde verkoopjournaalpost is verwerkt, niet noodzakelijk geïncasseerd. Gebruik de AFAS-balans voor PaidAmount en OutstandingAmount. Houd ook chargebacks, refunds en deelbetalingen als aparte gebeurtenissen bij.

Je retryt na een time-out met een nieuwe sleutel

De eerste write kan zijn geslaagd terwijl het antwoord verloren ging. Een nieuwe tracking identifier maakt een tweede boeking mogelijk. De veilige volgorde is: staging zoeken, bestaande response of doelrecord zoeken, read-back doen, pas daarna met dezelfde identifier hervatten.

Je behandelt een gedeeltelijke verwerking als alles-of-niets

Bij PartiallySucceeded moet je precies vastleggen welke AFAS-records bestaan en welke fouten overblijven. Zet de kandidaat op handmatige beoordeling. Een nieuwe volledige POST kan de geslaagde delen dupliceren.

Je laat geen eigenaar achter

vat_unknown zonder eigenaar is geen herstelproces. Voeg owner, reason, created_at, due_at en next_action toe. Maak een afspraak dat een financiële uitzondering binnen één werkdag wordt bekeken.

Je gebruikt polling als enige synchronisatie

Een poll die niets vindt kost capaciteit en kan updates missen als je venster te smal is. Gebruik events als versneller en een periodieke reconciliatie als vangnet. Gebruik een overlap in je tijdvenster en dedupliceer met de business key.

Beslis-kader: wanneer is maatwerk de moeite waard?

De keuze wordt bepaald door de impact van een fout, niet door de populariteit van Make of n8n. Beantwoord vier vragen: schrijft de koppeling geld of alleen informatie, hoeveel bronhouders zijn er, hoe vaak komen uitzonderingen voor en wie beheert de queue?

• Kant-en-klaar past bij één webshop, één AFAS-administratie, een vast verkoopjournaalpatroon en weinig uitzonderingen. Vraag de leverancier vóór aanschaf hoe refunds, dubbele events, relatie-ID’s en read-back zijn geregeld.
• Orkestratie met eigen staging past bij een webshop plus CRM, enkele uitzonderingen per week en een team dat de flow kan beheren. Laat Make of n8n de API-calls uitvoeren, maar houd zakelijke sleutel, payloadhash, status en eigenaar in je eigen database.
• Maatwerk past bij meerdere administraties, meerdere btw-regels, facturen uit verschillende bronnen, refunds of writes die niet opnieuw mogen plaatsvinden. De extra kosten zitten in testen, monitoring en beheer. Dat is precies waar de betrouwbaarheid vandaan komt.

Een standaardconnector is niet automatisch goedkoop. Als je iedere maand één dubbele omzetboeking moet uitzoeken, betaal je de ontbrekende bewijslaag in werktijd en onzekerheid. Maatwerk is omgekeerd overkill wanneer je alleen een niet-kritieke melding doorstuurt.

Wat schrijft je koppeling naar AFAS SB?

Alleen lezen of meldenOmzet, facturen of betalingen

De uitkomsten van de keuzehulp zijn bewust dezelfde drie routes als het geschreven kader. Het interactieve blok verkort de keuze, maar vervangt de afweging niet.

Uitgewerkt voorbeeld: Shopify-order als AFAS SB-verkoopjournaalpost

Neem een Nederlandse Shopify-webshop met HubSpot als CRM, Mollie als betaalprovider en AFAS SB als boekhouding. De webshop verkoopt een bureaulamp voor € 100 exclusief btw. De order bevat één regel, 21 procent btw en een betaalde Mollie-transactie. De webshop heeft de factuur al naar de klant verstuurd. Daarom kiest deze flow voor salesjournalentry, niet voor een tweede AFAS-factuur.

Stap 1: de kandidaat

Shopify levert order #10482, Mollie levert betaling tr_8Q1, HubSpot bevat contact hs_551 en AFAS SB heeft relatie rel_7b8. De integratie maakt:

business_key = afas-sb:admin_33:shopify:10482:sale:v1

De stagingrecord bevat de order-snapshot, de koppeling naar Mollie, AdministrationId=admin_33, RelationType=organisation, RelationId=rel_7b8, de omzetrekening ledger_4010, AmountExcludingVat=100, AmountVat=21, VatType=high en PaymentMethod=banktransfer. De payloadhash is sha256:voorbeeld-10482-v1. De exacte hash in productie is uiteraard langer en wordt berekend, niet ingevuld door een medewerker.

Stap 2: de controles

De administratie-ID komt uit de vaste klantconfiguratie. De relatie-ID komt uit de mapping, niet uit de naam “Bureaulamp BV”. De omzetrekening is door finance gekoppeld aan de productgroep verlichting. De btw-beslissing is gebaseerd op het factuuradres en de regel. De som klopt: € 100 exclusief btw, € 21 btw, € 121 totaal. De Mollie-transactie is betaald, maar dat feit staat los van de verwerking in AFAS SB.

Een tweede Shopify-webhook arriveert door een retry. De worker vindt dezelfde business_key en payloadhash. Hij maakt geen tweede stagingrecord en verstuurt geen nieuwe financiële write.

Stap 3: pending_approval en menselijke vrijgave

Na de controles zet de integratie de stagingrecord op pending_approval. De vrijgavekaart voor dit voorbeeld bevat:

• approver=finance-owner-01
• checked_payload_hash=sha256:voorbeeld-10482-v1
• mapping_version=afas-sb-mapping-2026-10-21-v3, met controle van AdministrationId, RelationId, LedgerAccountId, VatType en de bedragen
• audited_at=2026-10-21T16:42:00+02:00
• approval_decision=approved

De finance-owner vergelijkt de payload met de Shopify-snapshot, de Mollie-referentie en de mappingtabel. De gecontroleerde hash en mappingversie zijn gelijk aan wat de worker klaar heeft staan. Pas na dit menselijke besluit gaat de status naar ready en mag de write starten. Bij een mismatch wordt de beslissing rejected, blijft de write geblokkeerd en gaat de kandidaat naar de uitzonderingsqueue.

Stap 4: de write

De worker verstuurt de verkoopjournaalpost met Tracking-Identifier: 6f5c4f9e-0a5a-4ff3-9c89-10482v1. AFAS antwoordt positief met een boekings-ID en factuurnummer. De worker slaat de response op als accepted en gebruikt niet meteen paid=true.

Stel nu dat de verbinding na de POST verbreekt. De status wordt unknown. De volgende run gebruikt dezelfde stagingrecord en tracking identifier. Hij controleert eerst de opgeslagen response en het doelrecord. Hij maakt geen tweede verkoopjournaalpost.

Stap 5: read-back

De reconciliatie leest de verkoopfactuur of de relevante verkoopgegevens terug en controleert administratie, relatie, factuurnummer, bedragen en status. Daarna leest hij de debiteurenbalans terug. Verwacht is TotalAmount=121, PaidAmount=121 en OutstandingAmount=0 wanneer de AFAS-balans de betaling inmiddels heeft verwerkt. Als PaidAmount=0 terugkomt, blijft de verkoopjournaalpost verified voor de boeking maar wordt de betaalstatus payment_open. Dat is geen fout in de write. Het is een volgende gebeurtenis die de flow nog moet volgen.

Stel dat de tweede read RelationId=rel_91 teruggeeft. Dan is het systeem niet geslaagd omdat er een ID bestaat. De reconcile maakt een exception met relation_mismatch, stopt de automatische vervolgactie en toont de oorspronkelijke mapping naast de werkelijk opgeslagen relatie.

Dit is het verschil tussen gegevens doorgeven en een financiële keten kunnen verklaren.

Vergelijkingstabel: connector, orkestratie of maatwerk

De prijzen hierboven zijn abonnementen, geen totale integratiekosten. Make rekent per moduleactie en n8n per workflowuitvoering. Een loop over vijftig orderregels kan in Make veel meer credits kosten dan één lineaire run. De echte kosten van maatwerk zitten in testdata, monitoring en herstel.

De bedragen zijn ontleend aan de actuele AFAS SB-prijspagina, n8n Pricing en de actuele Make-prijscontrole die op 21 oktober 2026 is geraadpleegd. Make telt moduleacties als credits, terwijl n8n cloud per workflowuitvoering rekent. De onafhankelijke prijsuitleg van JetAdmin zet die Make-meter en de jaarprijzen naast de officiële Make-pagina, gepubliceerd op 26 september 2026.

Voor de technische route geldt dezelfde grens als voor de inhoudelijke route: automatiseer een write pas wanneer je kunt aantonen welke bron hem veroorzaakte, welke AFAS-administratie hem ontving en welke boekhoudstatus er daarna werkelijk staat. Een koppeling is pas klaar wanneer een fout geen raadsel meer is, maar een record met een eigenaar, sleutel en volgende stap.

De boekhoudstatus is het eindpunt

Een webshop- of CRM-koppeling levert pas waarde wanneer je administratie de echte uitkomst weerspiegelt. OAuth geeft toegang, mapping geeft betekenis en een queue geeft je een manier om te wachten. Het beslissende bewijs komt daarna: een read-back die laat zien welke relatie, bedragen, factuur en openstaande post AFAS SB werkelijk heeft opgeslagen.

Wie die controle overslaat, heeft een snelle koppeling. Wie haar wel bouwt, heeft een financiële stroom die ook na een dubbele webhook, een verlopen token of een verbroken verbinding uitlegbaar blijft.