Electronic invoicing: the whole chain, on your ERP

01 — STRATEGIC CONTEXT

Three obligations, and one place to meet them

You will no longer be able to send an invoice by email. It will have to travel through an approved platform, in a format machines can read.

Three things will be asked of you. Issue your invoices in that format. Receive your suppliers’ invoices, whichever channel they arrive by. Keep proof of what you have sent.

In return, the platform sends back the state of every invoice: received, accepted, rejected, paid. That is information you did not have. Provided it reaches your own screens, and not a portal nobody opens.

A module that produces the right file covers the first obligation only. This solution covers all three.

02 — VALUE LEVERS

Challenges holding back your performance

The Transformation Opportunity:

Handling a supplier invoice by hand has a full cost: the keying, the checking, the chasing, the filing. In a structured chain, with automatic matching, that cost falls sharply. The gap between the two, multiplied by your annual volume, is the first figure to put down — and it is yours, not a market average. The second gain is less visible but often heavier. Today you know an invoice has gone out. You do not know whether it was accepted, nor when it will be paid. Statuses change that: you chase on a dated fact, not on a theoretical due date. Your customers’ payment time becomes a figure you track continuously, and your cash requirement is steered on real data. Third gain, finally: an invoice received in the right format matches itself against the purchase order. What your teams did document by document is now handled by exception.

03 — THE APPROACH

Our Technical Approach

The solution covers an invoice’s whole journey, from preparation to sealed archive, without leaving your management system.

On issue, it produces the file in the right format and embeds it inside a readable document. On receipt, it brings every arrival channel down to a single handling sequence. Before each send, it checks the invoice will go to the right place. For the public sector, it files and follows the statuses. Upstream, it blocks whatever would be rejected. Downstream, it builds the proof.

It exists on Odoo, ERPNext and Dolibarr, with the same scope on all three.

Standard formats

Four profiles covered, structured file embedded inside the archivable document.

Single inbound channel

One handling sequence whatever the way a supplier invoice arrives.

Controlled routing

Recipient identifier checked before sending, priority rule made explicit.

Public-sector connection

Automated filing and retrieval of the administrative life-cycle statuses.

Upstream checking

Anomalies caught before transmission, not after the rejection.

Evidential proof

Cryptographic fingerprint, qualified timestamp, audit log of every transition.

04 — ARCHITECTURE & TECH

Technical Architecture

Schéma de la chaîne de facturation électronique : émission contrôlée puis transmise par plateforme immatriculée, réception multicanal convergeant vers un traitement unifié, archive à valeur probante

Standard formatsFour profiles covered, structured file embedded inside the archivable document.
Single inbound channelOne handling sequence whatever the way a supplier invoice arrives.
Controlled routingRecipient identifier checked before sending, priority rule made explicit.
Public-sector connectionAutomated filing and retrieval of the administrative life-cycle statuses.
Upstream checkingAnomalies caught before transmission, not after the rejection.
Evidential proofCryptographic fingerprint, qualified timestamp, audit log of every transition.

DEADLINES

Two dates, two different obligations

Receiving concerns everyone at the same time. At the first deadline, every business established in France must be able to receive invoices in the structured format. With no exemption by size.

Issuing, on the other hand, is staggered. Large companies and mid-caps first, SMEs and smaller structures a year later. Many businesses prepare to issue and discover late that they first had to be able to receive.

Receiving: every business, from the first deadline
Issuing: staggered according to company size
Receiving is the first obligation, and the one most often forgotten

ISSUING

Compliant invoices, even in the awkward cases

The solution produces a document you can read on screen, with the structured file hidden inside. Four standard formats are available. You choose according to the case.

Simple invoices trouble nobody. The others do. Three VAT rates on one invoice. An exempt line whose reason must appear in a precise place. A credit note that must point back to the original invoice. A discount on a single line. A sale in foreign currency, whose VAT must stay in euros. All of it is handled.

Readable document, structured file embedded inside
Multi-rate VAT, exemptions, credit notes, line discounts, currencies
No re-keying: the invoice leaves from the screen where you create it

Posted invoice with its electronic invoicing state: compliance 100, EN 16931 Comfort format, SEPA payment QR code — The compliance state lives on the invoice itself

Four standard profiles, selectable by use case

Invoice with three VAT rates, broken down by rate with totals per band — Several rates on one invoice, broken down by band

VAT exemption reason carried at the right level of the structure: article 261 of the French tax code, category E, zero rate — The exemption reason carried where the standard expects it

The structured file is genuinely embedded in the archivable document, visible in the list of attached files — Embedded in the document, not sitting beside it

RECEIVING

Every supplier invoice in one place

They arrive through the platform, by email, through a technical interface, through a watched folder or by hand. The solution handles them all the same way: it reads the content, checks it is valid, finds the supplier, extracts the amounts and prepares the accounting entry.

An unknown supplier is created automatically from the invoice. An invoice received twice is spotted, even when it came in by two different channels. A credit note is recognised as a credit note. And where the invoice carries an order reference, the matching happens on its own, with any differences flagged.

Five arrival channels, one handling sequence
Supplier found or created automatically, duplicates set aside
This is where the bulk of the gain on supplier invoices is won

Unified view of invoices received, all channels together, with amount, validity and processing status — One screen for every invoice received

Supplier invoice received by email and analysed automatically, with a non-compliant buyer alert — Email treated as a channel in its own right

Detection of an invoice received twice, with the reason retained and the link to the original document — Duplicate detected even across two different channels

Matching between the invoice received and the purchase order, with the reference found in the document — Automatic matching with the purchase order

Supplier credit note recognised and created with the right accounting sign from the document received — The credit note received, created with the right accounting sign

ROUTING

The right invoice to the right recipient

An invoice sent with the wrong identifier does not come back as an error. It goes somewhere else, quietly. You believe you have invoiced, your customer is waiting, and the problem shows up when you chase.

The solution keeps the receiving address on the customer record. Before each send, it checks that the address does belong to that customer, and flags any discrepancy with the possible corrections. Where several sending routes coexist, it shows which one will be taken.

Receiving address remembered, never re-keyed
Consistency check before every send
An invoicing dispute avoided costs more than the check that prevented it

Routing alert: the identifier entered does not match the customer’s, with the two possible corrections — The inconsistency caught before sending, not after

Receiving address remembered on the recipient’s record — Receiving address remembered per recipient

PUBLIC SECTOR

The public portal, without the portal

Invoicing a town hall, a hospital or a ministry means going through the public portal. More often than not, an accountant exports, opens the portal, re-keys the references, files, then comes back to check a few days later.

The solution files in their place, singly or in batches. The recipient service code is picked from an up-to-date directory. Where that service requires a commitment number, the invoice does not leave without it. Contract number and order references are carried across automatically. After that, the statuses come back on their own into your screens. Including refusals, which the portal shows under a misleading label and which the solution presents for what they are.

Automatic filing, singly or in batches
The references that make public invoices fail are checked before sending
Several days a month recovered in accounting, depending on public volume

Detail of a flow filed automatically on the public portal and integrated on the administration’s side — Automated filing, integration state confirmed

Missing legal commitment flagged before sending, the recipient service requiring it — Field made blocking when the service requires it

Rejection status correctly read as a refusal to act on, with the reason returned by the platform — An ambiguous label presented for what it is: a refusal

Cockpit tracking the life cycle of invoices filed on the public portal, status by status — The public life cycle followed from the management system

Contract and legal commitment references found on the administration’s side — References carried from the order through to filing

CHECKING

Errors seen before sending, not after

A rejected invoice costs the accounting team time and delays payment. Often, you only learn of it several days later.

The solution checks beforehand. It verifies that identification numbers are valid, not merely that they have the right number of digits. A well-formed but wrong identifier is caught. Blocked invoices are gathered on one screen, each with its likely reason and what to do about it. A period summary can be exported for management and for the accountant.

Blocking check before transmission
Every block with its likely cause and the action to take
The payment clock does not run while an invoice is rejected: every rejection avoided is cash

Full check of the chain before the first transmission, control point by control point — Every control point with its state and its explanation

Anomaly centre showing, for each blocked invoice, the likely cause and the recommended action — Likely cause and recommended action for every block

Detection of bank details in a valid format but with an incorrect check digit — Valid format, wrong check digit: caught all the same

Period summary for management: volume, revenue, share of invoices without incident, compliance — Summary exportable for management and the accountant

ARCHIVING

Enough to answer an inspection

The archive is created at the moment the invoice leaves. It carries a digital fingerprint and a timestamp that proves its date. At any point, one can verify that the document has not moved.

Alongside it, everything is traced: who did what, when, and why. Internal approvals are there, refusals too, with their reason. The compliance of that audit trail is checked point by point, against article L102 B of the French general tax code.

Fingerprint, timestamp, retention period carried by the archive
Everything traced, refusals and their reasons included
An audit trail that can be verified, rather than compliance that is merely declared

Compliance check of the reliable audit trail under article L102 B of the French general tax code — Audit trail checked point by point

Detail of an archive: cryptographic fingerprint, timestamped seal and retention period — Fingerprint, qualified timestamp, statutory retention

Audit log of state transitions, with the reason for each change — Every transition traced with its reason

Two-level internal approval circuit, traced and timestamped — Two-level internal approval, reasoned refusals included

PROVEN COMPLIANCE

Verified by independent checkers

The invoices produced pass the industry’s official validator with no error and no warning, across all four checking levels. The test was repeated on the VAT and exemption cases, where approximate implementations fail.

The European format was submitted to a second validator, unconnected with the solution. Same result.

Official French validator: four levels, no reservation
Independent European validator: no reservation
Public filings verified from the order through to integration

Official validation of the national format across the four checking layers, with no error and no warning — Industry official validator: four layers, no reservation

External validation of the document in the European format: zero warnings and zero errors across the four checking layers — Independent European validator: no reservation

IN PRODUCTION

Two deployments, 3,000 invoices a month

A business telephony operator, in Grenoble. 480 customer invoices and 52 supplier invoices a month. Straightforward B2B invoicing, with recurring subscriptions and usage re-billing.

A hotel group of three sites, in the Var. 2,543 customer invoices and 353 supplier invoices a month on average. Every difficulty peculiar to the sector is present: booking deposits, sales that switch from private individual to company when the guest asks for an invoice in their firm’s name, and a high supplier volume spread across three sites.

We do not name these clients. We work on their accounts, and therefore on their supplier balances and customer receivables. The principle holds for them as it will hold for you.

Two deployments in production, not a pilot
3,000 customer invoices and 400 supplier invoices handled each month
One recurring B2B case and one multi-site hotel case, the two most frequent profiles

THREE ERPs

On your own environment

The solution exists on Odoo, ERPNext and Dolibarr, with the same functions on all three. What comes from the standard is identical everywhere; only the integration into the screens differs.

On another management system, porting is possible. The standards work is already done. The effort goes into the connection and into bringing the statuses back onto your screens.

Three environments, same functions
Porting possible to another management system
Changing platform does not mean redoing the project

05 — DEPLOYMENT METHODOLOGY

Smooth and frictionless integration

Roll-out follows four stages. The first governs the other three: the quality of your counterparty data determines the rejection rate far more than the choice of tool.

Counterparty data review

A measure of the state of your master records: share of identified customers, validity of intra-community VAT numbers, consistency of bank details, tax qualification of invoice lines. The review produces one simple figure — the share of your invoices that would go through today without intervention — and a prioritised list of corrective actions.

Choosing a platform

Five questions applied to your flow profile cut the hundred-odd registered providers down to three or four candidates: share of public sector, number of issuing systems, international scope, volume, and how rejections are handled. The last one is decisive: only those opening a test environment before signature stay in the running.

Pilot on live flows

A limited perimeter connected to the chosen platform’s qualification environment, using live flows rather than test data. The pilot surfaces the cases that break: the customer with no identifier, the exempt line configured wrongly, the missing order reference.

Go-live and running

Production in waves, pre-transmission checking switched on from day one, accounting teams trained on their own screens and their own invoices, then support through the first closing periods.

Frise de méthode en quatre étapes : diagnostic du référentiel, choix de plateforme, pilote sur flux réels, bascule et exploitation, avec le livrable de chaque phase

06 — KEY BENEFITS

Measurable results for your organisation

5 channels — of receipt brought down to one handling sequence : Platform, email, programmatic interface, watched folder and manual import all converge on the same sequence, with the same trail.
3 ERPs — the solution is available on : Odoo, ERPNext and Dolibarr, with the same functional scope. Porting to another environment remains possible.
3,000 — invoices handled every month in production : Across two deployments: a business telephony operator and a hotel group of three sites. A further 400 supplier invoices a month are added to that.

07 — FREQUENTLY ASKED QUESTIONS

Clarifying your decision-making

Does the solution work on our ERP?

The electronic invoicing solution exists today on Odoo, ERPNext and Dolibarr, with the same functional scope. On another environment, porting is possible: the standards work is already done, and the effort goes into the connection and into bringing the statuses back onto your screens.

We already send our invoices as PDFs by email. Is that enough?

An ordinary PDF is not enough: it is a picture of an invoice, holding no data a machine can use. The rules require a structured file transmitted through a registered platform. The format chosen in France keeps a document you can read on screen, provided the structured file is genuinely embedded inside it.

How much can it earn us?

The main gain from electronic invoicing sits on supplier invoices. Multiply their annual number by the gap between the full cost of handling one by hand — keying, checking, chasing, filing — and that of a structured invoice matched automatically. We do that calculation with you, on your volumes and your costs, rather than on a market average. The second lever, less immediate, is the working-capital steering that dated statuses make possible.

Are we tied to one particular platform?

Clarendis ties its clients to no platform: the connection is designed to stay reversible, and we take no commission. The choice is yours, and changing provider does not mean redoing the project.

What happens if an invoice is rejected?

A rejected invoice has not reached its recipient, and the payment clock has not started. That is the reason for checking before transmission: blocking an incomplete invoice costs less than dealing with its rejection three days later.

Does the solution cover invoicing the public sector?

The solution covers public-sector invoicing: filing on the public portal is automated, singly or in batches, with the service code, the legal commitment and the contract references carried across from the order. The public life-cycle statuses come back into the management system.

What must we keep, and for how long?

The statutory retention period for invoices does not change, but the nature of the proof does. The archive is built at the moment of issue, with a cryptographic fingerprint and a qualified timestamp, rather than reconstructed afterwards from scattered files.

How long does it take to put in place?

Connecting an electronic invoicing solution technically is a matter of weeks. Bringing the counterparty records back up to standard, where that is needed, is what sets the real duration. That is why the review comes first.

We have several companies. Is that handled?

The solution handles multi-company with explicit separation: each company has its own identifiers, its own connection and its own data perimeter.

Our sector has its quirks. Are they covered?

The solution covers the most frequent cases natively: deposits and the switch of a sale over to B2B, exempt and taxed activities coexisting within one entity, multiple sites, and living alongside an existing EDI. The initial review identifies what would call for bespoke development.

How many clients use this solution?

The electronic invoicing solution has two deployments in production to date: a business telephony operator and a hotel group of three sites, for roughly 3,000 customer invoices and 400 supplier invoices handled each month. We describe these deployments — the sector, the volumes, the type of invoicing — but we do not give the company names: we work on their accounts, and therefore on data that is not ours.

Who, on our side, needs to be involved?

An electronic invoicing project draws on three functions: the finance department owns the subject, accounting runs it day to day, and IT holds the connection. Bringing accounting in from the review onwards changes the outcome markedly.

Electronic invoicing