Illustratie bij het artikel over het FEC en de boekhoudexport in e-commerce
E-commerce nieuws

FEC en boekhoudexport voor e-commerce in 2026: de Franse fiscale conformiteit die 80 % van de webshops mist

Het FEC: het stuk dat alleen bij een controle wordt gevraagd, maar dat u dezelfde dag moet kunnen voorleggen

Het Fichier des Écritures Comptables (FEC), het bestand met de boekhoudkundige boekingen, is sinds 2014 een Franse wettelijke verplichting voor elke onderneming die een geautomatiseerde boekhouding voert. In 2026 eist de Franse belastingadministratie bij elke controle een FEC dat conform is aan het besluit (arrêté) van 29 juli 2013, en het niet voorleggen ervan binnen de termijn (doorgaans 30 dagen) leidt tot verwerping van de boekhouding en een ambtshalve aanslag. Het is precies dat punt, de productie binnen een strikte termijn zonder de historiek te kunnen overdoen, dat de boekhoudexport vanuit e-commerce kritiek maakt.

Bij de webshops die wij auditen, weten 7 op de 10 hun FEC niet te produceren zonder een handmatige ingreep van meerdere dagen. Toch is de rekensom eenvoudig: geen conform FEC = verworpen boekhouding = naheffing op basis van benaderende cijfers, doorgaans in het nadeel van de onderneming. Voor een WooCommerce- of PrestaShop-webshop met 500 K€ omzet kan het verschil tussen een zuivere boekhouding en een naheffing oplopen tot enkele tienduizenden euro’s, de boetes niet meegerekend.

Wat een conform FEC precies is

Het FEC is een plat bestand (CSV met tab- of pipe-scheidingsteken, codering UTF-8 of ASCII) dat alle boekhoudkundige boekingen van het boekjaar bevat, in een genormaliseerd formaat van 18 verplichte kolommen:

# Kolom Beschrijving
1 JournalCode Dagboekcode (bv. VE voor verkopen, BQ voor bank)
2 JournalLib Omschrijving van het dagboek
3 EcritureNum Chronologisch boekingsnummer
4 EcritureDate Boekingsdatum (YYYYMMDD)
5 CompteNum Rekeningnummer (Plan Comptable Général)
6 CompteLib Omschrijving van de rekening
7-8 CompAuxNum / CompAuxLib Subrekening (klant/leverancier), indien van toepassing
9 PieceRef Referentie van het bewijsstuk
10 PieceDate Datum van het stuk
11 EcritureLib Omschrijving van de boeking
12-13 Debit / Credit Bedragen (alleen het ene OF het andere gebruiken, nooit beide)
14 EcritureLet Afpunting (lettrage), indien van toepassing
15 DateLet Datum van afpunting
16 ValidDate Validatiedatum van de boeking
17-18 Montantdevise / Idevise Bedrag in vreemde valuta + valutacode als het geen EUR is

Drie onveranderlijke regels:

  • Een gevalideerde boeking kan niet meer worden gewijzigd (keten van onomkeerbaarheid). Een correctie verloopt via een tegenboeking, nooit via wijziging van de oorspronkelijke boeking.
  • Totaal debet = totaal credit voor elke boeking (boekhoudkundig evenwicht).
  • De boekingsnummers zijn strikt opeenvolgend en doorlopend in de tijd.

Het is dat laatste punt dat bij 80 % van de webshops ontbreekt: bestellingen worden in de ene volgorde aangemaakt, in een andere betaald en later terugbetaald. De mapping naar een sequentieel FEC vereist een strikte normalisatie.

Waarom e-commerce en boekhouding het niet vanzelf eens zijn

WooCommerce en PrestaShop houden een commerciële database bij: bestellingen, betalingen, terugbetalingen, creditnota’s, verzendkosten. Een accountant heeft een boekhoudkundige database nodig: debet- en creditboekingen in evenwicht, gecodeerd per rekening van het PCG (Plan Comptable Général, het Franse algemene rekeningschema).

De vertaling tussen beide modellen verloopt via zes concepten:

1. De rekeningen van het Plan Comptable Général

Een typische B2C-verkoop in Frankrijk gebruikt:

  • 411xxx: klantenrekening (subrekening per klant bij een klein volume, geaggregeerd bij een groot volume)
  • 707000: verkoop van handelsgoederen (of 706000 voor diensten)
  • 4457xx: verschuldigde btw (per tarief: 20 %, 10 %, 5,5 %, 2,1 %)
  • 708500: gefactureerde verzendkosten (met hun eigen btw)
  • 411090 of vergelijkbaar: wachtrekening betaling (vóór de effectieve inning)
  • 512xxx: bank (bij de inning)
  • 627xxx: bankkosten van de payment processor (Stripe, PayPal)

2. De boekhoudkundige dagboeken

Minimaal drie afzonderlijke dagboeken:

  • VE (Verkopen): registreert de verkoop en de verschuldigde btw op het moment van facturering (betaalde bestelling)
  • BQ (Bank): registreert de werkelijke inning op de bankrekening
  • OD (Diverse verrichtingen): registreert creditnota’s, retouren, processorkosten, wisselkoersverschillen

3. De boekingsdatum vs. de betaaldatum

Een bestelling die op 31 maart om 23.59 uur is betaald en op 2 april door Stripe is uitbetaald, moet de verkoop in maart boeken (datum van het fiscale belastbare feit: de levering of de definitieve verkoop) en de inning in april (datum van de effectieve creditering op de bank). Deze verschuiving is de hoofdoorzaak van fouten in naïeve e-commerce-exports.

4. Het btw-beheer

Drie praktijkgevallen:

  • Verkoop in Frankrijk: btw verschuldigd tegen het toepasselijke Franse tarief
  • Intracommunautaire B2B-verkoop met geldig btw-nummer: btw tegen 0 % met de vermelding «verlegging», aangifte in de DEB en de DES
  • Intracommunautaire B2C-verkoop (OSS-IOSS sinds 2021): btw tegen het tarief van het land van bestemming als de EU-drempel van 10 000 €/jaar wordt overschreden, aangifte via het éénloketsysteem OSS

OSS-IOSS is de valkuil waardoor 60 % van de webshops die in meerdere landen verkopen niet-conform worden. Het is geen standaard FEC-export: er is een apart dagboek per land van bestemming nodig, of afzonderlijke 4457-rekeningen per toepasselijk tarief.

5. Retouren en creditnota’s

Een klantretour genereert een creditnota (negatieve factuur) EN een terugbetalingsboeking. Beide moeten afzonderlijk in het FEC verschijnen, met de traceerbaarheid via PieceRef die naar de oorspronkelijke bestelling verwijst. Een retour boeken als een «annulering» van de oorspronkelijke boeking is niet conform: het breekt de keten van onomkeerbaarheid.

6. De processorkosten

Een bestelling van 100 € die via Stripe wordt betaald, levert in werkelijkheid ongeveer 97,10 € op de bankrekening op (Stripe-kosten: 1,4 % + 0,25 € voor een EU-kaart). Het verschil van 2,90 € gaat naar rekening 627 (bankdiensten). Zonder deze uitsplitsing is de bankreconciliatie onmogelijk.

Waarom de native e-commerce-exports niet volstaan

WooCommerce en PrestaShop beschikken over native CSV-exports van bestellingen. Deze exports zijn geen FEC, om vijf redenen:

  1. Geen notie van boekhoudkundig dagboek: één regel = één bestelling, geen debet-/creditboeking.
  2. Geen uitsplitsing per PCG-rekening: de bedragen excl. btw, btw en verzendkosten worden niet gemapt op de rekeningen 707, 4457, 708.
  3. Geen beheer van de opeenvolging van boekingen: geen doorlopend EcritureNum.
  4. Geen scheiding verkoop/inning: betaaldatum en validatiedatum worden door elkaar gehaald.
  5. Geen verwerking van retouren, creditnota’s en processorkosten: deze verrichtingen worden genegeerd of incoherent verwerkt.

Praktisch resultaat: de accountant ontvangt een Excel-export en besteedt per boekjaar 8 tot 12 uur aan het handmatig reconstrueren van de boekingen. Bij een webshop met 2 000 bestellingen/jaar is dat tussen 1 200 en 1 800 € aan extra boekhoudkundige dienstverlening. Bij een webshop met 20 000 bestellingen/jaar weigert de accountant het dossier of factureert hij 4 000 tot 6 000 € voor de herverwerking.

De architectuur van een zuivere FEC-export

Een serieuze FEC-module voor WooCommerce of PrestaShop implementeert vijf lagen:

Laag 1: mapping van de rekeningen

De beheerder configureert de mapping tussen de e-commerce-entiteiten en de PCG-rekeningen:

  • Productcategorie → rekening 707/706 (verkoop van handelsgoederen vs. diensten)
  • Verzendmethode → rekening 708 (verzending) of 706 (dienst)
  • Btw-tarief → rekening 4457 (4457100, 4457200, 4457550, enz.)
  • Betaalmethode → wachtrekening 411090, daarna bank 512 of subrekening 512x per processor
  • Processorkosten → rekening 627 (met subrekeningen Stripe, PayPal, Mollie)

Laag 2: genereren van de boekingen

Voor elke bestelling in de periode genereert de module 3 tot 8 afzonderlijke boekingen:

  • Verkoop excl. btw (debet 411 klant, credit 707 verkopen)
  • Verschuldigde btw (credit 4457 per tarief)
  • Verzendkosten (credit 708 of 706)
  • Inning (debet 512 bank, credit 411 klant) met datumverschuiving
  • Processorkosten (debet 627, credit 512) in een aparte boeking

Voor een creditnota worden tegenboekingen gegenereerd, nooit een wijziging van de oorspronkelijke boekingen.

Laag 3: stabiele opeenvolgende nummering

Het EcritureNum wordt bij de export toegekend volgens een persistente globale teller, die elk boekjaar opnieuw start. Eenmaal geëxporteerd, behoudt een boeking haar nummer voorgoed. De module moet deze toestand opslaan om bij een nieuwe generatie nooit opnieuw te nummeren.

Laag 4: validatie en controles

Vóór de export controleert de module:

  • Evenwicht debet/credit per boeking (verschil ≤ 0,01 €)
  • Continuïteit van het EcritureNum (geen gaten of dubbels)
  • Conformiteit van het formaat (codering, scheidingsteken, datums YYYYMMDD)
  • Aanwezigheid van alle verplichte kolommen
  • Boekhoudkundige coherentie (de gebruikte rekeningen bestaan in het geconfigureerde PCG)

Laag 5: export en ondertekening

Het uiteindelijke bestand wordt geproduceerd in het wettelijke formaat (TXT met pipe- of tabscheidingsteken, UTF-8 of ASCII), met een genormaliseerde naam: SIREN+FEC+einddatum_boekjaar.txt (bijvoorbeeld 123456789FEC20251231.txt). Sommige modules berekenen daarnaast een SHA-256-hash voor interne traceerbaarheid.

De juridische valkuilen die u niet mag verwaarlozen

1. De bewaartermijn

Het FEC en alle bewijsstukken (facturen, creditnota’s, bankbewijzen) moeten 10 jaar worden bewaard vanaf de afsluiting van het boekjaar (artikel L.123-22 van het Franse wetboek van koophandel). Voor een webshop omvat dat de SQL-exports van de database, de PDF-facturen en de betalingslogs van de processor. De back-upstrategie moet deze lange bewaring dekken: zie ons artikel over PrestaShop-back-ups volgens de 3-2-1-regel.

2. De boekhouding moet chronologisch worden gevoerd

Artikel 921-2 van het PCG: het definitieve karakter van de registraties wordt verzekerd door een validatieprocedure die elke wijziging of verwijdering van de registratie verbiedt. Een FEC-module die toelaat een afgesloten boekjaar «opnieuw te genereren», is niet conform. Zodra het boekjaar door de accountant is afgesloten, ligt het FEC vast.

3. De ambtshalve aanslag bij niet-voorlegging

Als het FEC niet binnen de termijn van de controle wordt voorgelegd (doorgaans 30 dagen na de aanvraag), kan de administratie de boekhouding verwerpen en een ambtshalve aanslag vestigen op basis van door haar geschatte grondslagen. De boetes kunnen oplopen tot 5 000 € (artikel 1729 D van de Franse CGI) + 0,5 % van de omzet per maand vertraging.

4. AVG en boekhoudgegevens: de spanning met het recht op vergetelheid

Artikel 17 van de AVG staat een klant toe de verwijdering van zijn gegevens te vragen. Maar de boekhoudkundige verplichting legt 10 jaar bewaring op. De juridische oplossing: u bewaart de gegevens die nodig zijn voor de wettelijke verplichting (naam, factuuradres, bedragen) en verwijdert de rest (voorkeuren, surfgeschiedenis, marketing). Dat is precies het onderwerp dat we in het artikel van morgen behandelen over het recht op vergetelheid onder de AVG zonder het fiscale spoor te breken.

WooCommerce en PrestaShop: twee implementatielogica’s

WooCommerce: de Franse specificiteit

WooCommerce is ontworpen voor de Amerikaanse markt, waar het FEC niet bestaat. De Franse boekhoudexport vereist dus een plugin van derden die de WC-bestellingen, hun items en hun belastingen (via het systeem wc_tax_rate) kan lezen, en die de payment gateways kan mappen op de bankrekeningen. De DfWoo-FEC-module implementeert deze logica met een configureerbare mapping, ondersteuning van HPOS (High-Performance Order Storage) en native ondersteuning van WC-refunds.

PrestaShop: het voordeel van de native btw

PrestaShop, oorspronkelijk in Frankrijk ontworpen, beheert native de btw-tarieven, de klantsubrekeningen, de opeenvolgende facturen en creditnota’s (ps_order_invoice, ps_order_slip). Het werk van de FEC-module is dus eenvoudiger: de invoices en slips omzetten in boekhoudkundige boekingen, zonder de btw opnieuw te moeten berekenen. De module DataFirefly Accounting Export implementeert deze logica met ondersteuning voor multishop, meertaligheid en meerdere valuta’s.

Bijzondere gevallen om in de export te verwerken

B2B-bestellingen met intracommunautaire btw

Wanneer een Duitse klant met een geldig EU-btw-nummer koopt, bedraagt de Franse btw 0 %. De boeking moet dat expliciet weergeven, met de vermelding «btw verlegd naar de afnemer», en het bedrag moet de DEB (aangifte van goederenverkeer) en de DES (Europese aangifte van diensten) voeden. Een module die deze verkopen als Franse B2C behandelt, is niet conform.

OSS-IOSS voor B2C in de EU

Sinds juli 2021 vereisen B2C-verkopen in de EU boven 10 000 €/jaar cumulatief de btw van het land van bestemming. Het FEC moet een 4457-rekening per land/tarief tonen (bv. 4457DE19 voor btw Duitsland 19 %, 4457IT22 voor Italië 22 %). Zonder deze uitsplitsing is de driemaandelijkse OSS-aangifte onmogelijk.

Abonnementen en de btw in de tijd

Voor een webshop met abonnementen is de btw verschuldigd naar rata van de dienstverlening. Een jaarabonnement van 120 € dat op 15 oktober wordt afgesloten, genereert: 24 € omzet en 4,80 € btw in het lopende boekjaar (okt-nov-dec), en daarna 96 € omzet en 19,20 € btw gespreid over het volgende boekjaar. De FEC-module moet deze boekingen van vooruitontvangen opbrengsten kunnen genereren.

Cadeaubonnen en gift cards

Een cadeaubon van 50 € verkopen is geen verkoop: het is een toekomstige verplichting. De oorspronkelijke boeking is een schuld aan de klant (rekening 4419 of vergelijkbaar), geen verkoop (707). Bij het gebruik van de bon wordt de schuld vereffend en de verkoop geboekt. Het is subtiel en 90 % van de automatische exports vergist zich.

Aanbevolen workflow: de overdracht aan het accountantskantoor

De goede praktijk die we zien bij webshops die hun laatste belastingcontrole zonder problemen hebben doorstaan:

  1. Initiële mapping met het kantoor: een sessie van 2 uur met de accountant om de gebruikte rekeningen, de dagboeken en de verwerking van bijzondere gevallen (creditnota’s, processorkosten, OSS) te valideren.
  2. Maandelijkse export: elke maand een gedeeltelijk FEC genereren en aan het kantoor bezorgen voor bankreconciliatie en integratie in de boekhouding. Een vergeten maand is een maand die moet worden gereconstrueerd.
  3. Afpunten van de subrekeningen: klant per klant afpunten (of geaggregeerd bij zeer grote volumes) om niet-geboekte retouren en creditnota’s op te sporen.
  4. Jaarafsluiting: export van het volledige FEC van het boekjaar, definitieve validatie door de accountant, versleutelde archivering gedurende 10 jaar.
  5. Productietest: eenmaal per jaar een FEC-aanvraag simuleren: het bestand genereren, controleren dat het opent in de software voor fiscale controle (Test Compta Demat) en dat het de validaties doorstaat.

Kosten en ROI

Voor een webshop met 2 000 bestellingen/jaar ziet de economische vergelijking er zo uit:

  • FEC-module: licentie WooCommerce 49 € of licentie PrestaShop 99 €
  • Set-up met het kantoor: 200 tot 400 € (initiële mapping, instelling van de rekeningen)
  • Besparing op boekhoudkundige dienstverlening: 800 tot 1 500 €/jaar (vermeden handmatige herverwerking)
  • Besparing op fiscaal risico: niet in cijfers uit te drukken, maar cruciaal bij een controle

Terugverdientijd van 3 tot 6 maanden op de boekhoudkundige besparing alleen, de risicodekking niet meegerekend.

FAQ

Mijn accountant gebruikt al software die mijn WooCommerce-bestellingen importeert. Heb ik een FEC nodig?

De boekhoudsoftware produceert haar eigen FEC op basis van de boekingen die erin zijn ingevoerd. Maar de export vanuit uw webshop moet stroomopwaarts zuiver zijn opdat de boekingen correct zijn. Een directe connector WooCommerce → boekhoudsoftware (zoals Sage, Cegid, Quadra) kan een FEC-module vervangen, maar heeft zijn eigen kosten (doorgaans maandelijks) en zijn eigen mappingbeperkingen.

Kan ik mijn boekhouding in Excel voeren en vanuit Excel een FEC genereren?

Wettelijk wel, als Excel de principes van de boekhouding respecteert (met name de onomkeerbaarheid). In de praktijk is dat het grootste struikelblok: Excel laat toe eerdere boekingen te wijzigen, waardoor de boekhouding niet conform is. De administratie weigert Excel niet principieel, maar vraagt garanties (bijvoorbeeld een PDF-export met tijdstempel van elke maandafsluiting). Boven 100 bestellingen/maand is het onbeheersbaar.

Wat is het juiste dagboek voor Stripe-/PayPal-kosten?

Rekening 627 (bankdiensten) met een subrekening per processor (627100 Stripe, 627200 PayPal, 627300 Mollie). De boeking gaat naar het OD-dagboek (diverse verrichtingen) op het moment van de netto-uitbetaling van de processor op de bankrekening. Sommige accountants boeken liever in het BQ-dagboek (bank) met een kostenregel: beide worden aanvaard zolang het binnen het boekjaar coherent is.

Hoe verwerk ik verkopen via Amazon of eBay die via mijn webshop lopen?

Als de bestelling in WooCommerce/PrestaShop wordt aangemaakt (via een marketplaceconnector), behandelt de FEC-export haar als een normale verkoop, met subrekening 411 = Amazon/eBay (niet de eindklant). De marketplacekosten gaan naar een aparte 627-rekening. Als de bestelling nooit in WC/PS terechtkomt (pure Amazon FBA), valt ze onder de parallelle Amazon-boekhouding: uw kantoor moet dan twee stromen beheren.

Omvat de FEC-export de vennootschapsbelasting en de aftrekbare btw op aankopen?

Nee. Het FEC dat een e-commercemodule produceert, dekt alleen de boekingen die uit e-commerce voortkomen (verkopen, klantinningen, processorkosten). Aankopen bij leveranciers, lonen, sociale lasten, vennootschapsbelasting: dat alles loopt via de boekhoudsoftware van het kantoor en wordt samengevoegd met het e-commerce-FEC in het uiteindelijke jaarlijkse FEC.

Samengevat

Het FEC is niet zomaar een extra export. Het is een Franse wettelijke verplichting waarvan de niet-naleving rechtstreeks de deur openzet voor een naheffing. Een serieuze FEC-module vervangt per boekjaar 10 tot 30 uur handmatige boekhoudkundige herverwerking, waarborgt de productietermijnen bij een controle en geeft het accountantskantoor een bestand dat rechtstreeks in zijn software kan worden geïntegreerd.

Voor WooCommerce beheert de module DfWoo-FEC de mapping, de export en de bijzondere gevallen (HPOS, OSS, refunds). Voor PrestaShop dekt de module DataFirefly Accounting Export multishop, meertaligheid, meerdere valuta’s en intracommunautaire B2B-verkopen.

De juiste reflex in 2026: de boekhoudkundige mapping al bij de installatie van de module met uw kantoor valideren, maandelijks exporteren en jaarlijks een productietest van het FEC uitvoeren in de officiële controlesoftware. Een uur maandelijkse discipline die weken stress bij een controle voorkomt.

Om aan de slag te gaan: onze selecties van modules voor conforme facturatie op PrestaShop en op WooCommerce.

Lees verder

Gerelateerde artikelen