The conversation usually opens the same way: "we already invoice electronically, we just need the new system to do it too". And that sentence almost always hides two very different projects that look alike from the outside.
One is to keep issuing through a provider and have your system hand it the data. The other is for your system to be the issuer. The difference is not effort, it is accountability: it changes who answers when the tax authority rejects a document at four o'clock on a Friday.
This piece is about that difference, about the real flow in business terms, and about the two things almost everyone underestimates. There is no implementation detail in it, because what changes your decision is the process rather than the shape of the data.
For readers outside El Salvador: DTE stands for Documentos Tributarios Electrónicos, the country's mandatory electronic tax documents. Every sale has to be generated, signed, transmitted to the Ministerio de Hacienda and delivered to the buyer, and the document is not valid until the Ministry stamps it. Most countries in the region have some version of this. The names differ, the shape of the problem does not.
Issuing through a provider and issuing from your system are not the same thing
In the first model your system builds the sale and hands it to a third party, who signs, transmits and stores. You are buying a service, and that service answers for the transmission. It is cheaper to start, it is faster, and for a great many operations it is the correct decision.
In the second, your system is the one signing with your certificate, transmitting, receiving the response and knowing what to do with it. You gain control, independence from an intermediary, and the possibility of invoicing living inside your own workflow rather than beside it. You also gain the obligation to operate that, every day.
The question that settles the decision is not technical: who do you want answering when a document does not go through? If the honest answer is "I would rather somebody else answered", the first model is better, and there is nothing wrong with that.
The flow, in business terms
Seen from the operation, and without going into how it is built, issuing an electronic tax document is four moments:
It is generated. Your system turns a sale into a document with a unique identity. This is where you find out whether your business data model fits, or whether you are going to be filling fields with invented values, which is the earliest sign the design is wrong.
It is signed. The document is signed with the taxpayer's certificate, which is to say yours. That implies custody: where that certificate lives, who has access, what happens when it expires. It is a security responsibility you did not have before.
It is transmitted. The document goes to the tax authority and comes back with a reception seal. Before that seal the document does not exist for tax purposes, however printed and delivered it may be. That is the most important sentence in this article.
It is delivered. The recipient gets their file and its graphical representation. That sounds trivial and it is not: it is email, it is storage, it is resending when the customer says nothing arrived.
Four moments are four points of failure, and only the first is entirely under your control.
Contingency is the part that gets underestimated
Everyone designs for the happy path: generated, signed, transmitted, sealed. That path works the overwhelming majority of the time, which is exactly why demos always go well.
The problem is the rest. Your connection drops. The service on the other end drops. The certificate expired and nobody noticed. The response comes back malformed. And meanwhile there is a customer standing at the counter waiting for an invoice, or a truck waiting to leave.
A serious system has to be able to keep selling when it cannot transmit, and to catch up afterwards without anyone rebuilding the day by hand from a notebook. That means contingency is not an error screen. It is a queue, with retries, with visibility of what is still pending, and with somebody who gets told when the queue stops draining.
It is the least quoted part and the most expensive one. If you are comparing proposals, ask explicitly what happens when transmission fails. The answer will tell you more about the vendor than anything else in the conversation, and it is exactly the kind of question worth asking before hiring any agency.
What you need before anyone writes code
On the taxpayer's side there is work that is not programming and does not depend on your vendor. It tends to be discovered late, and it blocks.
Your status as an issuer has to be clear and confirmed by you, not by a hallway conversation. You need a valid certificate and you need to know who holds it. You have to request access to the test environment, and that request has its own waiting time that you do not control. And somebody on your side, who understands your operation and not just your software, has to be available to decide on the strange cases: the half-cancelled sale, the customer with incomplete details, the transaction that resembles nothing else.
That last point delays more projects than anything else. It is not technical and it is not solved by hiring better.
The mistake of treating it as the last module
The pattern that repeats most: the system is designed whole, built, and then invoicing arrives at the end as "the DTE module".
It does not work, because issuing is not an action that happens after the sale. It is a constraint on how the sale is modelled from day one. What a customer is, what a product is, what a cancellation is, what happens when somebody corrects something: every one of those decisions has consequences for what you will later be able to transmit. Making them first and adapting them afterwards is rework, not adjustment.
The healthy version is the reverse: invoicing is modelled early even if it is built late. It costs the same and it avoids the month nobody budgeted.
When you should not integrate it yourself
Better said here than on the call. If your volume is low, your operation is standard and you have nothing unusual that an off-the-shelf product does not cover, integrating issuance into your own system is taking on an operational obligation in exchange for very little. A provider serves you better.
Integration starts paying when invoicing has to live inside your process: when the document fires by itself as an order closes, when it depends on rules that exist only in your business, or when the back and forth with an intermediary is costing you more than running it would. At that point it stops being an expense and becomes infrastructure, and the order of magnitude of that project is in what custom software costs.
If you want a read on your case before committing budget, that fits in a thirty minute call.
How we see it
At GadDev we run our own electronic invoicing platform, so this is not a description from a manual: it is the problem we solve for ourselves and for the systems we build. What we have learned comes down to three things. The contingency queue is designed first, not last. Catalogues are treated as data with provenance, not as constants in the code. And the ugly cases are tested before the normal ones, because they are what breaks a migration.
This article describes engineering practice, not tax obligations. A system can meet or exceed the technical requirements and still leave organizational obligations on your company's side. Confirm your situation with your accountant and with official DGII information.
If you are deciding between issuing through a provider and integrating it into your system, we can go through your case with you. The discovery call runs thirty minutes, it is free and carries no obligation, and it is useful for ruling out the wrong path even if we never work together. You can book it here. What we do in this line of work is on custom systems.
Does this apply at your company?
30 minutes, no obligation, to review your case and decide whether there's anything to build.