E-commerce News

FEC and E-Commerce Accounting Export 2026: The French Tax Compliance 80% of Stores Miss

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

The FEC: a document only requested in case of audit, but that must be produced the same day

The FEC (Fichier des Écritures Comptables, French Accounting Entries File) is a French legal obligation since 2014 for any business keeping computerised accounts. In 2026, the French tax administration requests a FEC compliant with the decree of 29 July 2013 during any audit, and failure to produce within the deadline (typically 30 days) results in rejection of the accounts and ex-officio taxation. It’s this exact point — production under constrained deadline, without being able to redo the history — that makes accounting export from e-commerce critical.

This article applies primarily to French-incorporated stores using WooCommerce or PrestaShop, but the principles (clean accounting export, mapping to a national chart of accounts, separation of sale and payment dates, OSS-IOSS handling) are transposable to most European jurisdictions. Among the stores we audit, 7 out of 10 don’t know how to produce their FEC without manual intervention spanning several days. Yet the calculation is simple: no compliant FEC = rejected accounts = reassessment based on approximate figures, generally unfavourable to the business. For a WooCommerce or PrestaShop store generating €500K in revenue, the gap between clean accounts and a reassessment can reach several tens of thousands of euros — not counting penalties.

What a compliant FEC actually is

The FEC is a flat file (CSV with tab or pipe separator, UTF-8 or ASCII encoding) containing all accounting entries for the fiscal year, in a standardised format of 18 mandatory columns:

# Column Description
1 JournalCode Journal code (e.g. VE for sales, BQ for bank)
2 JournalLib Journal label
3 EcritureNum Chronological entry number
4 EcritureDate Posting date (YYYYMMDD)
5 CompteNum Account number (General Chart of Accounts / PCG)
6 CompteLib Account label
7-8 CompAuxNum / CompAuxLib Auxiliary account (customer/supplier) if applicable
9 PieceRef Supporting document reference
10 PieceDate Document date
11 EcritureLib Entry description
12-13 Debit / Credit Amounts (use only one OR the other, never both)
14 EcritureLet Reconciliation (if applicable)
15 DateLet Reconciliation date
16 ValidDate Entry validation date
17-18 Montantdevise / Idevise Foreign currency amount + currency code if not EUR

Three immutable rules:

  • A validated entry can no longer be modified (irreversibility chain). A correction goes through a reverse entry, never through modification of the original.
  • Total debit = total credit on each entry (accounting balance).
  • Entry numbers are strictly sequential and continuous over time.

It’s this last point that fails on 80% of e-commerce stores: orders are created in one order, paid in another, refunded later. Mapping to a sequential FEC requires rigorous normalisation.

Why e-commerce and accounting don’t naturally agree

WooCommerce and PrestaShop maintain a commercial database: orders, payments, refunds, credit notes, shipping costs. An accountant needs an accounting database: balanced debit and credit entries, coded by PCG (General Chart of Accounts) account.

Translation of the two models goes through six concepts:

1. PCG account numbers

A typical B2C sale in France mobilises:

  • 411xxx — Customer account (auxiliary per customer if low volume, aggregated if high volume)
  • 707000 — Sales of goods (or 706000 for services)
  • 4457xx — Collected VAT (per rate: 20%, 10%, 5.5%, 2.1%)
  • 708500 — Shipping charged (with its own VAT)
  • 411090 or similar — Payment suspense account (before actual collection)
  • 512xxx — Bank (upon collection)
  • 627xxx — Processor banking fees (Stripe, PayPal)

2. Accounting journals

At minimum three distinct journals:

  • VE — Sales: records the sale and collected VAT at invoicing time (paid order)
  • BQ — Bank: records actual collection in the bank account
  • OD — Miscellaneous operations: records credit notes, returns, processor fees, exchange differences

3. Posting date vs payment date

An order paid 31 March at 23:59 and collected by Stripe on 2 April must record the sale in March (tax-generating event date: delivery or definitive sale) and the collection in April (effective bank credit date). This lag is the main cause of errors in naive e-commerce exports.

4. VAT handling

Three practical cases:

  • France sale: VAT collected at applicable French rate
  • Intra-community B2B sale with valid VAT number: VAT at 0% with “reverse charge” mention, declaration on the DEB and DES
  • Intra-community B2C sale (OSS-IOSS since 2021): VAT at destination country rate if the €10,000/year EU threshold is exceeded, declaration via the OSS one-stop-shop

OSS-IOSS is the pitfall that tips 60% of multi-country stores into non-compliance. It’s not a standard FEC export: you need a separate journal per destination country, or distinct 4457 accounts per applicable rate.

5. Returns and credit notes

A customer return generates a credit note (negative invoice) AND a refund entry. Both must appear separately in the FEC, with PieceRef traceability pointing to the original order. Accounting for a return as a “cancellation” of the initial entry is non-compliant: it breaks the irreversibility chain.

6. Processor fees

An order of €100 paid via Stripe actually credits about €97.10 to the bank account (Stripe fees: 1.4% + €0.25 for an EU card). The €2.90 difference goes to account 627 (banking services). Without this split, bank reconciliation is impossible.

Why native e-commerce exports aren’t enough

WooCommerce and PrestaShop have native CSV exports of orders. These exports are not a FEC, for five reasons:

  1. No notion of accounting journal — One line = one order, not a debit/credit entry.
  2. No split by PCG account — Ex-tax, VAT, shipping amounts aren’t mapped to accounts 707, 4457, 708.
  3. No handling of entry sequentiality — No continuous EcritureNum.
  4. No separation of sale/collection — Payment date and validation date are confused.
  5. No processing of returns, credit notes and processor fees — These operations are ignored or inconsistent.

Practical result: the accountant receives an Excel export and spends 8 to 12 hours per fiscal year manually rebuilding the entries. On a store with 2,000 orders/year, that’s between €1,200 and €1,800 of additional accounting fees. On a store with 20,000 orders/year, the accountant either refuses the case or charges €4,000-6,000 for re-integration.

The architecture of a clean FEC export

A serious FEC module for WooCommerce or PrestaShop implements five layers:

Layer 1 — Account mapping

The admin configures the mapping between e-commerce entities and PCG accounts:

  • Product category → account 707/706 (goods sales vs services)
  • Shipping method → account 708 (shipping) or 706 (service)
  • VAT rate → account 4457 (4457100, 4457200, 4457550, etc.)
  • Payment method → suspense account 411090, then bank 512 or sub-account 512x per processor
  • Processor fees → account 627 (with sub-accounts Stripe, PayPal, Mollie)

Layer 2 — Entry generation

For each order in the period, the module generates 3 to 8 distinct entries:

  • Sale ex-tax (debit 411 customer, credit 707 sales)
  • Collected VAT (credit 4457 per rate)
  • Shipping (credit 708 or 706)
  • Collection (debit 512 bank, credit 411 customer) with date offset
  • Processor fees (debit 627, credit 512) as separate entry

For a credit note, reverse entries are generated, never modification of originals.

Layer 3 — Stable sequential numbering

The EcritureNum is assigned at export time according to a persistent global counter, reset each fiscal year. Once exported, an entry keeps its number for life. The module must store this state to never re-number on regeneration.

Layer 4 — Validation and controls

Before export, the module checks:

  • Debit/credit balance per entry (difference ≤ €0.01)
  • Continuity of EcritureNum (no gap or duplicate)
  • Format compliance (encoding, separator, YYYYMMDD dates)
  • Presence of all mandatory columns
  • Accounting consistency (accounts used exist in the configured PCG)

Layer 5 — Export and signature

The final file is produced in the legal format (TXT with pipe or tab separator, UTF-8 or ASCII), with a standardised name: SIREN+FEC+fiscal_year_end_date.txt (e.g. 123456789FEC20251231.txt). Some modules additionally compute a SHA-256 hash for internal traceability.

1. Retention period

The FEC and all supporting documents (invoices, credit notes, bank vouchers) must be retained for 10 years from the fiscal year close (article L.123-22 of the French Commercial Code). For an e-commerce store, this includes database SQL exports, PDF invoices, and processor payment logs. Backup strategy must cover this long retention: see our article on PrestaShop 3-2-1 rule backup.

2. Accounting must be chronological

Article 921-2 of the PCG: “the definitive nature of records […] is ensured by a validation procedure that prevents any modification or deletion of the record”. A FEC module that allows “re-generating” a closed fiscal year is non-compliant. Once the fiscal year is closed by the accountant, the FEC is frozen.

3. Ex-officio taxation in case of non-production

If the FEC isn’t produced within the audit deadline (typically 30 days after the request), the administration can reject the accounts and proceed with ex-officio taxation on bases it estimates. Penalties can reach €5,000 (article 1729 D of the General Tax Code) + 0.5% of revenue per month of delay.

4. GDPR and accounting data — the tension with right to erasure

GDPR article 17 allows a customer to request data deletion. But the accounting obligation requires 10 years retention. The legal resolution: retain data necessary for the legal obligation (name, billing address, amounts) and delete the rest (preferences, browsing history, marketing). That’s the precise topic of our article on the GDPR right to erasure without breaking the tax trace.

WooCommerce and PrestaShop: two implementation logics

WooCommerce — the French specificity

WooCommerce is designed for the US market, where the FEC doesn’t exist. French accounting export therefore requires a third-party plugin that knows how to read WC orders, their items, their taxes (via the wc_tax_rate system), and how to map payment gateways to bank accounts. The DfWoo-FEC module implements this logic with configurable mapping, HPOS (High-Performance Order Storage) handling, and native support for WC refunds.

PrestaShop — the advantage of native VAT

PrestaShop, originally designed in France, natively handles VAT rates, customer auxiliary accounts, sequential invoices and credit notes (ps_order_invoice, ps_order_slip). The FEC module’s work is therefore simpler: transform invoices and slips into accounting entries, without having to recalculate VAT. The DataFirefly Accounting Export module implements this logic with multishop, multilingual, multi-currency support.

Special cases to handle in export

B2B orders with intra-community VAT

When a German customer with a valid EU VAT number purchases, French VAT is at 0%. The entry must explicitly reflect this, with “reverse charged by the buyer” mention, and the amount must feed the DEB (declaration of trade in goods) and DES (European service declaration). A module treating these sales as French B2C is non-compliant.

OSS-IOSS for B2C EU

Since July 2021, EU B2C sales above €10,000/year cumulative require destination country VAT. The FEC must show a 4457 account per country/rate (e.g. 4457DE19 for Germany VAT 19%, 4457IT22 for Italy 22%). Without this split, quarterly OSS declaration is impossible.

Subscriptions and temporal VAT

For a subscription store, VAT is due pro-rata to the service. An annual subscription at €120 taken on 15 October generates: €24 revenue and €4.80 VAT for the current fiscal year (Oct-Nov-Dec), then €96 revenue and €19.20 VAT spread over the following year. The FEC module must be able to generate these prepaid revenue entries.

Gift cards and vouchers

Selling a €50 gift voucher isn’t a sale — it’s a future commitment. The initial entry is a debt to the customer (account 4419 or similar), not sale (707). When the voucher is used, the debt is cleared and the sale recorded. It’s subtle and 90% of automatic exports get it wrong.

Best practice observed on stores that have passed their latest tax audit without trouble:

  1. Initial mapping with the firm — A 2-hour session with the accountant to validate accounts used, journals, and handling of special cases (credit notes, processor fees, OSS).
  2. Monthly export — Generation of partial FEC each month, transmitted to the firm for bank reconciliation and accounting integration. A forgotten month is a month to rebuild.
  3. Auxiliary account reconciliation — Reconcile customer by customer (or in aggregate for very high volumes) to identify uncomptabilised returns and credit notes.
  4. Annual close — Export of complete fiscal year FEC, final validation by the accountant, encrypted archiving for 10 years.
  5. Production test — Once a year, simulate a FEC request: generate the file, verify it opens in the official tax control software (Test Compta Demat), and that it passes validations.

Cost and ROI

For a store with 2,000 orders/year, the economic equation:

  • FEC module: €49 WooCommerce licence or €99 PrestaShop licence
  • Setup with firm: €200 to €400 (initial mapping, account parameterisation)
  • Savings on accounting fees: €800 to €1,500/year (manual re-integration avoided)
  • Savings on tax risk: not quantifiable but critical in case of audit

Payback of 3 to 6 months on accounting savings alone, not counting risk coverage.

FAQ

My accountant already uses software that imports my WooCommerce orders. Do I need a FEC?

The accounting software produces its own FEC from the entries it has recorded. But the export from your store must be clean upstream for entries to be correct. A direct WooCommerce → accounting software connector (Sage, Cegid, Quadra type) can replace a FEC module, but it has its own cost (typically monthly) and its own mapping limits.

Can I keep my accounts in Excel and generate a FEC from Excel?

Legally yes, if Excel respects accounting principles (irreversibility notably). In practice, that’s the main pitfall: Excel allows modifying past entries, which makes accounts non-compliant. The administration doesn’t refuse Excel in principle but requires guarantees (timestamped PDF export of each monthly close, for example). Beyond 100 orders/month, it’s unmanageable.

What’s the right journal for Stripe/PayPal fees?

Account 627 (banking services) with a sub-account per processor (627100 Stripe, 627200 PayPal, 627300 Mollie). The entry goes to the OD journal (miscellaneous operations) when the processor’s net payout reaches the bank account. Some accountants prefer the BQ (bank) journal with a fee line — both are accepted as long as it’s consistent within the fiscal year.

How to handle Amazon or eBay sales transiting through my store?

If the order is created in WooCommerce/PrestaShop (via a marketplace connector), the FEC export treats it as a normal sale, with auxiliary account 411 = Amazon/eBay (not the end customer). Marketplace fees go to a separate 627. If the order is never in WC/PS (pure Amazon FBA), it falls under Amazon’s accounting in parallel — your firm must then handle two flows.

Does the FEC export include corporate income tax and deductible VAT on purchases?

No. The FEC produced by an e-commerce module only covers entries from e-commerce (sales, customer collections, processor fees). Supplier purchases, salaries, social charges, IS — all of that goes through the firm’s accounting software and merges with the e-commerce FEC into the annual final FEC.

In summary

The FEC isn’t just another export. It’s a French legal obligation whose non-compliance directly opens the door to tax reassessment. A serious FEC module replaces 10 to 30 hours of manual accounting reprocessing per fiscal year, secures production deadlines in case of audit, and gives the accounting firm a file directly integrable into its software.

For WooCommerce, the DfWoo-FEC module handles mapping, export, and special cases (HPOS, OSS, refunds). For PrestaShop, the DataFirefly Accounting Export module covers multishop, multilingual, multi-currency and intra-community B2B sales.

The right reflex in 2026: validate accounting mapping with your firm as soon as the module is installed, export monthly, and do an annual production test of the FEC in the official control software. An hour of monthly discipline that avoids weeks of stress in case of audit.