SAF-T (PT): What It Is and How It Works

SAF-T (PT) is a standard XML file that exports billing or accounting data for the Portuguese Tax Authority to read. It does not replace an invoice and is not, by itself, a monthly return. The source application generates it from its records using the Portuguese structure published by the Authority.

What does SAF-T (PT) mean?

SAF-T means Standard Audit File for Tax Purposes. “(PT)” identifies the Portuguese version of the standard tax audit file. Ordinance 321-A/2007 introduced the structure in Portugal, and Ordinance 302/2016 published version 1.04_01 for current records.

The Portuguese Tax Authority describes the file as a way to collect relevant tax data electronically. That data can support an inspection, the analysis of accounting records, or a reporting obligation that requires the format. SAF-T represents what exists in the application's repository; it does not recreate an invoice or prove that the file was delivered.

For example, an invoice issued in certified software remains the fiscal document. Its record may later appear in the source-documents section of billing SAF-T. The XML is the structured means of exporting that record, not a new document supplied to the customer.

What data does a SAF-T file contain?

The structure arranges data in blocks whose names are defined by the XSD schema. The actual content depends on whether the file covers billing or accounting and on the information held by the source application.

Not every section has the same content in every file. A billing SAF-T does not become an accounting file merely because it includes customers and products. Likewise, an accounting export contains ledger entries and master data that cannot be produced from a simple list of invoices.

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

This separation avoids the mistaken idea that there is one “monthly SAF-T”. Tax Authority FAQ 2740 requires one accounting file for the complete fiscal year. It permits billing SAF-T to be generated for complete monthly periods only as an exception when the size of commercial-document tables creates a technical limitation.

The guide to SAF-T requirements and deadlines in Portugal explains who produces each file, the 2026 reporting dates, and the future delivery of accounting SAF-T. This page remains focused on the format and how it works.

Who generates SAF-T, and where do its records come from?

The software producer implements the export, but the file represents the data of the entity using the application. For accounting, Tax Authority guidance covers applications used by entities with a commercial, industrial, or agricultural activity and their head office or effective management in Portugal, as well as non-resident entities with a permanent establishment in the country. Certified billing programs must also export their records.

The application must generate mandatory fields and the remaining fields for which it holds information in its repository. The Authority also says that the user must not be able to choose individual operations to include or exclude. For example, removing a credit note solely to make the XML total match an external spreadsheet is not valid.

Changing software does not remove the history. If the accounting application changes during the fiscal year, the final file must still represent the complete year. Migrating opening balances alone does not replace the earlier entries, as Tax Authority FAQ 2741 explains.

How is a valid SAF-T file generated?

1. Documents or entries are recorded in the billing or accounting application that acts as their source.
2. The application selects the structure for the period, including the version identified in the file header.
3. The exporter assembles master data, documents, and entries without altering or omitting existing records.
4. The XML is compared with the XSD and the content rules for that type of file.
5. The entity reconciles the result with the source documents before using it for reporting, an inspection, or delivery to its accountant.

The .xml extension does not demonstrate compliance. A file that was renamed, produced with the wrong version, or split by manually selected documents may still be XML without meeting the structure. The published version for current records is 1.04_01; records before July 2017 have their own rules.

Are SAF-T and monthly invoice reporting the same thing?

No. The monthly obligation is to report invoice data and other relevant documents to the Tax Authority, or report that no documents existed for the period. A multi-document file based on billing SAF-T is one possible channel. Web-service transmission and the other channels provided by the Authority are separate methods.

For example, an application can report each document by web service and still allow a SAF-T export for the accountant or an inspection. Clicking “Export” does not prove that reporting occurred, and an accepted reporting response does not prove that the annual accounting file is complete.

Dates move because of weekends, public holidays, and extensions. The operational calendar should be checked in the guide to invoice reporting and SAF-T deadlines in 2026 and confirmed on the Tax Authority website before filing.

What does the Tax Authority SAF-T validator check?

The Authority provides the XSD and a structural validation tool. These resources help detect malformed XML, missing mandatory nodes, and values that conflict with the schema. They are useful for confirming that the application produced the expected shape of the file.

Structural validation does not confirm the coherence of all data. FAQ 2736 expressly says that no official tool exists for that purpose and assigns coherence to the application that creates and exports the records. An XML file can pass the XSD and still omit an invoice that was never created in the source system.

The validator result must therefore be combined with reconciliation. Document counts, series, statuses, and totals can be compared with the application. The guide to ATCUD and QR codes on Portuguese invoices explains other document elements that should not be confused with file validation.

How do Stripe payments enter SAF-T?

A Stripe payment does not enter SAF-T directly. Certified billing software must first issue the fiscal document with the correct series, lines, values, and status. That software's exporter then includes the record in the appropriate section of the file.

In a sale with two lines under different tax treatments, the integration must preserve the lines and the tax data received from Stripe. It must not calculate an average rate, choose a rate from an address, or fill in an exemption by inference. Tax is configured in Stripe; the billing software receives that data, and the accountant validates it.

If payment succeeds but invoice creation fails, no document exists for SAF-T to export. Reconciliation between payments and documents must identify the gap before reporting. The complete path is described in the guide to automating Stripe invoicing in Portugal.

How should a SAF-T file be reviewed before use?

1. Confirm the entity, period, and version in the header.
2. Validate the XML with the XSD and the Authority's structural tool.
3. Compare series, statuses, and totals with the application that issued the documents.
4. Reconcile external payments with invoices and credit notes in the billing provider.
5. Retain the file, any reporting receipt, and the reconciliation evidence.

A reconciliation row without a matching document requires investigation even if the validator accepts the XML. Payment evidence also does not replace the fiscal document, as the guide to Stripe invoices and Portuguese fiscal documents explains. SAF-T works when it exports correct records faithfully; it does not repair gaps that already exist at the source.