Twinfield koppelen aan je website.

Twinfield Boekhouden is online boekhoudsoftware van Wolters Kluwer. Het wordt veel gebruikt door accountantskantoren en door mkb-bedrijven die hun administratie samen met hun accountant voeren. Eén organisatie in Twinfield kan meerdere administraties bevatten, bijvoorbeeld een holding met een paar werkmaatschappijen.

Wolters Kluwer houdt een overzicht bij van koppelingen met andere software, zoals salaris-, kassa- en urenpakketten. Een koppeling met je eigen website staat daar niet tussen, omdat elke website anders is. Die bouw je zelf, op de Twinfield API.

Boekhoud je in Exact Online of Moneybird, dan gelden andere voorwaarden en werkt de techniek anders. Op die pagina's staat hoe dat werkt.

De certificering is geen technische stap maar een afspraak met Wolters Kluwer. In de API-voorwaarden staat dat elke koppeling gecertificeerd moet worden, en dat de certificering onderdeel is van een doorlopend API-abonnement. Daarbij zit API-support en toegang tot de Developer Portal, waar je de koppeling registreert.

Wat dat in de praktijk betekent: voordat we bouwen, stemmen we af wie het abonnement afsluit en wanneer de certificering plaatsvindt. Zonder dat kun je wel ontwikkelen en testen, met 5% van de normale limiet, maar niet live gaan met een koppeling waar je bedrijf op draait. Wolters Kluwer behoudt zich ook het recht voor de vergoeding te herzien, dus reken het abonnement mee als vaste post in je begroting.

Het bedrag zelf hoort bij Wolters Kluwer. Wij noemen het hier niet, omdat het per situatie kan verschillen en omdat het niet in de openbare documentatie staat.

De Twinfield API is een verzameling SOAP-webservices. Het meeste gaat via ProcessXml: je stuurt een XML-bericht, bijvoorbeeld een debiteur of een verkoopfactuur, en krijgt een XML-antwoord terug. Voor zoeken is er Finder, voor overzichten zoals openstaande posten is er Browse Data.

Inloggen gaat via OAuth 2.0 en OpenID Connect op login.twinfield.com. Een koppeling met een eigen server gebruikt de authorization code flow en vraagt de scope offline_access, zodat er een refresh token terugkomt. Met dat token haalt de koppeling elk uur een nieuw access token op, zonder dat iemand opnieuw hoeft in te loggen.

Bij elke aanroep gaan het access token en de CompanyCode mee in de header. Die code bepaalt in welke administratie de boeking terechtkomt. Heb je er meer, dan legt de koppeling per site, land of merk vast welke administratie hoort.

Een klant is in Twinfield een dimensie van het type debiteur. Wij maken hem aan met je eigen klantnummer als code, en zoeken bij een volgende order eerst op dat nummer. Zo blijft er één debiteur per klant, ook als iemand drie jaar later terugkomt.

Daarna komt de verkoop. Bij Compleet Boekhouden en MKB Boekhouden kan dat een verkoopfactuur zijn die Twinfield zelf maakt. Bij de andere abonnementsvormen boeken we een verkooptransactie op de debiteur, met de omzet op de juiste grootboekrekening en het juiste btw-tarief. Welke rekening bij welk product of welke dienst hoort, leggen we vooraf vast met je accountant.

Twinfield vraagt zelf om zuinig te zijn met regels en dimensies. De Fair Use Policy zegt dat gebruik dat ver boven het gemiddelde ligt, kan leiden tot een verzoek om minder te doen of tot een hogere vergoeding. Een webshop met veel kleine orders kan daarom per dag of per betaling samen boeken, in plaats van elke order als losse factuur. Meer over het opzetten van zulke stromen staat bij bedrijfsprocessen automatiseren.

De documentatie van Twinfield beschrijft geen webhooks. Twinfield laat je dus niet uit zichzelf weten dat een factuur is betaald; de koppeling moet het zelf vragen.

Dat doen we met een vaste ronde, bijvoorbeeld elk uur, die de openstaande posten van de debiteuren opvraagt die nog iets open hebben. Een zoekvraag kost 1 credit, dus dat past ruim binnen de limiet zolang je niet elke minuut alles opvraagt. Het resultaat zetten we bij de order of in het klantportaal.

Voor een klant betekent dat: de status op je site loopt hooguit één ronde achter op Twinfield. Voor een overzicht van openstaande facturen in een portaal is dat goed genoeg. Voor het vrijgeven van een digitale download na betaling niet, en daar hoort de betaalprovider de bron te zijn.

Op WordPress met WooCommerce of een offerteformulier komt er een uitbreiding op de server. Die reageert op een nieuwe order of een geaccepteerde offerte, zet de aanroep in een wachtrij en boekt hem in Twinfield. De tokens staan versleuteld op de server en niet in de database van de site.

Op een maatwerksite in Next.js is het een eigen serverroute met dezelfde wachtrij. Dat is de route voor een klantportaal met openstaande posten, of voor een platform dat in meerdere administraties boekt.

Koppelingen en maatwerk als dit vallen bij ons onder Design & Development.