Hoe werkt data delen in de agrarische sector?
Kort antwoord
Een agrarisch bedrijf deelt data met zuivel, voerleverancier, slachterij, accountant en adviseur. Welke partij welke data mag ontvangen, legt de boer vast in een machtiging, steeds vaker centraal via JoinData. Hoe die data eruitziet, bepalen de standaarden van AgroConnect. Agrarische software moet dus twee dingen goed doen: de afgesproken berichten spreken en elke machtiging respecteren.
Op een gemiddeld melkveebedrijf komt meer data binnen dan bij menig MKB-kantoor. De melkrobot registreert per koe, de klimaatcomputer per stal, de zuivelfabriek per ophaling, de slachterij per dier. En al die data gaat weer ergens anders heen: naar de voerleverancier die het rantsoen bijstuurt, naar de accountant die de jaarrekening maakt, naar de adviseur die de KringloopWijzer invult.
Volgens Nieuwe Oogst had een melkveehouder in 2022 gemiddeld vijftien tot twintig actieve machtigingen voor het delen van data. Een deel daarvan op papier getekend, een deel digitaal gegeven, en een deel allang vergeten. Wie ooit van voerleverancier wisselde zonder de oude machtiging in te trekken, deelt misschien nog steeds data met een partij waar hij geen zaken meer mee doet.
Voor wie software bouwt of koopt in deze sector is dat geen randzaak. De vraag is niet alleen óf je aan een bron kunt koppelen, maar ook of je die data op dit moment, voor dit doel, nog mag ontvangen.
Twee partijen, twee rollen: JoinData en AgroConnect
In gesprekken over agrarische koppelingen worden deze twee namen vaak door elkaar gebruikt. Ze doen iets wezenlijk anders, en voor je architectuur is dat onderscheid belangrijk.
JoinData: wie mag wat ontvangen
JoinData is een coöperatie zonder winstoogmerk die zichzelf vergelijkt met een postbedrijf: het transporteert data, maar heeft er zelf geen belang bij. Het platform wordt gebruikt in de melkveehouderij, akkerbouw en varkenshouderij. De boer logt in op Mijn JoinData met eHerkenning, gekoppeld aan het KvK-nummer, en ziet daar per machtiging:
- Wie: de afnemer die de data wil ontvangen, bijvoorbeeld een zuivelonderneming, voerleverancier of accountantskantoor.
- Welke data: de berichttypen, zoals een factuurbericht, een slachtbericht of data van een melkrobot of klimaatcomputer.
- Waarvoor: de doelbinding. JoinData noemt als voorbeeld I&R-gegevens die een zuivelonderneming alleen mag gebruiken om de levensduur van afgevoerde dieren te berekenen.
- Hoe lang: een einddatum, die de boer kan aanpassen.
Per machtiging kan de boer activeren, weigeren, de einddatum wijzigen of intrekken. Belangrijk detail voor ontwikkelaars: JoinData probeert data zoveel mogelijk bij de bron te laten en haalt die pas op als er een verzoek binnenkomt met een actieve machtiging. Het platform is ISO 27001-gecertificeerd en heeft een auditcommissie met leden voorgedragen door LTO, POV, NMV en NAV.
AgroConnect: hoe ziet een bericht eruit
AgroConnect is een stichting uit 2007 die data delen in de sector stimuleert door afspraken te maken over standaarden. Die zijn georganiseerd in productgroepen: rund, varken, pluimvee, teelt, transactie en analyse. Een voerleverancier en een managementsysteem voor melkvee die dezelfde standaard spreken, hoeven niet voor elke koppeling opnieuw af te spreken wat een veld betekent.
JoinData beslist wie een bericht mag ontvangen. AgroConnect beslist hoe dat bericht eruitziet. Wie die twee vermengt, bouwt een koppeling die technisch werkt en juridisch rammelt.
Van XML-berichten naar API's
Een groot deel van de agrarische data-uitwisseling is gebouwd op berichtenverkeer in de traditie van EDI: vaste berichten die periodiek van systeem naar systeem gaan. Bij teelt is dat goed te zien. Sinds 2017 wordt teeltdata uitgewisseld met de EDI-Crop-berichtenset: drie XML-berichten voor het teeltplan, de teeltregistratie en het advies.
De opvolger heet eCrop en is een REST-API met JSON, beschreven in OpenAPI 3.0. De standaard volgt de AGRI API Style Guide van AgroConnect en de API-standaarden van de Nederlandse overheid. Het grootste verschil zit niet in het formaat, maar in het moment: in plaats van periodiek een bestand te sturen, haal je data op het moment dat je hem nodig hebt, direct bij de bron.
| Kenmerk | EDI-Crop | eCrop |
|---|---|---|
| Formaat | XML-berichten | JSON via een REST-API |
| Beschrijving | Berichtspecificaties | OpenAPI 3.0-specificatie |
| Uitwisseling | Periodiek, bericht voor bericht | Op aanvraag, direct bij de bron |
| Risico | Kopieën die uit de pas lopen | Afhankelijkheid van de beschikbaarheid van de bron |
| Wat het vraagt van je software | Bestanden verwerken en dubbele berichten herkennen | Autorisatie, time-outs en foutafhandeling per aanroep |
In de praktijk leven beide werelden nog jaren naast elkaar. Een managementsysteem dat vandaag gebouwd wordt, moet dus vaak XML-berichten kunnen inlezen én een moderne API kunnen aanroepen. Dat pleit voor een aparte vertaallaag tussen de buitenwereld en je eigen datamodel, zodat een nieuwe standaard niet door je hele applicatie heen snijdt.
Wat je software hiervoor moet kunnen
Of je nu een voerleverancier bent die rantsoenadvies wil geven, een adviesbureau dat bedrijfsdata analyseert of een agrarisch bedrijf dat zelf een systeem laat bouwen: dezelfde eisen komen steeds terug.
- De machtiging als eerste-klas gegeven: sla niet alleen de data op, maar ook onder welke machtiging die binnenkwam, voor welk doel en tot wanneer. Zonder die koppeling kun je later niet aantonen dat je iets mocht gebruiken.
- Doelbinding in de code: data die binnenkwam voor een rantsoenadvies hoort niet ongemerkt in een benchmarkrapport te belanden. Leg per gebruik vast onder welk doel het valt, en laat de software weigeren als dat niet klopt.
- Het KvK-nummer als sleutel: JoinData gebruikt het KvK-nummer om vast te stellen wie een bedrijf bezit en wie een machtiging mag afgeven. Gebruik dat ook in je eigen datamodel, naast interne klantnummers die per leverancier verschillen.
- Intrekking als normale status: een datastroom die stopt, is geen storing. Je software moet het verschil tonen tussen "geen data door een fout" en "geen data omdat de boer de machtiging heeft ingetrokken".
- Herhaalbare verwerking: berichten kunnen dubbel binnenkomen of opnieuw worden aangeboden. Met idempotente verwerking voorkom je dat een slachtbericht twee keer meetelt.
- Een spoor van wat er gebeurde: log welke data wanneer, onder welke machtiging, is ontvangen en gebruikt. Een audit trail is hier geen luxe maar je bewijs.
Valkuilen die we vaak zien
- Data kopiëren "voor het gemak": een volledige kopie van alle bedrijfsdata in je eigen database voelt handig, maar maakt het onmogelijk om een ingetrokken machtiging echt te laten doorwerken. Bewaar alleen wat je voor het doel nodig hebt.
- Machtigingen alleen bij de eerste koppeling controleren: een machtiging kan verlopen of worden ingetrokken. Controleer de status bij elke ophaalactie, niet één keer bij de start.
- Denken dat dierdata geen persoonsgegevens zijn: JoinData wijst er zelf op dat data over een dier in veel gevallen te herleiden is tot de ondernemer. Bij een eenmanszaak of maatschap is het onderscheid tussen bedrijf en persoon dun. Behandel het als persoonsgegevens, zoals de AVG het ook doet.
- Standaarden zelf "verbeteren": een eigen extra veld in een standaardbericht lijkt onschuldig, maar breekt de uitwisselbaarheid waar de standaard juist voor bestaat. Houd uitbreidingen buiten het standaardbericht.
De Data Act als extra laag
Sinds september 2025 is de EU Data Act van toepassing. Die gaat over data van verbonden producten, en op een boerderij staan er genoeg: melkrobots, trekkers, klimaatcomputers en sensoren. De kern is dat de gebruiker van zo'n product toegang moet kunnen krijgen tot de data die het genereert, en die ook met een derde partij moet kunnen delen.
Voor agrarische software betekent dat twee dingen. Leveranciers van machines kunnen de data minder makkelijk afschermen, waardoor er meer bronnen beschikbaar komen om op aan te sluiten. En wie data ontvangt via zo'n verzoek, krijgt ook met gebruiksvoorwaarden te maken. Een machtigingsmodel zoals JoinData dat hanteert — wie, wat, waarvoor, hoe lang — sluit daar goed op aan, ook voor bronnen die niet via het platform lopen.
Mijn kijk op data delen in de landbouw
Wat me opvalt aan de agrarische sector is dat hij op dit punt verder is dan veel andere branches. Het idee dat een ondernemer per afnemer, per doel en per periode toestemming geeft, en die op één plek kan intrekken, is precies wat je in de meeste zakelijke software mist. Daar is toestemming vaak een vinkje bij het aanmaken van een koppeling, en daarna nooit meer een onderwerp.
Tegelijk zie ik dat software de afspraken nog niet altijd bijhoudt. Een platform kan netjes registreren dat een machtiging is ingetrokken, maar als de ontvangende partij de data allang in een eigen database heeft gezet en daar ongestoord mee verder rekent, is het resultaat op papier beter dan in de praktijk. De verantwoordelijkheid ligt dus niet bij het platform, maar bij iedereen die data ontvangt.
Mijn advies aan wie hier iets bouwt: ontwerp je datamodel vanaf dag één rond de machtiging, niet rond de bron. Dan is een nieuwe standaard een kwestie van een extra vertaler, en een ingetrokken machtiging een kwestie van een status in plaats van een zoektocht door je database.
— Jasper
Zo helpt Coding Agency hierbij
Wij bouwen koppelingen en maatwerk voor bedrijven die met agrarische data werken: een vertaallaag die XML-berichten en moderne API's naar één datamodel brengt, verwerking die tegen dubbele berichten kan, en een administratie van machtigingen en doelbinding die je later ook kunt aantonen. Daarbij houden we rekening met de stappen van een goede API-koppeling en met wat je eigen proces al doet, zodat je geen tweede systeem naast het bestaande hoeft te onderhouden.
Werk je met boerendata en twijfel je of je huidige koppelingen machtigingen en doelbinding goed afhandelen? Neem contact op voor een vrijblijvend gesprek.
