Nueva Regulación del SRI para Proveedores de Software de Facturación Electrónica en Ecuador

El ecosistema de facturación electrónica en Ecuador incorpora un cambio importante para empresas de software, desarrolladores y contribuyentes que utilizan sistemas de terceros para emitir comprobantes electrónicos.

Mediante la Resolución Nro. NAC-DGERCGC26-00000027, el Servicio de Rentas Internas (SRI) establece normas específicas para crear un registro de proveedores de sistemas informáticos o servicios de facturación electrónica.

El cambio no afecta únicamente al proveedor tecnológico. También introduce una nueva obligación formal para los propios emisores de comprobantes electrónicos: identificar el RUC del proveedor de su sistema de facturación dentro de la información adicional del comprobante electrónico.

Desde la perspectiva de la ingeniería de software, esto significa que proveedores de ERP, sistemas contables, plataformas SaaS y servicios de facturación deberán revisar tanto su situación tributaria ante el RUC como sus motores de generación de documentos electrónicos (XML y esquemas XSD).

La resolución establece expresamente que su objetivo es regular a quienes permiten la emisión, firma, transmisión y conservación de comprobantes de venta, retención y documentos complementarios bajo esquema electrónico.

1. ¿Qué Busca Hacer el SRI?

Hasta ahora, un contribuyente podía contratar cualquier sistema de facturación electrónica y utilizarlo para comunicarse con los servicios web SOAP del SRI (Recepción y Autorización), sin que existiera dentro de la normativa tributaria un mecanismo que obligara a identificar públicamente a esos proveedores tecnológicos mediante actividades económicas especializadas ni en los comprobantes emitidos.

La nueva regulación introduce una cadena formal de trazabilidad estructurada en cuatro componentes:

En otras palabras, el SRI busca tener trazabilidad completa sobre quién desarrolla, opera o comercializa las plataformas utilizadas para facturación electrónica.

La motivación de la resolución señala la necesidad de crear este registro para:

1. Identificar formalmente a las empresas y profesionales que prestan estos servicios tecnológicos.
2. Habilitar un canal de comunicación directo y técnico entre la administración tributaria y los desarrolladores.
3. Fortalecer la transparencia, seguridad informática y confiabilidad en la emisión tributaria nacional.

2. ¿Quiénes son Considerados Proveedores?

El artículo 2 de la resolución clasifica a los sujetos obligados en dos grandes grupos técnicos y comerciales:

3. Nuevas Actividades Económicas en el RUC

Uno de los cambios más directos y vinculantes está contenido en el artículo 3 de la resolución. El SRI creó dos códigos de actividad dentro del clasificador nacional de actividades económicas para identificar con precisión el rol del proveedor:

4. No Basta con Tener la Actividad: Debe Existir un Establecimiento Exclusivo

Este detalle es crítico y suele pasarse por alto en una primera lectura rápida:

Por lo tanto, las empresas proveedoras de software deben coordinar de inmediato con su área contable o tributaria para evaluar la apertura o reasignación de un establecimiento específico (por ejemplo, el establecimiento 002 o uno nuevo), garantizando que cumpla con la exigencia de exclusividad estipulada en la normativa.

5. El SRI Publicará un Listado Público Mensual

El artículo 4 introduce un mecanismo de validación institucional con alto impacto comercial:

Efecto en el Mercado de Software Ecuatoriano

Este listado transformará la toma de decisiones de compra en el mercado corporativo. Cuando una empresa vaya a contratar un ERP, un sistema POS o un SaaS de facturación, el primer paso de auditoría interna será:

“¿Aparece este proveedor de software en el listado oficial publicado por el SRI?”

Estar en este listado se convertirá en un requisito indispensable de homologación de proveedores para clientes medianos y corporativos.

6. Cronograma: Primer Listado en Octubre de 2026

La resolución no deja este mecanismo en el aire ni como una declaración de intenciones a largo plazo. Establece que el SRI publicará el primer listado oficial:

7. El Cambio Más Importante para el Software: Identificar al Proveedor en el Comprobante

Desde la perspectiva de la ingeniería de sistemas, este es el cambio con mayor impacto operativo.

El artículo 5 dispone que los emisores de comprobantes electrónicos deberán incluir obligatoriamente el:

Este dato debe incorporarse en la sección de información adicional del comprobante electrónico, conforme a lo establecido en la Ficha Técnica de Comprobantes Electrónicos que publique el SRI.

Esto obliga a rediseñar la configuración de la empresa emisora en todo software tributario:

CompanyConfiguration
├── ruc: "0991111111001"
├── establishment: "001"
├── issue_point: "002"
├── electronic_signature_path: "/certs/company.p12"
├── sri_environment: "PRODUCCION"
└── billing_software_provider_ruc: "0992222222001"  <-- Nuevo Campo Requerido

8. ¿Significa que Tenemos que Modificar el XML Inmediatamente?

Conviene ser sumamente rigurosos como ingenieros de software:

Por lo tanto, la arquitectura del software debe desacoplar las responsabilidades:

9. Diseño de Implementación en Arquitecturas de Software

En plataformas de facturación, ERPs modulares y APIs REST de emisión tributaria, el RUC del proveedor debe aislarse en un servicio centralizado de configuración:

{
  "company": {
    "ruc": "0991111111001",
    "razon_social": "COMERCIAL EJEMPLO S.A."
  },
  "electronic_invoicing": {
    "schema_version": "2.1.0",
    "provider": {
      "ruc": "0992222222001",
      "activity_code": "J62021002",
      "status": "REGISTERED"
    }
  }
}

Pipeline de Construcción del Documento Electrónico

10. SaaS Multiempresa: Cuidado con Hardcodear el RUC

En plataformas multi-tenant (SaaS) donde conviven cientos o miles de contribuyentes emitiendo comprobantes, un grave antipatrón de arquitectura sería quemar el RUC en el código fuente:

# ANTIPATRÓN CRÍTICO: No hardcodear el RUC del proveedor
PROVIDER_RUC = "0999999999001"

Esto falla inmediatamente en escenarios de:

• Marcas blancas (White-Label): Donde un reseller vende la solución bajo su propia figura comercial y necesita declarar su RUC con código J62021003.
• Múltiples proveedores tecnológicos: Integradores que conectan su frontend con diferentes pasarelas de facturación según la región o el plan.
• Migraciones de RUC: Cambios societarios de la empresa de software sin requerir despliegues de código a producción.

Modelo de Dominio Recomendado

Tenant / Company
├── id: UUID
├── ruc: String (13)
├── legal_name: String
└── billing_provider_id: UUID
          │
          └──> BillingProvider
               ├── id: UUID
               ├── ruc: String (13)
               ├── legal_name: String
               ├── provider_type: Enum (CREATOR, DISTRIBUTOR)
               ├── sri_activity_code: String ("J62021002" | "J62021003")
               ├── is_active: Boolean
               └── valid_from: Date

11. ¿Qué Ocurre con un ERP Desarrollado Internamente (In-House)?

Existe un caso de estudio habitual en grandes empresas corporativas: compañías que cuentan con un departamento de TI que programó su propio facturador interno.

El artículo 2 de la resolución define como proveedores a quienes desarrollan o poseen sistemas:

“con la finalidad de ser comercializados”

o a quienes comercializan sistemas desarrollados por terceros.

Bajo una lectura textual estricta de la resolución:

1. Si una empresa desarrolló su software de facturación exclusivamente para su propio uso interno.
2. Y no comercializa, ni sublicencia, ni cobra por el uso de dicho software a terceros.

Ese sistema no encaja formalmente en las dos categorías de comercialización. Sin embargo, esto debe ser evaluado con cautela por el departamento legal y tributario de cada organización frente a las consultas vinculantes que emita el SRI, ya que el emisor de todas formas requerirá definir cómo se reporta a sí mismo en los campos adicionales si la Ficha Técnica lo exige para todos los comprobantes.

12. ¿Qué Ocurre con Software Open Source (Odoo, ERPNext, Dolibarr)?

El ecosistema de software libre presenta particularidades:

13. Cronograma de Cumplimiento: Plazos Diferenciados

La resolución establece dos plazos claramente diferenciados según el rol del actor:

14. Matriz Comparativa de Obligaciones

15. Los Cuatro Frentes de Acción para Empresas de Software

Para abordar este cambio normativo con rigor, recomendamos estructurar el plan de trabajo en cuatro frentes coordinados:

16. Implementación Técnica Paso a Paso

Para los equipos de ingeniería que mantienen sistemas de facturación en producción, proponemos el siguiente ciclo de implementación segura:

17. Validaciones Pre-Vuelo en Código

El objetivo fundamental de la ingeniería de software en entornos tributarios es capturar los errores antes de la firma y transmisión. Si el comprobante se transmite con datos inválidos, el Web Service del SRI retornará estados de DEVUELTA o NO AUTORIZADO, generando demoras operativas.

Ejemplo de validación defensiva en Python:

import re

class ElectronicDocumentValidator:
    @staticmethod
    def validate_ecuadorian_ruc(ruc: str) -> bool:
        """Valida que el RUC tenga 13 dígitos y termine en 001."""
        if not re.match(r"^\d{13}$", ruc):
            return False
        if not ruc.endswith("001"):
            return False
        return True

    def validate_provider_configuration(self, company, document):
        if not company.billing_provider_ruc:
            raise ValueError(
                f"Error de configuración normativa: La empresa emisor {company.ruc} "
                "no tiene configurado el RUC del proveedor de software según "
                "la Resolución SRI NAC-DGERCGC26-00000027."
            )
        
        if not self.validate_ecuadorian_ruc(company.billing_provider_ruc):
            raise ValueError(
                f"El RUC del proveedor de software '{company.billing_provider_ruc}' "
                "no es un RUC ecuatoriano válido de 13 dígitos."
            )

18. Pruebas Automatizadas para Toda la Suite Tributaria

La adición del RUC del proveedor debe verificarse para cada uno de los comprobantes electrónicos autorizados por el SRI:

Cada test debe verificar:

1. Existencia del nodo en infoAdicional conforme a la Ficha Técnica.
2. Integridad del digest de la firma criptográfica XAdES-BES.
3. Transmisión exitosa al web service de pruebas del SRI (celcer.sri.gob.ec).

19. No Confundir Emisor con Proveedor Tecnológico

Es imprescindible mantener clara la separación conceptual en las bases de datos:

El comprobante sigue perteneciendo exclusivamente al contribuyente emisor (0991111111001), pero ahora incluye la huella formal de trazabilidad de su proveedor de tecnología (0992222222001).

20. Versionamiento de Reglas Tributarias: SRI RuleSet Engine

Las normativas fiscales evolucionan constantemente. Una buena arquitectura de software debe permitir la coexistencia de reglas históricas y futuras sin que el software se rompa:

SRI Ruleset Engine
├── RuleSet_2022 (Facturación electrónica obligatoria para todos)
├── RuleSet_2024 (Reformas IVA 15% y retenciones temporales)
└── RuleSet_2026 (Resolución NAC-27: RUC de Proveedor obligatorio)

Almacenar la fecha de vigencia permite que una factura emitida en 2024 que necesite reimprimirse o revalidarse no falle por no contener campos adicionales que fueron creados por resoluciones del año 2026.

21. Checklist de Preparación para Proveedores de ERP y Facturación

Conclusiones

La Resolución Nro. NAC-DGERCGC26-00000027 marca un hito en la formalización de la industria de software en Ecuador. La facturación electrónica deja de ser un proceso anónimo entre un contribuyente y un servidor fiscal: ahora el software que procesa las operaciones mercantiles adquiere identidad tributaria propia.

Para los líderes de tecnología, CTOs y fundadores de software SaaS, esto representa:

• Mayor formalidad y barrera de entrada: El mercado premiará a las casas de software debidamente inscritas y listadas por el SRI.
• Disciplina arquitectónica: La necesidad de separar la lógica de negocio de la lógica tributaria mediante adaptadores y constructores de comprobantes desacoplados.
• Celeridad operativa: 30 días para trámites en el RUC y 60 días calendario para adecuar el software una vez se publique en el Registro Oficial.