ERP Requirements Consultant, Belgium

Laying out a specification across languages and entities

Belgian organizations often run several entities or sites across Flanders, Wallonia and Brussels, and the same process can work slightly differently in each. The specification is organized by process first, such as quote to cash, purchase to payment, stock and logistics, projects or services, and finance and close, with a note in each section on the entities and sites it applies to.

Every need is written once, in a sentence a bidder can mark as covered, partly covered or not covered. It carries a code, its origin, an internal owner, a priority level and a description of the evidence a key user will look for at acceptance.

Language needs a decision before anything is sent out. The engagement runs in English, which suits sponsors and parent companies abroad. Bidders may prefer to answer in French or Dutch, and key users may need to read their sections in their own language. I recommend fixing one reference version in the document itself and treating translations, produced by your team or a translation partner, as convenience copies. A glossary pairs English terms with the French and Dutch words your staff use, so test results are not lost in translation. The general method follows my ERP requirements gathering approach.

Peppol, CODA, listings and payroll journals as checkable needs

A need that reads "Belgian localization included" tells nobody what will be tested. I break Belgian obligations into needs with a visible result, and every one is reviewed by your accountant or tax advisor, who decides how the rules apply to you:

• Sales invoices and credit notes can be sent as structured documents over Peppol, through an access point named in the bid, and delivery status is visible on the invoice.
• Incoming Peppol invoices are received, checked against the purchase order and goods receipt, and archived in their original form next to the booking.
• CODA statements from each bank import automatically, and payments carrying a structured reference are matched to the right open item.
• VAT codes produce the grid figures for the periodic return, and a report reconciles them with the ledger.
• Data for the annual customer listing and the intra-community listing can be produced from the records.
• Payroll journals from your social secretariat post to agreed accounts and cost centers, with a check that totals match.
• Accounting documents and their source files stay retrievable for as long as your advisor says the law requires.

Public-sector customers may expect invoices through their own electronic channel, and Belgium is following the wider European direction toward transaction reporting, so the specification asks how each product handles that today rather than on a roadmap. The comparison of bidders against these needs continues on my ERP selection page for Belgium.

Hosting, the works council and three-language outputs

A specification that lists only processes leaves the behavior of the system to the partner. A separate section of platform rules closes that gap.

On data protection, bidders must disclose the country of their data centers and backup copies, any access by support staff from outside the EU and the legal safeguard used for it, the list of subcontracted processors and the content of the GDPR agreement they will sign. Your DPO or privacy counsel decides what is acceptable, and the answers are kept with the specification so they can be cited later.

Logging calls for careful wording. Where a works council exists, and where collective agreements on monitoring employees apply, information about what an ERP records on individual users can become a consultation topic. The specification therefore asks that tracking of individual users, productivity reports and time capture can be limited per role and are described in plain terms, so whatever is agreed internally can be configured and verified. Legal interpretation remains with HR and counsel.

Output needs are especially important in Belgium. Each customer-facing document, such as quotes, order confirmations, delivery notes, invoices and reminders, is listed with the language versions required, chosen by customer language rather than by user. Internal reports may stay in English for a parent company. Before release, a native-speaking colleague or a Belgian partner proofreads every translated layout. The section ends with access profiles and signing limits, an audit history for prices and bank details, response times at month-end, and behavior for depots or field staff when the connection is weak.

Exchanges, data takeover and what must be live first

Each exchange with an outside party is specified on its own: sending party, triggering event, data carried, rhythm, responsible person and the alert raised when it fails. Belgian lists typically include the Peppol access point, CODA from each bank and payment files back to them, the social secretariat, the external accounting firm if it keeps working in its own package, a web shop, a warehouse provider and any group reporting. More technical depth sits on the ERP integration page.

Takeover needs say which customers, suppliers and items are carried across, with their language preference and structured reference details, how much history is brought over, how opening balances are agreed with the accountant, and how the previous package stays readable once its license ends.

Priority follows a MoSCoW logic written as plain levels: needed at go-live, needed soon after, welcome if inexpensive, and excluded for now. Peppol, CODA, VAT and payroll journal needs start at the first level, together with any agreed works council needs. Exclusion criteria for the bid round come only from that level and are worded so a bidder who fails one receives a stated reason. Each section owner agrees the levels before release, and the management team confirms them.

Bids, the agreement, version control and gaps to watch

Bidders answer the released specification need by need, using a fixed answer code and a comment. Partner proposals in Belgium can differ widely in format and language, and this makes them comparable on substance. The bid process itself is covered under ERP RFP consulting.

The agreement should name the released reference version. Once the partner writes its design, each need should map to a design note, and anything answered as standard should not reappear as paid extra work. During testing, needs are followed to their acceptance tests and results recorded in the evidence trail.

Every release carries a version label, date, owner and change record entry, and translated copies state which reference version they reflect. Section owners sign their parts, the finance lead signs the obligation needs after the accountant's review, and management signs the whole.

Belgian specifications are exposed in predictable places: Peppol sending covered but receiving forgotten, CODA and structured references assumed, no plan for the social secretariat journal, documents specified in one language only, nothing on logging that may concern the works council, and no reference language defined. Each is checked before release. I have no tie to any software publisher or partner, take no commissions, and visit only by arrangement. See my work in Belgium.