Si su producto toca facturas — ERP, DMS, contabilidad, compras — le preguntarán si admite la facturación electrónica. Desde ahí hay dos caminos honestos. Esta página los compara sin fingir que construir es peor de lo que es, y sin pretender que comprar elimina todos los compromisos.
| Tarea | Continua, no puntual |
|---|---|
| Analizar y validar el modelo semántico EN 16931 (sintaxis UBL y CII) | Sí — el propio estándar pasó a una nueva versión en 2026 |
| Reglas CIUS de XRechnung (BR-DE-*) además de las reglas base de EN 16931 | Sí — versionadas por separado del estándar base |
| ZUGFeRD/Factur-X: incrustar/extraer correctamente el XML CII en un contenedor PDF/A-3 | Sí — la versión de perfil obligatoria volvió a cambiar en enero de 2026 |
| Schematron de PEPPOL BIS 3.0, mantenido al día con las versiones de OpenPeppol | Sí — salen parches varias veces al año |
| Cada formato nacional al que se expanda (KSeF, FatturaPA, Facturae, VeriFactu, ...) | Sí — cada uno es una especificación separada con su propio ritmo de publicación |
| Mantener un validador de referencia (o construir cobertura de pruebas contra él), para saber realmente que su salida es correcta, no solo que "no falla" | Sí |
Nada de esto es un proyecto de integración puntual. Es un compromiso permanente — alguien en su equipo debe seguir las notas de versión de CEN, OpenPeppol, KoSIT y cada autoridad nacional, indefinidamente, mientras venda esa función.
| Construirlo usted mismo | Integrar INVOX | |
|---|---|---|
| Tiempo hasta la primera validación funcional | Semanas a meses, según formatos/países | Minutos — clave sandbox, primera llamada |
| Quién garantiza la corrección | Su equipo, contra los datos de prueba disponibles | INVOX, reverificado contra la suite de conformidad/XSD oficial de cada estándar |
| Quién sigue los cambios de estándares | Su equipo, indefinidamente | INVOX, indefinidamente |
| Cobertura multi-formato (formatos nacionales) | Cada uno es un proyecto separado | Ya cubierto — una sola integración |
| Prueba/rastro de auditoría de un documento validado | Habría que construirlo aparte | Atestación firmada y verificable sin conexión incluida |
| Lo que mantiene bajo control | Todo | Su producto, su interfaz, su relación con el cliente — el motor de cumplimiento se delega, no su lógica de negocio |
| Residencia de datos / on-premise | Totalmente bajo su control por defecto | Disponible como opción de despliegue de pleno derecho, no solo SaaS |
Honestamente: si el cumplimiento de facturación electrónica es su producto principal — está construyendo una plataforma dedicada a la facturación electrónica, no el cumplimiento como una función de otra cosa — poseer el motor de extremo a extremo puede ser la apuesta estratégica correcta. La pregunta construir-vs-comprar trata en realidad de si el motor de validación es su diferenciador o su centro de costes. Para un proveedor de ERP, DMS o contabilidad, casi siempre es lo segundo.
INVOX no es un ERP, ni un DMS, y no envía facturas en su nombre por defecto — valida, genera, convierte y (donde esté conectado a un Access Point socio) admite la transmisión. Su producto, sus relaciones con clientes y su interfaz siguen siendo completamente suyos. La infraestructura técnica para la transmisión PEPPOL de cuatro esquinas en vivo existe; pasa por un Access Point socio en lugar de que INVOX actúe como AP acreditado — pregúntenos directamente sobre su necesidad específica de transmisión antes de asumir nada.