ERP Requirements Specification: The Method and Template for an SME in 2026

An ERP requirements specification exists to obtain comparable, priceable responses, then becomes the reference for the project and for acceptance testing. It describes your processes, your volumes, your constraints and what you expect from the provider. It is not meant to become a catalogue of 300 functions that every publisher will tick "yes": such a list produces identical answers and says nothing about how the software will handle your business. If your need is mainly about customer relationships, first reread the difference between ERP and CRM.

It is written in-house. The managing director is the sponsor: they set the objectives and make the calls. An internal project lead, often the CFO or management controller, holds the pen. Each process (purchasing, sales, stock, production, accounting) has a business owner who describes how it works today and what must change. The IT manager or your IT provider writes the technical part. Do not hand the drafting to an integrator you will then consult: they will describe what their software can do. General management and finance sign it off, after a review by the business owners.

A good ERP specification fits into ten parts, in an order the responses will have to follow. The first sets out the context and objectives: business, companies and sites, the reason for the project and a few measurable objectives, such as closing the month faster or removing re-keying between quote and invoice. The second describes the scope by process: quote to cash, supplier order to payment, receipt to stock, entry to close, and production or projects where relevant. What is out of scope is written down too.

The third gives the volumes: users by profile (data entry, viewing, approval), companies, currencies, items, customers, invoices issued and received per year. These figures drive licensing and design. The fourth lists the existing systems and interfaces: software being kept, critical Excel files, payroll, online shop, bank, logistics, with the direction and frequency of each flow. The fifth covers data migration: master data, open items, history, and who cleans and validates.

The sixth covers technology and security: hosting, multi-factor authentication, role-based rights, backup, return of data at the end of the contract. The seventh lists the French regulatory constraints, detailed below. The eighth sets out the selection criteria and scoring grid, announced to candidates before they respond. The ninth sets the timeline and budget: target go-live date, periods to avoid such as year-end close, and a range agreed internally before the consultation. The tenth imposes the response format: for each requirement, coverage as standard, by configuration, by extension or by custom development, and a quote that separates licences, integration, migration, training and support.

Your future ERP must comply with specific texts, and the specification should cite them so that every candidate commits to them. According to the DGFiP FAQ published on impots.gouv.fr (version of 1 September 2026), all businesses have had to receive their invoices in electronic format since 1 September 2026, through an accredited platform, and SMEs must issue them in that format by 1 September 2027 at the latest. Software only counts as a "compatible solution" if it offers the functions the reform requires and is connected to at least one accredited platform. Ask each candidate which platform they connect, who signs the contract with it and how the ERP handles the four new mandatory statements: the customer's SIREN number, the category of transaction, the option to pay VAT on debits, and the delivery address if it differs. The details are in our article Business Central and e-invoicing.

Retention comes next. Article L123-22 of the French Commercial Code requires accounting documents and supporting documents to be kept for 10 years. Article L102 B of the French Tax Procedures Code sets 6 years for documents subject to tax checks and requires those created or received electronically to be kept in that form. Article L47 A of the same code requires a business with computerised accounts to provide, during a tax audit, a copy of its accounting entries files, the FEC. So require FEC production, archiving of documents for the legal period and, if history is not migrated, a way to keep the old system readable. If the ERP is hosted by a third party, Article 28 of the GDPR requires a written contract with that processor, covering in particular data security and the return or deletion of data at the end of the service. Have these requirements checked by your chartered accountant and, for personal data, by your DPO.

A good requirement describes a process and the expected result, not a function. "The software must handle three-way matching" will get a "yes" from every candidate. Describing what happens in your business forces each one to show how they do it, and at what price. Each requirement carries an identifier, a process, an owner and a priority: mandatory (without it, the candidate is eliminated), important (it weighs in the score), desirable (it breaks ties). If almost everything is mandatory, your trade-offs are still to be made.

Here is how to word requirement PUR-07, supplier invoice matching, with mandatory priority: "Our supplier invoices arrive through our accredited platform, at a rate of [your volume] per month. The system matches each invoice against the purchase order and the goods receipt. If quantities and prices agree, the invoice is ready to post without re-keying. If there is a discrepancy, it goes to the relevant buyer for approval, with the difference shown, and cannot be paid before their decision. To be demonstrated on our data: a compliant invoice, an invoice with a price difference, an invoice without a purchase order." The candidate can price this text, and you can check it in the demo and then at acceptance testing.

The most common mistake is downloading an ERP specification template as a PDF and filling it in as is. Such templates help you forget nothing, but they describe nobody's business. The second is copying the current set-up, Excel files included, which amounts to paying for an ERP to reproduce your workarounds. The third is forgetting volumes, migration and interfaces, precisely the items hardest to price after the fact.

Building the grid after reading the offers amounts to picking the favourite offer and justifying it afterwards. Confusing the publisher, who makes the software, with the integrator, who implements it, means forgetting that the latter is often the one you are really choosing. Finally, do not underestimate your teams' time: the business owners who write the specification will also test the configuration, on top of their usual work.

Compare the responses on three pieces of evidence: a demo on your own cases, references you call yourself and a total cost over several years. After the written responses, shortlist three or four candidates and send them a scenario in advance, drawn from your mandatory requirements, with your anonymised data: a customer, an order, an invoice with a discrepancy, a month-end close. A standard demo shows what the software does best, yours shows what it does with your business. Score during the session, with several people, using the announced grid.

For references, ask for customers of a similar size and sector, and ask the question that matters: will the consultants who ran their project be on yours? For cost, add up licences, integration, migration, training, support, extensions and accredited platform. For licences alone, Microsoft lists on its French website Business Central Essentials at €69.30 excluding VAT per user per month and Team Members at €6.90, with annual commitment and payment (checked on 26 October 2026): 20 Essentials users and 10 Team Members come to €1,455 excluding VAT per month, or €17,460 excluding VAT per year, before any services. The other cost items are detailed in our article on the price of Business Central and of a project.