Die FEC: das Dokument, das nur im Falle einer Prüfung verlangt, aber am selben Tag vorgelegt werden muss
Die Fichier des Écritures Comptables (FEC, „Datei der Buchungssätze“) ist seit 2014 eine gesetzliche Verpflichtung in Frankreich für jedes Unternehmen, das eine elektronische Buchhaltung führt. 2026 verlangt die französische Steuerverwaltung bei jeder Prüfung eine FEC, die dem Erlass vom 29. Juli 2013 entspricht, und die Nichtvorlage innerhalb der Frist (in der Regel 30 Tage) führt zur Ablehnung der Buchhaltung und zur Schätzung von Amts wegen. Genau dieser Punkt – die Vorlage unter Zeitdruck, ohne die Möglichkeit, die Historie nachzubauen – macht den buchhalterischen Export aus dem E-Commerce kritisch.
Bei den Shops, die wir auditieren, wissen 7 von 10 nicht, wie sie ihre FEC ohne mehrere Tage manueller Eingriffe erstellen sollen. Dabei ist die Rechnung einfach: keine konforme FEC = abgelehnte Buchhaltung = Nachzahlung auf Basis ungefährer, in der Regel für das Unternehmen ungünstiger Zahlen. Für einen WooCommerce- oder PrestaShop-Shop mit 500 K€ Umsatz kann die Differenz zwischen sauberer Buchhaltung und einer Nachzahlung mehrere zehntausend Euro betragen – ohne die Strafen mitzurechnen.
Was eine konforme FEC genau ist
Die FEC ist eine flache Datei (CSV mit Tabulator- oder Pipe-Trennzeichen, UTF-8- oder ASCII-Kodierung), die alle Buchungssätze des Geschäftsjahres in einem normierten Format mit 18 Pflichtspalten enthält:
| # | Spalte | Beschreibung |
|---|---|---|
| 1 | JournalCode |
Journalcode (z. B. VE für Verkäufe, BQ für Bank) |
| 2 | JournalLib |
Journalbezeichnung |
| 3 | EcritureNum |
Chronologische Buchungsnummer |
| 4 | EcritureDate |
Buchungsdatum (YYYYMMDD) |
| 5 | CompteNum |
Kontonummer (französischer Kontenrahmen PCG) |
| 6 | CompteLib |
Kontobezeichnung |
| 7-8 | CompAuxNum / CompAuxLib |
Hilfskonto (Kunde/Lieferant) wenn anwendbar |
| 9 | PieceRef |
Belegreferenz |
| 10 | PieceDate |
Belegdatum |
| 11 | EcritureLib |
Buchungstext |
| 12-13 | Debit / Credit |
Beträge (nur EINEN von beiden verwenden, nie beide) |
| 14 | EcritureLet |
Abstimmung (wenn anwendbar) |
| 15 | DateLet |
Abstimmungsdatum |
| 16 | ValidDate |
Validierungsdatum der Buchung |
| 17-18 | Montantdevise / Idevise |
Betrag in Fremdwährung + Währungscode wenn nicht EUR |
Drei unverrückbare Regeln:
- Eine validierte Buchung darf nicht mehr geändert werden (Kette der Unwiderruflichkeit). Eine Korrektur erfolgt über eine Gegenbuchung, nie über eine Änderung des Originals.
- Soll-Summe = Haben-Summe pro Buchung (buchhalterisches Gleichgewicht).
- Die Buchungsnummern sind im Zeitverlauf streng sequenziell und lückenlos.
Genau am letzten Punkt scheitern 80 % der E-Commerce-Shops: Bestellungen werden in einer Reihenfolge erstellt, in einer anderen bezahlt, später erstattet. Das Mapping zu einer sequenziellen FEC erfordert eine rigorose Normalisierung.
Warum E-Commerce und Buchhaltung sich nicht natürlich verstehen
WooCommerce und PrestaShop führen eine Handelsbasis: Bestellungen, Zahlungen, Rückerstattungen, Gutschriften, Versandkosten. Ein Steuerberater braucht eine Buchhaltungsbasis: ausgeglichene Soll- und Habenbuchungen, codiert nach Konten des PCG (französischer Kontenrahmen).
Die Übersetzung der beiden Modelle erfolgt über sechs Begriffe:
1. Die Konten des französischen Kontenrahmens (PCG)
Ein typischer B2C-Verkauf in Frankreich umfasst:
411xxx– Kundenkonto (Hilfskonto pro Kunde bei geringem Volumen, aggregiert bei hohem Volumen)707000– Warenverkäufe (oder706000für Dienstleistungen)4457xx– vereinnahmte Umsatzsteuer (pro Satz: 20 %, 10 %, 5,5 %, 2,1 %)708500– berechnete Versandkosten (mit eigener Umsatzsteuer)411090oder ähnlich – Zwischenkonto Zahlung (vor dem effektiven Geldeingang)512xxx– Bank (beim Geldeingang)627xxx– Bankgebühren des Zahlungsdienstleisters (Stripe, PayPal)
2. Die Buchungsjournale
Mindestens drei separate Journale:
- VE – Verkäufe: erfasst den Verkauf und die vereinnahmte Umsatzsteuer zum Zeitpunkt der Rechnungsstellung (bezahlte Bestellung)
- BQ – Bank: erfasst den tatsächlichen Geldeingang auf dem Bankkonto
- OD – Verschiedene Operationen: erfasst Gutschriften, Retouren, Gebühren des Zahlungsdienstleisters, Wechselkursdifferenzen
3. Buchungsdatum vs. Zahlungsdatum
Eine am 31. März um 23:59 Uhr bezahlte und von Stripe am 2. April gutgeschriebene Bestellung muss den Verkauf im März verbuchen (Datum des steuerlichen Tatbestands: die Lieferung oder der endgültige Verkauf) und den Geldeingang im April (Datum der effektiven Bank-Gutschrift). Diese Verschiebung ist die Hauptursache für Fehler bei naiven E-Commerce-Exporten.
4. Umgang mit der Umsatzsteuer
Drei praktische Fälle:
- Verkauf in Frankreich: vereinnahmte Umsatzsteuer zum anwendbaren französischen Satz
- Innergemeinschaftlicher B2B-Verkauf mit gültiger USt-IdNr.: Umsatzsteuer zu 0 % mit Hinweis „Steuerschuldnerschaft des Leistungsempfängers“, Meldung in DEB und DES
- Innergemeinschaftlicher B2C-Verkauf (OSS-IOSS seit 2021): Umsatzsteuer zum Satz des Bestimmungslands, sobald die Schwelle von 10.000 €/Jahr EU überschritten wird, Meldung über das OSS-One-Stop-Shop-Portal
Das OSS-IOSS ist die Falle, die 60 % der Multi-Country-Shops in die Nichtkonformität kippen lässt. Es ist kein Standard-FEC-Export: Es braucht ein eigenes Journal pro Bestimmungsland oder separate 4457-Konten pro anwendbarem Satz.
5. Retouren und Gutschriften
Eine Kundenretoure generiert eine Gutschrift (negative Rechnung) UND eine Erstattungsbuchung. Beide müssen getrennt in der FEC erscheinen, mit der PieceRef-Rückverfolgbarkeit, die auf die Ursprungsbestellung verweist. Eine Retoure als „Stornierung“ der ursprünglichen Buchung zu erfassen, ist nicht konform: Das bricht die Kette der Unwiderruflichkeit.
6. Die Gebühren des Zahlungsdienstleisters
Eine über Stripe bezahlte Bestellung von 100 € erbringt tatsächlich etwa 97,10 € auf dem Bankkonto (Stripe-Gebühren: 1,4 % + 0,25 € für eine EU-Karte). Die 2,90 € Differenz gehen auf das Konto 627 (Bankdienstleistungen). Ohne diese Aufteilung ist der Bankabgleich unmöglich.
Warum die nativen E-Commerce-Exporte nicht ausreichen
WooCommerce und PrestaShop verfügen über native CSV-Exporte der Bestellungen. Diese Exporte sind keine FEC, aus fünf Gründen:
- Kein Konzept eines Buchungsjournals – Eine Zeile = eine Bestellung, keine Soll-/Haben-Buchung.
- Keine Aufteilung nach PCG-Konten – Die Beträge netto, Umsatzsteuer, Versand sind nicht den Konten 707, 4457, 708 zugeordnet.
- Kein Management der Buchungssequenzialität – Keine kontinuierliche
EcritureNum. - Keine Trennung Verkauf/Geldeingang – Zahlungsdatum und Validierungsdatum werden vermengt.
- Keine Behandlung von Retouren, Gutschriften und Dienstleistergebühren – Diese Operationen werden ignoriert oder sind inkohärent.
Praktische Folge: Der Steuerberater erhält einen Excel-Export und verbringt 8 bis 12 Stunden pro Geschäftsjahr damit, die Buchungen manuell nachzubauen. Bei einem Shop mit 2.000 Bestellungen/Jahr sind das zwischen 1.200 und 1.800 € zusätzliche Buchhalterleistung. Bei einem Shop mit 20.000 Bestellungen/Jahr lehnt der Steuerberater entweder das Mandat ab oder berechnet 4.000 bis 6.000 € für die Wiedereingliederung.
Die Architektur eines sauberen FEC-Exports
Ein seriöses FEC-Modul für WooCommerce oder PrestaShop implementiert fünf Schichten:
Schicht 1 – Konten-Mapping
Der Admin konfiguriert das Mapping zwischen den E-Commerce-Entitäten und den PCG-Konten:
- Produktkategorie → Konto 707/706 (Warenverkäufe vs. Dienstleistungen)
- Versandmethode → Konto 708 (Versand) oder 706 (Dienstleistung)
- Umsatzsteuersatz → Konto 4457 (4457100, 4457200, 4457550, etc.)
- Zahlungsmethode → Zwischenkonto 411090, dann 512 Bank oder 512x Unterkonto pro Dienstleister
- Dienstleistergebühren → Konto 627 (mit Unterkonten Stripe, PayPal, Mollie)
Schicht 2 – Buchungsgenerierung
Für jede Bestellung im Zeitraum generiert das Modul 3 bis 8 unterschiedliche Buchungen:
- Verkauf netto (Soll 411 Kunde, Haben 707 Verkäufe)
- Vereinnahmte Umsatzsteuer (Haben 4457 pro Satz)
- Versand (Haben 708 oder 706)
- Geldeingang (Soll 512 Bank, Haben 411 Kunde) mit Datumsverschiebung
- Dienstleistergebühren (Soll 627, Haben 512) als separate Buchung
Für eine Gutschrift werden Gegenbuchungen generiert, nie eine Änderung der Originale.
Schicht 3 – Stabile sequenzielle Nummerierung
Die EcritureNum wird beim Export entsprechend einem global persistenten Zähler vergeben, der zu jedem Geschäftsjahr neu startet. Einmal exportiert, behält eine Buchung ihre Nummer lebenslang. Das Modul muss diesen Zustand speichern, um bei der Regenerierung nie neu zu nummerieren.
Schicht 4 – Validierung und Kontrollen
Vor dem Export prüft das Modul:
- Soll-/Haben-Gleichgewicht pro Buchung (Differenz ≤ 0,01 €)
- Kontinuität der
EcritureNum(keine Lücken, keine Doppler) - Formatkonformität (Kodierung, Trennzeichen, Datumsformat YYYYMMDD)
- Vorhandensein aller Pflichtspalten
- Buchhalterische Kohärenz (die verwendeten Konten existieren im konfigurierten PCG)
Schicht 5 – Export und Signatur
Die endgültige Datei wird im gesetzlichen Format produziert (TXT mit Pipe- oder Tabulator-Trennzeichen, UTF-8 oder ASCII), mit normiertem Namen: SIREN+FEC+Geschäftsjahresende.txt (z. B. 123456789FEC20251231.txt). Einige Module berechnen zusätzlich einen SHA-256-Hash für die interne Rückverfolgbarkeit.
Die rechtlichen Fallstricke, die nicht zu unterschätzen sind
1. Die Aufbewahrungsfrist
Die FEC und alle Belege (Rechnungen, Gutschriften, Bankbelege) müssen 10 Jahre ab dem Abschluss des Geschäftsjahres aufbewahrt werden (Artikel L.123-22 des französischen Handelsgesetzbuchs). Bei einem E-Commerce-Shop schließt das die SQL-Exports der Datenbank, die PDF-Rechnungen und die Zahlungs-Logs des Dienstleisters ein. Die Backup-Strategie muss diese lange Retention abdecken: siehe unseren Artikel zur PrestaShop-Sicherung nach der 3-2-1-Regel.
2. Die Buchhaltung muss chronologisch geführt werden
Artikel 921-2 des PCG: „Der definitive Charakter der Aufzeichnungen […] wird durch ein Validierungsverfahren gewährleistet, das jede Änderung oder Löschung der Aufzeichnung verbietet.“ Ein FEC-Modul, das es erlaubt, ein abgeschlossenes Geschäftsjahr „neu zu generieren“, ist nicht konform. Sobald das Geschäftsjahr vom Steuerberater abgeschlossen ist, ist die FEC eingefroren.
3. Schätzung von Amts wegen bei Nichtvorlage
Wird die FEC nicht innerhalb der Frist der Prüfung vorgelegt (in der Regel 30 Tage nach Aufforderung), kann die Verwaltung die Buchhaltung ablehnen und eine Schätzung auf von ihr geschätzten Grundlagen vornehmen. Die Strafen können 5.000 € erreichen (Artikel 1729 D des CGI) + 0,5 % des Umsatzes pro Monat der Verspätung.
4. DSGVO und Buchhaltungsdaten – die Spannung mit dem Recht auf Vergessenwerden
Artikel 17 der DSGVO erlaubt es einem Kunden, die Löschung seiner Daten zu verlangen. Aber die Buchhaltungspflicht schreibt 10 Jahre Aufbewahrung vor. Die juristische Auflösung: Man bewahrt die für die gesetzliche Pflicht notwendigen Daten (Name, Rechnungsadresse, Beträge) auf und löscht den Rest (Präferenzen, Browser-Historie, Marketing). Genau dieses Thema behandeln wir morgen im Artikel über das DSGVO-Recht auf Vergessenwerden ohne Bruch der steuerlichen Spur.
WooCommerce und PrestaShop: zwei Implementierungslogiken
WooCommerce – die französische Besonderheit
WooCommerce ist für den US-Markt konzipiert, wo die FEC nicht existiert. Der französische Buchhaltungsexport erfordert daher ein Drittanbieter-Plugin, das die WC-Bestellungen, ihre Items, ihre Steuern (über das System wc_tax_rate) lesen kann und das die Payment Gateways auf die Bankkonten mappen kann. Das DfWoo-FEC-Modul implementiert diese Logik mit konfigurierbarem Mapping, der HPOS-Verwaltung (High-Performance Order Storage) und nativer Unterstützung der WC-Refunds.
PrestaShop – der Vorteil der nativen Umsatzsteuer
PrestaShop, ursprünglich in Frankreich konzipiert, verwaltet die Umsatzsteuersätze, die Kundenhilfskonten, die sequenziellen Rechnungen und Gutschriften (ps_order_invoice, ps_order_slip) nativ. Die Aufgabe des FEC-Moduls ist daher einfacher: die Invoices und Slips in Buchungssätze umzuwandeln, ohne die Umsatzsteuern neu berechnen zu müssen. Das DataFirefly-Accounting-Export-Modul implementiert diese Logik mit Unterstützung für Multishop, Multilingual und Multidevise.
Im Export zu behandelnde Sonderfälle
B2B-Bestellungen mit innergemeinschaftlicher Umsatzsteuer
Wenn ein deutscher Kunde mit einer gültigen EU-USt-IdNr. kauft, beträgt die französische Umsatzsteuer 0 %. Die Buchung muss dies explizit widerspiegeln, mit dem Hinweis „Steuerschuldnerschaft des Leistungsempfängers“, und der Betrag muss die DEB (Erklärung des Warenverkehrs) und die DES (europäische Dienstleistungserklärung) speisen. Ein Modul, das diese Verkäufe als französisches B2C behandelt, ist nicht konform.
Das OSS-IOSS für EU-B2C
Seit Juli 2021 erfordern EU-B2C-Verkäufe ab kumuliert 10.000 €/Jahr die Umsatzsteuer des Bestimmungslands. Die FEC muss ein 4457-Konto pro Land/Satz ausweisen (z. B. 4457DE19 für deutsche Umsatzsteuer 19 %, 4457IT22 für italienische 22 %). Ohne diese Aufteilung ist die vierteljährliche OSS-Meldung unmöglich.
Abos und zeitlich verteilte Umsatzsteuer
Bei einem Shop mit Abos wird die Umsatzsteuer im Verhältnis zur Leistung geschuldet. Ein am 15. Oktober abgeschlossenes Jahresabo zu 120 € generiert: 24 € Umsatz und 4,80 € Umsatzsteuer im laufenden Geschäftsjahr (Okt-Nov-Dez), dann 96 € Umsatz und 19,20 € Umsatzsteuer verteilt auf das folgende Geschäftsjahr. Das FEC-Modul muss diese Buchungen für passive Rechnungsabgrenzungen erzeugen können.
Geschenkgutscheine und Gift Cards
Einen Geschenkgutschein über 50 € zu verkaufen, ist kein Verkauf – es ist eine zukünftige Verpflichtung. Die Ausgangsbuchung ist Schuld gegenüber dem Kunden (Konto 4419 oder ähnlich), kein Verkauf (707). Bei Einlösung des Gutscheins wird die Schuld ausgeglichen und der Verkauf erfasst. Es ist subtil und 90 % der automatischen Exporte machen es falsch.
Empfohlener Workflow: die Übergabe an den Steuerberater
Die bewährte Praxis bei Shops, die ihre letzte Steuerprüfung problemlos überstanden haben:
- Initiales Mapping mit dem Steuerberater – Eine 2-stündige Sitzung mit dem Steuerberater, um die verwendeten Konten, die Journale und die Behandlung der Sonderfälle (Gutschriften, Dienstleistergebühren, OSS) zu validieren.
- Monatlicher Export – Generierung der partiellen FEC jeden Monat, übermittelt an den Steuerberater für den Bankabgleich und die Integration in die Buchhaltung. Ein vergessener Monat ist ein Monat, der nachgebaut werden muss.
- Abstimmung der Hilfskonten – Kunde für Kunde abstimmen (oder aggregiert bei sehr großen Volumen), um nicht verbuchte Retouren und Gutschriften zu identifizieren.
- Jahresabschluss – Export der vollständigen FEC des Geschäftsjahres, endgültige Validierung durch den Steuerberater, verschlüsselte Archivierung für 10 Jahre.
- Produktionstest – Einmal pro Jahr eine FEC-Anforderung simulieren: die Datei generieren, prüfen, dass sie in der Steuerprüfsoftware (Test Compta Demat) öffnet und die Validierungen besteht.
Kosten und ROI
Für einen Shop mit 2.000 Bestellungen/Jahr die wirtschaftliche Gleichung:
- FEC-Modul: 49 € WooCommerce-Lizenz oder 99 € PrestaShop-Lizenz
- Setup mit dem Steuerberater: 200 bis 400 € (initiales Mapping, Konteneinrichtung)
- Einsparung bei der Buchhalterleistung: 800 bis 1.500 €/Jahr (vermiedene manuelle Wiedereingliederung)
- Einsparung beim Steuerrisiko: nicht bezifferbar, aber kritisch im Prüfungsfall
Payback von 3 bis 6 Monaten allein durch die Buchhaltungs-Einsparung, ohne die Risikoabdeckung mitzurechnen.
FAQ
Mein Steuerberater nutzt bereits eine Software, die meine WooCommerce-Bestellungen importiert. Brauche ich eine FEC?
Die Buchhaltungssoftware erzeugt ihre eigene FEC aus den Buchungen, die sie erfasst hat. Aber der Export aus Ihrem Shop muss vorher sauber sein, damit die Buchungen korrekt sind. Ein direkter Konnektor WooCommerce → Buchhaltungssoftware (Sage, Cegid, Quadra-Typ) kann ein FEC-Modul ersetzen, hat aber seine eigenen Kosten (typischerweise monatlich) und seine eigenen Mapping-Grenzen.
Kann ich meine Buchhaltung in Excel führen und eine FEC aus Excel erzeugen?
Rechtlich ja, wenn Excel die Buchhaltungsprinzipien einhält (insbesondere die Unwiderruflichkeit). In der Praxis ist das der Hauptknackpunkt: Excel erlaubt es, vergangene Buchungen zu ändern, was die Buchhaltung nicht konform macht. Die Verwaltung lehnt Excel nicht grundsätzlich ab, verlangt aber Garantien (z. B. zeitgestempelter PDF-Export jedes Monatsabschlusses). Ab 100 Bestellungen/Monat ist das nicht mehr handhabbar.
Welches Journal eignet sich für Stripe-/PayPal-Gebühren?
Das Konto 627 (Bankdienstleistungen) mit einem Unterkonto pro Dienstleister (627100 Stripe, 627200 PayPal, 627300 Mollie). Die Buchung erfolgt im OD-Journal (verschiedene Operationen) zum Zeitpunkt der Netto-Überweisung des Dienstleisters auf das Bankkonto. Einige Berater bevorzugen das BQ-Journal (Bank) mit einer Gebührenzeile – beides ist akzeptiert, solange es im Geschäftsjahr kohärent bleibt.
Wie verwaltet man Amazon- oder eBay-Verkäufe, die über meinen Shop laufen?
Wenn die Bestellung in WooCommerce/PrestaShop (über einen Marketplace-Konnektor) erstellt wird, behandelt der FEC-Export sie als normalen Verkauf, mit dem Hilfskonto 411 = Amazon/eBay (nicht der Endkunde). Die Marketplace-Gebühren gehen auf ein eigenes 627-Konto. Wenn die Bestellung nie in WC/PS ist (reines Amazon FBA), fällt sie in die parallele Amazon-Buchhaltung – Ihr Steuerberater muss dann zwei Flüsse verwalten.
Umfasst der FEC-Export die Körperschaftsteuer und die abziehbare Vorsteuer auf Käufe?
Nein. Die von einem E-Commerce-Modul produzierte FEC deckt nur die aus dem E-Commerce stammenden Buchungen ab (Verkäufe, Geldeingänge von Kunden, Dienstleistergebühren). Lieferantenkäufe, Gehälter, Sozialabgaben, Körperschaftsteuer – all das läuft über die Buchhaltungssoftware des Steuerberaters und verschmilzt mit der E-Commerce-FEC in der jährlichen Gesamt-FEC.
Zusammenfassend
Die FEC ist nicht einfach ein weiterer Export. Sie ist eine französische gesetzliche Verpflichtung, deren Nichtkonformität direkt die Tür zur Steuernachzahlung öffnet. Ein seriöses FEC-Modul ersetzt 10 bis 30 Stunden manuelle Buchhaltungs-Wiederaufbereitung pro Geschäftsjahr, sichert die Produktionsfristen im Prüfungsfall und liefert dem Steuerberater eine direkt in seine Software integrierbare Datei.
Für WooCommerce verwaltet das DfWoo-FEC-Modul das Mapping, den Export und die Sonderfälle (HPOS, OSS, Refunds). Für PrestaShop deckt das DataFirefly-Accounting-Export-Modul Multishop, Multilingual, Multidevise und innergemeinschaftliche B2B-Verkäufe ab.
Der gute Reflex 2026: das Buchhaltungs-Mapping mit dem Steuerberater bereits bei der Installation des Moduls validieren, monatlich exportieren und einen jährlichen FEC-Produktionstest mit der offiziellen Prüfsoftware durchführen. Eine Stunde monatlicher Disziplin, die im Prüfungsfall Wochen voller Stress erspart.