FEC e exportação contabilística e-commerce 2026: a conformidade fiscal francesa que 80 % das lojas falham

O FEC: o documento que só é pedido em caso de inspeção, mas que tem de ser produzido no próprio dia

O Fichier des Écritures Comptables (FEC), o ficheiro dos lançamentos contabilísticos, é uma obrigação legal francesa desde 2014 para qualquer empresa com contabilidade informatizada. Em 2026, a administração fiscal francesa exige um FEC conforme ao despacho (arrêté) de 29 de julho de 2013 em qualquer inspeção, e a não apresentação dentro do prazo (geralmente 30 dias) implica a rejeição da contabilidade e uma liquidação oficiosa. É este ponto preciso, a produção num prazo apertado, sem poder refazer o histórico, que torna crítica a exportação contabilística a partir do e-commerce.

Nas lojas que auditamos, 7 em cada 10 não sabem produzir o seu FEC sem uma intervenção manual de vários dias. No entanto, o cálculo é simples: sem FEC conforme = contabilidade rejeitada = correção fiscal baseada em números aproximados, geralmente desfavoráveis à empresa. Para uma loja WooCommerce ou PrestaShop com 500 mil € de volume de negócios, a diferença entre uma contabilidade limpa e uma correção fiscal pode atingir várias dezenas de milhares de euros, sem contar as penalizações.

O que é exatamente um FEC conforme

O FEC é um ficheiro simples (CSV com separador de tabulação ou pipe, codificação UTF-8 ou ASCII) que contém todos os lançamentos contabilísticos do exercício, num formato normalizado de 18 colunas obrigatórias:

#	Coluna	Descrição
1	JournalCode	Código do diário (ex.: VE para vendas, BQ para banco)
2	JournalLib	Designação do diário
3	EcritureNum	Número cronológico do lançamento
4	EcritureDate	Data de contabilização (YYYYMMDD)
5	CompteNum	Número da conta (Plan Comptable Général)
6	CompteLib	Designação da conta
7-8	CompAuxNum / CompAuxLib	Conta auxiliar (cliente/fornecedor), se aplicável
9	PieceRef	Referência do documento de suporte
10	PieceDate	Data do documento
11	EcritureLib	Designação do lançamento
12-13	Debit / Credit	Montantes (utilizar apenas um OU outro, nunca os dois)
14	EcritureLet	Reconciliação (lettrage), se aplicável
15	DateLet	Data de reconciliação
16	ValidDate	Data de validação do lançamento
17-18	Montantdevise / Idevise	Montante em divisa + código da divisa, se não for EUR

Três regras imutáveis:

• Um lançamento validado já não pode ser modificado (cadeia de irreversibilidade). Uma correção faz-se por um contralançamento, nunca pela modificação do original.
• O total a débito = total a crédito em cada lançamento (equilíbrio contabilístico).
• Os números de lançamento são estritamente sequenciais e contínuos no tempo.

É este último ponto que falha em 80 % das lojas de e-commerce: as encomendas são criadas numa ordem, pagas noutra e reembolsadas mais tarde. O mapeamento para um FEC sequencial exige uma normalização rigorosa.

Porque é que e-commerce e contabilidade não se entendem naturalmente

O WooCommerce e o PrestaShop mantêm uma base comercial: encomendas, pagamentos, reembolsos, notas de crédito, portes. Um contabilista certificado precisa de uma base contabilística: lançamentos a débito e a crédito equilibrados, codificados por conta do PCG (Plan Comptable Général, o plano de contas francês).

A tradução entre os dois modelos passa por seis conceitos:

1. As contas do Plan Comptable Général

Uma venda B2C típica em França mobiliza:

• 411xxx: conta de cliente (auxiliar por cliente se o volume for reduzido, agregada se o volume for elevado)
• 707000: vendas de mercadorias (ou 706000 para os serviços)
• 4457xx: IVA liquidado (por taxa: 20 %, 10 %, 5,5 %, 2,1 %)
• 708500: portes faturados (com o seu próprio IVA)
• 411090 ou semelhante: conta transitória de pagamento (antes do recebimento efetivo)
• 512xxx: banco (no momento do recebimento)
• 627xxx: comissões bancárias do processador (Stripe, PayPal)

2. Os diários contabilísticos

No mínimo, três diários distintos:

• VE (Vendas): regista a venda e o IVA liquidado no momento da faturação (encomenda paga)
• BQ (Banco): regista o recebimento real na conta bancária
• OD (Operações diversas): regista as notas de crédito, devoluções, comissões do processador, diferenças de câmbio

3. A data de contabilização vs. a data de pagamento

Uma encomenda paga a 31 de março às 23h59 e recebida pela Stripe a 2 de abril deve contabilizar a venda em março (data do facto gerador fiscal: a entrega ou a venda definitiva) e o recebimento em abril (data do crédito bancário efetivo). Este desfasamento é a principal causa de erros nas exportações de e-commerce ingénuas.

4. A gestão do IVA

Três casos práticos:

• Venda em França: IVA liquidado à taxa francesa aplicável
• Venda intracomunitária B2B com n.º de IVA válido: IVA a 0 % com a menção «autoliquidação», declaração na DEB e na DES
• Venda intracomunitária B2C (OSS-IOSS desde 2021): IVA à taxa do país de destino se o limiar de 10 000 €/ano na UE for ultrapassado, declaração através do balcão único OSS

O OSS-IOSS é a armadilha que leva à não conformidade 60 % das lojas multipaís. Não é uma exportação FEC standard: é preciso um diário separado por país de destino, ou contas 4457 distintas por taxa aplicável.

5. As devoluções e notas de crédito

Uma devolução de cliente gera uma nota de crédito (fatura negativa) E um lançamento de reembolso. Os dois devem aparecer separadamente no FEC, com a rastreabilidade PieceRef a apontar para a encomenda de origem. Contabilizar uma devolução como uma «anulação» do lançamento inicial não é conforme: quebra a cadeia de irreversibilidade.

6. As comissões do processador

Uma encomenda de 100 € paga através da Stripe recebe na realidade cerca de 97,10 € na conta bancária (comissões Stripe: 1,4 % + 0,25 € para um cartão da UE). Os 2,90 € de diferença vão para a conta 627 (serviços bancários). Sem esta repartição, a reconciliação bancária é impossível.

Porque é que as exportações nativas de e-commerce não chegam

O WooCommerce e o PrestaShop dispõem de exportações CSV nativas das encomendas. Estas exportações não são um FEC, por cinco razões:

1. Nenhuma noção de diário contabilístico: uma linha = uma encomenda, não um lançamento a débito/crédito.
2. Nenhuma repartição por conta do PCG: os montantes sem IVA, IVA e portes não são mapeados nas contas 707, 4457, 708.
3. Nenhuma gestão da sequencialidade dos lançamentos: não há EcritureNum contínuo.
4. Nenhuma separação venda/recebimento: a data de pagamento e a data de validação são confundidas.
5. Nenhum tratamento das devoluções, notas de crédito e comissões do processador: estas operações são ignoradas ou incoerentes.

Resultado prático: o contabilista recebe uma exportação Excel e passa 8 a 12 horas por exercício a reconstruir os lançamentos manualmente. Numa loja com 2 000 encomendas/ano, isso representa entre 1 200 e 1 800 € de serviços contabilísticos adicionais. Numa loja com 20 000 encomendas/ano, é o contabilista que recusa o dossiê ou fatura 4 000 a 6 000 € de reintegração.

A arquitetura de uma exportação FEC limpa

Um módulo FEC sério para WooCommerce ou PrestaShop implementa cinco camadas:

Camada 1: mapeamento das contas

O administrador configura o mapeamento entre as entidades de e-commerce e as contas do PCG:

• Categoria de produto → conta 707/706 (vendas de mercadorias vs. serviços)
• Método de envio → conta 708 (portes) ou 706 (serviço)
• Taxa de IVA → conta 4457 (4457100, 4457200, 4457550, etc.)
• Método de pagamento → conta transitória 411090, depois banco 512 ou subconta 512x por processador
• Comissões do processador → conta 627 (com subcontas Stripe, PayPal, Mollie)

Camada 2: geração dos lançamentos

Para cada encomenda do período, o módulo gera 3 a 8 lançamentos distintos:

• Venda sem IVA (débito 411 cliente, crédito 707 vendas)
• IVA liquidado (crédito 4457 por taxa)
• Portes (crédito 708 ou 706)
• Recebimento (débito 512 banco, crédito 411 cliente) com desfasamento de data
• Comissões do processador (débito 627, crédito 512) num lançamento separado

Para uma nota de crédito, geram-se os contralançamentos, nunca uma modificação dos originais.

Camada 3: numeração sequencial estável

O EcritureNum é atribuído na exportação segundo um contador global persistente, reiniciado em cada exercício. Uma vez exportado, um lançamento conserva o seu número para sempre. O módulo tem de guardar este estado para nunca renumerar numa nova geração.

Camada 4: validação e controlos

Antes da exportação, o módulo verifica:

• Equilíbrio débito/crédito por lançamento (diferença ≤ 0,01 €)
• Continuidade do EcritureNum (sem lacunas nem duplicados)
• Conformidade do formato (codificação, separador, datas YYYYMMDD)
• Presença de todas as colunas obrigatórias
• Coerência contabilística (as contas utilizadas existem no PCG configurado)

Camada 5: exportação e assinatura

O ficheiro final é produzido no formato legal (TXT com separador pipe ou tabulação, UTF-8 ou ASCII), com um nome normalizado: SIREN+FEC+data_fim_exercício.txt (por exemplo 123456789FEC20251231.txt). Alguns módulos calculam ainda um hash SHA-256 para rastreabilidade interna.

As armadilhas jurídicas a não descurar

1. O prazo de conservação

O FEC e todos os documentos de suporte (faturas, notas de crédito, comprovativos bancários) devem ser conservados durante 10 anos a contar do encerramento do exercício (artigo L.123-22 do código comercial francês). Para uma loja de e-commerce, isso inclui as exportações SQL da base de dados, as faturas em PDF e os registos de pagamento do processador. A estratégia de cópias de segurança tem de cobrir esta retenção longa: veja o nosso artigo sobre a cópia de segurança PrestaShop com a regra 3-2-1.

2. A contabilidade tem de ser cronológica

Artigo 921-2 do PCG: o caráter definitivo dos registos é assegurado por um procedimento de validação que proíbe qualquer modificação ou eliminação do registo. Um módulo FEC que permita «regenerar» um exercício encerrado não é conforme. Depois de o exercício ser encerrado pelo contabilista, o FEC fica congelado.

3. A liquidação oficiosa em caso de não apresentação

Se o FEC não for apresentado dentro do prazo da inspeção (geralmente 30 dias após o pedido), a administração pode rejeitar a contabilidade e proceder a uma liquidação oficiosa com base em valores que ela própria estima. As penalizações podem atingir 5 000 € (artigo 1729 D do CGI francês) + 0,5 % do volume de negócios por mês de atraso.

4. RGPD e dados contabilísticos: a tensão com o direito ao esquecimento

O artigo 17 do RGPD permite a um cliente pedir a eliminação dos seus dados. Mas a obrigação contabilística impõe 10 anos de conservação. A solução jurídica: conservam-se os dados necessários à obrigação legal (nome, morada de faturação, montantes) e elimina-se o resto (preferências, histórico de navegação, marketing). É o tema preciso que tratamos no artigo de amanhã sobre o direito ao esquecimento RGPD sem quebrar o rasto fiscal.

WooCommerce e PrestaShop: duas lógicas de implementação

WooCommerce: a especificidade francesa

O WooCommerce foi concebido para o mercado norte-americano, onde o FEC não existe. A exportação contabilística francesa exige, portanto, um plugin de terceiros que saiba ler as encomendas WC, os seus itens, os seus impostos (através do sistema wc_tax_rate), e que saiba mapear os payment gateways nas contas bancárias. O módulo DfWoo-FEC implementa esta lógica com um mapeamento configurável, a gestão do HPOS (High-Performance Order Storage) e o suporte nativo dos refunds WC.

PrestaShop: a vantagem do IVA nativo

O PrestaShop, concebido originalmente em França, gere nativamente as taxas de IVA, as contas auxiliares de clientes, as faturas e notas de crédito sequenciais (ps_order_invoice, ps_order_slip). O trabalho do módulo FEC é, portanto, mais simples: transformar as invoices e os slips em lançamentos contabilísticos, sem ter de recalcular o IVA. O módulo DataFirefly Accounting Export implementa esta lógica com suporte multiloja, multilíngue e multidivisa.

Casos particulares a tratar na exportação

As encomendas B2B com IVA intracomunitário

Quando um cliente alemão com um número de IVA da UE válido faz uma compra, o IVA francês é de 0 %. O lançamento tem de refletir isso explicitamente, com a menção «autoliquidação pelo adquirente», e o montante deve alimentar a DEB (declaração de trocas de bens) e a DES (declaração europeia de serviços). Um módulo que trate estas vendas como B2C francês não é conforme.

O OSS-IOSS para o B2C na UE

Desde julho de 2021, as vendas B2C na UE acima de 10 000 €/ano acumulados exigem o IVA do país de destino. O FEC tem de fazer aparecer uma conta 4457 por país/taxa (ex.: 4457DE19 para IVA Alemanha 19 %, 4457IT22 para Itália 22 %). Sem esta repartição, a declaração OSS trimestral é impossível.

As subscrições e o IVA temporal

Para uma loja de subscrições, o IVA é devido na proporção da prestação. Uma subscrição anual de 120 € subscrita a 15 de outubro gera: 24 € de volume de negócios e 4,80 € de IVA no exercício em curso (out-nov-dez), e depois 96 € de volume de negócios e 19,20 € de IVA repartidos pelo exercício seguinte. O módulo FEC tem de conseguir gerar estes lançamentos de rendimentos diferidos.

Os vales de oferta e gift cards

Vender um vale de oferta de 50 € não é uma venda: é um compromisso futuro. O lançamento inicial é uma dívida para com o cliente (conta 4419 ou semelhante), não uma venda (707). No momento da utilização do vale, liquida-se a dívida e regista-se a venda. É subtil e 90 % das exportações automáticas enganam-se.

Workflow recomendado: a passagem ao gabinete de contabilidade

A boa prática observada nas lojas que passaram sem problemas a sua última inspeção fiscal:

1. Mapeamento inicial com o gabinete: uma sessão de 2 h com o contabilista para validar as contas utilizadas, os diários e o tratamento dos casos particulares (notas de crédito, comissões do processador, OSS).
2. Exportação mensal: geração do FEC parcial todos os meses, transmitido ao gabinete para reconciliação bancária e integração na contabilidade. Um mês esquecido é um mês a reconstruir.
3. Reconciliação das contas auxiliares: reconciliar cliente a cliente (ou de forma agregada para volumes muito grandes) para identificar as devoluções e notas de crédito não contabilizadas.
4. Encerramento anual: exportação do FEC completo do exercício, validação final pelo contabilista, arquivo cifrado durante 10 anos.
5. Teste de produção: uma vez por ano, simular um pedido de FEC: gerar o ficheiro, verificar que abre no software de controlo fiscal (Test Compta Demat) e que passa as validações.

Custo e ROI

Para uma loja com 2 000 encomendas/ano, a equação económica:

• Módulo FEC: licença WooCommerce de 49 € ou licença PrestaShop de 99 €
• Configuração com o gabinete: 200 a 400 € (mapeamento inicial, parametrização das contas)
• Poupança em serviços contabilísticos: 800 a 1 500 €/ano (reintegração manual evitada)
• Poupança no risco fiscal: não quantificável, mas crítica em caso de inspeção

Payback de 3 a 6 meses só com a poupança contabilística, sem contar a cobertura do risco.

FAQ

O meu contabilista já utiliza um software que importa as minhas encomendas WooCommerce. Preciso de um FEC?

O software de contabilidade produz o seu próprio FEC a partir dos lançamentos que registou. Mas a exportação da sua loja tem de estar limpa a montante para que os lançamentos estejam corretos. Um conector direto WooCommerce → software de contabilidade (tipo Sage, Cegid, Quadra) pode substituir um módulo FEC, mas tem o seu próprio custo (tipicamente mensal) e os seus próprios limites de mapeamento.

Posso manter a contabilidade em Excel e gerar um FEC a partir do Excel?

Legalmente sim, se o Excel respeitar os princípios da contabilidade (nomeadamente a irreversibilidade). Na prática, é o principal escolho: o Excel permite modificar lançamentos passados, o que torna a contabilidade não conforme. A administração não recusa o Excel por princípio, mas exige garantias (exportação PDF com carimbo temporal de cada encerramento mensal, por exemplo). Acima de 100 encomendas/mês, é ingerível.

Qual é o diário certo para as comissões da Stripe/PayPal?

A conta 627 (serviços bancários) com uma subconta por processador (627100 Stripe, 627200 PayPal, 627300 Mollie). O lançamento é feito no diário OD (operações diversas) no momento da transferência líquida do processador para a conta bancária. Alguns contabilistas preferem lançá-lo no diário BQ (banco) com uma linha de comissões: as duas opções são aceites desde que sejam coerentes no exercício.

Como gerir as vendas da Amazon ou do eBay que passam pela minha loja?

Se a encomenda for criada no WooCommerce/PrestaShop (através de um conector de marketplace), a exportação FEC trata-a como uma venda normal, com a conta auxiliar 411 = Amazon/eBay (não o cliente final). As comissões do marketplace vão para uma conta 627 distinta. Se a encomenda nunca estiver no WC/PS (Amazon FBA puro), pertence à contabilidade Amazon em paralelo: o seu gabinete terá então de gerir dois fluxos.

A exportação FEC inclui o imposto sobre as sociedades e o IVA dedutível nas compras?

Não. O FEC produzido por um módulo de e-commerce cobre apenas os lançamentos provenientes do e-commerce (vendas, recebimentos de clientes, comissões do processador). As compras a fornecedores, salários, encargos sociais, imposto sobre as sociedades: tudo isso passa pelo software de contabilidade do gabinete e funde-se com o FEC de e-commerce no FEC final anual.

Em síntese

O FEC não é mais uma exportação. É uma obrigação legal francesa cuja não conformidade abre diretamente a porta à correção fiscal. Um módulo FEC sério substitui 10 a 30 horas de tratamento contabilístico manual por exercício, garante os prazos de produção em caso de inspeção e dá ao gabinete de contabilidade um ficheiro diretamente integrável no seu software.

Para WooCommerce, o módulo DfWoo-FEC gere o mapeamento, a exportação e os casos particulares (HPOS, OSS, refunds). Para PrestaShop, o módulo DataFirefly Accounting Export cobre o multiloja, o multilíngue, a multidivisa e as vendas B2B intracomunitárias.

O reflexo certo em 2026: validar com o seu gabinete o mapeamento contabilístico logo na instalação do módulo, exportar mensalmente e fazer um teste anual de produção do FEC no software oficial de controlo. Uma hora de disciplina mensal que evita semanas de stress em caso de inspeção.

Para passar à ação: as nossas seleções de módulos para uma faturação conforme no PrestaShop e no WooCommerce.