Phased implementation means your customer base will be split for most of 2027. Some buyers will be on the Electronic Invoicing System and others will still be waiting for their mandate date, and Section 10.2.2 of the Guidelines requires your accounts receivable process to produce a different output for each. Chapter 6 explains what rides on that split: it names input tax recovery and corporate income tax deductions among the reasons a buyer who has yet to implement Electronic Invoicing still requires a separate Tax Invoice.
When the Electronic Invoice Is Enough
The revised definition of a Tax Invoice in the VAT Decree-Law includes an Electronic Invoice. Section 10.2.2 draws the consequence: a supplier may not be required to issue a separate Tax Invoice when issuing an Electronic Invoice to a buyer that has implemented Electronic Invoicing, provided the document meets the criteria of a Tax Invoice under Article 65 of the VAT Decree-Law and Article 59 of the VAT Executive Regulation. One document discharges both obligations, subject to that content test.
The same section confirms something that removes a common design assumption. An electronic Tax Invoice issued by a Taxable Person for Taxable Supplies may include non-Taxable Supplies on the same document. Splitting a mixed sale across two invoices to keep taxable and non-taxable lines apart is unnecessary.
When You Issue Twice
Where the buyer has not yet implemented Electronic Invoicing — because they have no mandatory date under the roll-out plan and have not moved voluntarily — the Guidelines require a regular Tax Invoice, in PDF for example, in addition to the electronic Tax Invoice. The buyer receives a document they can act on, and the FTA receives the structured data.
For the electronic document in that scenario, the buyer has no Participant Identifier. Section 10.2.2 supplies one: the predefined endpoint 0235:9900000098 must be included by the supplier on the Electronic Invoice. The value is mandatory in this case, and it is the only route by which a transaction with a non-onboarded buyer reaches Corner 5.
This is a different value from the one Scenario 2 uses. Deemed supplies carry the buyer electronic address 0235:9900000097, and the Guidelines fix that value regardless of the supplier’s identity. The two predefined endpoints answer two separate conditions: one turns on the buyer’s onboarding status, the other on the deemed supply itself.
The Master Data Consequence
The behaviour Section 10.2.2 describes turns on a single customer master attribute: whether this buyer is live on the Electronic Invoicing System, and if so, what their Participant Identifier is. That flag determines the endpoint written into the XML and whether a PDF Tax Invoice is generated alongside it.
The attribute is also unstable. Buyers cross into mandatory scope in waves through the phased plan, and each one that goes live changes the correct treatment of every subsequent invoice you issue to them. A field populated once at onboarding will keep sending 0235:9900000098 for a customer who now holds a real identifier, and will keep generating a redundant PDF alongside it.
What to Settle Before Go-Live
Decide now who owns the buyer-status field, how it gets refreshed, and what triggers the switch from the predefined endpoint to a real Participant Identifier. Section 5.2 of the Guidelines assigns contacting the buyer and gathering their Peppol participant identifier to the supplier, and limits the ASP’s role to looking up the identifier the supplier provides. Build the field as maintained master data, with a named owner and a defined refresh point.