Separa la migración contable de la continuidad del cliente
El cambio suele presentarse como una transferencia de datos entre un sistema anterior y uno nuevo. Esa descripción es incompleta para una oficina contable. Mientras se exportan maestros, saldos, documentos o configuraciones, la cartera sigue enviando antecedentes, haciendo preguntas y acercándose a vencimientos. Un dato puede migrarse correctamente y, aun así, perderse una acción que solo estaba en un correo o en la memoria de una persona.
Trabaja con dos planes relacionados. El plan de migración contable define qué información pasa, cómo se transforma, quién valida y qué resultado debe coincidir. El plan de continuidad de cartera identifica qué está ocurriendo con cada cliente durante el cambio. Ambos comparten fechas y responsables, pero no deben confundirse.
Al terminar esta guía podrás dividir el cambio en grupos, decidir qué validar antes de avanzar y proteger los pendientes de los clientes aunque la migración técnica todavía no haya terminado.
Esta distinción también aclara el rol de cada herramienta. El ERP o software contable procesa la contabilidad. Una capa de gestión muestra clientes, alertas, tareas, responsables y siguientes acciones. La página sobre cómo complementar un ERP contable desarrolla esa separación sin presentar CRMContable como un ERP.
Define el motivo y el límite del cambio
Antes de preparar archivos, escribe el problema que justifica la transición. Puede ser falta de soporte, dificultad para administrar varias empresas, ausencia de un proceso obligatorio, costos que cambiaron o dependencia de tareas manuales. Después define el resultado observable que debería mejorar. “Modernizar la oficina” no permite comprobar nada. “Cerrar el proceso mensual de un grupo de empresas con usuarios separados y reportes conciliados” sí permite una prueba.
La International Federation of Accountants recomienda alinear la inversión tecnológica con la estrategia de la firma, formular un plan realista, involucrar al equipo y considerar las necesidades de los clientes. Su guía sobre digitalización de firmas pequeñas también destaca la preparación para migrar, la capacitación y un responsable interno de la iniciativa. La idea práctica es simple: el sistema no reemplaza el cambio de proceso.
Fija también lo que queda fuera. Si el proyecto solo cambia el procesamiento contable, no agregues al mismo corte la reorganización completa de documentos, la renovación de equipos y un nuevo modelo de atención. Puedes relacionar esos trabajos, pero cada uno necesita su alcance y evidencia. Para elegir la solución antes de migrar, utiliza los criterios de software contable en Chile.
Construye un mapa de transición por cliente
No comiences con todos los campos disponibles. Comienza con la información que permite seguir atendiendo. Por cada empresa del grupo de transición, una persona autorizada debe poder reconocer la situación actual y explicar qué ocurrirá después. Ese mapa no sustituye los libros, respaldos ni documentos del sistema contable. Funciona como control operativo durante el cambio.
| Elemento | Pregunta de control | Evidencia esperada |
|---|---|---|
| Empresa y periodo | ¿Qué entidad y qué periodo están en transición? | Identificación inequívoca y alcance aprobado. |
| Responsable | ¿Quién responde por el siguiente avance? | Persona asignada y reemplazo definido. |
| Estado actual | ¿Qué ya fue procesado, revisado o enviado? | Resultado verificable en el sistema de origen. |
| Próxima acción | ¿Qué debe ocurrir y en qué herramienta? | Tarea concreta, fecha y criterio de cierre. |
| Bloqueo | ¿Falta información, acceso, decisión o soporte? | Dependencia visible y persona que debe resolverla. |
| Conciliación | ¿Qué resultado debe coincidir entre sistemas? | Reporte, saldo, cantidad o muestra validada. |
Si hoy la cartera no tiene una base común, utiliza primero la guía para organizar clientes contables. No intentes corregir datos históricos y migrar toda la operación en la misma sesión. Clasifica diferencias, define cuáles impiden avanzar y cuáles pueden tratarse después sin ocultarlas.
Agrupa empresas por riesgo, no solo por tamaño
Un piloto útil no comienza necesariamente con el cliente más pequeño. Debe incluir casos que permitan descubrir los riesgos importantes sin exponer toda la cartera. Forma un primer grupo con empresas ficticias o autorizadas que representen una operación frecuente, una excepción conocida y una combinación realista de usuarios. Evita escoger solo casos perfectos.
Evalúa al menos cuatro variables: proximidad de vencimientos, complejidad del proceso, cantidad de antecedentes abiertos y capacidad del equipo para revisar. Una empresa pequeña puede ser de alto riesgo si tiene una regularización en curso. Una empresa con mayor volumen puede ser adecuada para el piloto si su proceso está estable y cuenta con una persona que conoce bien los datos.
| Grupo | Composición | Condición para avanzar |
|---|---|---|
| Prueba controlada | Datos ficticios y procesos completos. | Configuración, permisos, exportación y reversión comprobadas. |
| Piloto | Pocas empresas representativas y sin urgencias extraordinarias. | Resultados conciliados y trabajo diario comprendido por usuarios. |
| Expansión | Empresas agrupadas por proceso y responsable. | Sin defectos críticos repetidos y con soporte disponible. |
| Excepciones | Casos complejos, regularizaciones o integraciones especiales. | Plan propio, responsable experto y evidencia adicional. |
No fijes el tamaño del siguiente grupo solo por calendario. Aumenta cuando el equipo pueda explicar los defectos del grupo anterior, corregirlos y repetir el control. Reducir el lote no es fracasar. Es mantener el impacto dentro de un alcance que todavía puedes observar.
Establece una fuente oficial durante la convivencia
Durante algunos días puede ser necesario consultar ambos sistemas. El peligro aparece cuando los dos aceptan cambios sin una regla. Una persona actualiza un dato en el sistema anterior, otra trabaja en el nuevo y ambas creen estar viendo el estado correcto. La convivencia debe responder tres preguntas: qué se consulta en cada sistema, dónde se registran cambios nuevos y quién reconcilia diferencias.
Define una hora de corte por grupo. Antes de esa hora, el origen sigue siendo la referencia para el alcance declarado. Después del corte, el nuevo sistema recibe las operaciones aprobadas. Si necesitas volver, la ruta de reversión debe indicar qué cambios ocurrieron después del corte y cómo evitar perderlos. No basta con conservar una copia antigua.
El material de ciberseguridad para pymes del CSIRT de Gobierno recomienda controles de acceso y respaldos. En una migración, convierte esas recomendaciones en pruebas: cuentas individuales, permisos mínimos, respaldo recuperable, registro de quién exportó y validación de que la copia puede abrirse. No compartas credenciales para acelerar el corte.
Reconcilia resultados, no solo cantidades de registros
Que el nuevo sistema muestre la misma cantidad de empresas no demuestra una migración correcta. Compara los resultados que sustentan el trabajo. Según el alcance, pueden incluir saldos, totales por periodo, documentos, cuentas, impuestos, identificadores, relaciones, usuarios y permisos. Define tolerancias antes de ejecutar la prueba y explica cualquier diferencia.
- Obtén un reporte de control en el sistema anterior con fecha y alcance.
- Ejecuta la migración o carga del grupo y conserva el registro del proceso.
- Genera el resultado equivalente en el sistema nuevo.
- Compara totales y una muestra a nivel de detalle.
- Clasifica las diferencias entre transformación esperada, defecto y dato pendiente.
- Haz que una segunda persona revise los criterios críticos.
- Aprueba, corrige o revierte antes de ampliar el grupo.
La muestra debe incluir una operación frecuente y una excepción. Si una diferencia no puede explicarse, no la conviertas en “ajuste de migración” para cumplir la fecha. Mantén el grupo detenido y relaciona la evidencia con un responsable.
Protege los trabajos abiertos y los vencimientos
El periodo de transición necesita un tablero de excepciones. No requiere duplicar todo el ERP. Debe mostrar los clientes que tienen una obligación cercana, antecedentes pendientes, una revisión sin cerrar o una incidencia de migración. El objetivo es que la jefatura pueda decidir cada mañana qué requiere atención y quién tiene la siguiente acción.
Para cada asunto abierto, conserva el contexto mínimo: empresa, periodo, trabajo, responsable, fecha, bloqueo, próxima acción y evidencia de cierre. Si el nuevo sistema no está listo para recibir ese flujo, mantén el registro temporal en un lugar compartido y autorizado. Define cuándo desaparecerá. Una planilla temporal sin dueño ni fecha de cierre puede transformarse en la nueva fuente paralela permanente.
La guía de gestión de cartera contable muestra cómo relacionar clientes, estados y próximas acciones. Durante el cambio, esa visibilidad permite que una incidencia técnica no oculte una necesidad del cliente.
Comunica solo lo que cambia para cada persona
No todos necesitan conocer la arquitectura completa. El equipo necesita saber qué herramienta usar, desde cuándo, qué proceso cambia, a quién pedir ayuda y cómo informar una diferencia. Los clientes necesitan una comunicación solo cuando el cambio afecta el canal, el formato, el plazo o una acción que deben realizar. Evita anunciar beneficios que todavía no fueron comprobados.
Prepara tres mensajes internos: inicio del piloto, cambio de grupo y cierre del sistema anterior. Cada mensaje debe indicar alcance, hora de corte, fuente oficial, soporte y plan ante incidentes. También prepara una respuesta breve para el cliente si una gestión demora por la transición. Explica la acción concreta que realizará la oficina y no uses el cambio de software como justificación genérica.
IFAC recomienda involucrar a clientes cuando la adopción tecnológica requiere su participación. Eso no significa enviar una campaña a toda la cartera. Significa anticipar el cambio a quienes deberán usar un nuevo canal, autorizar una acción o modificar la forma de entregar antecedentes.
Usa criterios de avance, pausa y reversión
La fecha de corte no debe ser el único criterio. Define condiciones observables antes de comenzar. Avanza si los procesos obligatorios terminan, los resultados críticos coinciden, los usuarios comprenden el flujo y las incidencias pendientes tienen dueño. Pausa si aparecen diferencias repetidas, permisos incorrectos, exportaciones incompletas o trabajo paralelo que nadie puede reconciliar.
Si no puedes demostrar qué dato es correcto, quién debe actuar y cómo volver al estado anterior sin perder cambios posteriores, el grupo todavía no está listo para avanzar.
La reversión no implica borrar el trabajo nuevo. Registra qué operaciones se hicieron después del corte y cómo se reincorporarán si vuelves al origen. Conserva respaldos según las obligaciones y políticas aplicables. Cerrar el sistema anterior requiere comprobar exportaciones, accesos, contratos y retención, no solo dejar de pagar una suscripción.
Confirma los requisitos aplicables en Chile
El alcance tributario del cambio depende del sistema utilizado y de la situación de cada contribuyente. Una pregunta frecuente del Servicio de Impuestos Internos, actualizada el 13 de mayo de 2025, indica que quienes cambien el sistema de contabilidad que sirvió de base para calcular la renta según sus libros deben solicitar aprobación mediante el Formulario 2117 y describir el sistema actual y el que lo reemplazará. Revisa la respuesta oficial del SII sobre cambio de sistema de contabilidad y la normativa relacionada antes de decidir si aplica a tu caso.
No supongas que una migración ofrecida por el proveedor resuelve autorizaciones, conservación, documentación o validaciones profesionales. Asigna a una persona para confirmar requisitos vigentes, alcance contractual y evidencia necesaria. Esta guía entrega un método operativo y no sustituye asesoría tributaria, legal, contractual, técnica ni de seguridad.
Cierra la transición con evidencia
Una transición termina cuando la oficina puede trabajar desde la fuente definida, no cuando finaliza la importación. Confirma que cada grupo fue conciliado, que los pendientes de clientes tienen estado y responsable, que los usuarios saben operar, que el soporte está disponible y que el sistema anterior quedó con un destino documentado.
- El motivo y el resultado esperado del cambio están escritos.
- La migración contable y la continuidad de cartera tienen planes separados.
- Los grupos se definieron por riesgo y capacidad de revisión.
- Cada cliente en transición tiene responsable y próxima acción.
- La fuente oficial y la hora de corte son inequívocas.
- Los resultados críticos fueron conciliados con evidencia.
- Accesos, respaldos y reversión fueron probados.
- Las incidencias pendientes tienen dueño y fecha.
- Los requisitos del SII y del contrato fueron revisados para el caso.
- El sistema anterior tiene una fecha y un procedimiento de cierre.
Cambiar de software contable puede mejorar una operación, pero el beneficio aparece después de una adopción verificable. Protege primero la continuidad del servicio, mueve un grupo que puedas observar y amplía solo cuando la evidencia permita confiar en el siguiente corte.
Preguntas frecuentes sobre cambiar software contable
¿Se puede cambiar de software contable sin migrar todo de una vez?
Sí. Una transición por grupos permite probar configuración, saldos, documentos, permisos y operación antes de ampliar el cambio. El grupo piloto debe representar casos reales de la cartera y tener criterios de aprobación y reversión definidos. La migración histórica depende del alcance, las obligaciones y la capacidad de exportación de cada sistema.
¿Qué conviene preparar antes de cambiar el sistema?
Conviene inventariar procesos, empresas activas, obligaciones cercanas, usuarios, permisos, integraciones, documentos, reportes, datos maestros, saldos y trabajos abiertos. También debes identificar el lugar oficial de cada dato y el responsable que validará su resultado en el nuevo sistema.
¿Cómo evito que se pierdan pendientes de los clientes?
Mantén un registro de continuidad separado de la migración técnica. Por cada cliente debe quedar visible el responsable, el estado actual, la próxima acción, la fecha comprometida, el bloqueo y la evidencia necesaria. Ese registro se reconcilia antes y después de mover cada grupo.
¿Cuánto tiempo deben convivir el sistema anterior y el nuevo?
Solo el periodo necesario para comprobar el alcance definido. La convivencia debe tener fecha de término, datos que se actualizan en cada sistema y un responsable de reconciliación. Mantener dos fuentes activas sin reglas ni cierre produce estados contradictorios.
¿Cambiar de software requiere un trámite ante el SII?
Depende del tipo de cambio y de la situación del contribuyente. El SII mantiene una consulta específica para cambios del sistema que sirve de base a los libros de contabilidad. Revisa la información oficial vigente y confirma el caso con el profesional responsable antes de ejecutar la transición.
¿Cómo ayuda CRMContable durante el cambio?
CRMContable puede mantener visible la cartera, la información y alertas disponibles del SII, las tareas, los responsables y el seguimiento mientras el ERP o software contable conserva el procesamiento. No ejecuta la migración contable ni reemplaza la validación profesional.
Fuentes y alcance
Esta guía utiliza publicaciones de IFAC sobre estrategia tecnológica y digitalización de firmas pequeñas, material del CSIRT de Gobierno sobre acceso y respaldo, y una consulta oficial del SII sobre cambios del sistema que sirve de base a los libros contables. El mapa de continuidad, las cohortes y los criterios de avance son un método operativo propuesto por CRMContable. Deben adaptarse al software, contrato, obligaciones y riesgos de cada oficina.