Invoice dematerialization (facturation électronique in France) is no longer optional. Starting September 1, 2026, all French companies must be able to issue and receive electronic invoices through registered private platforms (PDP). What many have yet to anticipate: these platforms will automatically check the quality of the data they carry. An invoice with an incorrect company name, an incomplete address or an invalid VAT number will simply be rejected — with no payment possible.
For companies that have not yet put their customer and supplier master data in order, the deadline is a hard one. And the road to get there is more complex than it looks.
Julien Rameau, an expert MDM (Master Data Management) and data governance consultant at FocusTribes, has just completed a multi-month assignment at an international industrial group specializing in animal nutrition — €2 billion in revenue, 3,000 employees, operations in more than 100 countries. He looks back on the challenges of a project run under pressure, the technology trade-offs that led to the choice of Semarchy MDM, and what this kind of assignment reveals about the data maturity of industrial companies.
Preparing your transition to electronic invoicing ?
Download our free ebook and structure your project ahead of the September 1, 2026 deadline.
In most industrial companies, the quality of master data is a known problem that keeps getting postponed. Business teams juggle duplicate customer records, outdated addresses and incomplete tax identifiers every day — and adapt. It is uncomfortable, but it works. Until an external constraint makes the status quo impossible.
That is exactly what happened here. The invoice dematerialization obligation of September 1, 2026 ended that tacit tolerance. The mechanism is unforgiving: electronic invoicing platforms make no compromises on data quality. Company name, billing address, SIREN, SIRET, intra-EU VAT number — everything must be exact, to the letter. In a group operating internationally, with entities in China and Indonesia, the constraint goes even further: addresses must be available in both the local alphabet and Latin characters.
As Julien Rameau puts it: "The first use case, the first consumer of our data, is regulatory."
This regulatory trigger had an unexpected effect: it legitimized a data initiative that management might not otherwise have prioritized within that timeframe. The project is also part of a broader ambition led by the group's Chief Data Officer, who reports to the CFO: to build a data office that, beyond the existing BI, gradually extends data governance to the plants and to research. The customer/supplier MDM repository is its first concrete building block.
Even so, Julien tempers the idea that business teams woke up on their own: "Most companies are aware they have problems day to day, but not necessarily that they are linked to their data. When you pull the thread, you realize that if the data had been clean to begin with, the problems would no longer be there."
The regulatory constraint did not, therefore, transform the organization's data culture overnight. Above all, it created a shared sense of urgency and a budget to act — which, in many industrial companies, is already a rare starting point.
Faced with the regulatory deadline, the group's first structuring decision was to rely on a dedicated MDM software package rather than build a solution in-house. Four vendors were put in competition, each with a distinct positioning.
Informatica is the benchmark of the MDM market. Its robustness and the functional richness of its platform make it a natural choice for large accounts. But that maturity has a downside: implementation lead times are significant. With the schedule as the number-one constraint, this option was quickly set aside.
SAP was already the group's main source system — customer and supplier master data lives there day to day. Choosing SAP MDM would have offered native consistency with the existing infrastructure. But as Julien explains: "I have always used SAP as a data source. For me, it was really sourcing." The SAP MDM solution was ruled out fairly early, in favor of tools that were more agile in terms of configuration and deployment.
Blueway, a French vendor, offered preconfigured models suited to third-party master data — a real asset for shortening the analysis phases. But against Semarchy on the criterion of industry maturity in manufacturing, the balance tipped against the French solution.
In the end, Semarchy won the decision, for two main reasons. First, its ability to be operational quickly: "Semarchy has a product that is simply fairly easy to configure — you can do things with it very quickly", Julien points out. Second, its established presence in the industrial sector, which offered references and sector credibility that internal teams could make their own.
But Julien is clear-eyed about the limits of any vendor choice: "They had seen the advantages well, but they had not anticipated the drawbacks." The marketing pitch highlights ease of implementation — the reality of a deployment under constraint is always more complex. And on this project, the real difficulty was not the tool.
"The heart of the system is not the tooling. The heart of the system is all the processes, the governance — that is the real key."
When Julien Rameau joined the project in February 2026, the technology choice had been made. Semarchy was selected and the integrator was in place. But the business process analyses, however, had not yet started. And the go-live deadline was set for the end of June. The pressure was immediate.
The priority: understand how customer and supplier data is created, modified and validated today — before even thinking about how it will be handled tomorrow with the MDM. Julien takes a deliberately simple approach: "We ask questions, we take notes, we describe things in a simplified way, we get it validated. Is that really what we understood?"
This graphical, accessible method proved decisive in bringing business teams on board. "The more you simplify things, the better you understand them", he sums up. Workshops follow one another, the workflows are built collectively, and deliverables reach the integrator within workable timeframes. A pseudo-agile approach is set up: Jira for ticketing, sprints to pace development, weekly operational committees and steering committees every two weeks.
One of the major frictions at the start came from the project organization itself. The MDM repository workstream and the invoicing project — run by an integrator dedicated to electronic invoicing — were moving forward in parallel, with no shared bodies. Two teams, the same end goal, but different timelines and logics.
"When I arrived, it was really two projects in parallel — they were not talking to each other", Julien confides. Coordination bodies had to be created along the way to synchronize acceptance testing and to make sure the data produced by the MDM met the use cases of the invoicing project. A concrete example of what is often underestimated in this type of project: project governance itself, not just data governance.
The relationship with the IT department was another point of friction, more tied to human dynamics than to the project structure. In this type of assignment, it is not unusual to meet very assertive technical profiles, with a precise vision of what they want to put in place — and a certain resistance to being challenged on their choices.
"It is quite complicated with IT people who are technical and do not really like being told how to do things", Julien observes. The stance of the external consultant who arrives with a critical eye on the specifications is never easy to get accepted, especially at the start.
The key was gradual adaptation. Taking the time to understand how counterparts work, adjusting one's posture, building trust before challenging. "Once you have understood how someone works, it is much easier." Today the IT team is fully involved in the project and the go-live is on track to meet the planned deadlines — which, on a project of this nature and complexity, is far from a given.
An MDM project with no associated governance produces a technical repository that quickly degrades. Data is cleansed, structured, integrated — then gradually re-contaminated by approximate data entry, processes that are not followed and unclear responsibilities. It is a scenario most industrial companies have already lived through, often without clearly identifying it as a governance problem.
On this project, governance was not a separate workstream. It was built in parallel with the technical setup, in the business workshops, in the definition of workflows, in the daily decisions about who validates what and through which process.
The first governance decision was also the most pragmatic: not to try to tackle everything at once. The initial scope was deliberately limited to core identity data — company name, billing address, tax identifiers, VAT number — for the customer and supplier repositories. A targeted scope, directly tied to the regulatory challenge, which made it possible to move fast without getting lost in the complexity of an overly ambitious data model.
"We knew which characteristics of the data we wanted to keep at first. We did not have to talk about a third party in the general sense, where you can quickly go off in all directions", Julien explains.
This scope discipline is one of the most valuable lessons of this kind of project. The temptation is often strong to widen the scope along the way — to add data domains, use cases, emerging needs. On a project under regulatory constraint, this drift can be fatal to the schedule.
Once the scope was defined, the governance work focused on modeling the existing processes and designing the new workflows that include the MDM. The approach: co-construction workshops with business teams, progressive validation, and a structured handover to the integrator.
The purchasing departments, very aware of their supplier data quality problems, were natural allies in this effort. They were already running an SRM project — a repository dedicated to suppliers — in parallel, a strong signal of emerging data maturity in this area.
On the customer side, the circle of directly affected users was smaller, which made change management easier. "They knew it was heading somewhere anyway — something they had no choice about since it was imposed by the government", Julien notes pragmatically.
One of the most structuring decisions for the project's longevity was hiring a dedicated internal data governance resource, who joined the team two months before the end of Julien's assignment. A deliberate choice by the Chief Data Officer so that governance would not rest solely on external expertise.
This gradual handover — working as a pair for several weeks before the consultant leaves — is a model worth remembering. "I do not leave them completely in the lurch", says Julien. "They have quite a lot of material, and at worst they will have my phone number."
Data governance is not a project that ends at go-live. It is an ongoing process that requires clear internal ownership, regular follow-up bodies and a data culture that is built over time. This project laid the first foundations — it is now up to the organization to keep them alive.
Preparing a Data Governance project ?
Discuss your project with a FocusTribes consultant
Every project run under pressure leaves marks — habits acquired, mistakes narrowly avoided, convictions reinforced. Julien Rameau draws several lessons from it, which he states plainly, for the CIOs and CFOs about to take the same step.
Julien's first piece of advice is also the most universal: "To plan a roadmap of more than 3 months — that is the message I tried to get across." On this project, the regulatory urgency concentrated all the energy on the June go-live, at the expense of a medium-term vision. What happens after production start? Which data domains are handled next — products, raw materials, other master data? Who runs governance day to day?
These questions do not always have answers at the start. But not asking them at all means risking building a repository with no future. "With all my clients, we had roadmaps of at least 3 years for all the projects we put in place", Julien recalls. A horizon that may seem distant in a tight budget context — but one that determines the consistency of all the technical and organizational choices made upstream.
Technology is rarely the real problem in an MDM project. The tools available on the market are mature, documented and well supported. What makes the difference — and what can derail a project — is the ability to align stakeholders, manage resistance and communicate differently depending on the audience.
"The main challenge is adaptation. What worked for one client does not necessarily work for others", Julien sums up. Every organization has its own codes, informal hierarchies and friction points. An experienced MDM consultant stands out not only through technical mastery of the tools — but through the ability to quickly read an organization and adjust their posture accordingly.
This is probably the most important lesson, and the hardest to get accepted upfront. An MDM project has a beginning and an end. Data governance does not. It requires a gradual transformation of practices, business teams taking responsibility for the quality of their data, and an organization able to stay the course over time — long after the external consultant has moved on.
"Governance plus data means that, behind it, there are significant issues. And if the data had been clean to begin with, the problems would no longer be there", Julien observes. This seemingly simple observation sums up on its own why invoice dematerialization is far more than a regulatory box to tick. It is an opportunity — often the first truly serious one — to put data quality at the center of the company's strategy.
For organizations that have not yet taken this step, the September 1, 2026 deadline is no longer far off. And as this case study shows, it is better to be supported by an expert who has already navigated these waters.
MDM (Master Data Management) is a set of processes and tools used to centralize, make reliable and govern a company's master data. In the context of invoice dematerialization, it is essential because the private electronic invoicing platforms automatically check the quality of the data transmitted. An invoice with an incorrect company name, an incomplete address or an invalid VAT number is automatically rejected — which blocks payment. A reliable MDM repository is therefore an operational prerequisite for regulatory compliance.
Choosing an MDM solution depends on several criteria: speed of implementation, the vendor's industry maturity, compatibility with the existing infrastructure and the ergonomics of the tool. Informatica is the market leader but involves longer deployment times. SAP MDM is consistent with an existing SAP environment but less agile. Blueway is a French solution with preconfigured models. Semarchy stands out for its ease of configuration and its strong presence in the industrial sector, which makes it a relevant choice for projects with tight deadlines.
The duration of an MDM project depends on the functional scope, the complexity of the data and the maturity of the organization. On a targeted scope — customer and supplier repository, core identity data — an efficient deployment is possible in a few months, provided you have an experienced consultant, involved business teams and a tool that can be configured quickly. A broader data governance project, covering several data domains and an organizational transformation, requires a multi-year roadmap.
MDM refers to the technical implementation of a master data repository: the tool, the data model, the feeding flows and the quality rules. Data governance is a broader organizational approach that defines who is responsible for which data, how it is validated, who can modify it and through which processes. An MDM project with no associated governance produces a technical repository that quickly degrades. The two are complementary and must be run together.
Business team involvement is often the key success factor of an MDM project. Several levers have proven effective: starting from the concrete problems they face every day rather than from the abstract data topic, adopting a graphical, simplified approach to make processes understandable, co-building workflows in workshops rather than imposing them, and relying on an external constraint — regulatory or business — to create a shared sense of urgency. Communication and adaptation to the context of each organization remain the most decisive skills.
Invoice dematerialization will have had at least one merit: forcing companies to face the reality of their master data. What this project illustrates concretely is that, with the right method, the right tool and the right support, it is possible to meet this challenge even on a tight schedule.
But beyond regulatory compliance, a longer-term initiative opens up — data governance at the scale of the company. An initiative that does not end at go-live, and that requires a vision, an organization and skills that few industrial companies have yet internalized.
FocusTribes supports business leaders and IT departments in this type of transformation, mobilizing MDM and data governance experts such as Julien Rameau — consultants able to step in operationally, with the architectural vision and critical perspective that these projects demand.