Herramientas Por Redacción de crux · 11 min de lectura

Factura electrónica: riesgos de depender del proveedor

Contenido del artículo

Cuando la facturación electrónica deja de ser un PDF que se manda por correo y pasa a ser un fichero estructurado con validaciones, estados y acuses, el programa que la emite deja de ser una herramienta y se convierte en el archivo de la empresa. Ahí está el problema que casi nadie plantea en la reunión de alta: no es si el software funciona bien, es qué pasa el día en que haya que irse.

El impacto de la factura electrónica en la gestión diaria

La obligación de facturar en formato electrónico entre empresas y profesionales (B2B, Ley Crea y Crece) y la adaptación de los sistemas de facturación a los requisitos de VeriFactu (Ley Antifraude) son dos normativas distintas, ambas con plazos escalonados y que ya se han movido en el pasado. Conviene confirmar siempre las fechas aplicables en la Sede Electrónica de la AEAT antes de informar a un cliente (el calendario de la factura B2B, en la guía de la factura electrónica obligatoria para gestorías). Lo que no cambia con estos calendarios es el riesgo de encerrar diez años de facturación en una base de datos a la que solo accede un proveedor. La AEAT pondrá además a disposición una solución pública para emitir y recibir facturas electrónicas, una alternativa que no depende de un proveedor privado: cómo funciona, en la solución pública de facturación electrónica.

En papel o en PDF, el original de la factura era legible por cualquiera. Con la factura electrónica, el original es un XML: lo valida una máquina, lo firma un sistema y su contenido va mucho más allá de lo que se ve impreso. Dentro hay identificadores de cliente, desglose por líneas, tipos de IVA aplicados, referencias a la factura rectificada si la hay y, cuando el receptor empieza a comunicar estados, un historial de aceptación, rechazo y pago.

Eso cambia dos cosas en el día a día del despacho. La primera: el libro registro de facturas expedidas ya no se reconstruye a mano con los PDF, se extrae del sistema. La segunda: el estado de un cobro deja de estar en la cabeza de quien llama al cliente y pasa a estar en una plataforma. Si mañana ese histórico no se puede sacar entero, lo que se pierde no es «el programa», es la trazabilidad de lo declarado.

De ahí sale la pregunta que conviene hacer antes de contratar, no después: ¿qué me llevo si me voy?

Riesgos de la dependencia tecnológica con un solo proveedor

El problema del “vendor lock-in” en la facturación

La dependencia tecnológica no se construye con malas intenciones, se construye con comodidad. Se contrata un software de facturación, se cargan los clientes, se montan las series, se enlazan las facturas recurrentes, se configuran los remesados y, a los dos ejercicios, cambiar significa reconstruir todo eso. El coste de salida ya no es el precio de la cuota: es el tiempo de un técnico durante semanas.

Las formas concretas en que se cierra la puerta son reconocibles:

  • Exportación solo en PDF. Se presenta como «descarga de todas tus facturas» y, en la práctica, son imágenes: no hay líneas de detalle, ni base por tipo, ni estado de cobro, ni vínculo con el asiento contable.
  • Exportación incompleta. Salen las cabeceras (número, fecha, cliente, total) pero no el desglose. Para un libro registro puede valer; para volver a emitir una rectificativa de hace tres años, no.
  • API en el plan caro. El acceso programático existe, pero está reservado al tramo de precio superior, justo el que no se contrató.
  • Datos vivos solo en su nube. Si se cancela la suscripción, el acceso se corta en días. Y la obligación de conservar la documentación sigue viva durante años después, con plazos distintos en el ámbito fiscal y en el mercantil: no son el mismo número, conviene contrastar ambos antes de decidir cuánto histórico hay que tener fuera de la plataforma.

Ese último punto es el que de verdad duele. Un requerimiento de la AEAT sobre un ejercicio antiguo no espera a que se negocie con el antiguo proveedor la recuperación de un volcado.

La dificultad de migrar datos históricos a otra plataforma

Migrar la cartera de clientes es fácil. Migrar el histórico, no. Lo que se rompe en un cambio de plataforma suele ser siempre lo mismo:

  • La serie de numeración. Cortar a mitad de ejercicio obliga a decidir si se continúa la serie en el sistema nuevo o se abre otra, y a dejarlo documentado para cuadrar el libro registro del año.
  • Los saldos iniciales de clientes y proveedores: las facturas pendientes de cobro no viajan con su estado, llegan como emitidas y hay que volver a marcarlas.
  • Las facturas recurrentes y los mandatos SEPA, que casi nunca se exportan y hay que recrear uno a uno.
  • Los adjuntos: justificantes, albaranes, contratos enlazados a cada factura. Un CSV no los lleva.
  • Las rectificativas, que pierden el enlace con la factura original si el formato de exportación no incluye esa referencia.

Nada de esto es insalvable. Es trabajo, y el trabajo se paga en horas de despacho en el peor momento del año.

Criterios para elegir un software de facturación escalable

Interoperabilidad y formatos de archivo estándar

La interoperabilidad real empieza por el formato del original. La norma europea EN 16931 fija el contenido de la factura electrónica, y sus sintaxis de referencia son UBL y CII, ambas en XML. En España se usa además Facturae, el formato XML que nació para facturar a las Administraciones públicas. Que el programa emita y, sobre todo, importe alguno de esos formatos es lo que convierte tus facturas en un fichero que otro sistema sabe leer.

Conviene no confundir capas: el XML es el original de la factura; JSON y CSV aparecen en la capa de exportación y de API, para mover datos entre aplicaciones. Un proveedor que ofrezca «exportación en JSON» de sus registros está hablando de volcado de datos, no de formato legal de factura. Las dos cosas hacen falta, pero no son la misma.

Pregunta incómoda y muy reveladora: ¿el sistema puede importar facturas emitidas desde otra plataforma, o solo exportar las suyas? Si la importación no existe, la portabilidad es de salida pero no de entrada, y eso convierte cada cambio futuro en una migración manual.

Acceso a la base de datos y exportaciones masivas

Lista de requisitos para pedir por escrito antes de firmar, con respuesta sí/no:

  1. Exportación masiva de facturas emitidas y recibidas con desglose por líneas, no solo totales.
  2. Exportación del maestro de clientes y proveedores completo: NIF, dirección fiscal, condiciones de pago, cuenta bancaria.
  3. Descarga de los XML originales y de sus acuses o justificantes de remisión, no solo del PDF de cortesía.
  4. Adjuntos descargables de forma masiva y asociados a su factura.
  5. Exportación de cobros y estados (pendiente, cobrado parcialmente, rechazado).
  6. Formato de salida documentado: qué columnas, qué codificación, qué separador. Un CSV sin diccionario de campos es un rompecabezas.
  7. Sin límite de registros ni de antigüedad en la exportación.
  8. Acceso tras la baja: cuántos días hay para descargar y si existe volcado final a petición.
  9. API con acceso de lectura al histórico, no solo a los movimientos nuevos, y en qué plan está incluida.

Entre las opciones pensadas para el marco fiscal español hay herramientas como Quipu o Billin, y suites de gestión más amplias como Holded cuando además hace falta contabilidad y bancos en el mismo sitio. Lo que no puede darse por supuesto es el alcance exacto de su exportación: cambia con el plan y con las versiones, así que la respuesta se pide al comercial y se guarda el correo. Las alternativas internacionales de facturación conviene mirarlas con lupa: su encaje con los modelos de la AEAT y con los formatos estructurados españoles suele ser el punto débil, y de poco sirve una exportación perfecta si el fichero no vale aquí.

Cómo garantizar la portabilidad de tus datos

Contratos que aseguren la exportación de facturas y clientes

Si la portabilidad no está en el contrato, no existe. Tres cláusulas que merecen revisión antes de la firma:

  • Devolución de datos a la terminación: plazo, formato y si tiene coste. Un «volcado bajo presupuesto» es una barrera de salida con otro nombre.
  • Ventana de acceso tras la baja: días de consulta en modo lectura una vez cancelada la suscripción.
  • Supresión certificada del resto de la información cuando acabe la relación.

Y una recomendación poco glamurosa que funciona: la exportación no se prueba el día de la baja. Se prueba el primer mes, se guarda el fichero resultante y se repite con periodicidad fija. Un volcado trimestral guardado fuera de la plataforma vale más que cualquier cláusula.

Integraciones vía API para evitar silos de información

Una API bien usada reduce el silo: permite que las facturas lleguen al programa contable, que los cobros se actualicen desde el banco y que el histórico salga sin pasar por la pantalla de descargas. Para encadenar esos pasos sin programar, plataformas de automatización como Make resuelven bien la sincronización periódica entre facturación, contabilidad y una copia propia.

Honestidad por delante: esa capa añade su propia dependencia. Si el flujo que vuelca tus datos vive en un servicio de terceros y nadie en el despacho sabe reconstruirlo, se ha cambiado un candado por otro. La regla práctica es documentar cada automatización en media página —qué mueve, de dónde a dónde, qué pasa si falla— y que el destino final del volcado sea un sitio bajo control propio.

Estrategias para una transición entre proveedores

Auditoría de datos antes de la migración

Antes de cargar nada en el sistema nuevo:

  1. Contar facturas por ejercicio y serie en el sistema antiguo. Ese número es el patrón de cuadre.
  2. Cuadrar las bases y las cuotas del fichero exportado contra lo ya declarado en los modelos trimestrales. Si no coincide, el problema está en la exportación, no en la carga.
  3. Revisar duplicados y clientes con el NIF mal grabado: la migración los multiplica.
  4. Cargar primero un lote de prueba pequeño y comprobar una factura con varios tipos de IVA, una rectificativa y una con retención.
  5. Trabajar en paralelo un periodo completo antes de cortar.

Dos avisos de calendario interno: no se migra en enero, con el cierre del ejercicio encima, ni entre el día 1 y el 20 del mes de presentación trimestral. Y si el motivo del cambio es una mejora marginal de precio o de interfaz, el coste en horas del trimestre puede superar el ahorro del año: en ese caso, no conviene.

Automatización en el traslado de registros

Las partes repetitivas del traslado —mapear campos, normalizar formatos de fecha, separar base y cuota, detectar registros sin NIF— se automatizan bien con scripts o con flujos de integración, y evitan el error de copiar y pegar a mano. Lo que no se delega es la validación: los totales los cuadra una persona contra lo declarado.

Datos de clientes, secreto profesional y RGPD

El proveedor de facturación trata datos personales por cuenta del despacho o de la empresa: es encargado del tratamiento y necesita el contrato correspondiente, con instrucciones, medidas de seguridad, uso de subencargados y previsión expresa de devolución o supresión al terminar. Si no hay ese contrato, la portabilidad es el menor de los problemas.

En una migración se mueve de golpe toda la cartera: nombres, NIF, direcciones, cuentas bancarias. De ahí tres cautelas concretas:

  • Los ficheros intermedios (CSV, volcados) no se dejan en carpetas compartidas ni en el correo. Se cifran y se borran al terminar.
  • El acceso del proveedor nuevo durante la carga se limita a quien haga falta y se revoca después.
  • Si se usa una IA pública para mapear campos o escribir un script, se trabaja con nombres de columna y datos inventados. Nunca con el fichero real de clientes: ahí entran el secreto profesional y las obligaciones del RGPD y la LOPDGDD.

Antes de firmar con un proveedor nuevo

  • Pedir por escrito el alcance de la exportación: líneas de factura, XML originales, adjuntos, estados de cobro.
  • Comprobar que el sistema importa formatos estructurados estándar, no solo los exporta.
  • Confirmar en qué plan está la API y si alcanza al histórico.
  • Leer la cláusula de terminación: plazo, formato y coste del volcado final.
  • Hacer la primera exportación completa el primer mes y guardarla fuera de la plataforma.
  • Fijar fecha de repetición de ese volcado en el calendario del despacho.
  • Contrastar en la AEAT los plazos de conservación y el calendario de la factura electrónica aplicable antes de informar a un cliente.
#factura electrónica#software contable#gestorías#automatización

Sigue leyendo