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, 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.

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.

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.