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 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.
Inhoudsopgave
- Waarom je Yuki waarschijnlijk niet zelf koos
- Wie is eigenaar van je administratie en de koppeling?
- Wat kan de Yuki-API zelf?
- SOAP of REST — waarom bronnen elkaar tegenspreken
- Yuki koppelen via drie routes
- Concrete koppel-scenario's: webshop, uren en eigen software
- Wanneer schakel je een maatwerkpartij in?
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). Sinds 2020 hoort Yuki bij de Visma-familie, de Noorse softwaregroep met tientallen boekhoud- en ERP-pakketten in Europa (Visma, 2026).
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 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 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 (Yuki Support, 2026). Dat "per administratie" is belangrijk: een kantoor met tientallen klantadministraties heeft niet één sleutel, maar per administratie een eigen sleutel en domein.
Documentstroom en financiële stroom
Grofweg vallen de mogelijkheden in twee stromen. De eerste is de documentstroom: verkoopfacturen, UBL-bestanden, bonnen en documenten aanleveren zodat Yuki ze verwerkt. De tweede is de financiële stroom: transacties en journaalposten wegschrijven en financiële rapportages ophalen. Een webshopkoppeling gebruikt vooral de eerste stroom — orders worden verkoopfacturen — terwijl een boekingskoppeling vanuit eigen software de tweede benut.
Let op de API-limieten
Standaard staat de quota op 1.000 API-calls per dag per Yuki-domein, met betaalde uitbreidingen naar 5.000 of 10.000 calls per dag (Apideck, 2026). Voor een MKB-webshop met enkele honderden orders per maand is 1.000 calls ruim voldoende. 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.
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 officiële Yuki-webservice is een SOAP-API: elke call loopt via SOAP over HTTPS, Yuki heeft geen native REST-interface (Apideck, 2026). Tegelijk adverteren koppelpartijen als Duopact nadrukkelijk met een "Yuki REST API" (Duopact, 2026). Beide kloppen — ze bedoelen alleen 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, 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 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.
| Route | Wie regelt het | Wanneer passend |
|---|---|---|
| Via je accountantskantoor | Kantoor activeert een bestaande koppeling | Bank, standaard webshop of kassa die het kantoor al aanbiedt |
| Via de Yuki-API (standaardkoppeling) | Softwareleverancier of koppelpartij | Je bronsysteem heeft een onderhouden, kant-en-klare Yuki-integratie |
| Via een maatwerkpartij | Ontwikkelaar bouwt de koppeling | Eigen software, afwijkende boekingslogica of een keten van systemen |
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. In onze gids over API-koppelingen en systeemintegratie 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 een API-koppeling laten maken 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 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.
Opgesteld met AI-tools en gecontroleerd door het redactieteam van CleverTech — tech-leads met ervaring in AI, procesautomatisering en IT-consulting.
