El Salvador's DTE 2.0 and the December 1 deadline

On 25 May 2026 El Salvador's Ministerio de Hacienda published version 2.0 of the compliance rules for Documentos Tributarios Electrónicos, the country's mandatory electronic tax documents, known everywhere here as DTE. The Transmission System functional manual and the Invoicing System user manual were updated alongside it.

If your company issues DTE from the Ministry's free platform, this arrives already solved. There is no technical work on your side.

If your company issues from its own system, or from a market solution wired into your ERP, you have a specific date: 1 December 2026. Until that day, version 1.2 of the rules remains valid for documenting operations. After it, no.

That is a little over four months away. This piece is about what changes, and about the question most companies have not asked themselves yet.

This is not a catalogue update

It is worth separating this release from the ones before it, because they do not all weigh the same.

In August 2024, for instance, the Ministry updated the municipality catalogues to reflect the municipal restructuring that cut the country's 262 municipalities down to 44. That was a real change, but a bounded one: it touched values inside fields that already existed. A good vendor handled it in an afternoon.

Version 2.0 is a different animal. It touches three layers at once: administrative processes, the catalogues, and the structure of the documents and of the events that get transmitted. There are new fields, new validations, and two event types that did not exist before. If your system builds the JSON, signs it and transmits it, that logic gets touched.

The changes with actual operational consequences

The full document is long, and your vendor or your technical team should read all of it. These are the ones that change how your people work, not just how your software works.

The Return Event. Until now, correcting a value on an electronic invoice meant issuing a new one, invalidating the previous one, and linking the two by generation code. It works, but it leaves an accounting trail of two documents where there was one sale. Version 2.0 introduces an event that allows electronic invoices, export invoices and excluded-subject documents to be amended without invalidating the original. Less noise in the books, and fewer customers calling to ask why they received two emails.

The Special Operations Event. This reports authorised operations that were documented with Internal Control Vouchers or with Simplified Sales Invoices. If your operation uses either of those two instruments, this applies to you directly and it probably means a new flow, not just a new field.

The deadlines move. The window to generate a DTE or an event with a later date goes from 1 day to 5, always within the corresponding tax period. And since February of this year, the electronic invoice, the export invoice and the excluded-subject invoice accept an invalidation request for up to 90 days afterwards. That extra room is a genuine improvement for any company with volume, but only if your system and your accountant know it exists. An extended deadline nobody uses is worth nothing.

The Control Number and the catalogues. The structure of the Control Number changes, technical catalogues are updated, and a district catalogue appears that did not exist before. New fields are also added for the Electronic Export Invoice. None of this is conceptually hard. All of it breaks integrations that assumed the previous shape of the data.

The part nobody puts on a calendar

The real schedule for this migration does not start the day your team writes the first new field. It starts the day the Ministry enables your test environment.

To test against 2.0 you have to send an enablement request to the DGII, at soporte.dtes@mh.gob.sv. That enablement is not instant and it does not depend on you. It depends on a queue that will be considerably longer in October and November than it is in August, because 1 December is a common date for the entire country and human nature is what it is.

After enablement comes everything else: adjusting generation and signing, transmitting against the test environment, fixing rejections, validating against your own strange cases (the credit note for the sale that was half cancelled, the customer with no NRC, the export with the new field), and only then moving to production.

That is the order. And every step depends on the one before it.

The practical consequence: if your company starts this in November, it is not starting with a month of margin. It is starting with whatever is left after the queue. And a company that cannot issue a valid DTE cannot legally invoice or collect, because the document only exists once it receives the Ministry's Reception Seal.

The right question is not a technical one

Almost every conversation we have had about this starts at the JSON and ends somewhere else. The question that actually organises the problem is this one:

Who in your company is accountable for the fact that you can still invoice on 1 December?

Not "who knows about electronic invoicing". Who answers for it.

There are three possible answers, and each one implies a different action this week:

1. An outside vendor. Ask them in writing for the date they will have 2.0 ready and the date they will test against the Ministry's test environment. If the answer is "we're working on it", that is not a date. It is a risk that is still yours, not theirs. That question belongs to a longer list worth asking any vendor, which we set out in twelve questions to ask before hiring an agency.
2. Your internal team. They need allocated time in the backlog, not goodwill. Four months sounds like a lot until it meets fiscal close, August holidays and whatever was already committed for the fourth quarter.
3. Nobody, yet. This is the most common answer and the only one you can fix today, by deciding which of the other two it is going to be.

And before any of the three: log in to factura.gob.sv with your NIT and confirm your status as an issuer. The official documentation and technical manuals live at portaldtes.mh.gob.sv. Do not delegate that check to a hallway conversation.

If the answer you land on is the third one, sorting out who is accountable is a half hour conversation and we can have it this week.

What we would do

At GadDev we run our own electronic invoicing platform, so migrating to 2.0 is a problem we are solving for ourselves and for the systems we have built. Here is what we are applying, in case it is useful:

First, request test environment enablement before the code is ready. The queue runs in parallel with development and there is no reason to serialise the two.

Second, treat the catalogues as versioned data with provenance, not as constants in the code. A catalogue that changes by decree should not force you into a deployment.

Third, test the ugly cases first. The normal invoices will pass. What breaks a migration is partial invalidations, excluded subjects and exports, and those surface late if you leave them for the end.

None of this requires custom software. It requires somebody to have the date on their calendar and the authority to move it forward.

And if the exercise does turn up something worth building, that is a separate conversation with its own budget: we break it down in what custom software costs, and what we do in that line of work is on custom systems.

Verified against Ministerio de Hacienda publications as of 16 August 2026. This article describes the regulatory framework published by the Ministry and is not tax or legal advice. Your company's specific obligations depend on your taxpayer classification and your tax situation. Confirm your case with your accountant and with official DGII information before making decisions.

If you are working out who should be accountable for this migration at your company, we can go through it with you. The discovery call runs thirty minutes, it is free and carries no obligation, and it is useful for getting the calendar straight even if we never end up working together. You can book it here.