ERP Requirements Consultant, Italy

Why an Italian ERP needs a written specification

Many Italian companies choose software through trust: the software house that already runs the accounts, a partner recommended by the commercialista, a system a competitor in the same district uses. Trust is useful, but it does not tell you what the offer includes. Without a written specification, the partner quotes what they assume you need, and the difference shows up as change requests once configuration starts.

The specification I prepare is organized so each reader finds their part:

• Scope: companies, plants and warehouses, sales channels, currencies for export and the processes in this phase.
• Functional chapters: sales and agents, delivery notes and invoicing, purchasing, stock and production, subcontracting, collections and payments, record to report.
• Statutory and advisor chapter: what the exchange system, preservation, VAT registers and payroll handoff must produce.
• Non-functional chapter: hosting, GDPR, access, audit trail, performance and support.
• Interfaces and migration: systems connected and data inherited.

Every requirement is one sentence that can be shown or tested, followed by its reason, priority and owner. Long descriptions of today's process belong in the process maps, not in the requirement line. The discovery work behind the document, including interviews with owners and administration, is covered on my ERP business analyst page for Italy.

SdI, preservation and VAT registers as testable lines

The phrase "compliant with Italian e-invoicing" appears in nearly every offer and proves nothing. I replace it with lines a partner has to demonstrate. Your commercialista confirms what each line must achieve; I make sure the wording is specific enough to test. Typical examples:

• The system generates the electronic invoice file from the posted invoice, sends it through the chosen channel and shows the transmission status and the returned notification on the invoice record.
• When the exchange system rejects a file, the user sees the reason, corrects the invoice and resends it while numbering stays consistent, as your advisor confirms.
• Supplier invoices received as structured files are imported, matched to purchase orders and goods receipts, and flagged when price or quantity differ.
• Issued and received invoices reach the preservation service named in the contract, and the company can retrieve a preserved document on request.
• VAT registers and the figures for the periodic settlement can be produced per company for the commercialista in the agreed format.
• Deferred invoices are generated from the delivery notes of the period and reference them.
• The payroll journal from the labor consultant imports by company and cost center, with a check report.

Where a treatment depends on the customer, such as invoices to public bodies that may require specific codes or split payment, the line says which customers it applies to and leaves the tax treatment to your advisor. That keeps the document precise without turning it into tax advice.

Hosting, access and the needs nobody demos

Non-functional requirements rarely appear in an Italian partner's offer unless someone asks. They often decide whether the system is acceptable to your auditor, your data protection advisor and the people at a plant away from head office. I write them as a separate chapter so they are scored and contracted like any feature:

• Hosting and GDPR: where production data and backups are held, which subprocessors can reach them, who approves support access, which data processing agreement applies and how all data is returned at exit. Your lawyer or data protection advisor reviews the answers.
• Access control: separate roles for administration, sales agents, warehouse staff and external workshops, with agents limited to their own customers and commissions.
• Audit trail: a readable history of changes to customer bank details, prices, VAT codes and posted documents.
• Remote sites: acceptable working speed for a warehouse, a second plant or a sales agent on a tablet, written as tasks the user must complete without delay.
• Availability and support: maintenance outside working hours, support in Italian for end users, and an escalation path during the VAT settlement and month-end period.

Written this way, a promise made in a meeting becomes a line in the contract, with a test attached.

From priorities to partner offers and the contract

Owners in Italian companies often want everything the old gestionale did, plus everything it could not do. Prioritization makes the list realistic. Every process owner places each line in a bucket: must, should, could or later, and justifies any must with a legal obligation confirmed by the commercialista, a commitment to a key customer or a control the business cannot run without. The owners or managing director settle the disputes.

I then link every line forward through a traceability matrix:

1. Requirement and priority.
2. The demo script step where a partner has to show it.
3. The fit-gap answer: standard, configuration, add-on module or development.
4. The section of the statement of work that covers it.
5. The user acceptance test that proves it.

When you ask partners for offers, the frozen specification becomes the annex partners complete requirement by requirement in a common response format, which is the approach described under ERP RFP consulting. That works whether you compare several partners or ask your current software house for an upgrade offer; the comparison stage is covered on my ERP selection page for Italy. Once a partner is chosen, the contract version of the document travels with the statement of work, and final acceptance depends on the linked test cases rather than to a general statement that the system works.

Gaps that put Italian specifications at risk

Some omissions recur in Italian requirement documents and tend to surface only in configuration or on go-live day:

• Inbound electronic invoices left out, as if the exchange system only mattered for sales.
• Preservation assumed to be "handled by the commercialista" with no line saying how documents get there or come back.
• Bank receipt collections and unpaid returns missing from the collections chapter.
• Agent commissions described in one sentence, although the rules sit in individual agreements.
• Material sent to outside workshops not tracked, so stock held by subcontractors disappears from view.
• No interface requirement for the labor consultant's payroll journal.
• Migration limited to master data, with open items, agent balances and preserved history ignored.

Equally important is how the document is kept. I maintain a numbered version history, a change log naming who asked for each change and why, and a separate list of open points with owners. After the contract version is frozen, any change passes through a change request so its cost and impact are visible. Approval runs from each process owner to management, with comments closed in writing.

The work runs remotely through video workshops and shared documents; a meeting in person can be added by arrangement. You own the specification and its annexes. My Italy overview and the ERP BRD consulting service describe the wider context.