Actualités e-commerce

FEC et export comptable e-commerce 2026 : la conformité fiscale française que 80 % des boutiques ratent

·sasha
FEC et export comptable e-commerce 2026 : la conformité fiscale française que 80 % des boutiques ratent

Le FEC : la pièce qu’on ne demande qu’en cas de contrôle, mais qu’il faut produire le jour même

Le Fichier des Écritures Comptables (FEC) est une obligation légale française depuis 2014 pour toute entreprise tenant une comptabilité informatisée. En 2026, l’administration fiscale demande un FEC conforme à l’arrêté du 29 juillet 2013 lors de tout contrôle, et la non-production dans le délai (généralement 30 jours) entraîne un rejet de la comptabilité et une taxation d’office. C’est ce point précis — la production sous délai contraint, sans pouvoir refaire l’historique — qui rend l’export comptable depuis le e-commerce critique.

Sur les boutiques que nous auditons, 7 sur 10 ne savent pas produire leur FEC sans une intervention manuelle de plusieurs jours. Pourtant le calcul est simple : pas de FEC conforme = comptabilité rejetée = redressement basé sur des chiffres approximatifs, généralement défavorables à l’entreprise. Pour une boutique WooCommerce ou PrestaShop qui fait 500 K€ de CA, l’écart entre une compta propre et un redressement peut atteindre plusieurs dizaines de milliers d’euros — sans compter les pénalités.

Ce qu’est exactement un FEC conforme

Le FEC est un fichier plat (CSV avec séparateur tabulation ou pipe, encodage UTF-8 ou ASCII) qui contient toutes les écritures comptables de l’exercice, dans un format normalisé de 18 colonnes obligatoires :

# Colonne Description
1 JournalCode Code journal (ex. VE pour ventes, BQ pour banque)
2 JournalLib Libellé journal
3 EcritureNum Numéro d’écriture chronologique
4 EcritureDate Date de comptabilisation (YYYYMMDD)
5 CompteNum Numéro de compte (Plan Comptable Général)
6 CompteLib Libellé du compte
7-8 CompAuxNum / CompAuxLib Compte auxiliaire (client/fournisseur) si applicable
9 PieceRef Référence de la pièce justificative
10 PieceDate Date de la pièce
11 EcritureLib Libellé de l’écriture
12-13 Debit / Credit Montants (utiliser uniquement l’un OU l’autre, jamais les deux)
14 EcritureLet Lettrage (si applicable)
15 DateLet Date de lettrage
16 ValidDate Date de validation de l’écriture
17-18 Montantdevise / Idevise Montant en devise + code devise si pas EUR

Trois règles immuables :

  • Une écriture validée ne peut plus être modifiée (chaîne d’irréversibilité). Une correction passe par une contre-écriture, jamais par modification de l’originale.
  • Le total débit = total crédit sur chaque écriture (équilibre comptable).
  • Les numéros d’écriture sont strictement séquentiels et continus dans le temps.

C’est ce dernier point qui fait défaut sur 80 % des boutiques e-commerce : les commandes sont créées dans un ordre, payées dans un autre, remboursées plus tard. Le mapping vers un FEC séquentiel exige une normalisation rigoureuse.

Pourquoi e-commerce et comptabilité ne s’entendent pas naturellement

WooCommerce et PrestaShop tiennent une base commerciale : commandes, paiements, remboursements, avoirs, frais de port. Un expert-comptable a besoin d’une base comptable : écritures débitrices et créditrices équilibrées, codifiées par compte du PCG (Plan Comptable Général).

La translation des deux modèles passe par six concepts :

1. Les comptes du Plan Comptable Général

Une vente B2C en France typique mobilise :

  • 411xxx — Compte client (auxiliaire par client si volume faible, agrégé si volume élevé)
  • 707000 — Ventes de marchandises (ou 706000 pour les services)
  • 4457xx — TVA collectée (par taux : 20 %, 10 %, 5,5 %, 2,1 %)
  • 708500 — Ports facturés (avec sa propre TVA)
  • 411090 ou similaire — Compte d’attente paiement (avant l’encaissement effectif)
  • 512xxx — Banque (lors de l’encaissement)
  • 627xxx — Frais bancaires processeur (Stripe, PayPal)

2. Les journaux comptables

Au minimum trois journaux distincts :

  • VE — Ventes : enregistre la vente et la TVA collectée au moment de la facturation (commande payée)
  • BQ — Banque : enregistre l’encaissement réel sur le compte bancaire
  • OD — Opérations diverses : enregistre les avoirs, retours, frais de processeur, écarts de change

3. La date de comptabilisation vs la date de paiement

Une commande payée le 31 mars à 23 h 59 et encaissée par Stripe le 2 avril doit comptabiliser la vente sur mars (date du fait générateur fiscal : la livraison ou la vente définitive) et l’encaissement sur avril (date de crédit bancaire effectif). Ce décalage est la cause principale d’erreurs sur les exports e-commerce naïfs.

4. La gestion de la TVA

Trois cas pratiques :

  • Vente France : TVA collectée au taux français applicable
  • Vente intracommunautaire B2B avec n° de TVA valide : TVA à 0 % avec mention « autoliquidation », déclaration sur la DEB et la DES
  • Vente intracommunautaire B2C (OSS-IOSS depuis 2021) : TVA au taux du pays de destination si le seuil 10 000 €/an UE est dépassé, déclaration via le guichet unique OSS

L’OSS-IOSS est le piège qui fait basculer en non-conformité 60 % des boutiques multi-pays. Ce n’est pas un export FEC standard : il faut un journal séparé par pays de destination, ou des comptes 4457 distincts par taux applicable.

5. Les retours et avoirs

Un retour client génère un avoir (facture négative) ET une écriture de remboursement. Les deux doivent apparaître séparément dans le FEC, avec la traçabilité PieceRef qui pointe sur la commande d’origine. Comptabiliser un retour comme une « annulation » de l’écriture initiale est non-conforme : cela casse la chaîne d’irréversibilité.

6. Les frais de processeur

Une commande à 100 € payée par Stripe encaisse réellement environ 97,10 € sur le compte bancaire (frais Stripe : 1,4 % + 0,25 € pour une carte UE). Les 2,90 € de différence vont sur le compte 627 (services bancaires). Sans cette ventilation, le rapprochement bancaire est impossible.

Pourquoi les exports e-commerce natifs ne suffisent pas

WooCommerce et PrestaShop disposent d’exports CSV natifs des commandes. Ces exports ne sont pas un FEC, pour cinq raisons :

  1. Aucune notion de journal comptable — Une ligne = une commande, pas une écriture débit/crédit.
  2. Aucune ventilation par compte du PCG — Les montants HT, TVA, port ne sont pas mappés sur les comptes 707, 4457, 708.
  3. Aucune gestion de la séquentialité d’écriture — Pas de EcritureNum continu.
  4. Pas de séparation vente/encaissement — La date de paiement et la date de validation sont confondues.
  5. Pas de traitement des retours, avoirs et frais processeur — Ces opérations sont ignorées ou incohérentes.

Résultat pratique : l’expert-comptable reçoit un export Excel et passe 8 à 12 heures par exercice à reconstruire les écritures manuellement. Sur une boutique avec 2 000 commandes/an, c’est entre 1 200 et 1 800 € de prestation comptable supplémentaire. Sur une boutique avec 20 000 commandes/an, c’est l’expert-comptable qui refuse le dossier ou facture 4 000 à 6 000 € de réintégration.

L’architecture d’un export FEC propre

Un module FEC sérieux pour WooCommerce ou PrestaShop implémente cinq couches :

Couche 1 — Mapping des comptes

L’admin configure le mapping entre les entités e-commerce et les comptes du PCG :

  • Catégorie de produit → compte 707/706 (ventes marchandises vs services)
  • Méthode de livraison → compte 708 (port) ou 706 (service)
  • Taux de TVA → compte 4457 (4457100, 4457200, 4457550, etc.)
  • Méthode de paiement → compte 411090 d’attente, puis 512 banque ou 512x sub-compte par processeur
  • Frais de processeur → compte 627 (avec sous-comptes Stripe, PayPal, Mollie)

Couche 2 — Génération des écritures

Pour chaque commande dans la période, le module génère 3 à 8 écritures distinctes :

  • Vente HT (débit 411 client, crédit 707 ventes)
  • TVA collectée (crédit 4457 par taux)
  • Port (crédit 708 ou 706)
  • Encaissement (débit 512 banque, crédit 411 client) avec décalage de date
  • Frais processeur (débit 627, crédit 512) en écriture séparée

Pour un avoir, on génère les contre-écritures, jamais une modification des originales.

Couche 3 — Numérotation séquentielle stable

Le EcritureNum est attribué à l’export selon un compteur global persistant, redémarré chaque exercice. Une fois exportée, une écriture conserve son numéro à vie. Le module doit stocker cet état pour ne jamais re-numéroter à la régénération.

Couche 4 — Validation et contrôles

Avant export, le module vérifie :

  • Équilibre débit/crédit par écriture (différence ≤ 0,01 €)
  • Continuité du EcritureNum (pas de trou ni de doublon)
  • Conformité du format (encodage, séparateur, dates YYYYMMDD)
  • Présence de toutes les colonnes obligatoires
  • Cohérence comptable (les comptes utilisés existent dans le PCG configuré)

Couche 5 — Export et signature

Le fichier final est produit dans le format légal (TXT avec séparateur pipe ou tabulation, UTF-8 ou ASCII), avec un nom normalisé : SIREN+FEC+date_fin_exercice.txt (par exemple 123456789FEC20251231.txt). Certains modules calculent en plus un hash SHA-256 pour traçabilité interne.

Les pièges juridiques à ne pas négliger

1. Le délai de conservation

Le FEC et toutes les pièces justificatives (factures, avoirs, justificatifs bancaires) doivent être conservés pendant 10 ans à compter de la clôture de l’exercice (article L.123-22 du code de commerce). Pour une boutique e-commerce, cela inclut les exports SQL de la base, les factures PDF, et les logs de paiement processeur. La stratégie de sauvegarde doit couvrir cette rétention longue : voir notre article sur la sauvegarde PrestaShop règle 3-2-1.

2. La tenue de la comptabilité doit être chronologique

Article 921-2 du PCG : « Le caractère définitif des enregistrements […] est assuré par une procédure de validation qui interdit toute modification ou suppression de l’enregistrement ». Un module FEC qui permet de « re-générer » un exercice clos est non-conforme. Une fois l’exercice clos par l’expert-comptable, le FEC est figé.

3. La taxation d’office en cas de non-production

Si le FEC n’est pas produit dans le délai du contrôle (généralement 30 jours après la demande), l’administration peut rejeter la comptabilité et procéder à une taxation d’office sur des bases qu’elle estime. Les pénalités peuvent atteindre 5 000 € (article 1729 D du CGI) + 0,5 % du CA par mois de retard.

4. RGPD et données comptables — la tension avec le droit à l’oubli

Article 17 du RGPD permet à un client de demander la suppression de ses données. Mais l’obligation comptable impose 10 ans de conservation. La résolution juridique : on conserve les données nécessaires à l’obligation légale (nom, adresse de facturation, montants) et on supprime le reste (préférences, historique de navigation, marketing). C’est le sujet précis que nous traitons dans l’article de demain sur le droit à l’oubli RGPD sans casser la trace fiscale.

WooCommerce et PrestaShop : deux logiques d’implémentation

WooCommerce — la spécificité française

WooCommerce est conçu pour le marché US, où le FEC n’existe pas. L’export comptable français exige donc un plugin tiers qui sait lire les commandes WC, leurs items, leurs taxes (via le système wc_tax_rate), et qui sait mapper les payment gateways sur les comptes bancaires. Le module DfWoo-FEC implémente cette logique avec un mapping configurable, la gestion HPOS (High-Performance Order Storage), et le support des refunds WC nativement.

PrestaShop — l’avantage de la TVA native

PrestaShop, conçu en France à l’origine, gère nativement les taux de TVA, les comptes auxiliaires clients, les factures et avoirs séquentiels (ps_order_invoice, ps_order_slip). Le travail du module FEC est donc plus simple : transformer les invoices et slips en écritures comptables, sans avoir à recalculer les TVA. Le module DataFirefly Accounting Export implémente cette logique avec le support multishop, multilingue, multidevise.

Cas particuliers à traiter dans l’export

Les commandes B2B avec TVA intracommunautaire

Quand un client allemand avec un numéro de TVA UE valide achète, la TVA française est à 0 %. L’écriture doit refléter cela explicitement, avec mention « autoliquidation par le preneur », et le montant doit alimenter la DEB (déclaration d’échange de biens) et la DES (déclaration européenne de services). Un module qui traite ces ventes comme du B2C français est non-conforme.

L’OSS-IOSS pour le B2C UE

Depuis juillet 2021, les ventes B2C UE au-delà de 10 000 €/an cumulés exigent la TVA du pays de destination. Le FEC doit faire apparaître un compte 4457 par pays/taux (ex. 4457DE19 pour TVA Allemagne 19 %, 4457IT22 pour Italie 22 %). Sans cette ventilation, la déclaration OSS trimestrielle est impossible.

Les abonnements et la TVA temporelle

Pour une boutique en abonnements, la TVA est due au prorata de la prestation. Un abonnement annuel à 120 € souscrit le 15 octobre génère : 24 € de CA et 4,80 € de TVA sur l’exercice en cours (oct-nov-dec), puis 96 € de CA et 19,20 € de TVA répartis sur l’exercice suivant. Le module FEC doit pouvoir générer ces écritures de produits constatés d’avance.

Les bons cadeaux et gift cards

Vendre un bon cadeau de 50 € n’est pas une vente — c’est un engagement futur. L’écriture initiale est dette envers le client (compte 4419 ou similaire), pas vente (707). Au moment de l’utilisation du bon, on solde la dette et on enregistre la vente. C’est subtile et 90 % des exports automatiques se trompent.

Workflow recommandé : la passation au cabinet d’expertise

La bonne pratique observée chez les boutiques qui ont passé sans souci leur dernier contrôle fiscal :

  1. Mapping initial avec le cabinet — Une session de 2 h avec l’expert-comptable pour valider les comptes utilisés, les journaux, et le traitement des cas particuliers (avoirs, frais processeur, OSS).
  2. Export mensuel — Génération du FEC partiel chaque mois, transmis au cabinet pour rapprochement bancaire et intégration dans la compta. Un mois oublié est un mois à reconstruire.
  3. Lettrage des comptes auxiliaires — Lettrer client par client (ou en agrégé pour les très gros volumes) pour identifier les retours et avoirs non comptabilisés.
  4. Clôture annuelle — Export du FEC complet de l’exercice, validation finale par l’expert-comptable, archivage chiffré pour 10 ans.
  5. Test de production — Une fois par an, simuler une demande de FEC : générer le fichier, vérifier qu’il s’ouvre dans le logiciel de contrôle fiscal (Test Compta Demat), et qu’il passe les validations.

Coût et ROI

Pour une boutique avec 2 000 commandes/an, l’équation économique :

  • Module FEC : 49 € licence WooCommerce ou 99 € licence PrestaShop
  • Setup avec cabinet : 200 à 400 € (mapping initial, paramétrage des comptes)
  • Économie sur prestation comptable : 800 à 1 500 €/an (réintégration manuelle évitée)
  • Économie sur risque fiscal : non chiffrable mais critique en cas de contrôle

Payback de 3 à 6 mois sur la seule économie comptable, sans compter la couverture du risque.

FAQ

Mon expert-comptable utilise déjà un logiciel qui importe mes commandes WooCommerce. Ai-je besoin d’un FEC ?

Le logiciel comptable produit son propre FEC à partir des écritures qu’il a saisies. Mais l’export depuis votre boutique doit être propre en amont pour que les écritures soient correctes. Un connecteur direct WooCommerce → logiciel comptable (type Sage, Cegid, Quadra) peut remplacer un module FEC, mais il a son propre coût (mensuel typiquement) et ses propres limites de mapping.

Puis-je tenir ma compta en Excel et générer un FEC depuis Excel ?

Légalement oui, si Excel respecte les principes de la comptabilité (irréversibilité notamment). En pratique, c’est l’écueil principal : Excel permet de modifier des écritures passées, ce qui rend la comptabilité non-conforme. L’administration ne refuse pas Excel par principe mais demande des garanties (export PDF horodaté de chaque clôture mensuelle, par exemple). Au-delà de 100 commandes/mois, c’est ingérable.

Quel est le bon journal pour les frais Stripe/PayPal ?

Le compte 627 (services bancaires) avec un sous-compte par processeur (627100 Stripe, 627200 PayPal, 627300 Mollie). L’écriture passe au journal OD (opérations diverses) au moment du versement net du processeur sur le compte bancaire. Certains experts préfèrent passer au journal BQ (banque) avec une ligne de frais — les deux sont acceptés tant que c’est cohérent dans l’exercice.

Comment gérer les ventes Amazon ou eBay qui transitent par ma boutique ?

Si la commande est créée dans WooCommerce/PrestaShop (via un connecteur marketplace), l’export FEC la traite comme une vente normale, avec le compte 411 auxiliaire = Amazon/eBay (pas le client final). Les frais marketplace vont en 627 distinct. Si la commande n’est jamais dans WC/PS (Amazon FBA pur), elle relève de la compta Amazon en parallèle — votre cabinet doit alors gérer deux flux.

L’export FEC inclut-il la TVA à l’IS et la TVA déductible sur achats ?

Non. Le FEC produit par un module e-commerce ne couvre que les écritures issues du e-commerce (ventes, encaissements clients, frais processeur). Les achats fournisseurs, salaires, charges sociales, IS — tout cela passe par le logiciel comptable du cabinet et fusionne avec le FEC e-commerce dans le FEC final annuel.

En synthèse

Le FEC n’est pas un export de plus. C’est une obligation légale française dont la non-conformité ouvre directement la porte au redressement fiscal. Un module FEC sérieux remplace 10 à 30 heures de retraitement comptable manuel par exercice, sécurise les délais de production en cas de contrôle, et donne au cabinet d’expertise un fichier directement intégrable dans son logiciel.

Pour WooCommerce, le module DfWoo-FEC gère le mapping, l’export, et les cas particuliers (HPOS, OSS, refunds). Pour PrestaShop, le module DataFirefly Accounting Export couvre le multishop, le multilingue, le multidevise et les ventes B2B intracommunautaires.

Le bon réflexe en 2026 : valider avec son cabinet le mapping comptable dès l’installation du module, exporter mensuellement, et faire un test annuel de production de FEC dans le logiciel officiel de contrôle. Une heure de discipline mensuelle qui évite des semaines de stress en cas de contrôle.