Iberian E-Invoicing: What Changes in 2027 and What Is Already Late
Portugal ends plain PDF invoices on 31 December 2026. Spain postponed Verifactu to 2027. The two calendars differ, and so does what you have to do about them.
What changes, and when
The two Iberian markets are moving on different calendars, and a company operating in both has to track both. Portugal ends the transitional arrangement that made a plain PDF legally equivalent to an electronic invoice. That equivalence runs to 31 December 2026. From 1 January 2027, an electronic invoice must be a structured XML file in the CIUS-PT format carrying a qualified digital signature. Spain has gone the other way. Veri*factu, set out in Royal Decree 1007/2023, requires invoicing software to produce an unalterable chained record of every invoice. It was due to start in January 2026 for companies and July 2026 for self-employed workers. A royal decree pushed both back by a year: 1 January 2027 for corporate income tax payers and 1 July 2027 for everyone else. The deadlines moved. The work did not.
What has been mandatory since 2023
Portugal has a requirement that predates all of this and still catches companies out. ATCUD, the unique document code introduced by Decreto-Lei 28/2019, has been mandatory since January 2023 after several delays. Any tax-relevant document issued without one is irregular. Alongside it goes a QR code, and both must be printed and perfectly legible. The failure we see most often is not in the data but in the template. The ATCUD is in the file, the print layout truncates it, or the QR is rendered at a resolution too low to scan. The system complies; the paper coming out of it does not.
SAF-T: two files, two calendars
SAF-T in Portugal is two different files on two different calendars, and companies routinely think they are current because they recognise the acronym. The invoicing SAF-T is filed monthly with the tax authority, by the fifth day of the month following the reference period, by every company with organised accounting. It is what feeds the e-fatura system. The accounting SAF-T is separate, and its filing obligation has been pushed to 2028, covering the 2027 financial year. Mistaking one for the other is the common failure: a company treats a monthly obligation as an annual one and discovers the gap several months in.
| Obligation | Portugal | Spain |
|---|---|---|
| Unique code on the document | ATCUD + QR, desde jan. 2023 | Sem equivalente directo |
| Unalterable record in the software | Software certificado pela AT | Veri*factu (RD 1007/2023) |
| End of the plain PDF | 31 dez. 2026 | Regulado pela Lei Crea y Crece |
| Structured XML required | 1 jan. 2027 (CIUS-PT) | Calendário Crea y Crece |
| Start date for companies | 1 jan. 2027 | 1 jan. 2027 (Veri*factu) |
| Start date for the self-employed | 1 jan. 2027 | 1 jul. 2027 (Veri*factu) |
Spain: postponed, not cancelled
Spain postponed Veri*factu by a royal decree, and the postponement has had a predictable effect: companies that had budgeted the change stopped, and companies that had done nothing carried on doing nothing. There is a distinction worth holding on to, because it is the one most often collapsed. Veri*factu is a requirement on the software: every invoice produces a chained, tamper-evident record that can be sent to the tax agency. The Crea y Crece law is a requirement on the document: business-to-business invoices must travel in a structured format through specific platforms. Software can satisfy Veri*factu and still email a PDF. That software will not satisfy Crea y Crece when its turn comes.
What to do in the months you have
The sequence we use starts without touching any software. First, establish who issues invoices and with what. A second channel is more common than people expect: someone issuing from a spreadsheet, a booking system producing its own documents, an online shop with its own module. Each channel is a separate obligation. Second, ask the software vendor in writing whether the product will meet the requirement on the date that applies to you, and whether that is in the contract or a paid module. The written answer is the one that counts, and a vendor who will not put a date in an email is telling you something useful about how ready they are. Third, test a real file before the deadline. An XML that validates against the schema is not the same as an XML the recipient can import. Ask a large customer or a public body for a sample and run the whole path once. Validation catches structural errors; it does not catch a tax code your customer's system rejects, or a field their importer expects and yours leaves empty. Only a round trip finds those. Fourth, do not leave the migration to the final quarter. Changing invoicing software means moving series, numbering and customer records, and doing it while the entire market does the same is the worst available option.
When changing software is the wrong answer
This is worth saying because the market will spend the coming months saying the opposite. If your current software is compliant, the vendor has confirmed the date in writing, and your volume is moderate, there is nothing to do but wait for the update. Changing products in that situation swaps a known risk for an unknown one, with a data migration in between. Changing makes sense when there is a second channel nobody has covered, when the vendor will not give a straight answer about dates, when part of the invoicing is done by hand, or when the compliance module costs nearly as much as a product that already includes it. Our work here is usually less glamorous than it sounds: connecting what exists rather than replacing it. A booking system that already holds the data rarely needs replacing. It needs to stop issuing documents on its own and start issuing through the invoicing software. It is also worth distrusting one particular line you will hear a great deal over the coming months: that you must migrate now because later there will be no time. Serious vendors publish a date on which the capability ships and then meet it. The ones applying urgency without naming a date are selling fear of the deadline rather than a solution to it. Ask for the date in writing and decide with it in front of you. And if you operate on both sides of the border, sequence the two jurisdictions rather than treating them as one project. Portugal has a hard date at the end of 2026 and Spain does not bite until 2027. Doing the Portuguese side first buys a working example to follow, on a smaller scope, before the Spanish deadline arrives.
The receiving side, which nobody prepares
The entire e-invoicing conversation is conducted from the issuer's point of view. Half the problem sits on the other side. From the moment your suppliers start sending structured files instead of PDFs, somebody in your company has to receive, validate and archive them. If the current process is printing the PDF attached to an email and handing it to accounts, that process stops working: an XML does not read on paper and there is no point printing it. There is an opportunity here that almost nobody takes, and it is the reason to treat this as a project rather than an obligation. A structured invoice arrives with every field already separated: supplier, tax number, lines, rates, totals, due dates. Getting that into the accounts without anyone typing it stops being an exercise in optical reading with a margin of error and becomes a direct import. Put differently: the same obligation that costs money on the issuing side can save hours on the receiving side, if someone connects the two ends. Treating the received file as an annoying attachment to convert into a PDF means paying the cost of the change without collecting the benefit. Archiving is the other half. Retention periods for tax documents have not changed, and a structured file has to be stored so that it stays legible and intact for those years with its signature still verifiable. Putting the XML in a shared folder with no versioning and no backups is not archiving.
Frequently Asked Questions
Can I keep sending PDF invoices after 2026?
In Portugal a plain PDF counts as an electronic invoice until 31 December 2026; from 1 January 2027 it must be structured CIUS-PT XML with a qualified signature. Nothing stops you sending a PDF as well for a human to read. What changes is that the PDF alone is no longer the invoice.
Does the Veri*factu delay mean I can wait?
It means the date moved to 1 January 2027 for companies and 1 July 2027 for the self-employed. It does not mean the work went away. If your software does not comply, the migration has to happen before then, and doing it at the same time as the rest of the market is the worst possible timing.
Are Veri*factu and the Crea y Crece law the same thing?
No. Veri*factu governs the internal record of invoices inside the software, to prevent later alteration. Crea y Crece governs the structured electronic exchange of the document between businesses. Software can meet the first and still email a PDF, in which case it will not meet the second.
How often do I have to file the SAF-T?
The invoicing SAF-T is monthly, by the fifth of the following month, for companies with organised accounting. The accounting SAF-T is a different file whose filing obligation has moved to 2028 for the 2027 financial year.
I invoice in both countries. Do I need two systems?
Not necessarily, but you need one that treats the two jurisdictions as distinct rather than translating one into the other. The rules do not overlap: Portugal's ATCUD has no Spanish equivalent, and Veri*factu's chained record has no Portuguese one. A product covering only one market forces a second channel, and every extra channel is an extra obligation.