E-Invoice Finder
Menu
Landen Software Deadlines Gidsen Checker Verplichting checken
ENFRDEPLNL
Onafhankelijk software-acceptatietestplan voor 2026

Zo test u e-reportingsoftware voor Frankrijk vóór ingebruikname

Praktisch demo- en acceptatietestplan voor Franse e-reportingsoftware, met scenario’s voor B2C, buitenlandse transacties, incassogegevens, correcties en PA-koppelingen.

Praktische samenvatting:
  • Test uitzonderingen vóór u standaardfacturen beoordeelt.
  • Een foutloos scherm zonder PA-bewijs is geen geslaagde proef.
  • Eis dat bronboeking, transmissie en grootboekcontrole op elkaar aansluiten.
Bekijk het rapportOfficiële bronnen
Laatst gecontroleerd: 24 juli 2026Officiële bronnenDuidelijke samenvattingPraktische informatie, geen juridisch advies
Officiële bronnen eerst
Controledatums zichtbaar
Gratis checker zonder registratie

Wat u moet weten

Gids

1. Bepaal eerst welk Frans proces u werkelijk test

De DGFiP onderscheidt drie scopes. Binnenlandse B2B-transacties vallen onder elektronische facturatie. Transacties met niet-belastingplichtige klanten, zoals consumenten, en transacties met in het buitenland gevestigde marktpartijen kunnen onder transactie-e-reporting vallen. Daarnaast bestaat afzonderlijke rapportage van betalingen of incasso’s voor handelingen waarbij de btw verschuldigd wordt bij ontvangst, doorgaans diensten waarvoor niet voor btw op debetbasis is gekozen en waarop geen verleggingsregeling van toepassing is. Alle ondernemingen moeten vanaf 1 september 2026 elektronische facturen kunnen ontvangen. Grote en middelgrote ondernemingen moeten vanaf die datum ook uitreiken en e-reporting uitvoeren; kleine en micro-ondernemingen krijgen daarvoor tot 1 september 2027. Leg voor de demo vast welke entiteiten, activiteiten en ingangsdatum in uw project vallen, want een leverancier kan anders een technisch correcte maar voor uw organisatie irrelevante route tonen. Voor gereguleerde uitwisseling en verzending is een door de Franse belastingadministratie erkend platform nodig. Een compatibele oplossing kan gegevens voorbereiden en tonen, maar mag de gereguleerde transmissie niet zelfstandig uitvoeren tenzij zij met een PA is verbonden. In oudere documentatie of productpresentaties kan nog de voormalige term PDP voorkomen; vraag welke actuele PA-registratie en productiekoppeling daadwerkelijk worden gebruikt. • Classificeer per proces: binnenlandse B2B-e-facturatie, transactie-e-reporting of rapportage van incassogegevens. • Markeer diensten met btw bij ontvangst afzonderlijk van goederen, btw op debetbasis en verlegde btw. • Leg per juridische entiteit vast of zij vanaf september 2026 of september 2027 moet uitreiken en rapporteren. • Vraag de leverancier om de actuele PA-naam, registratiestatus, technische route en verantwoordelijkheidsverdeling te documenteren.

Gids

2. Bereid de demo voor met representatieve brongegevens

Stuur geen algemene wensenlijst, maar een gecontroleerd testpakket met geanonimiseerde voorbeelden uit uw ERP, facturatiesysteem, POS of kassa, boekhouding en betaalomgeving. Neem normale transacties én uitzonderingen op. Vermeld per record het verwachte land, klanttype, btw-regime, munteenheid, factuur- of kassareferentie, betaaldatum en bronapplicatie. Maak vooraf een beslisblad waarop tax of finance de verwachte route vastlegt. Dat is geen universele juridische waarheid, maar uw toetsbare uitgangspunt op basis van actuele DGFiP-documentatie en advies. De leverancier moet afwijkingen zichtbaar verklaren in plaats van stilzwijgend zijn standaardconfiguratie te gebruiken. Laat de demonstratie plaatsvinden in een omgeving die de productiearchitectuur benadert. Een handmatig ingevuld leveranciersportaal bewijst weinig als de toekomstige gegevens via een API uit meerdere systemen komen. Vraag daarom om dezelfde mapping, PA-koppeling, statussen, foutafhandeling en exportmogelijkheden die tijdens implementatie en productie beschikbaar zullen zijn. • Lever een datadictionary met veldnaam, bronsysteem, formaat, eigenaar en verplicht of optioneel karakter. • Gebruik test-SIREN’s en fictieve klantgegevens; verstrek geen echte persoonsgegevens als die niet nodig zijn. • Neem meerdere btw-tarieven, valuta, betaalmomenten, creditnota’s en ontbrekende velden in het pakket op. • Definieer vooraf welke output per scenario als geslaagd, voorwaardelijk geslaagd of mislukt geldt. • Plan deelname van finance, tax, IT, security, accounting en de eigenaar van het POS- of facturatieproces.

Gids

3. Maak acceptatie afhankelijk van bewijs, niet van presentaties

Een scenario slaagt pas wanneer de volledige keten aantoonbaar werkt: invoer uit het bronsysteem, classificatie, veldmapping, technische validatie, verzending via de PA, ontvangst- of afwijzingsstatus, boekhoudkundige aansluiting en export van het audit trail. Een groen vinkje in de gebruikersinterface zonder onderliggende payload of PA-referentie is onvoldoende. Bewaar per test een tijdstempel, bronrecord, configuratieversie, gegenereerde payload, PA- of sandboxbevestiging, foutmelding, correctie, eindstatus en reconciliatierapport. Controleer ook wie een record heeft aangemaakt, gewijzigd, goedgekeurd, opnieuw verzonden of geëxporteerd. UBL, CII en het gemengde Factur-X-formaat zijn gestructureerde benaderingen die in de Franse hervormingscontext worden gebruikt. Een gewone PDF die per e-mail wordt verstuurd, is geen conforme elektronische factuur. Laat de leverancier daarom niet alleen een leesbare PDF tonen, maar ook het gestructureerde bestand en de route waarmee het wordt uitgewisseld. • Geslaagd: de werkelijke input produceert de vooraf verwachte classificatie, payload, status en aansluiting. • Voorwaardelijk: het scenario werkt alleen na een gedocumenteerde configuratie- of integratiewijziging met eigenaar en deadline. • Mislukt: de leverancier gebruikt handmatige tussenstappen, kan de payload niet tonen of levert geen PA-bewijs. • Controleer of wijzigingen in mapping en bedrijfsregels versieerbaar, goedkeuringsplichtig en herleidbaar zijn. • Herhaal minimaal één test vanaf een schone invoer om te bewijzen dat het resultaat reproduceerbaar is.

Gids

4. Acceptatietests 1 tot en met 5: transacties en eerste betaalgebeurtenissen

De eerste vijf tests onderzoeken of de software commerciële brongegevens correct omzet in de juiste Franse rapportageroute. Voer iedere test live uit met vooraf gedeelde invoer. Laat geen voorbereide schermafbeelding of handmatig aangepast eindresultaat als vervanging gelden. Voor B2C worden transactiegegevens volgens de praktische DGFiP-richtlijnen doorgaans per dag en per btw-tarief geaggregeerd; persoonlijke klantgegevens worden daarbij niet verwacht. Buitenlandse zakelijke transacties vragen juist om correcte identificatie en classificatie. De exacte velden en frequentie blijven afhankelijk van transactie, btw-regime, actuele specificaties en PA-inrichting. • Test 1 — Binnenlandse B2C-dagaggregatie met meerdere btw-tarieven. Input: kassaregels van één dag met bijvoorbeeld 20%, 10% en een retour. Verwacht: afzonderlijke dagelijkse totalen per btw-tarief, correcte verwerking van het negatieve bedrag en geen onnodige persoonsgegevens. Bewijs: bronregels, aggregatieberekening, payload, PA-bevestiging en aansluiting op het POS-dagtotaal. • Test 2 — B2C-verkoop zonder afzonderlijke factuur. Input: alleen POS- of kassadagtotalen, inclusief contante en kaartbetalingen. Verwacht: een geaccepteerde rapportage op basis van de beschikbare totalen zonder dat de software kunstmatig klantfacturen of fictieve persoonsgegevens aanmaakt. Bewijs: kassa-afsluiting, toegepaste mapping, verzonden dataset en verklaring van eventuele niet-rapporteerbare verschillen. • Test 3 — Buitenlandse B2B-klant, vreemde valuta en export- of intra-EU-variant. Input: twee vergelijkbare transacties met een buitenlands btw- of ander identificatienummer, één intra-EU en één export, plus documentvaluta en omrekeningsgegevens. Verwacht: het buitenlandse identificatiemiddel vervangt waar toepasselijk een SIREN, valuta blijven herleidbaar en beide varianten krijgen de juiste afzonderlijke classificatie. Bewijs: masterdata, beslisregels, payloads, gebruikte wisselkoersvelden en PA-resultaten. • Test 4 — Binnenlandse dienstenfactuur met btw verschuldigd bij ontvangst. Input: een dienst, geen keuze voor btw op debetbasis, geen verlegging en een latere betaling. Verwacht: de transactie en het betaalgebeuren worden onderscheiden; de incassodatum en het ontvangen bedrag worden per btw-tarief verwerkt en de e-factuur kan worden aangevuld met een status zoals ‘encaissée’. Bewijs: factuurpayload, betaalrecord, statusgeschiedenis en verzendbevestiging. • Test 5 — Aanbetaling of voorschot. Input: een voorschot vóór de eindfactuur met duidelijke referenties naar order en klant. Verwacht: de software volgt de geconfigureerde behandeling, voorkomt dat voorschot en eindafrekening dubbel worden gerapporteerd en bewaart de relatie tussen documenten en betalingen. Bewijs: configuratieregel, voorschotdocument, eindafrekening, gekoppelde betaalgebeurtenissen en reconciliatie.

Gids

5. Acceptatietests 6 tot en met 10: correcties, uitsluitingen en controle

De resterende tests richten zich op situaties waarin systemen in de praktijk vaak uiteenlopen: deelbetalingen, terugboekingen, uitzonderingen, afgewezen batches en dubbele verzending. Juist deze scenario’s tonen of het product een operationeel proces ondersteunt of alleen een ideale standaardtransactie. Dwing bij elke fout een herstelcyclus af. Het team moet kunnen vaststellen wat is afgewezen, welke brongegevens of mapping zijn gewijzigd, wie de correctie heeft goedgekeurd en of de nieuwe verzending dezelfde zakelijke referentie behoudt zonder een onbedoelde dubbele rapportage te creëren. • Test 6 — Deelbetalingen op verschillende data. Input: één dienstenfactuur die in twee of meer bedragen wordt voldaan. Verwacht: elk ontvangen bedrag krijgt zijn eigen incassodatum en verdeling per btw-tarief; de factuur blijft gedeeltelijk betaald tot het restant is ontvangen. Bewijs: bank- of betaalimport, allocatieregels, statusovergangen, payloads en openstaande-postenaansluiting. • Test 7 — Creditnota, terugbetaling en annulering. Input: een volledige annulering en een gedeeltelijke creditnota na eerdere rapportage, gevolgd door een terugbetaling. Verwacht: originele en corrigerende documenten blijven gekoppeld, tekenconventies zijn consistent en de correctie wordt via de juiste route verwerkt zonder de oorspronkelijke auditgeschiedenis te overschrijven. Bewijs: documentketen, reden, payloads, statussen en grootboekaansluiting. • Test 8 — Btw op debetbasis of verleggingsregeling. Input: een dienst waarvoor btw op debetbasis is gekozen en een afzonderlijke verlegde transactie. Verwacht: de engine herkent dat de standaardroute voor incassorapportage niet zonder meer van toepassing is en routeert of sluit uit volgens de gevalideerde bedrijfsregels. Bewijs: belastingcodes, beslislogica, uitzonderingsrapport en goedkeuring door de verantwoordelijke adviseur of taxfunctie. • Test 9 — Afgewezen, gecorrigeerde en opnieuw verzonden batch. Input: een batch met opzettelijk een ongeldig verplicht veld. Verwacht: de PA-afwijzing wordt op recordniveau zichtbaar, niet-geaccepteerde gegevens kunnen gecontroleerd worden hersteld en de nieuwe verzending krijgt een herleidbare relatie met de mislukte poging. Bewijs: foutcode, melding aan eigenaar, correctielog, nieuwe payload en definitieve ontvangstbevestiging. • Test 10 — Dubbele invoer, idempotentie en reconciliatie-export. Input: dezelfde transactie of batch tweemaal via de API, gevolgd door een periode-export. Verwacht: de koppeling voorkomt of markeert dubbele verwerking, bewaart idempotentiesleutels en levert een export waarin bronrecord, PA-referentie, status, bedrag en grootboekboeking aansluiten. Bewijs: API-log, duplicaatmelding, volledige audit trail en controleerbaar reconciliatiebestand.

Gids

6. Illustratief rekenvoorbeeld voor incassogegevens

Neem uitsluitend als testvoorbeeld een binnenlandse dienstenfactuur van €1.000 exclusief 20% btw, totaal €1.200. Veronderstel voor deze proef dat de btw bij ontvangst verschuldigd is, dat niet voor btw op debetbasis is gekozen en dat geen verleggingsregeling geldt. De klant betaalt €600 op 8 oktober en €600 op 22 oktober. De software moet in dit voorbeeld twee afzonderlijke betaalgebeurtenissen kunnen vastleggen, elk met de eigen incassodatum en €600 toegewezen aan het relevante btw-tarief. Na de eerste ontvangst hoort de factuur niet volledig betaald te zijn; na de tweede kan de status volledig geïncasseerd worden. De leverancier moet aantonen hoe deze informatie de e-factuur aanvult en via de PA wordt verwerkt. Dit voorbeeld bepaalt niet universeel welke velden, bedragen of rapportagefrequentie juridisch vereist zijn. Test ook een onjuiste betaling van €600 die later wordt teruggedraaid. Laat uw adviseur, PA en actuele DGFiP-documentatie bevestigen hoe de definitieve mapping voor uw btw-regime, transactie en platformconfiguratie moet worden ingericht. • Controleer of factuurbedrag, ontvangen totaal en openstaand saldo na iedere gebeurtenis rekenkundig aansluiten. • Controleer of beide incassodata afzonderlijk blijven bestaan en niet door de laatste betaaldatum worden overschreven. • Vraag welke velden naar de PA gaan en welke informatie uitsluitend intern in ERP of boekhouding blijft. • Herhaal het voorbeeld met twee btw-tarieven om de verdeling en afrondingsregels zichtbaar te maken.

Gids

7. Beslismatrix met harde pass-failvragen

Gebruik een beslismatrix met per vraag de waarden geslaagd, voorwaardelijk of mislukt. Voeg naast het leveranciersantwoord altijd een verwijzing naar het testbewijs toe. Een mondeling ‘ja’ zonder demonstratie, documentatie of eigenaar krijgt geen geslaagde status. Maak kritieke eisen blokkerend. Dat geldt normaal gesproken voor een aantoonbare PA-route, correcte scopeclassificatie, bescherming tegen dubbele verzending, herstel van afwijzingen en exporteerbare reconciliatie. Niet-kritieke gebruiksgemakken kunnen afzonderlijk worden gewogen. Beoordeel ook het implementatiemodel. Leg vast welke partij masterdata opschoont, mappings onderhoudt, DGFiP-wijzigingen volgt, incidenten analyseert en contact met de PA opneemt. Een technisch passend product kan alsnog een slechte keuze zijn wanneer geen enkele partij de operationele verantwoordelijkheid accepteert. • Scope en PA: classificeert de oplossing iedere test correct, en toont zij een werkende verbinding met een actuele erkende PA in plaats van alleen het label ‘solution compatible’? • Datamapping: zijn SIREN, buitenlandse identificatie, btw-tarieven, valuta, documentreferenties en classificaties zichtbaar gemapt, gevalideerd en versieerbaar? • Betalingen: ondersteunt het systeem incassodatum, ontvangen bedrag per btw-tarief, deelbetalingen, voorschotten, terugboekingen en de status ‘encaissée’ waar relevant? • Correcties en afwijzingen: zijn creditnota’s, annuleringen, PA-foutcodes, correcties en gecontroleerde herverzending volledig herleidbaar? • Reconciliatie en export: kan een gebruiker brontransactie, payload, PA-referentie, status, betaalrecord en boeking in een leesbaar en machinaal verwerkbaar bestand aansluiten? • Rechten en security: bestaan functiescheiding, goedkeuringen, auditlogs, sterke toegangscontrole, bewaarbeleid en veilige API-credentialprocessen? • Eigenaarschap en support: zijn implementatieverantwoordelijkheden, responstijden, escalatie naar de PA, releasebeheer en ondersteuning bij DGFiP-wijzigingen contractueel duidelijk?

Gids

8. Veelvoorkomende risico’s en misleidende demo-uitkomsten

Het grootste risico is dat een demo alleen het aanmaken van een factuur laat zien. Voor deze aankoopbeslissing zijn classificatie, e-reporting van B2C- en buitenlandse transacties, betaalgebeurtenissen, PA-transmissie en controle achteraf minstens zo belangrijk. Een fraaie interface compenseert geen ontbrekende ketencontrole. Een tweede fout is het verwarren van een compatibele oplossing met een erkend platform. Vraag de leverancier exact welke rechtspersoon als PA is geregistreerd, waar de gereguleerde transmissie plaatsvindt en wie verantwoordelijk is wanneer de PA of DGFiP een record afwijst. Ten slotte kunnen teams te vroeg vaste aannames maken over frequentie en datamapping. De precieze cadence en velden hangen af van btw-regime, transactietype, actuele specificaties en platforminrichting. Bevestig de productieconfiguratie daarom met uw adviseur, de gekozen PA en de meest recente DGFiP-documentatie. • Accepteer geen gewone PDF per e-mail als bewijs van conforme elektronische facturatie; inspecteer Factur-X, UBL of CII en de uitwisselingsroute. • Laat geen persoonsgegevens meesturen in dagelijkse B2C-aggregaties zonder aantoonbare noodzaak en rechtsgrond. • Voorkom dat buitenlandse klanten worden afgewezen omdat het systeem uitsluitend een Franse SIREN accepteert. • Test afrondingsverschillen, ontbrekende masterdata en teruggedraaide betalingen voordat productievolumes worden aangesloten. • Controleer of handmatige correcties het oorspronkelijke record bewaren in plaats van het audit trail te overschrijven. • Behandel een sandboxresultaat niet als productiegarantie zonder implementatieplan, volumetest en bewijs van de definitieve PA-route.

Gids

9. Van demo naar gecontroleerde implementatie

Sluit de demo af met een gezamenlijk bevindingenregister. Noteer per scenario de uitslag, het bewijs, de oorzaak van afwijkingen, de vereiste wijziging, de eigenaar en een her-testdatum. Splits producttekorten, configuratieproblemen, gebrekkige brondata en onduidelijke fiscale beslissingen van elkaar. Voer na herstel een beperkte end-to-end pilot uit met representatieve volumes uit ERP, billingsoftware, POS, boekhoudsysteem en API-koppelingen. Vergelijk de brontotalen met PA-bevestigingen en financiële rapportages. Neem ook storingen, time-outs, dubbele API-aanroepen en verwerking na een onderbreking mee. Geef pas productieacceptatie wanneer de blokkerende vragen zijn geslaagd, verantwoordelijkheden zijn toegewezen en de audit trail kan worden geëxporteerd. Plan vervolgens periodieke controles rond DGFiP-specificaties, PA-releases, belastingcodes en gewijzigde verkoop- of betaalprocessen. • Vraag binnen vijf werkdagen een compleet bewijsdossier en openstaande-puntenlijst van de leverancier. • Laat tax of de externe adviseur de classificatie- en uitsluitingsregels valideren. • Laat IT de PA-architectuur, API-beveiliging, monitoring, herstelprocedures en volumecapaciteit toetsen. • Voer een formele her-test uit voor iedere blokkerende afwijking; accepteer geen sluiting op basis van alleen een e-mail. • Leg go-livecriteria, terugvalprocedure, supportescalatie en controle van de eerste productieperiode schriftelijk vast.

Checklist

De tien scenario’s zijn met eigen representatieve brongegevens uitgevoerd.

De drie Franse scopes zijn per proces en juridische entiteit gedocumenteerd.

De actuele PA-registratie en werkelijke transmissieroute zijn gecontroleerd.

SIREN, buitenlandse identificatie, valuta, btw-tarieven en documentreferenties zijn gemapt.

B2C-dagaggregaties sluiten per btw-tarief aan op POS- of kassacontroles.

Deelbetalingen, voorschotten, terugbetalingen en incassodata zijn aantoonbaar verwerkt.

Creditnota’s, annuleringen, afwijzingen en herverzendingen bewaren hun volledige historie.

Dubbele API-aanroepen leiden niet tot ongecontroleerde dubbele rapportage.

Reconciliatie- en auditgegevens zijn volledig en in een bruikbaar formaat exporteerbaar.

Implementatie-eigenaars, supportescalaties, her-tests en go-livecriteria zijn schriftelijk vastgelegd.

Veelgestelde vragen

Hoe test ik e-reportingsoftware voor Frankrijk zonder alleen de leveranciersdemo te volgen?

Maak vooraf een testpakket met verwachte classificaties en voer dit door de volledige keten: bronsysteem, mapping, validatie, PA, status en reconciliatie. Vraag per scenario om de payload, ontvangst- of foutmelding en auditexport. Gebruik zowel standaardtransacties als deelbetalingen, creditnota’s, buitenlandse klanten, afwijzingen en duplicaten.

Welke betalingsscenario’s moet een Franse softwaredemo minimaal tonen?

Laat een volledige betaling, deelbetalingen op verschillende data, een voorschot, een teruggedraaide betaling, een terugbetaling en een betaling voor een factuur met meerdere btw-tarieven zien. Controleer afzonderlijk een dienst met btw bij ontvangst, btw op debetbasis en een verlegde transactie. Betalingsrapportage kan ongeacht het klanttype relevant zijn wanneer de btw bij ontvangst verschuldigd wordt.

Heeft mijn ERP of facturatiesoftware een erkend PA-platform nodig?

Voor de gereguleerde uitwisseling en transmissie moet een erkend platform worden gebruikt. Uw ERP, billingsoftware of boekhoudsysteem kan compatibel zijn en gegevens via een API voorbereiden, maar een louter compatibele oplossing kan de gereguleerde verzending niet zelfstandig uitvoeren zonder koppeling met een PA. Vraag welke PA de leverancier gebruikt en laat de werkelijke route demonstreren.

Hoe controleer ik dagelijkse B2C-aggregatie per btw-tarief?

Neem kassaregels voor één dag met meerdere btw-tarieven, retouren en verschillende betaalwijzen. Bereken vooraf de verwachte totalen en vergelijk die met de gegenereerde aggregatie en de PA-payload. Controleer dat negatieve bedragen correct worden verwerkt, dat het geheel aansluit op de kassa-afsluiting en dat geen onnodige persoonlijke klantgegevens worden meegestuurd.

Kan software een buitenlandse zakelijke klant verwerken zonder Franse SIREN?

Dat moet worden getest met realistische buitenlandse masterdata. Waar toepasselijk kan een buitenlands btw- of ander identificatienummer de SIREN vervangen. Controleer daarnaast land, valuta en de afzonderlijke classificatie van intra-EU- en exporttransacties. Laat tax of uw adviseur bevestigen welke behandeling voor uw concrete transactie geldt.

Hoe test ik deelbetalingen en creditnota’s zonder dubbele rapportage?

Gebruik één factuur met meerdere betaaldata en maak daarna een gedeeltelijke creditnota of terugbetaling. De software moet alle gebeurtenissen aan het oorspronkelijke document koppelen, openstaande bedragen correct bijwerken en de historie bewaren. Herhaal vervolgens een API-aanroep om te controleren dat idempotentie of duplicaatdetectie dubbele verwerking voorkomt.

Welk bewijs moet een leverancier na de acceptatietest opleveren?

Vraag per scenario om het bronrecord, de mappingversie, de gestructureerde payload, tijdstempels, PA-referenties, ontvangst- of foutcodes, correctielogs, gebruikersactiviteiten en reconciliatie-export. Het dossier moet aantonen hoe bedragen, btw-tarieven, documenten, betalingen en grootboekboekingen met elkaar samenhangen.

Staan frequentie en datavelden voor e-reporting al volledig vast?

Ga niet uit van één universele frequentie of mapping. De exacte cadence en gegevens kunnen afhangen van het btw-regime, het transactietype, actuele technische specificaties en de inrichting van het gekozen platform. Valideer de definitieve productieconfiguratie met de actuele DGFiP-documentatie, uw adviseur en de erkende PA.

Belangrijke regels, formaten en termen

Europese CommissieEN 16931Richtlijn 2014/55/EUgestructureerde elektronische factuurDemo- en acceptatietestplan 2026/2027 voor Franse e-reportingsoftwareFrankrijk

Lees verder

Officiële bronnen

We geven voorrang aan officiële overheids- en EU-bronnen waar beschikbaar en tonen controledatums zichtbaar.