FEC y exportación contable e-commerce 2026: la conformidad fiscal francesa que el 80 % de las tiendas se salta

El FEC: el documento que solo se pide en caso de control, pero que hay que producir el mismo día

El Fichier des Écritures Comptables (FEC) es una obligación legal francesa desde 2014 para toda empresa que lleve una contabilidad informatizada. En 2026, la administración fiscal francesa solicita un FEC conforme al decreto del 29 de julio de 2013 en cualquier control, y la no producción en el plazo (generalmente 30 días) conlleva el rechazo de la contabilidad y una imposición de oficio. Este punto preciso — la producción bajo plazo limitado, sin poder rehacer el histórico — es lo que hace crítica la exportación contable desde el e-commerce.

En las tiendas que auditamos, 7 de cada 10 no saben producir su FEC sin una intervención manual de varios días. Sin embargo, el cálculo es simple: sin FEC conforme = contabilidad rechazada = ajuste basado en cifras aproximadas, generalmente desfavorables para la empresa. Para una tienda WooCommerce o PrestaShop que factura 500 K€, la diferencia entre una contabilidad limpia y un ajuste puede alcanzar varias decenas de miles de euros — sin contar las penalizaciones.

Qué es exactamente un FEC conforme

El FEC es un fichero plano (CSV con separador tabulación o pipe, codificación UTF-8 o ASCII) que contiene todos los asientos contables del ejercicio, en un formato normalizado de 18 columnas obligatorias:

#	Columna	Descripción
1	JournalCode	Código de diario (p. ej. VE para ventas, BQ para banco)
2	JournalLib	Etiqueta del diario
3	EcritureNum	Número de asiento cronológico
4	EcritureDate	Fecha de contabilización (YYYYMMDD)
5	CompteNum	Número de cuenta (Plan Comptable Général)
6	CompteLib	Etiqueta de la cuenta
7-8	CompAuxNum / CompAuxLib	Cuenta auxiliar (cliente/proveedor) si aplicable
9	PieceRef	Referencia del documento justificativo
10	PieceDate	Fecha del documento
11	EcritureLib	Etiqueta del asiento
12-13	Debit / Credit	Importes (usar solo uno U otro, nunca los dos)
14	EcritureLet	Conciliación (si aplica)
15	DateLet	Fecha de conciliación
16	ValidDate	Fecha de validación del asiento
17-18	Montantdevise / Idevise	Importe en divisa + código divisa si no es EUR

Tres reglas inmutables:

• Un asiento validado ya no puede modificarse (cadena de irreversibilidad). Una corrección pasa por un contra-asiento, nunca por una modificación del original.
• Total debe = total haber en cada asiento (equilibrio contable).
• Los números de asiento son estrictamente secuenciales y continuos en el tiempo.

Es este último punto el que falla en el 80 % de las tiendas e-commerce: los pedidos se crean en un orden, se pagan en otro, se reembolsan más tarde. El mapeo hacia un FEC secuencial exige una normalización rigurosa.

Por qué e-commerce y contabilidad no se entienden de forma natural

WooCommerce y PrestaShop llevan una base comercial: pedidos, pagos, reembolsos, abonos, gastos de envío. Un experto contable necesita una base contable: asientos deudores y acreedores equilibrados, codificados por cuenta del PCG (Plan Comptable Général).

La traducción entre ambos modelos pasa por seis conceptos:

1. Las cuentas del Plan Comptable Général

Una venta B2C en Francia típica moviliza:

• 411xxx — Cuenta cliente (auxiliar por cliente si el volumen es bajo, agregada si es alto)
• 707000 — Ventas de mercancías (o 706000 para servicios)
• 4457xx — IVA repercutido (por tipo: 20 %, 10 %, 5,5 %, 2,1 %)
• 708500 — Portes facturados (con su propio IVA)
• 411090 o similar — Cuenta de espera de pago (antes del cobro efectivo)
• 512xxx — Banco (en el momento del cobro)
• 627xxx — Gastos bancarios del procesador (Stripe, PayPal)

2. Los diarios contables

Como mínimo tres diarios distintos:

• VE — Ventas: registra la venta y el IVA repercutido en el momento de la facturación (pedido pagado)
• BQ — Banco: registra el cobro real en la cuenta bancaria
• OD — Operaciones diversas: registra los abonos, devoluciones, gastos del procesador, diferencias de cambio

3. La fecha de contabilización vs la fecha de pago

Un pedido pagado el 31 de marzo a las 23:59 y cobrado por Stripe el 2 de abril debe contabilizar la venta en marzo (fecha del hecho generador fiscal: la entrega o la venta definitiva) y el cobro en abril (fecha de crédito bancario efectivo). Este desfase es la causa principal de errores en las exportaciones e-commerce ingenuas.

4. La gestión del IVA

Tres casos prácticos:

• Venta nacional: IVA repercutido al tipo aplicable
• Venta intracomunitaria B2B con nº de IVA válido: IVA al 0 % con mención «inversión del sujeto pasivo», declaración en la DEB y la DES
• Venta intracomunitaria B2C (OSS-IOSS desde 2021): IVA al tipo del país de destino si se supera el umbral 10 000 €/año UE, declaración vía la ventanilla única OSS

El OSS-IOSS es la trampa que hace caer en no conformidad al 60 % de las tiendas multipaís. No es un export FEC estándar: hace falta un diario separado por país de destino, o cuentas 4457 distintas por tipo aplicable.

5. Las devoluciones y abonos

Una devolución de cliente genera un abono (factura negativa) Y un asiento de reembolso. Ambos deben aparecer separadamente en el FEC, con la trazabilidad PieceRef que apunta al pedido original. Contabilizar una devolución como una «anulación» del asiento inicial no es conforme: rompe la cadena de irreversibilidad.

6. Los gastos del procesador

Un pedido de 100 € pagado por Stripe ingresa realmente unos 97,10 € en la cuenta bancaria (gastos Stripe: 1,4 % + 0,25 € para una tarjeta UE). Los 2,90 € de diferencia van a la cuenta 627 (servicios bancarios). Sin esta desagregación, la conciliación bancaria es imposible.

Por qué las exportaciones e-commerce nativas no son suficientes

WooCommerce y PrestaShop disponen de exportaciones CSV nativas de los pedidos. Estas exportaciones no son un FEC, por cinco razones:

1. Ninguna noción de diario contable — Una línea = un pedido, no un asiento debe/haber.
2. Ninguna desagregación por cuenta del PCG — Los importes sin impuestos, IVA, portes no están mapeados sobre las cuentas 707, 4457, 708.
3. Ninguna gestión de la secuencialidad de asiento — Sin EcritureNum continuo.
4. Sin separación venta/cobro — La fecha de pago y la fecha de validación se confunden.
5. Sin tratamiento de devoluciones, abonos y gastos del procesador — Estas operaciones se ignoran o son incoherentes.

Resultado práctico: el experto contable recibe una exportación Excel y pasa de 8 a 12 horas por ejercicio reconstruyendo los asientos manualmente. En una tienda con 2 000 pedidos/año, son entre 1 200 y 1 800 € de honorarios contables adicionales. En una tienda con 20 000 pedidos/año, es el experto contable quien rechaza el expediente o factura 4 000 a 6 000 € de reintegración.

La arquitectura de una exportación FEC limpia

Un módulo FEC serio para WooCommerce o PrestaShop implementa cinco capas:

Capa 1 — Mapeo de las cuentas

El administrador configura el mapeo entre las entidades e-commerce y las cuentas del PCG:

• Categoría de producto → cuenta 707/706 (ventas de mercancías vs servicios)
• Método de envío → cuenta 708 (portes) o 706 (servicio)
• Tipo de IVA → cuenta 4457 (4457100, 4457200, 4457550, etc.)
• Método de pago → cuenta 411090 de espera, luego 512 banco o 512x subcuenta por procesador
• Gastos del procesador → cuenta 627 (con subcuentas Stripe, PayPal, Mollie)

Capa 2 — Generación de los asientos

Para cada pedido del período, el módulo genera de 3 a 8 asientos distintos:

• Venta sin IVA (debe 411 cliente, haber 707 ventas)
• IVA repercutido (haber 4457 por tipo)
• Portes (haber 708 o 706)
• Cobro (debe 512 banco, haber 411 cliente) con desfase de fecha
• Gastos del procesador (debe 627, haber 512) en asiento separado

Para un abono, se generan los contra-asientos, nunca una modificación de los originales.

Capa 3 — Numeración secuencial estable

El EcritureNum se asigna en la exportación según un contador global persistente, reiniciado en cada ejercicio. Una vez exportado, un asiento conserva su número de por vida. El módulo debe almacenar este estado para no renumerar nunca en la regeneración.

Capa 4 — Validación y controles

Antes de exportar, el módulo verifica:

• Equilibrio debe/haber por asiento (diferencia ≤ 0,01 €)
• Continuidad del EcritureNum (sin saltos ni duplicados)
• Conformidad del formato (codificación, separador, fechas YYYYMMDD)
• Presencia de todas las columnas obligatorias
• Coherencia contable (las cuentas utilizadas existen en el PCG configurado)

Capa 5 — Exportación y firma

El fichero final se produce en el formato legal (TXT con separador pipe o tabulación, UTF-8 o ASCII), con un nombre normalizado: SIREN+FEC+fecha_fin_ejercicio.txt (por ejemplo 123456789FEC20251231.txt). Algunos módulos calculan además un hash SHA-256 para trazabilidad interna.

Las trampas jurídicas a no descuidar

1. El plazo de conservación

El FEC y todos los documentos justificativos (facturas, abonos, justificantes bancarios) deben conservarse durante 10 años desde el cierre del ejercicio (artículo L.123-22 del Código de Comercio francés). Para una tienda e-commerce, esto incluye las exportaciones SQL de la base, las facturas PDF y los logs de pago del procesador. La estrategia de copias de seguridad debe cubrir esta retención larga: véase nuestro artículo sobre la copia de seguridad PrestaShop regla 3-2-1.

2. La contabilidad debe llevarse cronológicamente

Artículo 921-2 del PCG: «El carácter definitivo de los registros […] se garantiza mediante un procedimiento de validación que impide toda modificación o eliminación del registro». Un módulo FEC que permite «regenerar» un ejercicio cerrado no es conforme. Una vez cerrado el ejercicio por el experto contable, el FEC queda fijado.

3. La imposición de oficio en caso de no producción

Si el FEC no se produce en el plazo del control (generalmente 30 días tras la solicitud), la administración puede rechazar la contabilidad y proceder a una imposición de oficio sobre las bases que estime. Las penalizaciones pueden alcanzar 5 000 € (artículo 1729 D del CGI francés) + 0,5 % de la facturación por mes de retraso.

4. RGPD y datos contables — la tensión con el derecho al olvido

El artículo 17 del RGPD permite a un cliente solicitar la supresión de sus datos. Pero la obligación contable impone 10 años de conservación. La resolución jurídica: se conservan los datos necesarios a la obligación legal (nombre, dirección de facturación, importes) y se suprime el resto (preferencias, historial de navegación, marketing). Es exactamente el tema que tratamos en el artículo de pasado mañana sobre el derecho al olvido RGPD sin romper la trazabilidad fiscal.

WooCommerce y PrestaShop: dos lógicas de implementación

WooCommerce — la especificidad francesa

WooCommerce está diseñado para el mercado estadounidense, donde el FEC no existe. La exportación contable francesa exige por tanto un plugin de terceros que sepa leer los pedidos WC, sus items, sus impuestos (vía el sistema wc_tax_rate), y que sepa mapear los payment gateways sobre las cuentas bancarias. El módulo DfWoo-FEC implementa esta lógica con un mapeo configurable, la gestión HPOS (High-Performance Order Storage) y el soporte de los refunds WC de forma nativa.

PrestaShop — la ventaja del IVA nativo

PrestaShop, diseñado en Francia originalmente, gestiona de forma nativa los tipos de IVA, las cuentas auxiliares de clientes, las facturas y abonos secuenciales (ps_order_invoice, ps_order_slip). El trabajo del módulo FEC es por tanto más simple: transformar las invoices y slips en asientos contables, sin tener que recalcular los IVA. El módulo DataFirefly Accounting Export implementa esta lógica con el soporte multishop, multilingüe y multidivisa.

Casos particulares a tratar en la exportación

Los pedidos B2B con IVA intracomunitario

Cuando un cliente alemán con un número de IVA UE válido compra, el IVA francés es del 0 %. El asiento debe reflejarlo explícitamente, con mención «autoliquidación por el adquirente», y el importe debe alimentar la DEB (declaración de intercambio de bienes) y la DES (declaración europea de servicios). Un módulo que trata estas ventas como B2C francés no es conforme.

El OSS-IOSS para el B2C UE

Desde julio de 2021, las ventas B2C UE por encima de 10 000 €/año acumuladas exigen el IVA del país de destino. El FEC debe hacer aparecer una cuenta 4457 por país/tipo (p. ej. 4457DE19 para IVA Alemania 19 %, 4457IT22 para Italia 22 %). Sin esta desagregación, la declaración OSS trimestral es imposible.

Las suscripciones y el IVA temporal

Para una tienda en suscripciones, el IVA se devenga proporcionalmente a la prestación. Una suscripción anual de 120 € contratada el 15 de octubre genera: 24 € de facturación y 4,80 € de IVA en el ejercicio en curso (oct-nov-dic), después 96 € de facturación y 19,20 € de IVA repartidos en el ejercicio siguiente. El módulo FEC debe poder generar estos asientos de ingresos diferidos.

Los bonos regalo y gift cards

Vender un bono regalo de 50 € no es una venta — es un compromiso futuro. El asiento inicial es deuda con el cliente (cuenta 4419 o similar), no venta (707). En el momento del uso del bono, se salda la deuda y se registra la venta. Es sutil y el 90 % de las exportaciones automáticas se equivocan.

Flujo de trabajo recomendado: el traspaso al gabinete

La buena práctica observada en las tiendas que han pasado sin problema su último control fiscal:

1. Mapeo inicial con el gabinete — Una sesión de 2 h con el experto contable para validar las cuentas utilizadas, los diarios y el tratamiento de los casos particulares (abonos, gastos del procesador, OSS).
2. Exportación mensual — Generación del FEC parcial cada mes, transmitido al gabinete para conciliación bancaria e integración en la contabilidad. Un mes olvidado es un mes a reconstruir.
3. Conciliación de las cuentas auxiliares — Conciliar cliente por cliente (o de forma agregada para los volúmenes muy grandes) para identificar las devoluciones y abonos no contabilizados.
4. Cierre anual — Exportación del FEC completo del ejercicio, validación final por el experto contable, archivado cifrado durante 10 años.
5. Test de producción — Una vez al año, simular una solicitud de FEC: generar el fichero, verificar que se abre en el software de control fiscal (Test Compta Demat) y que pasa las validaciones.

Coste y ROI

Para una tienda con 2 000 pedidos/año, la ecuación económica:

• Módulo FEC: 49 € licencia WooCommerce o 99 € licencia PrestaShop
• Setup con gabinete: 200 a 400 € (mapeo inicial, parametrización de las cuentas)
• Ahorro en honorarios contables: 800 a 1 500 €/año (reintegración manual evitada)
• Ahorro en riesgo fiscal: no cuantificable pero crítico en caso de control

Payback de 3 a 6 meses solo con el ahorro contable, sin contar la cobertura del riesgo.

FAQ

Mi experto contable ya usa un software que importa mis pedidos WooCommerce. ¿Necesito un FEC?

El software contable produce su propio FEC a partir de los asientos que ha registrado. Pero la exportación desde su tienda debe ser limpia aguas arriba para que los asientos sean correctos. Un conector directo WooCommerce → software contable (tipo Sage, Cegid, Quadra) puede reemplazar un módulo FEC, pero tiene su propio coste (mensual normalmente) y sus propios límites de mapeo.

¿Puedo llevar mi contabilidad en Excel y generar un FEC desde Excel?

Legalmente sí, si Excel respeta los principios de la contabilidad (irreversibilidad en particular). En la práctica, es el principal escollo: Excel permite modificar asientos pasados, lo que hace la contabilidad no conforme. La administración no rechaza Excel por principio pero pide garantías (exportación PDF con sello de tiempo de cada cierre mensual, por ejemplo). Por encima de 100 pedidos/mes, es inmanejable.

¿Cuál es el buen diario para los gastos Stripe/PayPal?

La cuenta 627 (servicios bancarios) con una subcuenta por procesador (627100 Stripe, 627200 PayPal, 627300 Mollie). El asiento pasa al diario OD (operaciones diversas) en el momento del abono neto del procesador en la cuenta bancaria. Algunos expertos prefieren pasarlo al diario BQ (banco) con una línea de gastos — ambos son aceptados mientras sea coherente en el ejercicio.

¿Cómo gestionar las ventas Amazon o eBay que pasan por mi tienda?

Si el pedido se crea en WooCommerce/PrestaShop (vía un conector marketplace), la exportación FEC lo trata como una venta normal, con la cuenta 411 auxiliar = Amazon/eBay (no el cliente final). Los gastos marketplace van a 627 distinto. Si el pedido nunca está en WC/PS (Amazon FBA puro), depende de la contabilidad de Amazon en paralelo — su gabinete debe gestionar entonces dos flujos.

¿La exportación FEC incluye el IVA del Impuesto de Sociedades y el IVA deducible sobre compras?

No. El FEC producido por un módulo e-commerce solo cubre los asientos provenientes del e-commerce (ventas, cobros de clientes, gastos del procesador). Las compras a proveedores, salarios, cargas sociales, IS — todo eso pasa por el software contable del gabinete y se fusiona con el FEC e-commerce en el FEC final anual.

En síntesis

El FEC no es una exportación más. Es una obligación legal francesa cuya no conformidad abre directamente la puerta al ajuste fiscal. Un módulo FEC serio reemplaza de 10 a 30 horas de reprocesamiento contable manual por ejercicio, asegura los plazos de producción en caso de control y le da al gabinete un fichero directamente integrable en su software.

Para WooCommerce, el módulo DfWoo-FEC gestiona el mapeo, la exportación y los casos particulares (HPOS, OSS, refunds). Para PrestaShop, el módulo DataFirefly Accounting Export cubre el multishop, multilingüe, multidivisa y las ventas B2B intracomunitarias.

El buen reflejo en 2026: validar con su gabinete el mapeo contable desde la instalación del módulo, exportar mensualmente y hacer un test anual de producción de FEC en el software oficial de control. Una hora de disciplina mensual que evita semanas de estrés en caso de control.