Portugal guide

Running Dynamics 365 Finance & Operations in Portugal

What a global D365FO template has to handle before it can invoice in Portugal. Most of these rules apply to the software itself, not only to the documents it produces. That is why they are expensive to discover late.

The life of an invoice in Portugal

  1. 1Register the series Each document series is communicated to the tax authority before its first use. AT returns a validation code
  2. 2Issue the document Signed into a hash chain per series. ATCUD and QR code printed on it. Nothing sent yet
  3. 3Move the goods The transport document is communicated before the goods leave. AT returns a movement code
  4. 4Correct it Credit or debit note for value or VAT. Cancel and reissue for formal errors. Seen in the invoice data
  5. 5Report it Invoice data is communicated to the tax authority every month. Invoice data in e-fatura
  6. 6Prove it A full SAF-T (PT) extract on request, from records kept for years. Hash chain checked against the file

What the ERP does What the tax authority gets back or receives

Certified invoicing software

Most companies in Portugal, and in practice any company running D365FO, must issue invoices from software certified by the tax authority. Small businesses below the legal thresholds have alternatives, such as the tax authority's own invoicing application. The certificate number appears on every document. Certification is granted to a program against a published set of requirements, and those requirements limit what the program lets a user do.

In practice: documents can't be deleted, numbering can't have gaps, and cancelling a document means a new status or a new document, not making the old one disappear. Each document is signed with a hash that includes the signature of the previous document in the same series. Removing or reordering one breaks every document after it.

For a D365FO rollout: issuing becomes a serialised operation per series. High-volume interfaces and batch posting have to be designed around that. More in this briefing.

Series registration and ATCUD

Every document series has to be communicated to the tax authority before it is used. The tax authority returns a validation code. That code, together with the document's sequential number, forms the ATCUD, which is printed on the document next to a QR code with the main fiscal data.

For a D365FO rollout: a number sequence becomes a fiscal object. Splitting series by site or flow needs a registration step, migrating historical documents into a live series is an issuance problem, and sandboxes copied from production carry real series codes.

Transport documents

Under the movement-of-goods regime, transport documents are communicated to the tax authority before the transport starts. The tax authority returns a code that travels with the goods. The rules include contingency procedures for when that communication fails. Small businesses below a turnover threshold are exempt from communicating, which is rarely the case for a D365FO customer.

For a D365FO rollout: this lands on the warehouse, not on finance. A shipping process built around a nightly interface has to move closer to real time, with a fallback that follows the legal contingency rules.

Corrections and cancellations

Since Ofício Circulado 25120/2026, the tax authority is explicit: credit and debit notes correct the taxable value or the VAT, and a credit note can't be used to cancel an invoice that was wrong in form or one for an operation that never happened. Formal errors are cancelled and reissued. Invoices for operations that never happened are cancelled, with no new invoice. A real operation that later ends, such as a return of goods, is still corrected with a credit note. Recovering VAT charged in excess needs proof that the customer knew.

For a D365FO rollout: the system needs a cancel and reissue flow that keeps the original supply date, and credit and debit notes that can carry VAT only. Briefing on the circular.

Monthly invoice reporting

Invoice data is communicated to the tax authority every month, either as a SAF-T (PT) invoicing file or through a web service. This is separate from the full audit file and separate from the transport document communication.

For a D365FO rollout: the monthly file has to match what was actually issued, document by document, including cancelled ones.

SAF-T (PT) and keeping the records

SAF-T (PT) is a full structured extract of accounting and invoicing data for a period, validated against a schema published by the tax authority. It is what an inspector uses to verify the hash chain and the books. A file that is almost right doesn't validate. An annual accounting SAF-T submission has been announced and postponed several times. Under current law it starts with 2027 periods, filed in 2028. The 2027 State Budget proposal would move it to 2028 periods, filed in 2029.

The records behind it have to be kept for the legal retention period, and still be readable and exportable at the end of it. Archiving and data retention features in D365FO have to be checked against that before they are switched on.

For a D365FO rollout: the export has to scale with the business, and archived years still have to produce a valid file. Briefing on archiving to Dataverse.

Electronic invoices and qualified signatures

When an invoice is sent electronically, with the customer's acceptance, its origin and integrity must be guaranteed. The decree lists three ways to do it: a qualified electronic signature, a qualified electronic seal, or an EDI agreement. Plain PDF invoices have been accepted under a transitional rule that has been extended more than once.

For a D365FO rollout: the signature applies to a stored final document, with a key held outside the ERP. That is a different mechanism from the certified-software hash. Latest briefing.

Also on the list

Stamp duty and the periodic declarations around it, communication with the tax authority's web services, and keeping all of this working through Microsoft's service updates. How service updates reach production.

Main sources: Portaria n.º 363/2010 (certified invoicing software); Portaria n.º 195/2020 (series communication, ATCUD and QR code); Decreto-Lei n.º 147/2003 as amended (movement of goods); Decreto-Lei n.º 28/2019 (invoicing and electronic invoices); Ofício Circulado 25120/2026; the SAF-T (PT) schema and technical specifications published by the Autoridade Tributária e Aduaneira. This page describes the rules in general terms. Check the current text in Diário da República for dates and details.