ERP Business Analyst in Portugal

Why invoicing rules come first in a Portuguese BRD

Portugal has a tightly specified invoicing regime. Invoices and many other commercial documents are generally expected to come from invoicing software that holds certification from the tax authority, with each document carrying a unique code known as ATCUD and a QR code, and with document series handled in a controlled way. These are not formatting preferences. If the chosen platform cannot meet them, either directly or through a compliant invoicing tool beside it, the design changes.

So the first requirements area I document is document issuing. With your finance team I record:

• Every document type you issue today: invoices, simplified invoices, invoice-receipts, credit and debit notes, pro formas and delivery documents.
• How series are created, who uses which series and what happens when a document is cancelled or corrected.
• Where documents are issued: the ERP itself, a point-of-sale system, a property system or an external billing tool.
• Which data must appear on each document and in which language.

I never state that a product is certified. For each shortlisted platform, the requirement is that the vendor or implementer shows current evidence for the exact product, edition and setup, and that your accountant accepts it. Where a platform does not cover this itself, the fit-gap analysis records the gap and the realistic options for closing it.

Goods movements, transport documents and warehouse data

Distributors, manufacturers and exporters in Portugal deal with a second set of document rules that sits in the warehouse rather than in finance. Goods in circulation generally need a transport document, and depending on the movement and the type of business, details may need to be communicated to the tax authority before the goods leave. Your accountant or advisor confirms which movements apply to you; my job is to make sure the system specification covers them.

In process sessions with logistics and sales, I trace each kind of movement: sales dispatches, transfers between your own warehouses, consignment stock, returns from customers and goods sent to subcontractors. For each one, the requirements state what triggers the document, which data must be complete beforehand, such as addresses, load and unload points, vehicle details and customer tax numbers, and how the reference received back is stored.

This matters because a dispatch that cannot be documented in time becomes a truck waiting at the dock. When warehouse staff currently fill gaps by hand in a separate tool, the map shows it plainly. During process mapping, these flows are drawn alongside order picking and invoicing, so the BRD connects what happens on the floor with what the tax files later need.

SAF-T files, the chart of accounts and accountant review

Portugal uses its own version of the SAF-T standard, and the file is shaped by decisions taken long before anyone exports it. Account structure, tax code design, how customers and suppliers are identified by tax number, and how invoicing data relates to the general ledger all affect whether the export is complete and consistent.

In the requirements document I describe these as data rules rather than as tax advice:

• How the chart of accounts aligns with the national accounting framework your accountant works with, and how it maps to any group chart a foreign parent imposes.
• Which tax codes and exemption reasons the business uses, written in plain language and confirmed by the accountant.
• Where invoicing data originates when billing runs in a separate tool, and how the two sources stay aligned.
• Who generates the file, how often, and how it is checked before it is submitted.

During vendor demonstrations, I ask each candidate to produce a sample export from realistic test data rather than describe the feature. During UAT, the accountant reviews a full test file. Treating the export as a test case, not a checkbox, is the most reliable way to avoid surprises after go-live. Current filing obligations should always be checked with your tax advisor.

Service centers, hotels and the processes beyond the ledger

Two kinds of Portuguese operation bring requirements that a standard trading template will miss. The first is the service or technology center owned by an international group. Its revenue is mostly intercompany, so the important processes are timesheets or activity drivers, cost pools, markup rules agreed by the group's transfer pricing advisors, and invoices to sister entities in several currencies. I map who approves time, how costs are allocated and how the local ledger reconciles with the group's consolidation, then write each step as a requirement the platform must support.

The second is hospitality and tourism. A hotel group often runs a property management system, restaurant tills and booking channels, with finance receiving summaries. Requirements here focus on which system issues the customer document, how daily revenue and deposits flow into the ledger, how purchasing works across properties with shared suppliers, and how seasonal staffing affects cost reporting.

In both cases the BRD describes interfaces in business terms, such as what data moves, how often and who corrects errors, so integration partners can estimate accurately. See my requirements gathering approach for how these sessions are run.

English documents with Portuguese review built in

I run workshops and write every deliverable in English, which keeps them readable for international parents, auditors and implementers. Some outputs, though, must be in Portuguese: invoice wording, legal texts on documents, labels and the step-by-step procedures warehouse or front-desk staff will follow. Those artifacts are produced or reviewed by bilingual members of your team, or by a local partner of your choosing, and the BRD lists each one with an owner so nothing is left to the final week.

A short glossary helps. For each Portuguese tax or document term used in workshops, the glossary records the local term, an English explanation and the requirement it links to. Reviewers can then confirm meaning without rewriting the documents.

Sessions take place by video while Portuguese business hours overlap with my working day in India, and everything between sessions happens in shared documents with comments. Sign-off is recorded in writing, area by area. For context on the wider ERP decision, see my ERP consultant page for Portugal, the Portugal overview and the platform notes for Odoo in Portugal and Dynamics 365 in Portugal.