ERP Requirements Consultant, Spain

How a Spanish requirements specification is organized

Spanish companies arriving at an ERP project often bring a desktop invoicing program, a gestoría that keeps the books, and spreadsheets for the rest. The requirements document is the first place where all of that is described as one system. I organize it so that each reader can go straight to their chapter:

• Scope: companies, tax territories, warehouses, stores and what this phase covers.
• Functional requirements grouped by business process: selling, buying, stock, projects and closing the books.
• Statutory requirements: invoice reporting, record integrity, VAT or IGIC books, informative returns and public sector invoicing, as your asesor fiscal confirms.
• Non-functional requirements: integrity, hosting, access, audit, performance and support.
• Interfaces and migration.

Each line carries a territory attribute, such as common territory, Canary Islands, Basque provinces or Navarre, so the integrator sees at once which tax logic it must handle. Working out which territory applies where is discovery work, part of my Spanish ERP business analyst service.

Priorities are set line by line. Owners mark each requirement as must, should, could or not for this phase, and a must needs a reason: a tax obligation, a bank or customer requirement, or a control the business relies on. Management settles conflicts between departments. The result is a list an integrator can respond to without guessing what matters.

Invoice reporting and software rules as testable statements

The rules on invoice reporting and invoicing software are where loose wording costs most. Your asesor fiscal decides which obligations apply to each company; I write lines that make each integrator show, not claim, how the system meets them.

Because these rules continue to develop, the specification also asks how updates are delivered: by the vendor's standard localization, by the integrator's own module or by a third-party connector, and who pays when the rules change.

Integrity, hosting and the other non-functional needs

In Spain some non-functional requirements carry legal weight. Invoicing software rules expect records that cannot be silently altered, which makes integrity and event logging a requirement in their own right rather than a technical detail. I collect these needs in a separate chapter:

• Integrity: no deletion of issued invoices, corrections only through corrective documents, and an event log covering exports, restores and configuration changes.
• Hosting and data protection: the data center region for live data and backup copies, the list of subprocessors, the approval route for support logins and the export you receive if you leave. Your data protection advisor reviews the answers against GDPR and Spanish data protection law.
• Access control: roles per company and function, with creation and approval of supplier payments separated.
• Audit trail: readable history of changes to bank accounts, prices, tax codes and customer data.
• Performance at sites: stores, warehouses or a Canary Islands branch completing everyday tasks without delay, written as user scenarios.
• Support: end-user support in Spanish, and response times that protect the short reporting windows for invoice records.

Written as requirement lines, these points can be scored during selection and written into service terms. Left out, they surface as surprises once the system is live and the reporting clock is already running.

Interfaces, migration and the route into offers and contract

Spanish finance teams rely on bank files and outside advisors, so the interface chapter is often the longest. For each interface I record direction, trigger, format, owner and what happens on error: SEPA direct debit remittances and returns, transfers and confirming files to each bank, bank statements, exports or access for the gestoría, the payroll journal, point-of-sale and e-commerce feeds, and any public sector invoicing channel. Migration requirements list the masters, open items, invoice series and history moving from your current program, the cleaning owner and the reconciliation that proves the result.

Every line then gets a trail. It points to the demo step where it must appear, the integrator's fit-gap answer (standard, setup, add-on or custom code), the statement-of-work clause that covers it and the acceptance test that proves it. When a line has no test, the gap is visible before signature rather than after go-live.

In an integrator request, the frozen document forms the requirement annex, answered in a common response format; see ERP RFP consulting for that method and my ERP selection page for Spain for the comparison stage. At contract stage the statement of work cites the agreed issue of the document, and acceptance follows the linked test cases, which my UAT service builds from the same references.

Weak spots in Spanish specifications and keeping the document current

Several omissions put Spanish requirement documents at risk, and each tends to surface late:

• Received invoices left out of the reporting chapter, as if only sales mattered.
• A single tax logic assumed for a group that also has Canary, Basque or Navarre entities.
• Simplified invoices from stores or counters not described, although they need their own series.
• Confirming and remittance files specified for one bank only.
• The gestoría's role unclear, so nobody owns the exports it needs.
• Update responsibility for compliance modules never written down.
• Migration that ignores invoice series continuity and records that must stay readable.

A specification also needs housekeeping. I keep a version history and change log, freeze an issue when integrators are invited and a second when the contract is drafted. From then on, edits arrive as change requests stating the reason and the effect on cost and plan. Process owners approve their chapters first; management then signs the whole, and every comment gets a written answer.

The work is remote: workshops on video calls, shared drafts and short review sessions, with a visit by arrangement if your steering group wants one. The specification, annexes and traceability matrix are yours to keep. See my Spain overview or ERP requirements gathering for related work.