Migrar de A3 o Sage sin Perder el Histórico Contable 2026

Actualizado: 24 de julio de 2026 — Redactado por el equipo de COPILOT GESTORIA con la revisión de asesores fiscales colegiados.

Migrar de A3 o Sage a otro programa sin perder el histórico contable es posible si se sigue un protocolo con fecha de corte: se cierra y concilia el sistema antiguo, se traspasan los saldos de apertura verificados a esa fecha, y el detalle histórico de asientos (con su numeración y su conciliación bancaria completa) permanece consultable en el programa viejo durante el plazo legal de conservación, en vez de intentar reconstruirlo asiento a asiento en el nuevo. Ningún fabricante —tampoco A3 ni Sage— reconstruye automáticamente el histórico completo de asientos al migrar entre programas: lo que se traspasa de forma fiable son los saldos de apertura a una fecha concreta, no todo el detalle transaccional de ejercicios anteriores.

Este es el miedo que casi ningún proveedor te explica antes de venderte el cambio: no es un problema de "que se pierdan los datos" en el sentido literal, sino de que el traspaso automático nunca fue diseñado para reconstruir el detalle histórico, solo para arrancar el nuevo ejercicio con saldos correctos. Entender esa diferencia —y planificar en consecuencia— es lo que separa una migración controlada de una que acaba en descuadres, llamadas a soporte y noches sin dormir antes de una presentación trimestral.

1. El miedo real: qué se pierde de verdad al cambiar de programa contable

Cuando un gestor busca "cambiar de A3 o Sage sin perder el histórico contable", detrás de esa frase hay tres miedos concretos y bien fundados: que los saldos de apertura del nuevo ejercicio no coincidan con el mayor del año anterior, que desaparezca la trazabilidad de años de asientos de clientes con obligaciones fiscales todavía vivas, y que el cambio coincida mal con un cierre de trimestre o con una inspección en curso. Ninguno de los tres es infundado.

El hilo del foro Plan General Contable ilustra el primer miedo con un caso real: un usuario relata que al exportar e importar el diario entre ContaPlus y A3 "no me importa todos los asientos, dejando fuera los relativos a las ventas. El error que da es: % iva o rec distinto". Otro usuario del mismo hilo, dos años después, describe exactamente el mismo síntoma: "al importar tengo problemas con los asientos por el iva". Que el mismo fallo aparezca en usuarios distintos con años de diferencia no es casualidad puntual: es un patrón estructural de cómo se configuran las cuentas de IVA en cada programa, no un bug aislado.

El servicio de soporte de Software DELSOL documenta el segundo miedo con un artículo de ayuda propio, cuyo título ya lo dice todo: "El saldo de una cuenta, en apertura, no coincide con el mayor del ejercicio anterior". Que un fabricante tenga que dedicar un artículo de ayuda permanente a este síntoma confirma que no es un caso aislado, sino un ticket de soporte recurrente en el propio ecosistema de software contable español.

La buena noticia es que ninguno de estos tres miedos exige renunciar al cambio. Exige planificarlo como lo que realmente es: un mini-cierre contable con fecha de corte, no una simple exportación de fichero. El resto de este artículo desarrolla ese protocolo, formato por formato y paso por paso.

2. El marco legal que condiciona tu migración

¿Qué obligaciones legales siguen vivas después de cambiar de programa contable? Cambiar de software no elimina ninguna obligación de conservación, legalización ni suministro de información a la AEAT: esas obligaciones están atadas al ejercicio y al obligado tributario, no al programa informático que se use en cada momento. Cuatro normas concretas condicionan cómo debe ejecutarse la migración.

2.1. Conservación de libros: 6 años desde el último asiento

El artículo 30 del Código de Comercio establece la obligación con literalidad clara: "Los empresarios conservarán los libros, correspondencia, documentación y justificantes concernientes a su negocio, debidamente ordenados, durante seis años, a partir del último asiento realizado en los libros, salvo lo que se establezca por disposiciones generales o especiales" (Art. 30 Código de Comercio). Este plazo de 6 años es independiente de si el programa contable con el que se generaron esos libros sigue instalado o no: la obligación recae sobre el empresario, no sobre el proveedor de software.

2.2. Prescripción tributaria: 4 años, pero hasta 10 para bases negativas

Según el artículo 66 de la Ley 58/2003 General Tributaria, el derecho de la Administración a determinar la deuda tributaria mediante liquidación prescribe a los 4 años. Sin embargo, el artículo 66 bis extiende ese plazo a 10 años cuando se trata de comprobar bases o cuotas compensadas o pendientes de compensar (por ejemplo, bases imponibles negativas o deducciones no aplicadas), aunque el ejercicio de origen ya haya prescrito a efectos de liquidación. En la práctica, si un cliente arrastra una base negativa de hace 8 años, el histórico contable de ESE ejercicio concreto debe seguir siendo recuperable aunque el software haya cambiado dos o tres veces desde entonces.

2.3. Legalización telemática de libros: obligatoria desde 2015, plazo 30 de abril

Desde el 1 de enero de 2015, "la legalización debe realizarse exclusivamente de forma telemática, en soporte electrónico" (Sage), con plazo general de 4 meses tras el cierre del ejercicio (30 de abril para quien cierra a 31 de diciembre). Esto tiene una implicación técnica poco comentada: si el cambio de programa se produce a mitad de ejercicio, el Libro Diario que se legalice en el Registro Mercantil debe corresponder a un ejercicio completo, uniendo de forma coherente el tramo generado con el programa viejo y el tramo generado con el nuevo. No basta con legalizar "lo que hay en el programa nuevo": hay que poder generar el Diario íntegro del año.

2.4. VeriFactu: aplazado a 2027, pero relevante si ya se aplica de forma voluntaria

El Real Decreto-ley 15/2025 (BOE de 3 de diciembre de 2025) aplazó por segunda vez la entrada en vigor de VeriFactu: el 1 de enero de 2027 para empresas sujetas al Impuesto de Sociedades y el 1 de julio de 2027 para el resto de empresas y autónomos, según confirman TeamSystem y el ICAM. Es la segunda prórroga de esta norma (venía de un aplazamiento previo de 2026), lo que aconseja no dar por cerrado el calendario de forma definitiva. Si el sistema origen ya genera hash y QR encadenado de forma voluntaria, el nuevo programa debe decidir explícitamente cómo tratar esa cadena de integridad al migrar: importarla, o documentar el punto de corte donde empieza a generar la suya propia.

2.5. Portabilidad de datos y devolución al finalizar el contrato (RGPD)

Dos artículos del RGPD son directamente aplicables cuando un proveedor de software pone trabas a la exportación. El artículo 20 regula el derecho a la portabilidad: la AEPD lo resume con claridad, "la compañía no podrá negarse a proporcionarte los datos salvo que exista una causa de peso que lo justifique" (AEPD). Y el artículo 28.3.g) obliga al encargado del tratamiento a "suprimir los datos a elección del responsable, o bien devolver todos los datos personales una vez finalice la prestación de los servicios de tratamiento". En la práctica, uno de los errores más frecuentes es que muchos contratos de software de gestoría ni siquiera regulan de forma explícita esta cláusula de devolución al finalizar el servicio: conviene revisarlo antes de firmar la baja con el proveedor actual.

2.6. El caso especial del SII

Si un cliente está en el SII, la AEAT exige el envío de los registros de facturación en un plazo máximo de 4 días desde la emisión de la factura, con sanción del 0,5% del importe de la factura (mínimo 300€, máximo 6.000€ por trimestre), según las FAQs oficiales del SII (AEAT, actualizadas 16/06/2025). Si la migración de software coincide con un hueco operativo de varios días en el que ninguno de los dos sistemas está suministrando registros, ese hueco es sancionable en sí mismo, con independencia de que los datos contables acaben cuadrando.

3. Los formatos de fichero que de verdad existen

¿Qué formato de fichero exporta cada programa contable español y qué se queda fuera? No existe un estándar único: cada fabricante usa su propio formato de intercambio, y ninguno traspasa el 100% de la información operativa (adjuntos, conciliación bancaria, series de numeración) junto con los asientos. Conocer las limitaciones de cada uno antes de empezar evita sorpresas a mitad de proceso.

3.1. La diferencia estructural que nadie explica: A3 vs ContaPlus/Sage

Hay un detalle técnico documentado en un hilo del Sage Community Hub que explica buena parte de los descuadres de apertura: "A3, a diferencia de Contaplus, carga los saldos de apertura directamente en la propia cuenta, no en un asiento". Quien migra desde A3 esperando encontrar un asiento de apertura reconocible en el nuevo sistema —como el que genera ContaPlus o Sage 50— no lo va a encontrar de la misma forma: el saldo vive en el campo de la cuenta, no en una línea de asiento con fecha 1 de enero. Hay que reconstruirlo de forma explícita en el nuevo programa, no asumir que se traspasa igual.

3.2. Por qué el formato "estándar" no es tan estándar

El propio soporte de Sage reconoce con honestidad los límites del proceso: la migración de datos estándar "no permite recuperar el histórico de datos contables, por lo que puede ser necesario establecer una fecha de transición e importar los saldos de apertura de las cuentas". Es la confirmación, desde el lado del fabricante, de lo que ya has visto en los foros: el fichero de intercambio traspasa saldos y estructura, no el detalle transaccional completo con su trazabilidad documental.

4. Por qué no te cuadran los saldos de apertura (y el protocolo para que cuadren)

¿Por qué no me cuadran los saldos de apertura al cambiar de programa contable? Casi siempre por una de tres causas: el sistema origen no estaba realmente cerrado y conciliado en el momento de exportar, las cuentas de IVA no estaban configuradas de forma equivalente entre ambos programas, o se mezcló el concepto de "saldo de apertura" (A3) con el de "asiento de apertura" (ContaPlus/Sage) sin ajustar la diferencia estructural descrita en la sección anterior.

4.1. El protocolo: tratar la migración como un mini-cierre

La recomendación que se repite en fuentes de soporte especializado (STEL Order, foros técnicos, soporte de Software DELSOL) coincide en un mismo enfoque: la migración de saldos iniciales debe planificarse como un mini-cierre contable, no como una simple exportación de fichero. Eso implica tres pasos secuenciales:

1. Cerrar y conciliar el sistema viejo a la fecha elegida: todos los apuntes bancarios punteados, todas las facturas del periodo contabilizadas, ningún asiento pendiente de repaso.
2. Generar el balance de comprobación (sumas y saldos) a esa fecha de corte en el sistema origen, como fotografía de referencia inmutable.
3. Cargar los saldos de apertura en el sistema nuevo verificando que se cumple la ecuación patrimonial (activo = pasivo + patrimonio neto) y que el sumatorio de deudor coincide con el de acreedor, cuenta por cuenta.

4.2. Los tres puntos de fricción del cuadre

El fallo de IVA documentado en el foro de Plan General Contable ("% iva o rec distinto") tiene una causa habitual señalada por otro usuario del mismo hilo: las cuentas de IVA "no estén bien configuradas" de forma equivalente entre programas. En la práctica, tres focos concentran la mayoría de los descuadres al migrar saldos de apertura:

4.3. La fecha de corte como cifra de control, no como trámite

La fecha de corte no es un formalismo administrativo: es la cifra de control contra la que se valida todo el proceso. Si el balance de comprobación del sistema viejo a esa fecha y el balance de apertura del sistema nuevo no coinciden al céntimo, no se avanza al siguiente paso. Este principio —no seguir adelante hasta que cuadre— es el que evita que un descuadre pequeño en la apertura se arrastre y se multiplique durante todo el ejercicio siguiente.

5. Protocolo de migración paso a paso con fecha de corte

¿Cuándo es el mejor momento para cambiar de programa de contabilidad? El momento técnicamente más seguro es el cierre de un trimestre natural, una vez presentados el Modelo 303 y, en su caso, el 130/131, porque esa fecha ya exige tener la contabilidad conciliada por obligación fiscal y proporciona una cifra de control externa (lo declarado a la AEAT) contra la que verificar el traspaso.

5.1. Por qué el cierre de trimestre y no una fecha arbitraria

Elegir el cierre de trimestre como fecha de corte tiene una ventaja práctica: el propio calendario fiscal obliga a tener el IVA y, en su caso, el pago fraccionado ya calculados y presentados. Eso convierte la declaración ya presentada en un punto de referencia verificable, algo que no ocurre si se elige una fecha intermedia sin obligación fiscal asociada. No existe una norma que impida cambiar de programa a mitad de ejercicio, pero hacerlo coincidir con un cierre trimestral reduce el riesgo de arrastrar descuadres desde el primer día.

5.2. Los tres tramos del protocolo

5.3. Duración realista del proceso

Según una comparativa especializada de software para gestorías, "las migraciones de ContaPlus a A3 normalmente toman 2-4 semanas y requieren validación exhaustiva. No se pierden datos, pero sí requiere tiempo y experiencia técnica" (BVNJ). Es una referencia útil para dimensionar el proyecto frente a un cliente o a un socio del despacho: no es un proceso de una tarde, aunque tampoco requiere un proyecto de meses si el fichero de origen está limpio y conciliado.

6. Qué se pierde SIEMPRE (y cómo mitigarlo)

Hay tres elementos que ningún proceso de migración estándar traspasa de forma íntegra, con independencia del programa de origen o destino: la trazabilidad y numeración de documentos, la conciliación bancaria histórica, y los adjuntos digitalizados. Aceptarlo de entrada permite diseñar una mitigación realista en lugar de perseguir una migración "perfecta" que ningún fabricante ofrece.

6.1. Trazabilidad y numeración: por qué se rompe

Como confirma el análisis de Cubio citado en la sección 1, "la numeración y los enlaces entre documentos se rompen" al migrar el histórico de asientos. Esto es especialmente relevante para facturas rectificativas o asientos que hacen referencia cruzada a otro documento: el enlace lógico (esta rectificativa corrige aquella factura) no siempre sobrevive al cambio de programa, aunque el importe y la fecha sí lo hagan.

Mitigación: mantener el acceso de solo lectura al programa antiguo durante el plazo legal de conservación (los 6 años del art. 30 CCom, o los 10 años si hay bases negativas pendientes de comprobación bajo el art. 66 bis LGT), en vez de forzar una reconstrucción del 100% del histórico en el nuevo sistema. Es más barato y más fiable conservar el programa viejo como archivo consultable que intentar migrar cada enlace documental uno a uno.

6.2. Conciliación bancaria: el papel de la Norma 43

El punteo banco-contabilidad acumulado durante años rara vez se traspasa de forma automática entre programas. Aquí la Norma 43 —el estándar de cuaderno bancario de la Asociación Española de Banca— cumple un papel independiente del software contable: permite reconstruir los movimientos bancarios y volver a conciliarlos en el sistema nuevo sin depender de que el programa viejo "exporte bien" ese punteo. Si la conciliación histórica es crítica para un cliente concreto (por ejemplo, de cara a una inspección), solicitar los extractos en Norma 43 al banco es una vía de reconstrucción independiente del fabricante de software.

6.3. Adjuntos digitalizados

Los PDF de facturas escaneadas o los justificantes adjuntos a un asiento casi nunca viajan dentro del fichero de intercambio contable (ni SUENLACE.DAT, ni xdiario, ni MovConta contemplan adjuntos binarios). El manual de traspaso de Criterium para A3ECO/A3CON/A3Asesor lo confirma de forma explícita entre lo que no se traspasa. La mitigación pasa por exportar los adjuntos por separado, en carpetas organizadas por cliente y ejercicio, antes de dar de baja el acceso al sistema origen.

6.4. Series de facturación

Si el cliente lleva varias series de facturación (ordinaria, rectificativa, simplificada), la correlatividad de cada serie es un dato que puede perderse o discontinuarse al cambiar de sistema. Conviene documentar el último número usado de cada serie en el sistema viejo antes de arrancar la numeración en el nuevo, para evitar tanto huecos como duplicidades.

7. Lista de comprobación de cuadre tras la migración + plan de marcha atrás

¿Qué hago si tras migrar detecto que los saldos no coinciden? Antes de tocar nada en el sistema nuevo, hay que determinar si el descuadre es un ajuste menor localizado (una cuenta, un cliente) o un fallo sistémico que afecta a todo el balance; solo el segundo caso justifica volver por completo al sistema anterior.

7.1. Lista de comprobación tras la migración

7.2. Cuándo es un ajuste menor y cuándo hay que parar

Un descuadre localizado en una única cuenta o cliente, identificable y corregible con un asiento de ajuste puntual, no justifica deshacer toda la migración. En cambio, si el balance de sumas y saldos global no cuadra, si aparecen cuentas duplicadas de forma masiva, o si el IVA migrado no coincide con lo declarado en más de una cuenta, es momento de parar el proceso antes de seguir operando sobre datos no verificados.

7.3. Plan de marcha atrás

1. No borrar ni desinstalar el sistema viejo hasta que el nuevo esté validado con la lista de comprobación completa, aunque hayan pasado semanas desde la fecha de corte.
2. Congelar la operativa en el sistema nuevo (sin nuevos asientos) en cuanto se detecta un descuadre sistémico, para no mezclar datos correctos con datos importados con error.
3. Volver a exportar desde el sistema viejo con la configuración corregida (cuentas de IVA, longitud de subcuentas) y repetir el tramo de validación intermedia antes de reimportar.
4. Documentar el incidente: qué falló, en qué cuenta, y qué ajuste se aplicó, como referencia para la siguiente migración de otro cliente de la cartera.

8. Errores frecuentes y preguntas para tu proveedor actual antes de pedir la exportación

Antes de solicitar la baja o la exportación de datos al proveedor actual, conviene tener claras las respuestas a un pequeño número de preguntas que anticipan la mayoría de los problemas descritos en este artículo.

8.1. Cinco preguntas que hacer al proveedor actual

• ¿En qué formato exacto se entrega la exportación (SUENLACE.DAT, xdiario, MovConta u otro) y qué versión del fichero es?
• ¿La exportación incluye adjuntos digitalizados y series de facturación, o solo asientos y saldos?
• ¿Existe alguna cláusula contractual (art. 28 RGPD) que regule expresamente la devolución de datos al finalizar el servicio?
• ¿Cuánto tiempo seguirá siendo accesible el histórico si se mantiene una licencia de solo consulta tras la baja?
• ¿Cómo está configurado el plan de cuentas (longitud de subcuenta, codificación de IVA) para poder homogeneizarlo antes de exportar?

8.2. Errores frecuentes documentados

8.3. Cuándo conviene planificar la migración cliente a cliente

En una cartera de decenas o cientos de clientes no es necesario migrar a todos el mismo día. Priorizar primero los clientes con contabilidad más sencilla (menos cuentas, sin bases negativas históricas, sin SII) permite validar el protocolo completo con bajo riesgo antes de abordar los expedientes más complejos, donde un error de cuadre tiene mayor coste.

Preguntas frecuentes