SAF-T Portugal Requirements and Deadlines

SAF-T (PT) is not one monthly return. In Portugal, billing SAF-T can supply invoice data for monthly reporting, while accounting SAF-T is a separate annual file. In 2026, use structure 1.04_01 for current records, follow the Tax Authority's published monthly dates, and prepare 2027 accounting data for submission from 2028.

What is SAF-T (PT), and who must produce it?

SAF-T (PT) is a standard XML export of records held by accounting or invoicing software. The Portuguese Tax Authority describes it as a common, readable format for accounting records, invoices, transport documents, and receipts. It exports data from the source application; it is not a replacement invoice or a copy of a bank statement.

The official guidance covers taxable persons whose main activity is commercial, industrial, or agricultural and extends the production duty to users of certified invoicing software. For accounting applications, it also identifies Portuguese-headquartered entities and non-residents with a permanent establishment in Portugal. The location of a parent company or director does not, by itself, remove the Portuguese entity's duties.

For example, a Portuguese subsidiary managed from London should assess the subsidiary, its software, and its Portuguese records. A UK parent with no Portuguese establishment is not placed in the same category merely because it sells to a Portuguese customer. The entity and establishment must be identified before deciding which export is due.

What is the difference between billing and accounting SAF-T?

The Tax Authority's technical FAQ makes the period distinction explicit. Accounting records must be generated in one file for the complete fiscal year. Billing SAF-T may be generated for complete monthly periods when the size of commercial-document tables makes that necessary. Selecting a few convenient invoices for an export is not the same thing.

A January billing export can therefore contain January's issued documents, while the accounting file must later preserve the full year's ledger. The shorter introduction to SAF-T (PT) explains the file itself; this guide focuses on the operational duties.

Which SAF-T schema version applies to current records?

The current structure published by the Tax Authority is version 1.04_01, associated with Ordinance 302/2016 of 2 December. The Authority's FAQ says that it applies to records produced from 1 July 2017. Accounting movements use the relevant taxonomies from 1 January 2017. Older records can therefore require an earlier structure.

The version belongs in the file header and must match the XSD used for validation. Renaming an old XML file does not convert its fields. For example, a migration that combines records from June and July 2017 must preserve the version rules applicable to each source period rather than forcing both into an improvised structure.

The Tax Authority publishes the 1.04_01 XSD and a local validation application alongside the legal structure. Software suppliers should generate that structure from their own repositories. The user should not repair production exports by deleting nodes or excluding documents until the file happens to pass.

When must invoice data be reported in Portugal in 2026?

Invoice data is reported every month for documents issued in the preceding period, or the absence of documents is reported. The exact operational date must come from the Tax Authority's calendar because weekends, public holidays, and administrative extensions move some deadlines. These dates were checked on 28 August 2026.

The table lists reports due during 2026, so it begins with December 2025 documents and ends with November 2026 documents. July documents are the clearest exception to a simple “day five” rule: the published reporting date is 31 August. December 2026 documents fall into the 2027 calendar.

For the complete calendar, including VAT returns, payments, and IES, use the Portugal invoicing deadlines for 2026. A saved recurring task should use the published date for each period, not an assumed fixed day.

Is the full SAF-T file submitted every month?

Not necessarily. The monthly obligation is to communicate invoice and document data. A file extracted from billing SAF-T is one accepted route, alongside web-service transmission and other methods made available by the Tax Authority. That does not turn accounting SAF-T into a monthly return.

A business whose invoicing provider reports documents by web service may still need the ability to export billing SAF-T for inspection or reconciliation. For example, reporting January invoices through an API and exporting a January SAF-T file for the accountant are related controls, but they are not two submissions of the same obligation.

Responsibility must be assigned explicitly. The company should know whether its software, accountant, or internal team sends the monthly data, where the receipt is stored, and who checks rejected records. A provider's export button alone does not prove that anything reached the Tax Authority.

What does the Tax Authority SAF-T validator actually check?

The published XSD and local application help validate the file's structure and restricted field content. They can identify malformed XML, missing mandatory nodes, or values that do not match the schema. This is a technical check against structure 1.04_01, not a complete audit of the underlying business records.

Tax Authority FAQ 2736 states that there is no official tool for validating the coherence of exported data. The application that created and exported the records must ensure that coherence, and export must not alter or exclude database records. Passing the XSD therefore does not prove that every Stripe payment produced an invoice or that accounting classifications are correct.

A structurally valid file could, for example, contain no document for a payment that never reached the invoicing provider. The validator cannot compare the XML with an external Stripe account it cannot see. A separate reconciliation between payments, provider documents, and reported data is still required.

When does accounting SAF-T enter the IES process?

Article 95(2) of the 2026 State Budget applies the accounting SAF-T submission under Ordinance 31/2019 to periods beginning in 2027 and later, with delivery in 2028 or later. It does not require the accounting file for the 2026 period to be submitted under that new timetable.

A calendar-year company should therefore use 2026 to confirm that its ledger, taxonomies, customer and supplier records, and migration history can produce the complete 2027 file. If the accounting application changes during the year, the Tax Authority FAQ says the final file must still include the complete year rather than only migrated opening balances.

For example, changing accounting systems in October 2027 does not permit an export containing only October to December entries. The old and new records must be handled so that one complete accounting file can be produced for the period submitted from 2028.

How do invoices from certified software reach SAF-T?

1. Record the sale and issue the applicable fiscal document in the invoicing provider, using its registered series.
2. Preserve document number, date, customer reference, lines, totals, taxes, status, and the provider's audit fields in that system.
3. Reconcile the provider document with the corresponding payment and investigate transactions that have no invoice match.
4. Communicate the document data through the assigned channel by the published date and retain the submission result.
5. Generate the billing SAF-T from the provider when it is needed for reporting, inspection, or accounting review.

For a Stripe sale with two lines taxed differently, the invoicing record should preserve those lines and the tax data supplied by Stripe. The connector should not replace them with an average rate or infer VAT from an address. The Stripe invoicing workflow for Portugal explains the preceding payment-to-document steps.

What happens when a Stripe payment was never invoiced?

A Stripe payment does not appear in billing SAF-T merely because it was successful. If no fiscal document was created in the invoicing provider, there is no provider document for that export to include. The gap must be found by reconciliation, not by expecting the XML validator to discover an external payment.

Before the reporting deadline, identify the failed or unmatched transaction, preserve its evidence, and retry or send it for manual review. The invoicing provider must create the correct legal document with the applicable series and source data. Do not type a fabricated document number into the XML, delete another record, or invent a tax treatment to make totals match.

If the period has already been reported, the accountant and invoicing provider should determine the permitted correction and reporting path. The answer depends on what was omitted and what has already been issued. The guide on Stripe invoices and Portuguese fiscal documents explains why payment evidence cannot fill that gap.

What should a foreign-run Portuguese entity check each month?

1. Confirm which Portuguese entity or establishment issued the sale.
2. Assign responsibility for document issue, reporting, rejection handling, and submission evidence.
3. Reconcile Stripe payments with provider invoices before the published monthly deadline.
4. Validate the 1.04_01 structure, then perform separate completeness and accounting checks.
5. Keep billing SAF-T, accounting SAF-T, monthly reporting, and IES as distinct controls.
6. Prepare the complete 2027 accounting dataset for submission from 2028 and recheck the law before filing.

A closing pack can show one row per Stripe payment, provider document, and reporting result. An unmatched row is then visible before the deadline, even when the finance team and directors work outside Portugal. That evidence is more useful than a technically valid XML file reviewed without its source transactions.