The body of the document explains the predictable things: how certification is requested, how documents are signed, which online services authorise and query them, which code each error returns. What actually changes from year to year lives somewhere else: in the annexes at the back and in the version table on the opening pages.
What I took from it
A reading order that is the reverse of the contents page. Version history first, annexes second, body last. The body has barely moved in years; what forces a change to a working system sits in the annex added last quarter, and nobody rereads four hundred pages to find it.
Annex twenty-six, the change with the most practical consequences in this version: anyone issuing through a third party's system must now include that provider's tax identification number in an additional field of the XML, with a defined field name and a deadline counted from publication in the official gazette. It is a small change to the file and a large item on the to-do list of whoever maintains the system, because the template, the printed representation and the tests all have to move. I wrote it up in detail on the page about the provider tax ID requirement.
And an observation worth carrying into any quote: the specification does not distinguish between an issuer sending ten documents a month and one sending ten thousand. Same obligation, same deadline, and the fixed cost of compliance weighs far more on the first.
What I left out
Nothing, and that is exactly the problem. A document like this cannot be read in parts, because one rule can appear in the body, in an annex, in the glossary and in the frequently asked questions at the end. It is a word-processor file carrying ten years of accumulated layers, and that way of growing is the real difficulty of electronic invoicing in Ecuador, more than any technical detail in it.