France Mandatory E-Invoicing & E-Reporting

The problem

The French reform changes what an invoice is for a company running Dynamics 365 Finance & Operations. A PDF emailed to a customer stops being a valid B2B invoice. Instead, every domestic B2B invoice has to leave your system as a structured electronic document, travel through a registered exchange platform to your customer's platform, and come back with lifecycle statuses that you are expected to act on. On top of that sits e-reporting: transactions that are not domestic B2B — B2C sales, cross-border sales and purchases — still have to be reported to the administration on a schedule, along with payment data for services.

Standard F&O gives you the invoice, the customer master, the tax transactions and the electronic reporting framework. What it does not give you out of the box is a French flow that is complete end to end: directory lookup so you know where a customer's invoices should be routed, a structured document carrying every mandatory field in the format your platform accepts, an outbound channel to that platform, an inbound channel for statuses and for supplier invoices arriving the same way, a rejection loop your AR team can actually work, and the periodic e-reporting extracts derived from the same posted data. Missing any one of those turns a deadline into an operational incident, because an invoice that never reaches the platform is an invoice that has not legally been issued.

What ECOSIRE builds

We build an X++ extension package for Dynamics 365 Finance and Supply Chain Management, delivered as extension models only — event handlers, chain-of-command, table and form extensions and new elements in our own model. No overlayering. Where the standard electronic reporting configurations already carry part of the work, we build on them rather than around them.

Structured invoice generation

We extend customer invoice posting so that every in-scope document produces a structured electronic invoice alongside the normal posting. That covers sales order invoices, free text invoices, project invoices and credit notes. Mandatory French content is sourced from where it actually lives in F&O — legal entity registration identifiers, customer identifiers, delivery address, VAT breakdown per rate, payment terms and due date, purchase order references, and the transaction category and options-for-payment indicators the reform requires. Fields that F&O has no home for are added as extension fields on the customer, the legal entity and the invoice header, so your users maintain them in the standard forms.

Platform exchange

We build the outbound channel to the partner platform you have contracted with, and the inbound channel back. Transmission runs on the batch framework with a queue, retry policy and a per-document transmission log, so a platform outage delays delivery rather than losing documents. Inbound handles two flows: lifecycle statuses against invoices you sent, and supplier invoices arriving through the platform, landed into the vendor invoice journal or the invoice register for your AP process rather than dumped into a folder. Because platform contracts and APIs differ, the connector is built to your provider's published interface as part of the scoped work.

Lifecycle status tracking

Every in-scope invoice carries its own status history — submitted, received by the platform, made available to the customer, approved, disputed, rejected, cash received where applicable. Statuses are visible on the invoice journal and on the customer, and rejections raise a work item so somebody owns the correction. Where a status obliges a response within a deadline, the extension surfaces the ageing rather than leaving it in a log.

E-reporting extracts

We build the periodic transaction e-reporting from the same posted data: B2C sales, cross-border sales and purchases, and payment data where the reform requires it. Extracts are generated as data entities through the data management framework, on a batch schedule aligned to your reporting frequency, with a frozen snapshot per submitted period so a late posting produces an adjustment rather than silently changing a filed figure.

Directory and validation

We build the customer routing data — the identifier and platform each customer receives invoices on — as maintained data on the customer record, refreshable from your platform's directory service where it offers one. Alongside it runs a validation batch job: customers missing routing information, invoices missing mandatory fields, unresolved rejections and documents stuck in transmission. Running that job daily is what stops the deadline being the moment you discover the gaps.

Who it is for

Companies with a French legal entity on F&O that have to move onto the mandatory flow; international groups whose French subsidiary is one entity among many and needs a country layer without disturbing the group template; and shared service centres issuing invoices on behalf of French entities that need the exchange, the statuses and the e-reporting in one place.

How delivery works

Everything here is built to order — nothing is pre-packaged or downloadable.

1. Scoping call. We go through your French legal entities, invoice types in scope, the partner platform you have contracted with and its interface documentation, your current customer and tax master data, and how supplier invoices should land in AP. We agree what is in scope for e-reporting. 2. Fixed quote. You receive a written scope, a fixed price and a delivery date. Nothing starts until you approve it. 3. Build. We develop against a matching F&O version in our own environment, including unit tests on document generation and status handling, and connect to your platform's test endpoint. 4. Install in test. We deliver the deployable package into your sandbox through your LCS pipeline, configure the routing data and the platform credentials with your team, and run end-to-end tests against the platform's test environment — issue, transmit, receive statuses, handle a rejection, receive a supplier invoice. 5. Production. After sign-off, the same package moves through your release pipeline to production and the connector is pointed at the live platform endpoint. We are on the call for the first live cycle. 6. Support. A defined support window covers defects, platform interface questions and configuration after go-live.

Two honest limits. First, the registered platform contract is yours — we integrate with the provider you appoint, we do not act as one. Second, French requirements and platform interfaces have been revised during the reform's rollout; the build targets the specification and platform interface current at the time of the scoping call, and later changes are handled as quoted follow-on work.