CESOP in France: art. 286 sexies CGI filing to the DGFiP

France’s CESOP return goes to the DGFiP under Article 286 sexies of the Code général des impôts, and most first files fail on packaging, not on payment data. The French tax administration does not accept a plain XML upload. It wants the file zipped, encrypted with its own public key, named to a fixed pattern and deposited through PASSTRANS from the professional area of impots.gouv.fr, against a SIREN chosen at upload. Providers with no SIREN need a substitute identifier first. This piece covers the legal basis, enrolment, the packaging chain, the two status messages, the French-only checks and four cases from practice.

1. The legal basis

Council Directive (EU) 2020/284 inserted the payment-data duties into the VAT Directive, and Council Regulation (EU) 2020/283 created CESOP, the Commission’s central database. France transposed the Directive through Article 286 sexies of the CGI, in force since 1 January 2024. The detailed content of the records is set by Decree no. 2023-1149 of 6 December 2023, issued for the application of that article.

The rule itself follows the EU text. A payment service provider must keep records of, and report, cross-border payments to any beneficiary that receives more than 25 cross-border payments in a calendar quarter. The count runs per beneficiary, and where the payer’s provider and the beneficiary’s provider are both in the EU, the duty to report sits with the beneficiary’s side. The file for each quarter is due by the end of the following month: 30 April, 31 July, 31 October and 31 January.

The operational rules sit in the DGFiP’s cahier des charges CESOP, the technical specification for Article 286 sexies. The current edition is version 1.90 of 8 July 2025. It tracks each Commission release of the CESOP schema and the Commission’s XSD User Guide, and it adds national rules that the EU validation module does not check.

2. Who files with the DGFiP

The specification addresses every professional subject to Article 286 sexies. In practice that covers two groups of providers:

• French providers — credit institutions, payment institutions and e-money institutions authorised in France, filing for the services France is the home Member State for.
• Non-resident providers — firms authorised in another Member State but providing payment services in France, for example under a European passport. The specification has a dedicated enrolment route for them, described in section 4.

A passported firm therefore deals with two tax administrations for the same quarter: its home authority for the home-state file, and the DGFiP for the French leg. The two files are separate messages, with separate identifiers and separate status messages.

3. Enrolment: espace professionnel and the CESOP service

Filing starts in the espace professionnel on impots.gouv.fr. A provider that already has one for other French tax obligations reuses it. Otherwise it creates one through the online enrolment page. Once the account exists, the provider subscribes to the service “Déclarer > Paiements transfrontaliers – CESOP”.

The subscription is made per SIREN. If one professional account files for several companies — a group shared-service team, for example — it must subscribe to the service once for each SIREN. At upload, the filer chooses the SIREN the deposit is for. That choice, not the PSPId in the XML, drives the status messages: the specification says the DGFiP ignores the SIREN or BIC in the SendingPSP and ReportingPSP tags when it routes the response.

From the service the filer is redirected to PASSTRANS, the DGFiP’s file-transfer application, and deposits the file over HTTPS. Status messages come back into the same PASSTRANS space under “Transfert > Fichiers reçus”. They stay there for 45 days, and an e-mail alert goes to the address linked to the depositing account.

4. Providers without a SIREN: the IDSP route

A provider registered outside France has no SIREN and cannot open a professional account. The specification solves this with an IDSP (identifiant de substitution provisoire), a provisional substitute identifier that stands in for the SIREN. The request goes by e-mail to the registration unit of the SIEE at the DINR, the DGFiP’s directorate for non-residents, with:

• form EE0 (cerfa 15928*04), completed and signed, with a current company e-mail address, and the activity box stating that the firm is a payment service provider that must report cross-border payment transactions;
• a copy of the company’s registration in its home country — the specification lists examples such as a Handelsregister extract, a Registro Mercantil certificate or a Dutch Chamber of Commerce extract;
• a copy of the articles of association, with a translation of the main elements;
• a mandate completed and signed by both parties.

With the IDSP, the provider opens its professional account, subscribes to the CESOP service and files like a French entity.

5. The packaging chain: XML, zip, GnuPG

The DGFiP accepts only a specific package. The steps, in order:

1. Build the XML against the Commission’s CESOP schema, encoded in UTF-8 without a byte-order mark, named PMT-<quarter>-<year>-FR-<PSPId>-<part>.xml. The PSPId is the BIC or another identifier that names the provider unambiguously, and it should match ReportingPSP/PSPId in the file.
2. Validate it with the Commission’s validation module. The module runs offline, so it cannot see previous files: it will not catch a duplicate MessageRefId or a broken link between an initial and a corrective file.
3. Zip it, one XML per archive, without a password.
4. Encrypt the zip with GnuPG (OpenPGP) using the DGFiP’s public key for CESOP, published in annex 6.4 of the specification and on impots.gouv.fr. No signature is needed: the secure deposit identifies the filer.
5. Upload the .gpg through PASSTRANS. The specification’s own example is PMT-Q1-2024-FR-310499959-1-1.gpg.

For the part number, the DGFiP prefers the form x-x, incremented per file (1-1, 2-2, and so on). The Commission also allows x-y with a total, but the DGFiP notes the total is hard to know in advance and converts it to x-x before forwarding.

Size is controlled by count, not bytes. A file holding more than 135,000 ReportedTransaction elements is rejected, however they are spread across payees — roughly 100 MB. A deposit over 200 MB is rejected as a technical failure before it is even read.

6. Two status messages: MS1 from the DGFiP, MS2 from CESOP

Every deposit produces two responses, told apart only by their file names.

MS1 normally arrives within 24 hours and at most 72. The DGFiP forwards the file to the Commission exactly as deposited, so it cannot cut out bad records: its checks either pass the whole file or reject the whole file. Only CESOP can reject part of a file, and when it does, MS2 names each rejected payee record by its DocRefId. Both messages carry a CorrMessageRefId pointing to the MessageRefId of the file they answer — except when the file could not be read at all, in which case MS1 names the deposited archive in the error description instead.

7. The checks that reject the whole file

The specification lists the first-level controls. The ones that recur in practice:

• Technical: 50010 (XML not valid against the schema — MS1 quotes the first schema error), 50020 (archive not encrypted with GnuPG, or decryption failed), 50030 (not a zip, or more than one file in the zip), 50050 (virus or threat found), 50070 (too large: over 200 MB, or over 135,000 transactions).
• French only: 500901, the file is UTF-8 with a BOM. The DGFiP added this code itself so that it could tell filers why their file was unreadable.
• Header and sequence: 10010 (MessageRefId already used), 10020 (timestamp in the future — dropped from the Commission’s schema but kept by the DGFiP at first level), 10030 (reporting period before Q1 2024), 10040 (a correction points to a file that does not exist or was rejected at first level), 10070 and 10080 (DocTypeIndic values inconsistent with the message type), 10100 (a correction’s period differs from the original’s), 10110 (CorrMessageRefId present on a new-data or nil message), 10120 (country in the header is not FR).
• Nil message: 40040, a CESOP102 “no data” message that still contains ReportedPayee blocks. The Commission treats this as a record-level error; the DGFiP rejects the whole file.

8. Worked case: a passported EMI with no French entity

Facts: an e-money institution authorised in Spain serves French merchants under the freedom to provide services. In Q3 several of them each receive more than 25 cross-border payments.

What the rule says: France is a host Member State for those services, so a French file is owed to the DGFiP for the quarter, separate from the Spanish file. The firm has no SIREN.

What the practitioner does: sends the DINR the EE0 form, the Registro Mercantil certificate, the articles with a translation of the key clauses, and the signed mandate. Once the IDSP is issued, opens the professional account, subscribes to the CESOP service against the IDSP, imports the DGFiP public key and runs a test deposit.

Outcome: the French leg is filed by 31 October through PASSTRANS, with its own MessageRefId register kept apart from the Spanish one.

9. Worked case: an unreadable file two days before the deadline

Facts: a French payment institution deposits its Q2 file on 29 July. MS1 comes back FULLY REJECTED with code 500901 and no CorrMessageRefId.

What the rule says: the file was UTF-8 with a BOM, so the DGFiP could not read it. Nothing reached CESOP, which is why MS1 names the archive rather than the MessageRefId.

What the practitioner does: re-exports the XML without the BOM, re-runs the validation module, re-zips, re-encrypts and deposits again the same day — then waits for both MS1 and MS2 before closing the quarter.

Outcome: MS1 VALIDATED on 30 July. The team adds a byte-level BOM check to the export job, because the EU module does not flag it.

10. Worked case: 160,000 transactions in one quarter

Facts: a marketplace payment provider has 160,000 reportable transactions for Q4.

What the rule says: one file cannot exceed 135,000 ReportedTransaction elements. The DGFiP accepts several files for one quarter, numbered x-x.

What the practitioner does: splits by payee so that no payee’s records straddle two files, producing ...-1-1 and ...-2-2, each with its own MessageRefId, both as CESOP100 new-data messages.

Outcome: two deposits, four status messages, all filed against the Q4 period.

11. Worked case: a partial rejection for an invalid IBAN

Facts: a file passes MS1, but MS2 returns PARTIALLY REJECTED with error 40030 (IBAN not valid) on one DocRefId.

What the rule says: the other records stand. The rejected payee must be resent in a correction: MessageTypeIndic CESOP101, a CorrMessageRefId equal to the original file’s MessageRefId, and the same reporting period, or the DGFiP rejects it under 10040 or 10100.

What the practitioner does: fixes the IBAN at source, builds a CESOP101 message containing that payee only with a new MessageRefId, and deposits it.

Outcome: MS1 VALIDATED, then MS2 accepted. The quarter’s file pack holds the original, the correction and four status messages.

FAQ

What to do, today

• Head of regulatory reporting: list every SIREN or IDSP you file for, and check each is subscribed to the CESOP service.
• Passported firms: if you serve France with no French entity and have no IDSP yet, send the EE0 pack to the DINR now.
• Data team: add pre-deposit checks the EU module skips — BOM, the 135,000-transaction cap, file naming and MessageRefId uniqueness against your own history.
• Operations: store the DGFiP public key with an owner and a review date, and archive every MS1 and MS2 before the 45 days run out.

Related: Building the CESOP file · CESOP XML, field by field · The French reporting calendar