Invalidar un Documento Tributario Electrónico no significa borrarlo del sistema ni eliminar su historial. Significa transmitir un evento que deja constancia de que un DTE previamente recibido por el Ministerio de Hacienda ya no debe producir los efectos de la operación original, según el motivo y las condiciones aplicables.
Con la Normativa de Cumplimiento de los DTE versión 2.0, el tratamiento de las invalidaciones adquiere mayor importancia. Se modifican plazos, se refuerza la trazabilidad del solicitante y del responsable, se exige comunicar el evento al receptor y se diferencia con más claridad cuándo corresponde invalidar, emitir un documento de ajuste o utilizar un Evento de Retorno.
Estos cambios obligan a revisar tanto el procedimiento administrativo como el ERP. Ya no basta con mostrar un botón llamado “Anular”: el sistema debe identificar el tipo de DTE, calcular su fecha límite desde el Sello de Recepción, solicitar los datos correctos y conservar la respuesta del evento.
Qué es un Evento de Invalidación
El Evento de Invalidación es el mecanismo electrónico utilizado para informar a la Administración Tributaria que un DTE con Sello de Recepción debe quedar invalidado. El documento original no desaparece: permanece disponible junto con el evento y su trazabilidad.
La invalidación únicamente procede sobre un DTE que ya obtuvo Sello de Recepción. Si un documento fue rechazado, no existe un DTE recibido que invalidar; corresponde corregir la causa del rechazo y generar o transmitir el documento conforme al flujo aplicable. La guía sobre cómo interpretar observaciones de rechazo explica esa diferencia.
Fuentes oficiales recomendadas:
- Normativa de Facturación Electrónica
- Información técnica y funcional
- Portal oficial de Facturación Electrónica
Factura 2.0 y Evento de Invalidación v3 no son lo mismo
En algunas pantallas o archivos técnicos puede aparecer “Evento de Invalidación v3”, mientras la normativa general se identifica como Factura Electrónica o DTE versión 2.0. Esto no es necesariamente un error.
La versión 2.0 identifica la actualización de la normativa y del ecosistema de facturación. La versión del evento identifica la estructura técnica específica del JSON utilizado para transmitir la invalidación. Un ERP debe controlar ambas referencias y utilizar el esquema vigente que corresponda al ambiente de pruebas o producción.
Qué cambió en la versión 2.0
Los cambios no se limitan a ampliar un plazo. La empresa debe revisar el proceso completo:
- los plazos se diferencian según el tipo de DTE;
- el cómputo toma como referencia el otorgamiento del Sello de Recepción;
- se refuerza la identificación del solicitante y del responsable del evento;
- el evento debe relacionar correctamente el documento invalidado y, cuando corresponda, su reemplazo;
- el receptor debe recibir el archivo del evento y su representación gráfica, además de la representación del DTE invalidado;
- el Evento de Retorno atiende devoluciones en los casos definidos por la nueva normativa sin convertir toda devolución en una invalidación;
- el ERP debe conservar estados, respuestas y evidencias para evitar invalidaciones duplicadas o fuera de plazo.
Nuevos plazos de invalidación por tipo de DTE
La regla más importante es que no todos los documentos tienen el mismo plazo. El sistema debe calcularlo a partir de la fecha y hora en que el DTE obtuvo el Sello de Recepción, no únicamente desde la fecha impresa o la fecha en que el usuario creó la venta.
| Tipo de DTE | Plazo para transmitir el Evento de Invalidación | Desde cuándo se cuenta |
|---|---|---|
| Factura Electrónica | Tres meses | Desde el otorgamiento del Sello de Recepción. |
| Factura de Exportación Electrónica | Tres meses | Desde el otorgamiento del Sello de Recepción. |
| Factura de Sujeto Excluido Electrónica | Tres meses | Desde el otorgamiento del Sello de Recepción. |
| Comprobante de Crédito Fiscal Electrónico | Hasta los primeros diez días hábiles del mes siguiente | Respecto del período tributario en que obtuvo el Sello de Recepción. |
| Nota de Remisión Electrónica | Hasta los primeros diez días hábiles del mes siguiente | Respecto del período tributario en que obtuvo el Sello de Recepción. |
| Nota de Crédito Electrónica | Hasta los primeros diez días hábiles del mes siguiente | Respecto del período tributario en que obtuvo el Sello de Recepción. |
| Nota de Débito Electrónica | Hasta los primeros diez días hábiles del mes siguiente | Respecto del período tributario en que obtuvo el Sello de Recepción. |
| Comprobante de Retención Electrónico | Hasta los primeros diez días hábiles del mes siguiente | Respecto del período tributario en que obtuvo el Sello de Recepción. |
| Comprobante de Liquidación Electrónico | Hasta los primeros diez días hábiles del mes siguiente | Respecto del período tributario en que obtuvo el Sello de Recepción. |
| Documento Contable de Liquidación Electrónico | Hasta los primeros diez días hábiles del mes siguiente | Respecto del período tributario en que obtuvo el Sello de Recepción. |
| Comprobante de Donación Electrónico | Hasta los primeros diez días hábiles del mes siguiente | Respecto del período tributario en que obtuvo el Sello de Recepción. |
Cómo entender “los primeros diez días hábiles del mes siguiente”
Esta regla no equivale a diez días desde la emisión. Si un Comprobante de Crédito Fiscal obtiene su Sello de Recepción durante septiembre, el plazo se extiende hasta el décimo día hábil de octubre. Para calcularlo correctamente, el ERP debe considerar fines de semana y días no laborables aplicables.
También conviene guardar por separado:
- fecha de generación del DTE;
- fecha y hora de transmisión;
- fecha y hora del Sello de Recepción;
- fecha límite calculada para invalidar;
- fecha y respuesta del Evento de Invalidación.
Esta separación es especialmente importante cuando un documento se genera un día y recibe el sello posteriormente, por ejemplo durante una contingencia DTE.
Tres meses no siempre son noventa días
Para Factura Electrónica, Factura de Exportación y Factura de Sujeto Excluido, la normativa expresa el plazo en meses. Por eso, no conviene programar una constante de 90 días. El cálculo debe conservar la lógica de meses calendario tomando como origen el Sello de Recepción.
Por ejemplo, si una factura recibió el sello el 11 de septiembre, la referencia de tres meses conduce al 11 de diciembre. Los casos de cierre de mes y fechas sin equivalente exacto deben resolverse conforme a la regla normativa implementada y probarse antes de producción.
Motivos de invalidación y documento de reemplazo
El evento solicita un tipo y un motivo de invalidación. En términos operativos, las causas suelen distinguir entre un error en la información del documento, la rescisión de la operación y otros supuestos admitidos por el catálogo vigente.
Cuando la operación continúa pero el DTE contiene información incorrecta, normalmente se requiere emitir primero el documento correcto y relacionar su código de generación dentro del evento. Cuando la operación se rescinde completamente, puede no existir un documento de reemplazo. El ERP no debería decidirlo solo por un campo opcional: debe aplicar las reglas del esquema y del motivo seleccionado.
Datos del solicitante y del responsable
La invalidación debe conservar quién la solicitó y quién la realizó por parte del emisor. Esto mejora la trazabilidad, pero también exige controles internos para que los datos no se inventen al momento de transmitir.
| Participante | Qué debe registrar el sistema | Control recomendado |
|---|---|---|
| Solicitante de la invalidación | Nombre, tipo y número de documento según el esquema vigente. | Conservar la solicitud o autorización que originó el proceso. |
| Responsable del evento | Identidad de la persona que gestiona la invalidación por el emisor. | Vincularla con el usuario autenticado y su permiso. |
| Receptor | Datos y medio utilizado para comunicar el evento. | Registrar fecha, archivos entregados y resultado del envío. |
La invalidación debe comunicarse al receptor
Uno de los cambios operativos más relevantes es la entrega al receptor de la información relacionada con la invalidación. La empresa debe preparar el envío de:
- el archivo JSON del Evento de Invalidación;
- la representación gráfica del evento;
- la representación gráfica del DTE invalidado.
Esto evita que el receptor continúe utilizando un documento que ya fue invalidado. También obliga a revisar correos, contactos y mecanismos de reenvío. El estado “invalidado en Hacienda” y el estado “notificado al receptor” deberían controlarse por separado.
Invalidación, Nota de Crédito y Evento de Retorno
| Mecanismo | Uso general | Resultado sobre el DTE original |
|---|---|---|
| Evento de Invalidación | Errores, rescisión u otros motivos admitidos dentro del plazo aplicable. | El DTE queda relacionado con un evento que lo invalida. |
| Nota de Crédito o Débito | Ajustes sobre operaciones y documentos para los cuales la legislación permite esos comprobantes. | El documento original permanece y el ajuste se documenta por separado. |
| Evento de Retorno | Devoluciones o retornos comprendidos por la Normativa 2.0. | Registra el retorno sin invalidar necesariamente el DTE original. |
Elegir el mecanismo incorrecto puede afectar libros, inventario, cuentas por cobrar y declaraciones. Antes de transmitir, el sistema debería aplicar validaciones previas según el tipo de documento y la operación.
Qué debe cambiar en el ERP
- actualizar el JSON del evento al esquema vigente;
- calcular el plazo por tipo de DTE desde el Sello de Recepción;
- mostrar la fecha límite antes de permitir la invalidación;
- bloquear eventos fuera de plazo y explicar la razón;
- solicitar datos del responsable y del solicitante;
- validar cuándo se necesita un DTE de reemplazo;
- firmar y transmitir el evento con trazabilidad;
- guardar JSON, representación gráfica, respuesta y sello;
- notificar al receptor y registrar la entrega;
- reflejar el resultado en reportes, libros e inventario.
Estos ajustes deberían formar parte de cualquier migración de ERP a DTE 2.0, porque la compatibilidad no termina al lograr que una factura sea recibida.
Errores frecuentes
- contar el plazo desde la fecha de generación y no desde el Sello de Recepción;
- usar 90 días fijos en lugar de tres meses calendario;
- aplicar el plazo de tres meses a todos los DTE;
- invalidar un documento rechazado que nunca obtuvo sello;
- omitir el documento de reemplazo cuando corresponde;
- confundir una devolución con la invalidación total;
- guardar el evento, pero no su respuesta;
- no entregar la documentación de la invalidación al receptor;
- permitir que cualquier usuario invalide sin autorización.
Preguntas frecuentes
Conclusión
La actualización de invalidaciones en Factura Electrónica 2.0 ofrece más tiempo para ciertos documentos, pero también exige más control. El plazo debe calcularse por tipo de DTE y desde el Sello de Recepción; además, la empresa debe identificar responsables, relacionar reemplazos cuando corresponda y comunicar el evento al receptor.
La mejor práctica es convertir estas reglas en controles automáticos del ERP. Un usuario no debería tener que recordar de memoria qué documentos tienen tres meses y cuáles vencen durante los primeros diez días hábiles del mes siguiente.
Actualiza tu sistema para Factura Electrónica 2.0
En Sistemas Web LA trabajamos en soluciones de facturación electrónica con validaciones, trazabilidad y procesos de invalidación adaptados a la operación de empresas salvadoreñas.
Comentarios