What the 2027 signature deadline actually means for an ERP
Portugal has pushed back the qualified electronic signature requirement for e-invoices a few times now. Every time it gets reported as relief. Reading into it a bit, I think it's more useful to see it as a deadline nobody's actually built for yet, because it's not really an extra step on what invoicing systems already do. It's a different mechanism with a different trust root.
What the rule actually says
Under the Portuguese e-invoicing rules, an electronic invoice needs guaranteed authenticity of origin and integrity of content. There are three ways to get that guarantee: a qualified electronic signature, a qualified electronic seal, or EDI under a contractual framework between the parties.
On top of that there's been a transitional rule accepting plain PDF invoices as electronic invoices. That's the part that keeps getting extended: the current extension runs to 31 December 2026, and the qualified signature requirement kicks in from 1 January 2027. Separately, and easy to mix up with this one, the SAF-T (PT) accounting file obligation got pushed again too, now to periods from 2027, filed in 2028.
Dates in this area move a lot. Both of these have been rescheduled more than once through successive State Budget laws. Worth checking the current text before planning around either one.
Why it's not the same signature the ERP already does
Any invoicing system in Portugal already signs documents in some form. Certified software computes a signature over a string built from the document date, the system entry date, the document ID, the total, and the signature of the previous document in the same series. That's a hash chain: each document commits to the one before it, so nothing can be removed or reordered later without breaking every document issued after it.
That mechanism has specific properties. The key belongs to the software producer, tied to the certification of the program. The one checking it is the tax authority, during an inspection, working from the audit file. What it proves is that a sequence of documents is complete and hasn't been tampered with.
A qualified electronic signature proves something else. The key belongs to a person or a company, not the software, issued by a qualified trust service provider under eIDAS, backed by a qualified certificate. Whoever checks it could be anyone holding the document, usually the recipient, maybe years later. What it proves is that this specific document, exactly as the recipient has it, came from the issuer and hasn't been changed.
Having one doesn't give you the other. Both get called “signature” in normal conversation, and that's probably where most scoping conversations go wrong.
What actually needs building
Boiled down, the requirement adds a signing step over the document that gets sent out, using a key that lives outside the ERP. A few things follow from that, and each one is a real decision, not just a setting to turn on.
1. What gets signed, and when
The signature covers whatever gets sent to the customer: the PDF, or the structured document. That's usually produced by a reporting layer, and reporting layers are usually happy to regenerate a document whenever someone asks. Once it's signed, regenerating it isn't harmless anymore. Either the signed document gets stored once and every later request returns that same copy, or every regeneration becomes a new signing operation with its own timestamp. Storing it once is almost always the right call, which means the archive becomes the actual record, not the report.
2. Where the key lives
A qualified certificate can't just sit where an ERP normally keeps configuration. Either signing gets delegated to a provider through a remote signing service, or the key sits in a vault backed by an HSM and the ERP only has permission to call it. For cloud-hosted D365FO, the second option fits better: key material in Azure Key Vault or an HSM behind it, the ERP calling out, and the private key never actually showing up in application memory.
3. Throughput
Signing means a network call to a service that's rate-limited and billed per operation. An organisation issuing invoices in batches at period end is going to notice the difference between signing one document interactively and signing forty thousand in one window. That's a queueing problem, and it's better to design for it before the deadline than during the first month-end after it.
4. What happens when signing fails
The signing service is going to be down at some point. Meanwhile the invoice has already been issued: it has a number in a registered series, a spot in the hash chain, a fiscal existence that can't just be undone because a remote call timed out. Issuance and signing need to be separate states of the same document, with delivery gated on the signature rather than signing being part of posting. Systems that treat signing as part of posting are eventually going to get asked to un-post a fiscal document, and there's no good answer to that request.
5. Whether it's still valid years later
A signature that checks out today might not check out in seven years, once the certificate has expired and the invoice comes up in an audit. Long-term validation formats exist for exactly this: a timestamp from a qualified authority, revocation data captured at signing time. They're much cheaper to build in from the start than to add across an entire archive later.
The question worth asking now
The useful question isn't “does the product support qualified signatures”. It's: which document is actually the invoice? If the answer is “whatever the report renders when someone asks for it”, there's no place to put a signature yet, and building that place, an immutable archive with delivery reading from it instead of a live render, is the real work. The cryptography part is small, a few hundred lines against a provider API. Pointing every delivery path in a mature ERP at a stored document instead of a fresh render each time is not.
Which is why I don't think the postponements buy as much time as they look like they do. The 2027 date buys time for the signing integration. It doesn't buy time for the archive, and the archive is the part with the long lead time.
Sources: Decreto-Lei n.º 28/2019 and subsequent amendments; Regulation (EU) 910/2014 (eIDAS); Portaria n.º 363/2010 for the certified-software signature. Deadlines cited are those in force at the time of writing and have been revised repeatedly. Verify against Diário da República.