Yuki koppelen: via je accountant of de Yuki API?

Yuki koppelen doe je via drie routes: je accountantskantoor dat een standaardkoppeling activeert, de Yuki-API met een kant-en-klare integratie, of een maatwerkpartij die de brug bouwt. Welke route past, hangt af van een vraag die bij Yuki anders ligt dan bij Exact of Moneybird: bij Yuki koos jij het pakket waarschijnlijk niet zelf — je accountant deed dat.

CleverTech AI ziet dat onderscheid terugkomen in bijna elk koppeltraject op Yuki, want het bepaalt wie eigenaar is van de administratie én van de koppeling.

Yuki verkoopt zijn boekhoudplatform namelijk niet rechtstreeks aan ondernemers. Het kantoor koopt de licenties en biedt ze aan zijn klanten aan (Yuki, 2026).

Dat maakt Yuki accountant-gedreven zodra je een webshop, urenregistratie of eigen software wilt koppelen. Onze gids over maatwerk software behandelt het bredere plaatje; dit artikel zoomt in op de Yuki-dynamiek: wie beslist, wat de API kan en wanneer je maatwerk inschakelt.

Waarom je Yuki waarschijnlijk niet zelf koos#

Yuki is een boekhoudplatform dat via accountants- en administratiekantoren bij de ondernemer terechtkomt, niet via een directe verkoop aan het MKB. Yuki maakt daarin een bewuste keuze: het levert alleen aan kantoren, die de licentie inkopen en doorzetten naar hun klanten (Yuki, 2026).

Yuki hoort bij de Visma-familie, de Noorse softwaregroep met tientallen boekhoud- en ERP-pakketten in Europa (Visma, 2026). Sinds 1 september 2026 gaat Yuki verder als Nmbrs Accounting, met accounting.nmbrs.nl als nieuw adres en inloggen via Visma Connect.

Verwar die nieuwe naam niet met de Nmbrs API-migratie: die gaat over de SOAP-koppeling van de salarissoftware Nmbrs uit dezelfde Visma-groep, niet over de webservices van Yuki.

Het kantoor is de poortwachter#

Dat verklaart waarom het gesprek over een koppeling bij Yuki bijna altijd langs het kantoor loopt.

Bij een pakket dat je zelf afsluit, beslis jij over integraties. Bij Yuki werk je in software die het kantoor beheert — herkenning van bonnen, verwerking van documenten en de communicatie tussen ondernemer en boekhouder zitten in één omgeving.

Het handwerk zit aan de randen#

Het handwerk dat overblijft, zit niet in Yuki zelf maar aan de randen: verkoopfacturen uit je webshop, gefactureerde uren, of orders uit een eigen systeem die iemand overtypt. Precies daar komt een koppeling in beeld, en precies daar wordt de vraag "van wie is dit eigenlijk?" ineens relevant.

Wie is eigenaar van je administratie en de koppeling?#

Als ondernemer ben je in de basis eigenaar van je bronadministratie in Yuki, maar het domein — de technische omgeving — kan een andere eigenaar hebben. Standaard is de ondernemer eigenaar van de brondata, terwijl de domeineigenaar de beheerder is met bijzondere rechten.

In sommige gevallen is met Yuki afgesproken dat het accountantskantoor eigenaar van de administratie is (Yuki Support, 2026). Dat onderscheid lijkt juridisch muggenziften, maar het bepaalt wie de API-sleutel mag aanmaken en wie akkoord moet geven op een koppeling.

Eigenaar van de data versus eigenaar van het domein#

In de Yuki-trajecten die CleverTech AI begeleidt is de eerste blokkade zelden techniek — het is het aanvragen van de webservice-sleutel. De ondernemer maakt die namelijk niet zelf aan; de domeineigenaar (vaak het kantoor) moet dat doen of goedkeuren.

Wie niet weet wie de domeineigenaar is, staat stil nog voordat er een regel code is geschreven. Dat maakt de eigenaarschapsvraag geen formaliteit maar de eerste praktische horde.

Eigenaar van de koppeling bij een overstap#

Voor de koppeling zelf geldt een aparte eigenaarschapsvraag. Een standaardkoppeling die je kantoor activeert, blijft in het beheer van het kantoor of de leverancier.

Een maatwerkkoppeling die je laat bouwen, hoort van jou te zijn — inclusief de code en documentatie.

Dat verschil telt op het moment dat je van kantoor wisselt of van pakket migreert. Zit je koppeling vast aan het abonnement van een derde partij, dan verlies je die bij een overstap.

CleverTech AI adviseert daarom om vóór de bouw vast te leggen wie de sleutel beheert, wie akkoord geeft op de boekingslogica en wie de koppeling meeneemt bij een verhuizing. Die afspraken maak je het beste sámen met je boekhouder, want die houdt de regie over hóe posten geboekt worden.

Wat kan de Yuki-API zelf?#

De Yuki-API laat externe software gecontroleerd boekhouddata, documenten, verkoopfacturen, relaties en journaalposten met Yuki uitwisselen. Toegang loopt via een webservice-API-sleutel plus een Administratie-ID, uniek per administratie (Nmbrs Accounting Support, 2026).

Dat "per administratie" is belangrijk: een kantoor met tientallen klantadministraties heeft niet één sleutel, maar per administratie een eigen sleutel en domein.

De twaalf webservices van de Yuki API#

De supportsite van Nmbrs Accounting telt op dit moment twaalf SOAP-webservices, elk met een of meer methodes (Nmbrs Accounting Support, 2026). De eerste twee kolommen volgen die lijst; de derde is onze eigen indeling naar het koppeltype waarin we elke webservice in de praktijk het vaakst tegenkomen.

Een webshopkoppeling leeft vooral op Sales, Contact en Upload: orders worden verkoopfacturen op de juiste relatie. Een boekingskoppeling vanuit eigen software benut daarnaast Accounting en AccountingInfo; de laatste drie rijen (Domains, Backoffice en VAT) zijn vooral gereedschap voor het kantoor zelf.

Je maakt de sleutel aan via het icoon Instellingen en daarna Webservices, op portaal-, domein- of administratieniveau; het Administratie-ID staat in datzelfde scherm naast de sleutel. Op portaalniveau kan alleen een Portaalbeheerder dat; in het domein of de administratie ook een gebruiker met de rol Directie of een Backoffice-rol, en die rechten gaan vóór portaalrechten (Nmbrs Accounting Support, Nmbrs Accounting Support, 2026).

Let op de API-limieten#

Elk domein heeft standaard 1.000 webservice-calls per dag; een Portaalbeheerder kan de accountant-features Webservice (tot 5.000 calls per dag) of Webservice Uitgebreid (tot 10.000) aan het domein toevoegen (Nmbrs Accounting Support, 2026). Voor een MKB-webshop met enkele honderden orders per maand is 1.000 calls ruim voldoende.

Twee uitzonderingen zitten in de kleine letters: in de bundel Minimal moet het kantoor de Sales-webservice apart als accountant-feature toevoegen, en de Purchase-webservice gaat pas open na een formeel verzoek per e-mail, waarna je naast de API-sleutel een Client-ID en Secret krijgt.

Draai je duizenden transacties per dag of koppel je meerdere administraties via één domein, dan is de quota een ontwerpkeuze die je vooraf moet doorrekenen — niet iets dat je ontdekt als de sync halverwege de dag stilvalt.

Yuki SOAP of REST: waarom bronnen elkaar tegenspreken#

Als je online zoekt of de Yuki-API REST of SOAP is, krijg je tegenstrijdige antwoorden — en dat is precies waar veel koppeltrajecten misgaan. De boekhoud-webservices van Yuki zijn SOAP: Sales, Upload, Accounting en de andere diensten uit de tabel spreken XML over HTTPS, met TLS 1.2 of hoger als minimum (Nmbrs Accounting Support, 2026).

Daarnaast publiceert Yuki op developer.yukisoftware.com wél een REST-API: de Yuki Platform API (versie 1.0.78, JSON, inloggen met een Visma Connect-token). Die bedient portalen, domeinen, bedrijven en gebruikers en kent geen endpoints voor facturen of journaalposten (Yuki Developer Portal, 2026).

Tegelijk adverteren koppelpartijen als Duopact met een "Yuki REST API" voor verkoopfacturen en boekingen (Duopact, 2026). Ook dat klopt — maar het is een derde ding, en de drie bedoelen niet hetzelfde.

De verklaring: Yuki's eigen boekhoud-webservice is SOAP. Externe partijen bouwen daar een REST-laag bovenop, zodat ontwikkelaars met moderne JSON-endpoints kunnen werken in plaats van met XML-envelopes.

Wie "REST API" leest in een koppelaanbod voor facturen, koppelt dus aan een tussenlaag van een derde, niet aan Yuki direct. Dat verschil bepaalt wie je afhankelijkheid is: bij de SOAP-route praat je rechtstreeks met Yuki; bij een REST-wrapper hangt je koppeling aan de beschikbaarheid, prijs en levensduur van die tussenpartij.

Geen van beide is fout, maar je moet weten welke je kiest — het is het verschil tussen één leverancier in de keten en twee.

Yuki koppelen via drie routes#

Er zijn drie manieren om Yuki te koppelen, en de juiste keuze hangt af van je bronsysteem en je boekingslogica. We noemen dit intern het CleverTech AI Yuki-koppelroute-model: eerst kijken of het kantoor of een standaardkoppeling het volledig dekt, en pas maatwerk overwegen als je scenario buiten de standaard valt.

Begin bij de goedkoopste route die past#

Begin altijd bij de goedkoopste route die je scenario volledig dekt. Heeft je webshopplatform een goed onderhouden standaardkoppeling met Yuki die jouw BTW-situatie en retouren aankan, gebruik die.

Vraag je kantoor wat het al voor je kan activeren voordat je iets laat bouwen. Pas als de standaard je scenario niet dekt — omdat je software geen kant-en-klare integratie heeft, of omdat je boekingslogica afwijkt van de standaard-mapping — komt maatwerk in beeld.

Op onze pagina over een API-koppeling laten maken leggen we uit hoe die afweging technisch uitpakt.

Concrete koppel-scenario's: webshop, uren en eigen software#

De meeste Yuki-koppelingen vallen in drie patronen, elk met een eigen aandachtspunt.

Webshop naar Yuki#

Een webshopkoppeling (Shopify, WooCommerce, Magento) zet orders automatisch als verkoopfactuur in Yuki, met de juiste relatie, BTW-splitsing per orderregel en betaalstatus.

Het aandachtspunt zit in de randgevallen: retouren, creditfacturen en gemengde BTW-tarieven. Een standaardkoppeling die alleen de "goede dag" aankan, laat die randen liggen — en dan zoekt je boekhouder ze alsnog met de hand uit.

Urenregistratie en projectsoftware#

Bij urenregistratie of projectsoftware stroomt gefactureerde tijd als verkoopfactuur met grootboekmutaties naar Yuki. Hier is de mapping van projecten naar grootboekrekeningen het gevoelige punt: die moet aansluiten op jóuw rekeningschema, niet op een generieke default.

Eigen software of maatwerk#

Het derde patroon is eigen software of maatwerksoftware die orders of facturen genereert. Omdat er geen kant-en-klare integratie bestaat, is dit vrijwel altijd een maatwerktraject.

In alle drie de gevallen geldt dezelfde volgorde die we ook in ons artikel over API-integratie uitwerken: eerst de boekingslogica met de boekhouder vastleggen, dan pas bouwen. Een koppeling automatiseert een goed proces — ze repareert geen onduidelijke afspraken over hoe posten geboekt horen te worden.

Snap je nog niet precies wat een API is en hoe die data uitwisselt, lees dan eerst wat een API precies is.

Wanneer schakel je een maatwerkpartij in?#

Schakel een maatwerkpartij in wanneer geen standaardkoppeling je scenario dekt, of wanneer de administratie zó bedrijfskritisch is dat een no-code flow die stilletjes breekt te riskant wordt.

Wanneer de standaard niet volstaat#

Concreet is dat het geval bij eigen software zonder kant-en-klare Yuki-integratie, een keten van webshop plus CRM plus kassa die samen naar Yuki moet, of boekingslogica die afwijkt van de standaard: verlegde BTW, de OSS-regeling voor EU-verkoop, of deelretouren op regelniveau. Dekt een bestaande koppeling dit allemaal, dan heb je geen maatwerk nodig.

De garanties die maatwerk toevoegt#

Het verschil tussen een koppeling die werkt op een goede dag en een die jaren betrouwbaar draait, zit in de garanties: idempotentie zodat geen factuur dubbel geboekt wordt, een wachtrij voor wanneer een systeem offline is, en monitoring die het probleem eerder ziet dan jij. Die garanties zijn software-engineering, geen boekhoudwerk — en daarom niet iets wat je van je accountant mag verwachten.

CleverTech AI bouwt zulke koppelingen op jouw infrastructuur, met de boekhouder aan tafel voor het boekingsplan; wil je weten wat dat kost en oplevert, kijk dan op onze pagina over een Yuki koppeling laten maken. Draai je maar een handvol facturen per maand, dan zeggen we het eerlijk: dan loont maatwerk niet en is de route via je kantoor prima.

Meer over de bredere afwegingen staat in onze gids over maatwerk software.