SureSync Blog

Van Excel naar XBRL: wat je aangiftesoftware moet opleveren

Geschreven door SureSync | 06 augustus 2026

De meeste aangiftesoftware voor erf- en schenkbelasting is historisch gebouwd rond Excel. Handig voor de opsteller, minder handig als je aangiftes elektronisch bij de Belastingdienst wilt indienen, want Digipoort accepteert alleen XBRL. Wil je via SureSync Reporting indienen, dan vraagt dat drie concrete aanpassingen aan je applicatie. Geen van drieën is complex, maar ze raken wel verschillende delen van je product. Dit is wat er verandert.

Wijziging 1: XBRL-document in plaats van Excel

De belangrijkste inhoudelijke wijziging: je applicatie moet een XBRL-document opleveren dat voldoet aan de SBR-taxonomie voor erf- en schenkbelasting. Dat is een andere output dan een Excel-bestand met dezelfde data. XBRL is gestructureerd, gevalideerd tegen een taxonomie en machine-leesbaar op elementniveau. Dat betekent dat je data-model moet aansluiten op de conceptnamen en context van de taxonomie: welke gegevens horen bij de erflater, welke bij de verkrijger, hoe verhouden schenkingen zich tot de nalatenschap, welke waardegrondslagen worden gehanteerd.

Concreet levert dit twee soorten werk op. Ten eerste een mapping van je interne data-model naar de SBR-taxonomie. Ten tweede een XBRL-serializer die op basis van die mapping een valide instance document produceert. Beide zijn onderhoudsgevoelig: de taxonomie krijgt jaarlijks een update, en je mapping moet daarmee mee.

Heb je nog geen XBRL-implementatie en zie je op tegen deze stap? SureSync kan optioneel een Excel-template beschikbaar stellen en de conversie naar XBRL verzorgen. Het uiteindelijke aanleveren van correcte data blijft je eigen verantwoordelijkheid, maar de XBRL-generatie hoef je dan niet zelf te bouwen. Het is een tussenstap, geen eindstation: op termijn wil je waarschijnlijk zelf XBRL opleveren om regie te houden over je data-model.

Wijziging 2: REST API met authenticatie

De koppeling met SureSync Reporting verloopt via een REST API, geauthentiseerd met een API-sleutel per eindgebruiker. Dat betekent dat je applicatie een HTTP-client krijgt (als die er nog niet is) en dat je API Key management inbouwt: elke eindgebruiker die aangiftes indient, heeft zijn eigen sleutel. Die sleutels beheer je zelf via het Management Dashboard van SureSync, uitgeven en intrekken doe je daar.

Aan de applicatiekant vraagt dit een aantal keuzes. Waar sla je de API-sleutel op? Hoe koppel je een sleutel aan een gebruiker of aan een organisatie? Wat gebeurt er als een sleutel wordt ingetrokken terwijl er nog aangiftes in behandeling zijn? En: wie in jouw organisatie krijgt toegang tot het Management Dashboard? Dit zijn kleine beslissingen, maar ze bepalen of het beheerbaar blijft als je van tien naar duizend eindgebruikers groeit.

De API-documentatie beschrijft de endpoints voor het indienen van een document, het opvragen van statussen en het ophalen van het validatie resultaat als PDF. Klanten implementeren de koppeling meestal in dagen, niet in weken.

Wijziging 3: statusupdates via polling in plaats van e-mail

De derde wijziging is minder zichtbaar, maar heeft impact op je user experience. In veel bestaande aangifte-workflows krijgt de eindgebruiker een e-mail zodra de aangifte is verwerkt of afgewezen. Bij SureSync Reporting werkt dat anders: de status is opvraagbaar via de API. Je applicatie haalt die status op en informeert de gebruiker zelf.

Dat is een bewuste keuze. E-mail is niet betrouwbaar voor procesbewaking, en gebruikers verwachten statusinformatie in de applicatie waar ze de aangifte hebben opgesteld, niet in hun mailbox. Voor jou betekent het wel dat je een pollingmechanisme (of een webhook-integratie als die beschikbaar is) moet inbouwen, en dat je nadenkt over hoe je statussen presenteert. Denk aan: "verzonden", "in validatie", "gevalideerd, wordt aangeboden bij Digipoort", "ontvangen door Belastingdienst", of "afgekeurd, zie validatie resultaat".

Het validatie resultaat wordt als PDF beschikbaar gesteld. Overweeg of je die PDF automatisch downloadt en toont aan de gebruiker bij een validatiefout, of dat je de fouten uitleest en in de applicatie zelf zichtbaar maakt. Het tweede is meer werk, maar geeft een betere user experience.

Wat je nog nodig hebt naast de code

Naast de technische aanpassingen komen er twee organisatorische zaken bij. Ten eerste: een verwerkersovereenkomst, want er worden persoonsgegevens verwerkt. Ten tweede: helderheid richting je klanten over wat er verandert. Voor eindgebruikers verandert namelijk niet alleen de indiening zelf. Ze zien statussen op een nieuwe plek, ze krijgen mogelijk andere foutmeldingen dan voorheen, en het uploaden van een Excel via een portaal is verleden tijd. Deze wijzigingen zijn goed voor het proces, maar wel goed om vooraf te communiceren.

De tijdlijn in de praktijk

Grofweg: één sprint voor de API-integratie inclusief API Key management, twee tot vier sprints voor de XBRL-mapping en serializer (afhankelijk van hoe ver je data-model al aansluit op de taxonomie), plus een acceptatietraject op de SureSync acceptatieomgeving voordat je live gaat. In totaal doorlooptijd van enkele weken tot een paar maanden, sterk afhankelijk van je startpunt.

Wil je concreet weten wat er in jouw situatie moet gebeuren om aan te sluiten? Plan een adviesgesprek, dan lopen we samen door je huidige architectuur en de stappen die nodig zijn.

Meer weten over hoe SureSync Reporting de route naar Digipoort voor erf- en schenkbelasting invult, en wat dat concreet betekent voor jouw applicatie? Bekijk de productpagina voor erf- en schenkbelasting.