De Servische eOtpremnica: uw ERP, WMS en TMS aansluiten vóór 1 oktober 2027

Vanaf 1 oktober 2027 heeft elke goederenbeweging tussen twee btw-geregistreerde private bedrijven in Servië een elektronische afleverbon nodig, de eOtpremnica, die via het systeem van het Servische ministerie van Financiën wordt verstuurd voordat de goederen vertrekken. Het bedrijf dat ze ontvangt, moet de ontvangst binnen enkele dagen in hetzelfde systeem bevestigen, en de vervoerder moet de bon bij een controle kunnen tonen.

Dat geldt voor verkoopleveringen, retouren en overboekingen tussen uw eigen magazijnen. De afleverbon is niet langer een formulier dat uw ERP-systeem afdrukt. Hij wordt een UBL-bestand dat via een overheids-API gaat, terugkomt met een identificatie en een QR-code, en daarna aan beide kanten een statusworkflow doorloopt.

Voor wie dit is

Factureert en verzendt u vanuit Minimax, BizniSoft of Pantheon, dan levert uw leverancier al ondersteuning voor eOtpremnica. Is uw volume laag genoeg om bonnen in te typen in het gratis webportaal van het ministerie of in de mobiele app, dan werkt dat ook. Lees het deel over de ontvangsttermijnen, train de mensen aan het laadperron, en u bent grotendeels klaar.

Dit artikel is voor de andere groep: distributeurs, fabrikanten, groothandels en vervoerders van wie verzending en goederenontvangst via hun eigen ERP-systeem lopen, via een aangepast WMS, een TMS of de backend van een webwinkel die B2B-orders boekt. Niemand gaat u een update sturen. U moet de integratie zelf bouwen.

Wat al geldt en wat er verandert

De wet op elektronische afleverbonnen (Zakon o elektronskim otpremnicama) dateert uit 2024 en is sindsdien twee keer gewijzigd. De laatste wijzigingswet, op 31 augustus 2026 gepubliceerd in Službeni glasnik 80/2026, hield de datum van oktober 2027 aan. De FAQ van het ministerie en de geconsolideerde tekst beschrijven de fasen.

Sinds 1 januari 2026:

• Private bedrijven versturen en ontvangen eOtpremnica voor accijnsgoederen: tabak, nicotineproducten, koffie, alcoholhoudende dranken en aardolieproducten.
• Private bedrijven versturen haar voor alle goederen die aan een publieke instantie worden geleverd, en publieke instanties versturen haar voor hun eigen goederenbewegingen.
• Vervoerders tonen de bon bij die goederenbewegingen.

Het productiesysteem draait sinds 30 december 2025. De demo-omgeving, bedoeld om interne software te testen, staat sinds 5 maart 2025 open.

Vanaf 1 oktober 2027:

• De verzendplicht als verzender en ontvanger allebei private partijen zijn en het niet om accijnsgoederen gaat.
• De ontvangstplicht voor elke private partij.
• Vervoerders die de bon tonen bij die goederenbewegingen.

Een paar details overvallen mensen. Een overboeking tussen twee magazijnen op hetzelfde fabrieksterrein heeft een interne bon nodig (type Int in de XML) als de goederen van adres veranderen en over de openbare weg gaan. Bij invoer is een interne bon nodig van de plaats waar u de beschikkingsmacht hebt verkregen, of in sommige gevallen van het douanekantoor, naar uw magazijn. Bij uitvoer is er doorgaans een nodig tot het punt waar de expediteur het overneemt. Detailhandelsverkopen onder de fiscaliseringswet zijn vrijgesteld, dus een webwinkel die tegen fiscale bonnen verkoopt, valt voor die orders erbuiten. De groothandelskant ervan niet.

De wijziging van augustus bepaalt ook dat toezichthouders tot 1 januari 2027 geen rekening houden met gegevensfouten in verstuurde bonnen en ontvangstbevestigingen. Dat helpt de verzenders van accijnsgoederen en de publieke sector. Voor oktober 2027 doet het niets.

Kan de datum verschuiven? De wet is in minder dan twee jaar twee keer gewijzigd, dus verdere wijzigingen zijn mogelijk. Maar de wijziging die net is aangenomen, hield de datum aan. Plan erop.

De ontvangststap is waar de termijnen zitten

Versturen is de makkelijke helft. De geconsolideerde wet legt de harde termijnen aan de ontvangende kant.

1. Voordat de goederen vertrekken, verstuurt de verzender de bon. Tot de ontvanger de fysieke ontvangst bevestigt, kan de verzender haar annuleren, met opgave van reden.
2. Fysieke ontvangst moet worden bevestigd op de dag dat de goederen worden overgenomen, of uiterlijk drie werkdagen nadat de ontvangst is begonnen.
3. Binnen acht dagen na die bevestiging aanvaardt of weigert de ontvanger de levering, geheel of gedeeltelijk, door een ePrijemnica (elektronische ontvangstbon) te versturen.
4. Een private ontvanger die binnen acht dagen niets verstuurt, wordt geacht de levering volledig te hebben geweigerd. Voor een publieke ontvanger is het omgekeerd: stilzwijgen betekent aanvaarding.
5. Bij gedeeltelijke aanvaarding heeft de verzender 30 dagen vanaf de ontvangst van de ePrijemnica om met de verschillen in te stemmen. Anders wordt hij geacht de ePrijemnica volledig te hebben geweigerd.
6. Een bon zonder bevestiging van fysieke ontvangst verliest 30 dagen na het begin van de goederenbeweging zijn geldigheid.

Zodra beide kanten het eens zijn, krijgen de documenten de status Usaglašeno (Fulfilled in de API) en kan er niets meer veranderen.

Het missen van de termijn voor fysieke ontvangst is een opgesomde overtreding: 200.000 tot 2.000.000 dinar voor het bedrijf en 50.000 tot 150.000 dinar voor de verantwoordelijke persoon. Dezelfde bandbreedte geldt voor het helemaal niet versturen van een bon.

De praktische conclusie: fysieke ontvangst hoort aan het laadperron, in het WMS, op het moment dat de goederen worden ingeboekt. Wacht het op iemand die aan het eind van de maand aansluit, dan is de termijn al verstreken.

Wat u tegen de API van het ministerie bouwt

De technische documentatie beschrijft een REST-API die UBL 2.1-XML uitwisselt. De eOtpremnica is een DespatchAdvice, de ePrijemnica een ReceiptAdvice, en elke andere stap (annulering, start van het transport, wissel van voertuig, fysieke ontvangst, aanvaarden of weigeren van een ePrijemnica) is een ApplicationResponse met een numerieke code. Het ministerie hield op 5 december 2025 een workshop voor de IT-sector over documenttypen, de XML-extensies, indienen en webhooks.

Versturen

Elk document gaat naar één endpoint, POST /public/documents/requests, met een uniek eigen request-ID. De verwerking is asynchroon. Het resultaat komt later, via een webhook of door /public/documents/requests/changes te pollen, dat elk verzoek meldt als in behandeling, geslaagd of mislukt, met de bijbehorende bedrijfsfouten.

Uw ERP-systeem heeft dus een outbox nodig: een record per bon, een toestandsmachine en een pad voor nieuwe pogingen dat geen duplicaten aanmaakt. Het systeem weigert een documentnummer dat voor uw bedrijf al bestaat, wat helpt, maar alleen als uw nummering bij nieuwe pogingen stabiel blijft.

De foutenlijst in de API-FAQ van het ministerie laat zien waar het datawerk zit:

• De uitgiftedatum moet vandaag zijn, in Servische tijd. Geen terugdateren, en geen bonnen van gisteren die een nacht in een wachtrij blijven staan.
• Elk adres (het uwe, dat van de klant, dat van de vervoerder, laad- en losplaatsen) heeft een straat en een plaats nodig.
• Bij eigen vervoer, een vervoerder of vervoer door de ontvanger zijn de vervoerder, het kenteken en het vervoermiddel verplicht. Eigen vervoer vereist bovendien dat u de vervoerdersstatus voor uw bedrijf inschakelt.
• Hoeveelheden dragen een code voor de maateenheid. Regels worden vanaf 1 genummerd. Een GTIN, als die wordt opgegeven, bestaat alleen uit cijfers.
• De ontvanger moet geregistreerd en actief zijn. GET /public/companies/status controleert een PIB voordat u verstuurt.

Stamgegevens zijn meestal een grotere klus dan de XML. Met een validatie-endpoint kunt u documenten vóór indiening testen, en dat hoort in uw testsuite.

Ontvangen en het magazijn

Inkomende bonnen komen binnen via /public/documents/customers/changes, per datum gepold met 1.000 wijzigingen per pagina, of via een webhook. Het webhookabonnement geldt per dag: een aanroep van /public/webhook-notifications/subscribe dekt de volgende dag. Draai die als geplande taak, waarschuw als hij mislukt, en houd het pull-endpoint aan als nachtelijke aansluiting, zodat een gemiste push geen gemiste termijn wordt.

Elke inkomende bon hoort in het WMS te landen als verwachte ontvangst, met de artikelcodes van de leverancier gekoppeld aan de uwe. Worden de goederen ingeboekt, dan verstuurt het WMS de actie voor fysieke ontvangst. Na de controle op hoeveelheid en kwaliteit verstuurt het de ePrijemnica: per regel de hoeveelheid die is aangekomen en de hoeveelheid die is geweigerd en met hetzelfde voertuig is teruggegaan. Het systeem accepteert geen geweigerde hoeveelheid die groter is dan de ontvangen hoeveelheid.

Het rollenmodel van het ministerie zelf is een bruikbaar sjabloon. De magazijnrol kan inkomende bonnen opvragen en downloaden en fysieke ontvangst bevestigen. Dat is ook de juiste vorm voor een autorisatie in het WMS.

Als verzender ontvangt u ook de ePrijemnica van de andere kant en moet u die aanvaarden of weigeren. Bewaak de termijn van 30 dagen om tot overeenstemming te komen in het ERP-systeem, niet in iemands mailbox.

Koppelen aan SEF-e-facturen

Een afleverbon koppelen aan een e-factuur in SEF is optioneel. Zodra een bon is verstuurd en het werkelijke verzendtijdstip is verstreken, kan SEF een of meer bonnen aan één e-factuur koppelen, en de factuur hoeft niet te wachten tot de ontvangstworkflow is afgerond. Draait uw three-way match van order, levering en factuur al in het ERP-systeem, dan geeft de koppeling de crediteurenadministratie van uw klant hetzelfde bewijs. Ons werk aan e-facturatie-integratie dekt de SEF-kant.

Vervoerders en de weg

De chauffeur kan de bon tonen vanuit de vervoerdersapp van het ministerie. Is de vervoerder geen gebruiker van het systeem, dan drukt de verzender de bon af, ondertekent de vervoerder die vóór vertrek, en uploadt de verzender het ondertekende exemplaar voordat de goederen vertrekken. Sinds de wijziging van augustus mag een vervoerder die het systeem niet kan gebruiken in plaats daarvan de QR-code tonen die bij het versturen van de bon is gegenereerd; de verzender voegt dan vóór vertrek de afdrukbare weergave toe. Uw TMS moet aanmaken wat uw vervoerders ook gebruiken, en de API geeft de QR-code los terug voor etiketten.

Voor een storing is er een papieren terugvaloptie: drie afgedrukte exemplaren met beveiligingshologramstickers van de Topčider-munt van de Nationale Bank van Servië, uiterlijk de volgende werkdag in het systeem vastgelegd. Koop de stickers voordat u ze nodig hebt.

Hoe de API-sleutel werkt

De wettelijk vertegenwoordiger registreert het bedrijf en logt daarvoor in via het eID-portaal van de overheid. Sleutels worden daarna aangemaakt in de webinterface (Settings, API settings, Admin module, API keys). Demo en productie zijn aparte omgevingen, dus reken op sleutels in beide.

De sleutel identificeert het bedrijf. De API-FAQ is onomwonden: u kunt geen documenten versturen namens een ander bedrijf, en het systeem herkent het bedrijf aan de API-sleutel die het krijgt aangeboden. In de praktijk:

• Een concern met vijf rechtspersonen heeft vijf sleutels nodig en een router die op basis van het PIB de juiste kiest.
• Een shared service center of een softwarehuis kan niet alle klanten via één sleutel laten lopen.
• Sleutels horen in een secrets store met een eigenaar en een rotatieprocedure, niet in een configuratiebestand op de ERP-server.

Een plan van 12 maanden

Het is oktober 2026. Terugtellend vanaf 1 oktober 2027:

Oktober tot december 2026: inventarisatie en toegang.

• Maak een lijst van elk type goederenbeweging: verkoop, retouren, overboekingen tussen magazijnen, invoer, uitvoer, eigen wagenpark, externe vervoerders, afhalen door de klant.
• Registreer het bedrijf in productie en regel API-sleutels voor de demo-omgeving.
• Begin met het opschonen van stamgegevens: adressen, PIB's en registratienummers van partners, vervoerders, voertuigen, maateenheden.

Januari tot maart 2027: het verzendpad.

• Genereer de DespatchAdvice uit zendingen, met de outbox, asynchrone statusbewaking en foutafhandeling.
• Een dagelijkse taak voor het webhookabonnement plus aansluiting via pull.
• De validator draait in CI tegen de demo-omgeving.

April tot juni 2027: ontvangen en ontvangstbevestiging.

• Inkomende bonnen als verwachte ontvangsten in het WMS.
• Fysieke ontvangst aan het laadperron, ePrijemnica na de controles, waarschuwingen op dag twee van drie en op dag zes van acht.
• Afhandeling van aanvaarden en weigeren voor de ePrijemnica's die u als verzender krijgt. Koppeling met SEF, als u dat wilt.

Juli tot september 2027: de weg en de piloot.

• De stroom voor vervoerders, afdrukken en QR-code, de offlineprocedure met stickers op locatie.
• Draai echte bonnen in productie met partners die zich hebben geregistreerd; private bedrijven mogen het systeem al vrijwillig gebruiken.
• Train magazijnmedewerkers en chauffeurs. Bevries wijzigingen in september.

Twaalf maanden is ruim voor één rechtspersoon met schone data. Het is krap voor een concern met meerdere rechtspersonen, meerdere magazijnen en stamgegevens waar al jaren niemand aan heeft gezeten.

Waar u hulp krijgt

C9 Group heeft een kantoor in Novi Sad, dus Servische regels zijn voor ons thuisterrein. Wij bouwen de integratie zelf: UBL-generatie, de API-client, de verwerking van webhooks en de ontvangstworkflow in het magazijn, binnen uw bestaande ERP-systeem, WMS of webwinkelbackend. Zie onze dienst voor ERP-modernisering, of schrijf naar office@c9group.dev.