# Accounting Export — Complete Guide

> Overview DataFirefly Accounting Export (dfaccountingexport) generates your PrestaShop accounting entries in eight formats: FEC (French legal requirement, article A-47 A-1 of the French Tax Procedures Code), Sage 100, EBP Compta,…

- Page: <https://www.datafirefly.com/en/documentation/dfaccountingexport/>
- Language: en
- Last updated: 2026-09-17
- Other languages: [fr](https://www.datafirefly.com/documentation/dfaccountingexport/index.md), [es](https://www.datafirefly.com/es/documentation/dfaccountingexport/index.md), [de](https://www.datafirefly.com/de/documentation/dfaccountingexport/index.md), [it](https://www.datafirefly.com/it/documentation/dfaccountingexport/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfaccountingexport/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfaccountingexport/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfaccountingexport/index.md)
- Index: <https://www.datafirefly.com/en/documentation/llms.txt>

## Overview

DataFirefly Accounting Export (`dfaccountingexport`) generates your PrestaShop accounting entries in eight formats: **FEC** (French legal requirement, article A-47 A-1 of the French Tax Procedures Code), **Sage 100**, **EBP Compta**, **Ciel XIMPORT**, **Quadratus ASCFIC**, **Pennylane**, **Tiime** and **Indy**. The module reads paid orders and credit notes within the chosen period, builds journal entries (sales journal VE and credit-note journal AV), automatically splits by VAT rate and produces a file ready to send to your accountant or import into your accounting software.

## Installation

1. In the PrestaShop back office, go to **Modules → Module Manager → Upload a module**.
2. Upload the `dfaccountingexport.zip` file.
3. The module automatically creates the `ps_dfae_export_log` table (export history) and an **Accounting export** tab under the **Orders** menu.

Compatibility: PrestaShop 8.0 to 9.x, PHP 7.4 minimum (8.1+ recommended), multistore supported.

## Configuration

Open **Modules → dfaccountingexport → Configure**. The configuration is organised in panels.

### Journals

- **Sales journal code** (default `VE`) and its label.
- **Credit-note journal code** (default `AV`) and its label.

### Chart of accounts

Default values follow the French General Chart of Accounts. Every number can be changed:

- `411` — Customers (general account root)
- `707` — Sales of goods
- `4457` — Collected VAT
- `708` — Invoiced shipping
- `709` — Discounts and rebates
- Treasury accounts: one account per payment method, configured in the dedicated panel (see the Payments journal section)

**Breakdown mode**: by VAT rate (default), by product category, or none. In rate mode, each rate encountered generates a sub-account: `707000` (20%), `707010` (10%), `707055` (5.5%), `707021` (2.1%). Collected VAT follows the same logic on `4457`.

**Exact accounts per VAT rate** (since 1.2.0): a separate panel lets you force an account number as is for a given rate, for example `707100` for sales at 20% and `445720` for the matching VAT, instead of the automatic suffix. The setting also applies to VAT on shipping at the same rate. Leave the field empty to keep automatic suffixing.

### Customer accounts (since 1.3.0)

The **Customer account handling** setting offers three modes:

- **Single collective account + per-customer auxiliary account** (default): every customer entry is posted to the 411 account configured above, and the per-customer detail goes into the `CompAuxNum` / `CompAuxLib` auxiliary columns, in the form `C000123` for customer 123. This is what most accounting firms expect: one customer account on the balance sheet, payment reconciliation and unpaid invoice follow-up still possible.
- **Single collective account, no auxiliary account**: the 411 account alone, with no auxiliary column. The customer is no longer identifiable in the file.
- **One general account per customer**: `411001`, `411002` and so on, built from the 411 root and the customer ID. This was the behaviour of versions 1.0 to 1.2.

The **Collective account label** field ("Clients" by default) is used as the general account label in both collective modes. It stays constant on purpose: in an FEC, one account number must not carry different labels from one line to the next. The customer name is carried by the auxiliary column instead.

Shops upgrading from an earlier version automatically keep their current behaviour. The former "Customer auxiliary account" setting is converted to _one general account per customer_ if it was enabled, and to _collective account with no auxiliary_ otherwise. No export changes until you pick another mode yourself.

### Options

- **SIREN**: required for the FEC. The regulatory file name is `SIREN + FEC + closing date` (e.g. `123456789FEC20261231.txt`). Without a configured SIREN, the file literally contains the word "SIREN" and is not acceptable for a tax filing.
- **Included order statuses**: by default "Payment accepted" and "Delivered". Tick the statuses your workflow considers bookable.
- **Output encoding**: UTF-8 or ISO-8859-15. Sage, Ciel and Quadratus often prefer ISO; Pennylane, Tiime and the FEC stay UTF-8.

## Generating an export

1. Go to **Orders → Accounting export**.
2. Choose the **period** (start date / end date). The filter applies to the invoice date for orders and the creation date for credit notes.
3. Select the **format** among the eight available.
4. Click **Preview**: the module computes, without generating a file, the order count, journal line count, total debit and total credit. A green banner confirms a perfect balance; a red banner highlights a gap.
5. Click **Export**: the file is generated and downloaded immediately, and the operation is logged in the history.

### Entry logic — sales journal

For each paid order: debit `411` (customer, tax incl.), credit `707xxx` per rate (net sales), credit `4457xxx` per rate (VAT), credit `708` (net shipping) and debit `709` (discounts) where applicable. An automatic rounding adjustment (gap < €0.10) is injected on the VAT account to guarantee the balance — residual VAT cents are a classic of e-commerce exports.

### Entry logic — credit-note journal

`OrderSlip` records within the period generate mirror entries in the AV journal: credit `411`, debit `707xxx`, debit `4457xxx`. Credit notes are included in the global balance check.

## The eight formats in detail

- **FEC** — 18 pipe-separated columns, YYYYMMDD dates, positive amounts with debit/credit direction, UTF-8 without BOM. Compliant with article A-47 A-1 of the French LPF.
- **Sage 100** — Semicolon CSV: Journal;Date;PieceNumber;GeneralAccount;AuxiliaryAccount;Label;Direction;Amount;Currency.
- **EBP Compta** — Tab-separated with debit/credit in separate columns and reconciliation code.
- **Ciel XIMPORT** — 81-character fixed width, 13-character zero-padded amounts.
- **Quadratus ASCFIC** — Fixed width, amounts in whole cents.
- **Pennylane** — Modern CSV, forced UTF-8, decimal point, ISO dates.
- **Tiime** — Semicolon CSV with DD/MM/YYYY dates.
- **Indy** — Simplified CSV for freelancers.

The customer auxiliary account feeds the columns provided by FEC, Sage 100, EBP, Quadratus, Pennylane and Tiime. Ciel XIMPORT and Indy have no such column in their layout: in collective mode without auxiliary, those two formats are the only ones that lose nothing compared to the other modes.

The **Ciel XIMPORT** and **Quadratus ASCFIC** layouts have variants depending on the accounting firm. Have the first file validated by the recipient before going to production.

## Payments journal (since 1.1.1)

Optional and disabled by default. Enable **Generate the payments journal** in the **Treasury accounts per payment method** panel of the configuration.

### Payment method to account mapping

The panel automatically lists your payment modules (installed and found in the order history, with order counts). Enter an account next to each module, for example `580000` cash, `580100` checks, `580200` card, `580300` wire transfers, `580400` PayPal. A field left empty falls back to the **default account**, inherited from the legacy bank account on upgrade.

### Entry logic

Each payment recorded (`ps_order_payment`) within the period generates, in the bank journal (BQ): debit treasury account / credit `411` customer (with the auxiliary account where enabled). The entry date is the **payment date**, not the invoice date: a March order paid in April lands in the April receipts, consistent with your bank statements. Negative amounts (refund transactions) automatically swap the debit/credit direction. The piece reference is `RG` followed by the payment number and the order reference, to ease reconciliation.

## Export history

Every export is logged in the database (`ps_dfae_export_log`): format, period, order and line counts, debit/credit totals, file name, operator, timestamp. The last 20 exports are displayed at the bottom of the export screen.

## FAQ & troubleshooting

### My accountant wants a single 411000 account for every customer, how do I do that?

Set **Customer account handling** to _Single collective account + per-customer auxiliary account_. Every entry is posted to the configured 411 account, and each customer keeps its identification in the auxiliary columns. If your accountant wants no trace of the customer in the file, pick the mode without auxiliary. The change takes effect immediately: simply run the export again for the period concerned, the module recomputes everything on each generation.

### The preview shows a debit/credit gap — what should I do?

A gap above €0.10 usually indicates an order with atypical taxation (custom tax, ecotax, currency rounding). Narrow the period to isolate the faulty order, check its tax configuration, then run the preview again.

### The FEC file is rejected by the DGFiP validation tool

First check that the SIREN is filled in the configuration, then that the exported period matches the fiscal year, and that the encoding stayed UTF-8. If the check concerns account labels, make sure you are in collective mode with a fixed label: a general account whose label changes from one line to the next is flagged as an anomaly. The DGFiP "Test Compta Demat" tool lets you validate the file locally.

### Can I export several formats for the same period?

Yes, without reconfiguring: simply select another format and run the export again. Each generation is logged separately.

### Does the module modify my order data?

No. The module is strictly read-only on orders, invoices and credit notes. Its only database write is the history logging.