Contact Info
What does an ERP requirements consultant produce for a company in France?
An ERP requirements consultant produces the cahier des charges that integrators answer and the contract later cites. For a company in France I structure it by process, write e-invoicing reform, FEC, TVA and payroll journal lines as testable statements your expert-comptable confirms, add hosting, access and CSE-related logging rules, set priority classes and trace each line to demo and acceptance tests. Delivery is remote and vendor-independent.
Last reviewed by Vikas Saroj
French ERP projects rarely lack documents. There is often a cahier des charges, then the integrator's detailed functional specifications, then a contract and a test plan. The risk sits in the joins between them: a requirement that was never testable, a reform obligation phrased as a wish, or a line that disappears between the tender and the integrator's design.
I work remotely as an independent ERP requirements consultant, and my job here is the document and its life cycle: a clear chapter structure, statutory lines written so they can be checked, non-functional rules, priority classes, version control and traceability through to acceptance.
How processes are discovered and interviews are run is explained on the ERP business analyst page for France; this page starts where that work ends.
One controlled document, reused by the tender, the integrator's design, the contract and the acceptance tests.
Chapters for scope, entities, each process from devis to payment and from purchase request to supplier payment, finance, statutory lines, non-functional rules, interfaces and migration, with a fixed line format and acceptance criterion.
Statements on receiving and issuing structured invoices, invoice status updates, e-reporting data, Chorus Pro for public customers, the FEC export and TVA timing, each flagged for review by your expert-comptable.
Lines on where data is hosted, the GDPR processing agreement, user profiles and separation of tasks, change history, French and English outputs, response times at closing and access for regional agencies or depots.
Each flow described by direction, trigger, content, frequency and failure handling, covering the invoicing platform, banks, payroll journals, retail EDI and web shop, plus what history moves and what stays archived.
Every line linked to its source, its demo scenario, the integrator's design reference, its acceptance test and its result, so a dropped requirement is visible the moment it disappears.
A structured read of an existing cahier des charges or an integrator draft: untestable lines, missing reform or non-functional coverage, inflated priorities and phrasing that points toward one package.
Set scope, chapters and line format
Write, test the wording, prioritize
Release a version others rely on
The structure decides whether integrators can answer a cahier des charges consistently. I organize it around the flows a French company actually runs: sales administration from devis to order, delivery, invoice and collection; purchasing from request to supplier payment; stock and logistics; production, projects or services where they apply; and finance from posting to closing. Each chapter starts with a brief description of the process and the entities concerned, then lists numbered lines.
A line holds one need, written so an integrator can reply with a clear covered, partly covered or not covered. It names its source, such as the sales administration lead, the finance director, the expert-comptable, group IT or the DPO. Each one also gets a ranking in the agreed priority scheme and a short note on the evidence that would show, during acceptance, that the need is met.
Behind the process chapters come the legal and tax obligations, the rules on system behavior, a list of every flow in and out, the data takeover plan and a glossary pairing English working terms with the French vocabulary staff use, such as lettrage, avoir or bon de livraison. The engagement runs in English; if integrators need a French version, translation is arranged by your team or theirs, and the document states which version is the reference. The general method is on the ERP requirements gathering page.
A line such as "compliant with the e-invoicing reform" cannot be scored or tested. I split each obligation into statements a tester can verify, and every one is marked for confirmation by your expert-comptable, because applying the rules to your company is their call:
Timing of the reform depends on company size and is set by the authorities; the specification follows what your advisor confirms rather than a fixed date. How the platform choice and the ERP choice interact is covered on my ERP selection page for France.
A cahier des charges can describe processes thoroughly and still leave system behavior to the integrator's goodwill. A non-functional chapter puts that behavior into writing.
Hosting and data protection lines state where production data and backups must be held, whether hosting in France or the EU is a requirement or a preference, which subprocessors are acceptable and what the GDPR processing agreement must contain. Your DPO sets the position and the document records it. Access lines define roles, segregation between ordering, receiving and paying, approval limits and the audit trail expected on master data and postings.
Employee-related logging needs particular wording. Where a CSE exists, introducing tools able to monitor staff activity generally calls for informing and consulting it. I write lines requiring that user logs, activity reports and time capture can be switched on, limited or off per role, with each setting described, so any agreement reached with the CSE can actually be configured and verified. The legal reading belongs to HR and counsel.
Language and output lines matter too. Users may need the interface in French, customer documents and legal mentions in French, and management reporting in English for a parent company. Each output is listed with its language, layout owner and reviewer, and French texts are checked by native speakers on your team. Finally, regional agencies or depots need stated response times and behavior when connections are poor.
Interfaces are where integrator estimates drift most, so each one is written as a small specification of its own: which system sends, what starts the exchange, which fields travel, how often, who owns it and how a rejected file is reported and corrected. In a French context the list commonly includes the invoicing platform, bank channels for statements and payment files, payroll journals, EDI with retail or industrial customers, a web shop or marketplace, a CRM and group reporting. Technical depth continues on the ERP integration page.
For the data takeover, the document says which customers, suppliers and articles are carried over, how much transaction history is worth bringing, what the opening position of the new ledgers will be, how lettrage status is carried across, and how older records stay accessible for an audit once the previous package is switched off. Detail is on the ERP data migration page.
Priorities follow a MoSCoW logic expressed in words rather than scores: lines the company cannot start without, lines that matter but could follow in a later lot, lines that are welcome if they cost little, and lines deliberately excluded from this phase. Reform and FEC lines start in the first class. Elimination criteria for the tender are drawn from that class and written so an integrator who cannot meet them is excluded with a recorded reason. Department heads agree the classes before the tender goes out.
In the tender the cahier des charges becomes the requirement annex. Each integrator answers line by line with a coverage code and a comment, which makes replies comparable rather than a set of brochures. The tender mechanics are described on the ERP RFP consulting page.
After award, the integrator usually writes detailed functional specifications. I compare them with the cahier des charges line by line: each requirement should map to a design element, and anything quoted as standard should not come back as a paid change. The contract should name the released versions of both documents and refer to the acceptance criteria.
The traceability matrix then follows each line into UAT, through its test case to its result. Each release of the specification has an identifier, a date, an owner and a change register entry, and department heads sign their chapters in writing.
Gaps that put French specifications at risk are fairly predictable: reform lines with no named platform interface, a FEC export assumed rather than tested, French document templates left out, nothing on CSE-related logging, no e-reporting data and no archive access after migration. I check for each before release. The work is remote, visits are by arrangement and I accept no commission from integrators or vendors. See also my work in France.
Tell me about your business and current systems. I’ll suggest the most sensible first step.
Book a Consultation
Not sure which ERP you need?
Share your business requirements with me and I will help you understand the right process, architecture and platform before implementation.
Yes. The specification describes what must happen to invoices and status messages, not which platform carries them. Platform-related lines are written as interface requirements with a placeholder for the chosen route, so integrators can respond either way. Once the platform is selected, the interface chapter is updated in a new version and the traceability matrix shows which lines changed.
Yes, and it is a sensible step. A document written by the party that will answer it can reflect that party's product. I check testability, missing statutory, non-functional and interface lines, priorities and product-specific wording, then return an annotated copy with suggested additions. You decide what to change before the integrator prices the work.
Length matters less than coverage. A smaller company can keep process chapters short, but the statutory lines on e-invoicing, the FEC and TVA, the interface list and a basic non-functional chapter should still be there. Those are the parts that cost most when they are missing. I scale the detail to the number of entities, flows and integrations involved.
A named owner on your side, supported by a change register. Every change records the reason, the requester, the impact on cost or schedule and the approval. I can act as that owner during design and testing, or set up the register and hand it to your project lead. Either way, the integrator works from the latest released version only.
Every business is different. Share where you are today and what you want to fix, and I’ll tell you honestly whether and how I can help.
Book a Consultation
Book a consultation to talk through your processes, systems and goals. I’ll reply with practical next steps - no obligation.