What I've learned about Portuguese fiscal compliance in D365FO
Portugal usually gets treated like just another country on a rollout plan, sized about like Spain or Italy. From what I've seen it behaves differently, and it's not really a matter of how much work it is. Portugal regulates the software itself, not only what it produces.
Certification limits the whole program, not just the invoice
Portuguese law says invoices have to be issued by software certified by the tax authority, and the certification number shows up on every document the software produces. The certification is granted to a program, against a declared set of requirements, and it limits what that program is allowed to let a user do.
That was a different starting point than I expected. Usually, if a requirement is inconvenient, you can work around it by changing a process: post it differently, correct it later, adjust it in reporting. Under certification, a lot of those workarounds are closed off by design. Documents can't be deleted. Sequences can't have gaps. Cancelling something means a new document with its own number, not making the old one disappear. Corrections go through credit notes, not edits.
In practice this removes options from the whole solution, including parts that seem to have nothing to do with Portugal. That's why it's expensive to find out about late.
A numbering series is a fiscal object, not just a counter
In most systems a number sequence is just a technical convenience. Something that produces unique identifiers, that you can reset, split, rename, or replace when the business restructures.
In Portugal a series has to be registered with the tax authority before it's used. The registration returns a validation code, which becomes part of the ATCUD printed on every document in that series, next to the document QR code, mandatory since 1 January 2023. A series has a start, an expected sequence, and a fiscal identity attached to it. It can't be quietly retired, reused across legal entities, or reordered because a data migration produced documents out of order.
That changes decisions that would normally be routine. Splitting a series by site or by document flow becomes a fiscal act with a registration step. Loading historical documents into a live series stops being a data migration problem and becomes an issuance problem. And environment refreshes need thinking about too: a sandbox copied from production carries series codes that belong to real registrations.
The hash chain limits ordering, not just content
Certified invoicing signs each document over a string that includes the signature of the previous document in the same series and document type. So the chain encodes the order documents were issued in, and that's what gets checked against the audit file.
What that means in practice is that issuing a document is a serialised operation within its series. Anything that wants to issue in parallel, a high-throughput interface, a batch split by customer, an integration replaying a queue, ends up contending for one chain per series. It's something you can plan for ahead of time, but it's not a fun thing to discover during a volume test three weeks before go-live, because the fix is usually architectural.
SAF-T PT is a full extract, not a report
SAF-T PT often gets planned like a reporting deliverable and tested with a month of demo data. It's actually a full structured extract of the accounting and invoicing data for a period, checked against a published schema, and it has to match what was actually issued.
Two things follow from that. First, matching the schema is all or nothing: a file that's 99% correct is a file that doesn't validate, and that tends to show up right when the tax authority is asking for it, which isn't a great moment to run out of slack. Second, the file grows with the business. An export built to assemble everything in memory can work fine for years and then, at some volume, just stop working entirely instead of getting slower. Rewriting it to stream instead of build everything in memory is well understood work, and it's much cheaper to do before the file is due than after.
Goods move only after the tax authority has been told
Under the movement-of-goods regime, transport documents have to be communicated to the tax authority before the transport starts. Not the same day, not in a nightly batch. Before.
This is probably the requirement most likely to get missed, because it doesn't look like a finance requirement at all. It lands on the warehouse. A picking and shipping process built around a nightly interface has to become closer to real time, with a call sitting in the path of a truck leaving the yard, and a real fallback for when that call fails, because the legislation has contingency procedures built in and the system has to support them, not improvise them.
What I take from this
None of these requirements is complicated on its own. The certification rules are public, the ATCUD spec is published, the SAF-T schema is published, and the transport rules are readable in an afternoon. What makes Portugal expensive is timing. Every one of these ends up being a constraint on the architecture, and they usually get read properly during UAT, when the architecture is already fixed.
The cheapest thing to do is read them early, and treat Portugal as a set of things the solution has to hold true rather than a package installed near the end.
Sources: Portaria n.º 363/2010 (certification of invoicing software); Portaria n.º 195/2020 (series communication, ATCUD, document QR code); Decreto-Lei n.º 147/2003 as amended (movement of goods); the SAF-T (PT) schema and technical specifications published by the Autoridade Tributária e Aduaneira. Verify all references and dates against Diário da República.