ERP Requirements Consultant, Portugal

What sits inside a Portuguese requirements specification

A Portuguese requirements document has to serve readers with different concerns: the implementer pricing the work, the accountant who answers for the books, the data protection advisor and the staff who will test the system. I split it into chapters so each reader can find their part without reading the rest:

• Scope and context: entities, sites, sales channels, currencies and the processes covered now and later.
• Process requirements: sales and billing, purchasing, stock and dispatch, production or service delivery, collections, payments and the close.
• Statutory requirements with evidence: invoicing software rules, series and ATCUD, SAF-T, transport documents, public sector e-invoices and archiving.
• Non-functional requirements: where data lives, GDPR, who may do what, the audit record, speed at sites and support terms.
• Connections to other systems and the data taken over.

A requirement line has a fixed shape: a reference, one statement, why it matters, the priority, the owner and either an acceptance note or, for statutory lines, the evidence a vendor must supply. Background on how things work today stays in the process maps, which keeps the requirement lines short enough to answer one by one.

The discovery that feeds the document, from billing maps to the questions for your accountant, is the subject of my Portuguese ERP business analyst page. Here the focus is the specification and how it is used once written.

Invoicing rules written as lines a vendor must evidence

Portugal regulates how commercial documents are issued in unusual detail, and status under the tax authority's software certification rules belongs to a specific product and version. A requirement that says "compliant invoicing" therefore proves little. Your accountant confirms which rules apply; I write lines that oblige each vendor to show how the proposed setup meets them:

• Software status: the vendor states in writing the status of the exact product, version and deployment proposed under the invoicing software rules, and how that status is maintained through upgrades.
• Series and ATCUD: every document series needed is communicated before first use, and each document prints its ATCUD and QR code; a sample invoice and credit note are supplied.
• SAF-T: the system produces the invoicing and accounting files your accountant needs, and a sample file from test data is provided for their review.
• Transport documents: goods movements generate the required document and, where your accountant confirms it applies, the communication to the tax authority before transport begins.
• Public sector: invoices to public bodies are issued in the required electronic format.
• Archiving: issued documents remain legible and tamper-proof in the archive for as long as your accountant says the law requires.

Answers to these lines are reviewed with your accountant and, where needed, a legal advisor. I do not confirm the status of any product myself; the specification simply makes sure the question is asked precisely and the answer is on file.

Hosting, access and interface requirements

The non-functional chapter covers the points that rarely feature in a demo but determine whether auditors and everyday users will accept the system:

• Hosting and GDPR: the country of the data center for live data and copies, the third parties involved, the approval route for support access and the export you receive at exit. Your data protection advisor reviews the answers.
• Access and segregation: roles per entity, with document issuing, credit notes and payment release kept apart.
• Audit trail: a readable record of changes to customer tax numbers, bank details, prices and series.
• Sites: usable speed for a warehouse, a hotel front desk or a nearshore service team, written as tasks staff must complete without waiting.

Interface requirements state the direction, trigger, format, owner and error handling for each connection: SEPA transfers and direct debits, Multibanco payment references and their reconciliation, bank statements, the payroll file from your provider or accountant, accountant access to ledgers and SAF-T output, and links to e-commerce, CRM or property management systems.

Migration requirements name the masters, open items, document history and series continuity moving from packages such as PHC, Primavera, Sage or Moloni, who cleans each data set and how the reconciliation is signed. Specifying this early stops it from becoming a client task hidden in the implementer's assumptions; my ERP data migration service goes deeper on the method.

Ranking requirements and carrying them into bids and contract

Not every line deserves the same weight. Owners rank their requirements as must, should, could or not now, and a must needs a reason: a legal obligation confirmed by the accountant, a customer or bank demand, or a control the company depends on. The sponsor settles disagreements so the ranking reflects business value rather than habit.

Each line then gets a chain of references. The demo script names the step where the vendor has to show it; the fit-gap record shows whether it is standard, configured, delivered by an add-on or built; the statement of work cites the clause covering it; and an acceptance test proves it before go-live. Statutory lines also link to the evidence received, so the file shows who claimed what.

When you invite proposals, the frozen specification becomes the requirement annex, and implementers answer every line in the same response format. That is the method under ERP RFP consulting, and the shortlisting stage is described on my ERP selection page for Portugal. For the contract, I recommend that the agreed version sits alongside the statement of work, together with the customization guardrails: changes to invoicing behavior must stay within vendor-supported paths and be assessed for compliance impact before deployment.

Common gaps in Portuguese specifications and version control

Certain omissions make Portuguese requirement documents risky, and they usually come to light during configuration or in the first days live:

• Software status taken from a brochure rather than confirmed for the exact version and hosting proposed.
• Series planned for the main company only, with none for a second entity, a new store or credit notes.
• Transport documents treated as a warehouse matter and left out of the specification.
• SAF-T assumed to work by default, with no sample reviewed by the accountant.
• A hybrid setup, with a separate invoicing system feeding the ERP, chosen without interface requirements in both directions.
• Migration ignoring document history that must remain readable after the old package is retired.

Maintaining the document is part of the job. The document carries a revision table and a log of every edit. One issue is frozen for bidders, a later one for the contract, and anything after that moves through change requests recording who asked, why and with what effect. Process owners approve their chapters, management approves the whole, and comments are closed in writing.

Delivery is remote, using online workshops and shared drafts; your board can still request an in-person session by arrangement. The specification, evidence file and traceability matrix stay with you. For more on how I work with Portuguese companies, see the Portugal overview or ERP requirements gathering.