The five changes, as the tax authority writes them
The Manual of Annexes and Structures for version 4.4 ends with a change log. Its latest entry is dated 22 April 2026 and lists five changes. Here is what it says, condensed but with nothing added:
- Identification numbers may contain letters. The annex clarifies that alphanumeric characters are permitted for legal persons, in line with the provisions of the National Registry.
- A telephone exception. The phone field now admits an exception for special numbers, and the annex itself gives 911 as the example.
- VAT returned. The description of that field is expanded to clarify its use.
- Six new reference codes. Codes 13, 14, 15, 16 and 17 are added to note 9, code 12 is adjusted, and codes 19 and 20 are added to note 10.
That is four blocks rather than five, because the last two entries in the log deal with the same thing: reference codes. They are also, by a distance, the change with the most practical consequences.
The 50-character key now accepts letters
Until now the key identifying each electronic document was fifty digits. The annex now says of that field that it admits numbers and letters for legal persons. And it does not stop at the description: the XSD schema that validates documents changed its pattern, which now admits letters as well as digits, at the same exact length of fifty.
The people who should lose sleep over this are the ones who wrote their own validation. If your system — or your provider's — checks that the key is fifty digits, then the day a customer with an alphanumeric ID appears, the document will fail before it leaves, and the error message will tell you nothing useful.
Reference codes: why they actually matter
When you issue a credit or debit note you have to say why, with a code. That code is not paperwork: it decides which period the accounting effect falls in. And that is where the real change is.
The annex spells it out in the footnotes to note 9:
- Codes 01, 02 and 06 take effect “in the same period in which the credit note was generated”. That is: today.
- Codes 13 and 14 — the new ones — take effect “in the same period as the electronic document being modified”. That is: in the month of the original invoice.
The difference is the one between a clerical error and a new commercial fact. If you invoiced wrongly — a typing mistake — that is not an October return of an August sale: the August invoice was always wrong, and its correction belongs to August. If the customer returned goods, that did happen in October. Until now both were declared the same way; now each has its own code.
| Code | What the annex says | Where it goes |
|---|---|---|
| 13 | Voids referenced document for clerical error | Note 9 · effect in the original's period |
| 14 | Corrects amount for clerical error | Note 9 · effect in the original's period |
| 15 | Replaces electronic document for clerical error | Note 9 · the one replacing a document voided with 13 |
| 16 | Replaces rejected electronic document | Note 9 |
| 17 | Payment against an electronic document | Note 9 · electronic payment receipt only |
| 19 | Electronic export invoice | Note 10 · type of referenced document |
| 20 | Electronic payment receipt | Note 10 · type of referenced document |
One detail is easy to miss: when a document is voided with 13 and the correct one has to be issued, that new document must reference the voided one with code 15. It is the same pairing that already existed between 01 and 07.
Code 12, which already existed, was also adjusted: a financial credit note for an exemption approved after invoicing takes effect in the period the credit note was generated.
The date: what is written and what is not
This is where it pays to go slowly, because it is what is being repeated wrongly.
What is on record: the annex's change log is dated 22 April 2026. And the header of that same document states that version 4.4 runs from 1 September 2025.
What is not on record: an effective date for these five changes. We checked the full annex, the tax authority's site and the official gazette, and found no resolution setting one.
Does that mean there is nothing to do? No. It means two things have to be kept apart:
- The schema has already changed. The XSD that validates documents accepts the alphanumeric key. That is published and waiting for no resolution.
- The obligation to use the new codes is the part with no known date. Meanwhile, the existing codes remain the valid ones.
What to do today, depending on who you are
If you invoice with someone else's software, all you have to do is ask your provider one question: whether it already accepts the alphanumeric key and codes 13 to 17, 19 and 20. If the answer is that they are “looking into it”, write down the date of that answer.
If you invoice with your own system, the urgent part is the key validation. Find any check in your code that the key is fifty digits and change it to fifty alphanumeric characters. It is one line, and it is the one that leaves you unable to invoice the day your first customer with letters in their ID turns up.
If you keep other people's books, the change that will reach you is codes 13 and 14. They put the adjustment in the original invoice's period, so a correction for a clerical error reopens a month already declared. It is worth deciding now how you will handle that.
About this article. Everything quoted comes from the Manual of Annexes and Structures for the Issuance of Electronic Documents, version 4.4 — its change log of 22 April 2026 and its notes 9 and 10 — and from the XSD schema published for that version. The number of the National Registry decree on alphanumeric identifications does not appear in the annex: if you see it cited, it comes from another source.
Verified as of 16 October 2026. Tax rules change: confirm the version in force before applying any of this to a real case. This is general information, not tax advice.
Sources: Annexes and structures v4.4 (Ministry of Finance) Manual of Annexes and Structures v4.4 (PDF) La Gaceta (official gazette)