Exact Online zet XML-API's uit vanaf januari 2027: zo weet je welke koppeling van jou omvalt

Op de aankondiging van Exact staat januari 2027. Dat is niet de datum waar je deze maand iets mee moet.

Over vier weken, op 1 oktober 2026, gaat er een klein XML-endpoint uit dat in Exacts eigen handleiding de allereerste stap van een XML-koppeling is: het adres waar externe software opvraagt welke administraties er zijn en onder welke code ze te bereiken zijn. Wie die code ooit vast heeft ingebouwd merkt niets. Wie hem bij elke run opnieuw ophaalt, of ermee een nieuw geopende administratie ontdekt, heeft vanaf oktober een koppeling die niet meer weet waar hij moet boeken.

Deze gids legt niet uit wat REST is. Hij beantwoordt de vraag die daaronder ligt en die je zelf kunt beantwoorden: welke van jouw draaiende koppelingen zit nog op de oude XML-webservice, wie factureert je daarvoor, en wat gaat er stil kapot als niemand belt. Van je eigen Exact-omgeving naar een lijst partijen, met per partij één mail en één datum.

Wat er stopt, en de vijf datums die ertoe doen

De XML-webservice van Exact Online is de oude in- en uitgang van je administratie. Externe software praat er met drie vaste adressen: XMLDivisions.aspx voor de lijst administraties, XMLDownload.aspx om per Topic een heel bestand op te halen, en XMLUpload.aspx om er een naar binnen te duwen. De opvolger is de REST-API, die per record werkt en aparte sync-endpoints heeft voor alleen wat sinds de vorige keer wijzigde.

Op zijn breaking-changes-pagina zet Exact het in één regel neer: een selectie XML-API-topics vervalt vanaf januari 2027 en je moet over naar de REST-API's. Die pagina is geen nieuwsbericht maar een lijst, en op die lijst staan zes items, waarvan er vijf jouw koppelingen kunnen raken. Het zesde laat ik bewust weg: het App Center gaat in september 2026 offline voor klanten, maar alleen in Spanje, Frankrijk, het Verenigd Koninkrijk en de Verenigde Staten, en Exact schrijft er zelf bij dat bestaande integraties, endpoints en autorisaties ongewijzigd blijven werken. Tel je de pagina zelf na, dan kom je dus op zes en niet op vijf. Van de vijf die wel jouw kant op komen zijn er twee al geweest.

Nieuw is vooral de datum. Toen Exact de uitfasering eind juli 2026 aan ontwikkelaars meldde, ontbrak er nog een concrete einddatum, tekende koppelleverancier Invantive toen aan. Die datum staat er inmiddels wel, en dat is het verschil tussen een aankondiging en een agendapunt.

De elf topics staan met naam op die pagina, en het loont om ze naast je eigen processen te leggen: Stock Positions, Purchase Orders, Deliveries, Accounts Receivable, VAT Codes, GL Accounts, Accounts Payable, Bill of Materials, Sales Orders, Invoices en Payment Conditions. Voorraad, inkoop, levering, debiteuren, crediteuren, verkoop en facturatie. Dat is niet de rand van je administratie, dat is de kern.

Twee dingen die er níet staan wegen minstens zo zwaar. GLTransactions, de topic waarmee de meeste financiële importen hun boekingen inschieten, ontbreekt op de lijst en blijft dus voorlopig gewoon werken. En Exact houdt de deur open: alleen de genoemde topics vervallen in januari 2027, komen er meer bij dan wordt dat ruim van tevoren gemeld. Daar staat één zin achter die je hele planning bepaalt, namelijk dat niet elke XML-topic per se een REST-equivalent krijgt. Voor een deel van de stromen is de vraag aan je leverancier dus niet wanneer hij migreert, maar wat jouw alternatief wordt.

Dat voorbehoud is niet theoretisch. Een ontwikkelaarsgids over de Exact Online-API, gepubliceerd in januari 2026 en in mei 2026 nog bijgewerkt, noemt het programmatisch matchen van betalingen aan facturen als voorbeeld van iets dat geen REST-endpoint heeft en alleen lukt via een XML-bestand dat iemand met de hand aanlevert. Dat voorbehoud stond er bij die update in het voorjaar van 2026 dus nog steeds. Of dat inmiddels is opgelost weet je leverancier, en jij niet: het is vraag twee van je mail.

De datum van 1 oktober 2026 heeft daarbij een eigen karakter. Exact schrijft dat integraties die het XMLDivisions.aspx-endpoint gebruiken na 1 oktober 2026 geen administratiegegevens meer kunnen ophalen. Of jou dat raakt hangt af van iets wat nergens in je contract staat: heeft de bouwer de administratiecode hard ingebouwd, of vraagt de koppeling hem elke keer opnieuw op. Dat is precies zo'n detail waar niemand meer een antwoord op weet, en het is de eerste vraag van je mail.

De drie sporen: zo vind je wat er echt draait

Je gaat een koppelinventarisatie doen: vaststellen welke applicaties nog via de XML-webservice je administratie in en uit gaan, wie daarachter zit, en per partij een datum en een gevolg vastleggen. Drie sporen, en het eerste geeft in twintig minuten een antwoord waarvan de meeste ondernemers denken dat er een ontwikkelaar voor nodig is.

Spoor 1: twee schermen in je eigen Exact-omgeving

Het eerste scherm is de vondst van deze klus. In Exact Online zit een verbruiksoverzicht dat per applicatie laat zien wélke endpoints zijn aangeroepen. Ga naar Gebruikersnaam, dan Mijn Exact Online, dan Mijn abonnement, en klik in de sectie Verbruiksoverzicht per app op Overzicht. Kies op de pagina Overzicht, API-verkeer je administratie en periode en klik op Vernieuwen. Je krijgt een lijst applicaties die API-calls hebben gestuurd. Klik op het aantal bij een app, ga naar het tabblad Per endpoint, en er verschijnt een lijst van de endpoints die die app in de gekozen periode gebruikte.

Daar staat het antwoord letterlijk. Zie je XMLDownload.aspx, XMLUpload.aspx of XMLDivisions.aspx, dan draait die app op de XML-webservice. Zie je alleen paden die met api/v1 beginnen, dan zit hij op REST. Je hebt hiervoor het recht API-verkeer bekijken nodig, en je kunt het overzicht naar Excel exporteren. Dat exportbestand is de eerste kolom van je lijst.

Let op het venster. De periode staat standaard op de laatste 30 dagen, en dat is te kort voor alles wat maandelijks, per kwartaal of alleen bij de jaarafsluiting loopt. Zet het venster zo ruim als het scherm toelaat en zet de rest uit je hoofd op de lijst: de archiefrun, de jaarwerkexport, het bestand dat de accountant in januari ophaalt.

Het tweede scherm vertelt wie er überhaupt naar binnen mág, ook zonder verkeer in jouw venster. Dat is de pagina Overzicht, Appmachtigingen: ga naar Gebruikersnaam, dan Mijn Exact Online, dan Beveiligingscentrum, en klik bij Machtigingen voor mijn apps op Alles tonen. Je ziet alle apps die aan je Exact Online-account gekoppeld zijn, met de mogelijkheid om machtigingen per gebruiker of administratie in te trekken. Het tabblad Administraties per app laat zien welke app in welke administratie zit, en per app zie je of hij je gegevens alleen mag bekijken of ook mag beheren. Voor dit beheer heb je de rol Licentie beheren nodig.

Leg de twee lijsten naast elkaar. Een app die in het API-verkeer staat maar niet in de machtigingen kán er niet zijn, dus dan kijk je naar de verkeerde administratie. Een app die wel een machtiging heeft maar geen verkeer, is óf een seizoenskoppeling óf een toegang die niemand meer gebruikt. Die tweede categorie is geen migratieklus maar een opruimklus, en die doe je dezelfde middag.

Spoor 2: je eigen facturen

Niet elke koppeling heeft een eigen regel in het API-verkeer die je herkent. Een appnaam als "Connector" of "Sync Service" zegt je niets, en je hebt de naam nodig van het bedrijf dat je factureert. Loop daarom je softwarefacturen van de laatste twaalf maanden langs en markeer elk abonnement waarvan de productpagina belooft dat het met Exact Online praat.

De verdachten zitten bijna altijd in dezelfde hoeken: het WMS of voorraadpakket, de webshop of het orderplatform, de urenregistratie, het scan-en-herkenpakket voor inkoopfacturen, de abonnementen- of incassotool, de rapportage-add-in in Excel, en het integratieplatform waar iemand ooit een flow in bouwde. Elk van die abonnementen is een kandidaat, en elk kandidaat krijgt straks dezelfde mail.

Zet er per regel bij wat de koppeling in je administratie dóet, in gewone taal. Niet "Exact-koppeling", maar "haalt elke nacht de voorraadstanden op" of "boekt verkoopfacturen weg". Dat zinnetje is later je toets: als de leverancier zegt dat het bij hem geregeld is, weet je welk gedrag je in november moet terugzien.

Spoor 3: het maatwerk dat niemands eigendom is

Dan de categorie zonder leverancier. Het Excel-bestand met een macro dat elke maandag een export trekt. Het scriptje dat een oud-collega schreef om orders in te schieten. De koppeling die het bureau bouwde dat er niet meer is, of die je accountant ooit inrichtte en sindsdien stil laat draaien.

Deze stromen verschijnen wél in het API-verkeer, alleen onder een naam die niemand herkent, en er bestaat geen migratiedatum voor. Er bestaat alleen een opdracht. Hoe je die opdracht insteekt, met een kant-en-klare app, een integratieplatform of een eigen koppeling, is een aparte keuze; de afweging tussen een kant-en-klare app uit het App Center, een integratieplatform en een eigen koppeling op de REST-API maak je per datastroom en niet per systeem.

Wat je nodig hebt voordat je één leverancier mailt

Deze klus kost geen euro aan gereedschap. Hij kost je twee rechten, een halve dag, en een lijst die niemand ooit heeft gemaakt. Op die lijst blijft hij ook meestal steken.

Twee daarvan worden onderschat. De eerste is alle administraties: het API-verkeer kies je per administratie, dus met drie administraties draai je deze inventarisatie drie keer, en de kans is groot dat er in de kleinste een koppeling draait die niemand meer noemt. De tweede is de naam per koppeling. Zonder eigenaar wordt elk besluit over die stroom een gok, en de vraag "kan dit weg?" blijft dan een jaar liggen.

De stappen: van een endpointlijst naar een leverancier met een datum

In zeven stappen ligt er een lijst waarop elke koppeling een leverancier, een datum en een gevolg heeft: je meet het API-verkeer per administratie, splitst XML van REST, legt de topics naast de lijst van elf, vertaalt appnamen naar facturen, stuurt per partij één mail van vier regels, legt de antwoorden vast met een datum, en meet in november opnieuw. Stap 2 bepaalt hoe klein het werk daarna wordt.

1. Trek het API-verkeer per administratie en exporteer het. Gebruikersnaam, Mijn Exact Online, Mijn abonnement, sectie Verbruiksoverzicht per app, Overzicht. Herhaal dit voor elke administratie en zet de exports onder elkaar in één blad. Kolommen: administratie, applicatie, endpoint, aantal calls.

2. Splits de lijst in XML en REST. Alles met XMLDownload.aspx, XMLUpload.aspx of XMLDivisions.aspx gaat naar de ene stapel, alles met api/v1 naar de andere. De REST-stapel is klaar, op de GUID-wijziging van juli 2026 en de InvoiceSalesOrders-parameter van oktober 2026 na. De XML-stapel is je project.

3. Lees de topics uit de endpointregels, of vraag ze op. Bij XMLDownload.aspx en XMLUpload.aspx zit de topic in de aanroep zelf, als ?Topic=GLAccounts of ?Topic=SalesOrders. Zet naast elke regel of die topic op de lijst van elf staat. Een app die alleen GLTransactions gebruikt heeft geen januari-deadline; een app die Invoices of SalesOrders gebruikt wel.

Reken er niet op dat die topic er altijd staat: Exact belooft in zijn eigen handleiding bij het tabblad Per endpoint alleen "een lijst van de endpoints die in de gekozen periode zijn gebruikt", niet de volledige query string erachter. Zie je alleen XMLDownload.aspx zonder topic, dan lees je hem hier niet af maar stel je hem als vraag twee van je mail (die vraag staat al in stap 5), en gebruik je ondertussen het tabblad Per dag om de koppeling te herkennen aan zijn ritme: een stroom die elke nacht dezelfde uitslag geeft is een andere klus dan een die één keer per maand of alleen bij de jaarafsluiting piekt. Je verliest er geen stap mee, je verplaatst alleen wie het antwoord geeft.

4. Vertaal elke appnaam naar een factuur. Dit is de vertaalslag waar de hele klus om draait. "Sync Service" is geen leverancier maar een product; jij hebt de naam nodig van de partij die je factureert en die je kunt bellen. Blijft er een naam over die niemand herkent en die geen factuur heeft, dan is dat je belangrijkste rij: actieve schrijftoegang tot je administratie zonder eigenaar.

5. Stuur per leverancier één mail met vier vragen. Niet vijf, niet twee. Kopieer hem letterlijk:

Draait onze koppeling met administratie [naam] op de XML-webservice of op de REST-API van Exact Online? Welke XML-topics gebruikt hij, en zit daar een van de elf topics bij die per januari 2027 vervallen? Op welke datum staat jullie migratie naar REST gepland, en gebruikt de koppeling XMLDivisions.aspx, dat al op 1 oktober 2026 uitgaat? Wat moet ik aan mijn kant doen, en op welke dag: opnieuw autoriseren, een versie bijwerken, of iets anders?

6. Leg het antwoord vast met een datum en een gevolg. "Wij zijn ermee bezig" is geen planning. Vraag om een maand, zet die in je agenda met vier weken marge ervoor, en bevestig het antwoord schriftelijk terug. De leverancier die te laat is, is bijna nooit de leverancier die dat vooraf toegeeft.

7. Plan de tweede meting. Trek het API-verkeer opnieuw in november 2026 en in februari 2027. Het aantal XML-endpoints hoort te dalen richting nul. Blijft er één staan die volgens de leverancier al over is, dan draait er ergens nog een oude versie of een vergeten dienstaccount.

De stille faalvormen, en waarom je ze pas bij de btw-aangifte ziet

Een koppeling die niet meer mag schrijven valt zelden luid om. Hij loopt leeg. Dit zijn de vormen waarin dat gebeurt, met de maatregel erbij.

Hij levert een halve batch. Rate limits gelden bij Exact voor zowel de XML-webservice als de REST-API, en de reikwijdte is preciezer dan de meeste samenvattingen doen voorkomen: 60 API-calls per app, per administratie, per minuut en 5.000 API-calls per app, per administratie, per dag, waarna je HTTP 429 terugkrijgt. Per app dus, niet per administratie: twee koppelingen op dezelfde administratie delen dat budget niet, ze hebben er elk één. Er zit een addertje in de weging: op zijn eigen prijspagina schrijft Exact dat elke XML-call voor 50 API-calls telt. Binnen dat dagbudget van 5.000 zijn dat dus ongeveer honderd XML-calls, per koppeling, niet voor je hele huis. Wordt een bulk-XML-download vervangen door een REST-koppeling die rij voor rij ophaalt, dan verandert het aantal calls totaal van karakter, en een naïeve herbouw loopt op dag één tegen de minuutlimiet. Vraag je leverancier of de nieuwe versie de sync-endpoints gebruikt.

Hij raakt op door het verbruik van een andere koppeling. Boven al die losse app-budgetten hangt namelijk één plafond dat wél optelt, en dat is de regel die in geen enkele leveranciersmail staat: dezelfde pagina noemt een fair use van 20.000 API-calls per Exact Online-contract per dag, op een Premium-licentie 30.000. Zes koppelingen over drie administraties blijven elk moeiteloos binnen hun eigen 5.000 en tikken samen toch tegen dat contractplafond, zeker met de weging van 50 per XML-call erbij. Exact weigert die calls niet per direct: het schrijft dat het bij structureel overschrijden corrigerend optreedt en de app gaat afknijpen. Voor jou ziet dat er precies zo uit als de vorige faalvorm, een halve batch, alleen zit de oorzaak dan niet in de koppeling die klaagt maar in de zwaarste die er naast draait. Zet daarom bij elke koppeling op je lijst niet alleen wat hij doet, maar ook wanneer hij draait. (Limieten en weging gecontroleerd september 2026.)

Hij boekt een dag niet. Een nachtelijke run die op een fout stuit stopt, en de volgende nacht begint hij bij vandaag. De dag ertussen is geen fout, het is een gat. Dat gat vind je alleen terug door aan beide kanten dezelfde sleutel te tellen.

Hij vindt de administratie niet meer. Dit is de faalvorm van 1 oktober 2026. De koppeling draait, authenticeert netjes, en krijgt op zijn vraag naar de administratielijst geen antwoord. Bij een goed gebouwde koppeling levert dat een foutmelding in een logbestand dat niemand leest. Bij een minder goed gebouwde levert het nul records, wat er precies zo uitziet als een rustige dag.

Hij wordt geblokkeerd door zijn eigen fouten. Exact telt fouten: meer dan tien fouten per API-sleutel, per gebruiker, per administratie, per endpoint en per uur en de sleutel gaat tijdelijk op slot, waarbij codes 400, 401, 403 en 404 als fout meetellen. Een koppeling die na 1 oktober blijft proberen sluit zichzelf dus buiten, en de blokkade loopt op als hij doorgaat.

Niemand merkt het, want er is geen alarm op afwezigheid. Dat is de rode draad onder alle vier. De voorziening die dit afvangt zet je aan vóór de migratie, niet erna: een hartslag per geslaagde run met een coulanceperiode van het normale interval plus een marge, en een nachtelijke telling van dezelfde sleutels aan beide kanten. Merk je het toch te laat, dan is de volgorde van herstel het hele verschil: eerst tellen, dan stamdata, dan pas transacties opnieuw aanbieden met een sleutel die dubbele verwerking blokkeert.

Nog twee valkuilen die niets met techniek te maken hebben. De eerste: je gaat af op de app-lijst en niet op het verkeer. Een leverancier kan drie ingangen naar je administratie hebben waarvan er twee ooit met de hand zijn ingericht. Het API-verkeer toont ze allemaal, de facturen niet. De tweede: je trekt in oktober een machtiging in van een app die je niet herkende. Doe dat pas als je in het verbruiksoverzicht hebt gezien dat hij al maanden niets doet. Anders zet je op maandag zelf de storing aan die je op vrijdag wilde voorkomen.

Blijven, ombouwen of vervangen: hoe je per stroom kiest

Er zijn maar vier uitkomsten per stroom, en welke het wordt hangt van drie dingen af: gebruikt de stroom een van de elf topics, bestaat er een REST-equivalent, en hoe erg is het als deze stroom drie dagen stilstaat.

Eén stelling erbij, want een kader zonder mening is een catalogus. Voor de meeste ondernemers is "blijven op XML" een verdedigbare keuze en "afwachten" dat niet. Een topic die vandaag niet op de lijst staat kan er over een halfjaar bij komen, en Exact zegt zelf dat het dat ruim van tevoren meldt. Ruim van tevoren is geen garantie dat jouw leverancier dan sneller is dan nu. Het verschil tussen blijven en afwachten is één regel in je agenda.

Uitgewerkt voorbeeld: een groothandel met drie administraties

Neem een groothandel met drie administraties in Exact Online: de werkmaatschappij, een holding en een slapende B.V. die ooit voor een overname is opgericht. Het bedrijf is verzonnen, de samenstelling is doodgewoon: een webshop, een WMS, een scanpakket voor inkoopfacturen en een rapportagebestand in Excel.

Dag 1. Het API-verkeer over de werkmaatschappij toont vijf applicaties. Drie ervan gebruiken alleen paden onder api/v1. Twee vallen op. Het WMS haalt elke nacht XMLDownload.aspx?Topic=StockPositions op en schrijft terug via XMLUpload.aspx?Topic=SalesOrders; de topics staan hier in de endpointregels zelf. Beide staan op de lijst van elf. Had het overzicht alleen kale XMLDownload.aspx-regels getoond, dan waren die twee namen niet verloren maar verplaatst: naar vraag twee van de mail. De vijfde applicatie heet iets met "Reporting" en roept alleen XMLDivisions.aspx aan, één keer per week.

Dag 2. De holding levert twee applicaties op, allebei bekend. De slapende B.V. levert er één op: een scanpakket dat drie jaar geleden is opgezegd en waarvan de machtiging nooit is ingetrokken. Er is geen verkeer, wel schrijfrecht. Die machtiging gaat er diezelfde middag uit, na een blik op het verbruiksoverzicht om te bevestigen dat hij inderdaad niets doet.

Week 1. De mail met vier vragen gaat naar drie partijen. Het WMS antwoordt binnen twee dagen: de REST-versie staat gepland voor november 2026, de klant moet daarna eenmalig opnieuw autoriseren. De webshopkoppeling zit al op REST en heeft alleen de nieuwe InvoiceSalesOrders-parameter nodig, die de leverancier bij de eerstvolgende release meeneemt. De derde mail komt terug met "wij houden de ontwikkelingen in de gaten". Dat is de rij die in de agenda gaat, met een herinnering voor half oktober.

Week 2. De "Reporting"-applicatie blijkt het Excel-bestand van de controller te zijn, met een macro die de administratielijst ophaalt en dan per administratie een export trekt. Er is geen leverancier. Dit is de enige echte oktoberdeadline in het hele huis: op 1 oktober 2026 stopt XMLDivisions.aspx en vindt de macro geen administraties meer. De oplossing is twee uur werk: de drie administratiecodes komen vast in het bestand te staan en de rest van de export blijft draaien, want GLTransactions staat niet op de lijst van elf.

De uitkomst. Van vijf regels in het API-verkeer was er één een echte januari-deadline, één een oktoberdeadline die niemand had zien aankomen, één een opruimklus en waren er twee al klaar. Kosten: ongeveer een dag werk verspreid over twee weken, plus twee uur voor de macro. Wat het bedrijf overhield was niet de migratie maar de slapende B.V.: een opgezegde leverancier met drie jaar ononderbroken schrijfrecht op een administratie waar niemand naar keek.

Wat de datum je over je leveranciers vertelt

De klus is te overzien. Een halve dag meten, drie mails, twee agendapunten. Wat eronder ligt is groter, en dat merk je pas als de antwoorden binnenkomen.

Een leverancier die in september 2026 nog geen migratiedatum kan noemen voor een wijziging die Exact in 2023 aankondigde, vertelt je iets over de rest van het contract. Niet dat hij slecht is, wel dat jouw administratie geen prioriteit heeft in zijn planning, en dat je dit gesprek bij de volgende einddatum opnieuw voert. Datzelfde patroon zag je bij een salariskoppeling waarvan de SOAP-API per 1 maart 2027 stopt en bij de mail- en agendakoppelingen die vanaf 1 oktober 2026 hun toegang tot Microsoft 365 kwijtraken. De migratie is zelden het dure deel. Het dure deel is de inventarisatie die je nooit had, uitgevoerd onder een datum die je niet zelf koos.

Doe daarom vóór de kerst één ding dat langer meegaat dan deze deadline. Sla de Excel-export van je API-verkeer op met de datum in de bestandsnaam, en zet er per regel de leverancier en de eigenaar bij. Dat blad is over een jaar meer waard dan de koppeling die je ermee redde, want de volgende einddatum komt er hoe dan ook, en dan is dit een middag werk in plaats van een zoektocht.