ERP and accounting software for France — Factur-X, partner platforms and DGFiP e-reporting

Where the rollout actually stands

France has been talking about mandatory e-invoicing for years, and for part of that time the talking was the only thing happening: the programme was postponed, and a great many businesses reasonably concluded that they had time. The rollout began in September 2026, and the obligations phase in by company size through 2028.

That history has a practical effect that matters more than the dates themselves. Businesses that shelved a project during the postponement are restarting it with less runway, and the vendors and platforms they will need are working through the same compressed period. Being early is worth more in France than it usually is, not because the deadline is unusual but because the queue is.

The other consequence is that during the phase-in, French businesses will not all be under the same obligation at the same time. Some of your customers will be in scope before you are, and some of your suppliers will start sending you structured invoices before you are required to send any. The receiving side, in other words, arrives before the issuing side does in practice.

The date that applies to your business depends on your size and is set by the administration, not by a software vendor. Confirm your own phase with DGFiP or your expert-comptable before you set a project deadline around it. Nothing on this page should be treated as your date.

• The rollout began in September 2026, after an earlier postponement
• Obligations phase in by company size through 2028
• Projects shelved during the postponement now have less runway
• Suppliers ahead of you will send structured invoices first
• Confirm your own phase with DGFiP or your expert-comptable

The partner platform model, and what it means for your system

The structural choice France made is that invoices flow through a certified partner platform rather than being submitted one by one by each business to the tax administration. Your platform receives the invoice from you, transmits it to your customer, or to your customer's platform, and handles the associated reporting.

This is a different shape of obligation from a clearance regime and it changes where your risk sits. You are not primarily managing a relationship with a government system. You are managing the quality of what you hand to your platform, because the platform can only transmit what you give it, and it will reject a document that does not meet the format's requirements.

So the question to ask a finance system is not whether it is a platform, but whether it can hand a platform a complete, valid document without a person assembling it. That means the invoice record itself has to carry every element the format requires: identifiers, addresses as structured fields, line-level tax, payment terms, references to the order or contract where those are expected.

It also means you need to see what came back. An invoice handed over and then forgotten is an invoice whose status is unknown, and the status matters both to your customer relationship and to your records. Acceptance, rejection and the reason for a rejection should be visible against the invoice in your own system, not only in the platform's portal.

• A complete, valid document handed to the platform without manual assembly
• Identifiers and addresses held as fields, not as printed text
• Tax recorded at line level and consistent with the document total
• Platform acceptance or rejection visible against the invoice
• Rejection reasons retained, so the same defect is not repeated
• The transmitted file retained with the transaction as the record

Three formats, and why Factur-X gets chosen

UBL and CII are XML formats. They are made to be read by systems, and a person opening one without a viewer sees markup rather than an invoice. For businesses whose counterparties are all systems, that is entirely satisfactory and arguably the point.

Factur-X is the pragmatic middle. The file is a PDF, so the person who receives it can open it and read a normal-looking invoice, and the same file carries the invoice data in machine-readable form for the receiving system. That solves a real transitional problem: during a phase-in, not every recipient is processing invoices as data yet, and a format that works for both audiences avoids sending two versions of the same document.

The risk in a hybrid format is divergence. If the readable PDF and the embedded data are produced separately, they can disagree, and a document whose visible total differs from its structured total is worse than either version alone. Both should be generated from one invoice record in one operation, which is a system design question rather than a formatting preference.

Which format you use will in practice be settled by your platform and by what your larger customers ask for. It is worth confirming that a system can produce more than one, because the answer that suits your first big customer may not suit the next.

• UBL: XML, system-to-system
• CII: XML, system-to-system
• Factur-X: a readable PDF carrying the invoice data inside it
• Both faces of a hybrid file produced from one record, in one operation
• The ability to produce more than one format, since customers differ

E-reporting is the limb that gets forgotten

Alongside the invoice exchange, the French regime carries an obligation to report transaction data to the administration. It is easy to leave out of a project plan because it produces no document a customer ever sees, and because the e-invoicing half is the part everyone talks about. It is not optional for that reason.

The practical difficulty with a reporting obligation is that it draws on data that a business may not currently capture in a reportable form. An invoice exists as a document whether or not the underlying data is tidy; a report is only as good as the fields behind it. Businesses discover this when the first period's report cannot be produced without a week of manual assembly.

The system implication is that transactions need to be classified correctly at the point they are recorded, not sorted out afterwards. Whether a sale is domestic or cross-border, business or consumer, and what tax treatment applies, are properties of the transaction, and if they are assigned at entry the report is a query rather than a project.

The exact scope, content and frequency of what you must report are set by DGFiP and depend on your circumstances. Confirm them with the administration or your expert-comptable. This page will not restate them, because a reporting obligation stated approximately is worse than no statement at all.

• A second limb of the regime, separate from invoice exchange
• Reporting draws on data an invoice document does not expose
• Classify transactions at entry, not when the report is due
• Domestic, cross-border, business and consumer sales distinguishable
• Scope, content and frequency confirmed with DGFiP

Data quality decides whether this is easy or painful

A printed invoice is a forgiving object. A human reads it, and a human fills gaps from context: they know which company the abbreviation refers to, they recognise the address, they understand what the note in the margin means. A structured invoice removes the reader, and with them all of that tolerance.

The commonest French project delays are not about formats or platforms. They are customer records without a complete identifier, addresses typed into a single free-text line, item records whose tax treatment was never recorded because everyone knew it, and payment terms expressed in a sentence rather than as a date rule. Each of those is fine on paper and fatal in XML.

The useful preparatory exercise is concrete. Take a hundred recent invoices, list the fields the format requires, and count how many of the hundred you could produce completely from what you hold today. The shortfall is the project, and it is almost always larger and duller than the software work.

Doing that review before choosing a platform also improves the choice, because you will be asking platforms about the problems you actually have rather than the ones in their demonstration.

• Customer records without a complete identifier
• Addresses typed into a single free-text line
• Item tax treatment that was never recorded because everyone knew it
• Payment terms written as a sentence rather than a date rule
• Order and contract references missing where a format expects them
• A hundred real invoices tested against the required fields

The plan comptable, and why the chart of accounts is not yours to invent

French accounting is organised around a prescribed chart of accounts. Entries are classified according to the plan comptable from the moment they are posted, which is a genuine difference from markets where a business designs its own account structure and maps it to a reporting format later.

For a finance system, this is a straightforward but non-negotiable requirement: the account structure has to be able to follow the French convention rather than an internal scheme invented by the software. A system whose chart of accounts cannot be shaped to the plan comptable will create work for your expert-comptable at every stage, and it will keep creating it.

For a group with French and non-French entities, this is also a consolidation question. The French entity classifies to the plan comptable, other entities classify to their own conventions, and the group needs one consolidated view. That is a mapping exercise, and it works when the underlying entries carry enough dimension to be mapped rather than being pre-summarised.

Listed groups in the European Union report under IFRS as adopted by the EU, so many French groups produce both a local view and an IFRS view. Which framework applies to which entity, and how a specific transaction should be treated under it, is a question for your auditor and your expert-comptable.

• Entries classified to the plan comptable from the moment of posting
• An account structure that follows the French convention
• Mapping to a group structure, rather than pre-summarised entries
• Listed EU groups reporting under IFRS as adopted by the EU
• Framework questions settled with your auditor and expert-comptable

VAT at 20%, and the treatment questions behind it

The French standard rate is 20%. Reduced rates and exemptions apply to particular goods and services, and cross-border supplies inside and outside the European Union follow their own rules. None of that is a software question, and a vendor page is the wrong place to look for the answer.

What is a software question is whether the answer, once you have it, is applied consistently and can be evidenced. Tax determined at line level and stored with the transaction; rate changes dated so that historical invoices keep showing what was charged; domestic, intra-EU and third-country transactions separately identifiable rather than merged into one total.

Under a structured regime this matters more than it did on paper. When tax detail travels as data through a platform, an inconsistency between the lines and the total is a defect in the document rather than an untidiness a reader will overlook, and it may be the reason a transmission fails.

Skyline Nexus stores the tax treatment on the line, keeps the rate that applied on the date it applied, and produces the transaction list behind each reported figure. It does not decide your VAT position, and it is not certified for the French regime. Those are matters for DGFiP and your adviser.

A workable order for a French project

Start with the data review, because it determines everything after it and because it can begin before any commercial decision is made. Then choose a platform, with the review in hand. Then make receiving work, because suppliers ahead of you in the phase-in will start sending structured invoices whether or not you are ready to issue them. Then issue, first to the customers who need it, then generally.

Treat e-reporting as a parallel workstream from the beginning rather than as a phase at the end. It draws on the same transaction data, and building the classification correctly at entry costs almost nothing while retrofitting it costs a great deal.

Run a real transmission with a real counterparty as early as your platform allows. Schema validation proves a file is well formed; it does not prove that your customer's system will accept and post it. The gap between those two is where identifier and reference problems live.

Keep a written record of what was done and when. During a phased rollout, being able to show when your business became able to receive and to issue is worth more than a memory of roughly when the project finished.

• Data review first, before any platform decision
• Choose the platform with the review in hand
• Make receiving work before issuing is required of you
• Issue to the customers who need it first, then generally
• E-reporting as a parallel workstream, not a final phase
• One real end-to-end transmission with a real counterparty, early

French groups, branches and cross-border trade

French businesses of moderate size commonly run several establishments and often several legal entities, with trade across the European Union and beyond. That makes intercompany transactions, consolidation, and a shared account structure ordinary requirements rather than advanced ones, and it makes location a dimension that has to be carried on the posting.

Currency follows from the same fact. A transaction should be recorded in the currency it happened in, with the rate applied and the date it applied, so that the difference realised on settlement can be explained rather than reconstructed at the year end from bank statements.

Skyline Nexus records transactions in their original currency with the applied rate, carries entity, establishment and location as dimensions on the posting, holds the tax treatment at line level, and retains the transmitted invoice file against the transaction it belongs to. What it does not do is make a filing decision or represent itself as approved by any French authority.

Where a French entity sits under a parent elsewhere, the same transactions have to serve local classification and the group's reporting framework on consolidation. That is met by carrying enough dimension on each posting to support both readings, not by maintaining a second ledger by hand for the parent's benefit.

• Several entities and establishments under one account structure
• Intercompany balances that agree in both directions
• Original currency and applied rate stored on the transaction
• Domestic, intra-EU and third-country supplies separately reportable
• Transmitted invoice files retained with their postings

What to ask a vendor, and a platform, in France

Ask the software vendor to produce a Factur-X file from a live invoice and open it in front of you, both as a PDF and as data, and check that the two agree. Ask what happens when the platform rejects a document: where the rejection appears, whether the reason is retained, and how the corrected document is linked to the original.

Ask about receiving as carefully as about issuing. A supplier invoice arriving as structured data should populate a purchase invoice without anyone typing, and should fail loudly rather than quietly when it cannot be matched.

Ask the platform separately about the reporting limb, because that is where responsibilities divide and where a project can discover late that neither side thought it was theirs. Get the division of responsibility in writing before you sign either contract.

And treat compliance claims with the same scepticism you would anywhere. No accounting system can guarantee that your business complies with the French regime, because compliance depends on your data, your processes and your obligations. Confirm your own position with DGFiP or your expert-comptable.

• A Factur-X file opened as both a PDF and data, and the two agreeing
• Where a platform rejection appears and whether the reason is kept
• A supplier invoice posted from data rather than retyped
• Which party owns the reporting limb, in writing
• What the system does not do, in the vendor's own words
• No guarantee of compliance, because none can be given

Common questions

When does French e-invoicing become mandatory for my business?

The rollout began in September 2026, after an earlier postponement, and phases in by company size through 2028. The date that applies to your business depends on your size and is set by the administration. Confirm your own phase with DGFiP or your expert-comptable rather than planning from a vendor page.

Do French invoices go directly to the tax administration?

No. France uses a partner platform model: invoices flow through a certified partner platform, which handles transmission to the recipient and the associated reporting. Your finance system's job is to hand that platform a complete and valid document, and to show you whether it was accepted or rejected.

Which invoice formats does France accept?

UBL, CII and Factur-X. UBL and CII are XML formats meant to be read by systems. Factur-X is a hybrid that carries machine-readable invoice data inside a PDF, so one file serves both a human reader and a receiving system. Both faces of a hybrid file should be produced from the same invoice record so they cannot disagree.

What is e-reporting, and is it separate from e-invoicing?

It is the second limb of the regime: an obligation to report transaction data to the administration alongside the exchange of electronic invoices. It is frequently left out of project plans because it produces nothing a customer sees. Its scope, content and frequency are set by DGFiP and should be confirmed with them or with your expert-comptable.

Does the plan comptable affect which system we can use?

It affects how the system has to be configured. French accounting is organised around a prescribed chart of accounts, so entries are classified to the plan comptable from the moment they are posted. A system whose account structure cannot be shaped to that convention creates work for your expert-comptable at every stage.

Rates, regimes and deadlines in this summary change, and many countries are actively legislating on e-invoicing. This is general information, not tax or legal advice — confirm the current position with the authority named above or with your tax adviser before you rely on it.