¿Puede un ERP gestionar varias entidades jurídicas? Lista práctica de evaluación

Empiece por sus requisitos, no por la expresión «multientidad»

La contabilidad multientidad suele referirse a la gestión de más de una entidad jurídica en un sistema. Esta definición no indica cómo gestiona un producto concreto los libros contables, las transacciones, las reglas de acceso o los informes: esos flujos varían según el producto y su configuración. (Rillet, “Multi-Entity, Multi-Currency ERP for Scale-Ups”: https://www.rillet.com/blog/multi-entity-multi-currency-erp-global-expansion)

Considere la consolidación, unos cierres más sencillos y la reducción de riesgos como resultados que debe comprobar, no como beneficios automáticos. Oracle NetSuite los describe como posibles objetivos de la contabilidad multientidad, pero esa descripción no demuestra lo que logrará una implementación concreta. Además, gestionar entidades en un solo sistema puede añadir complejidad a los procesos a medida que crece una organización. (Oracle NetSuite: https://www.netsuite.com/portal/resource/articles/accounting/multi-entity-accounting.shtml; Citrin Cooperman: https://www.citrincooperman.com/In-Focus-Resource-Center/Multi-Entity-Accounting-in-QuickBooks-When-Does-It-Make-Sense-to-Take-the-Next-Step)

Compare un entorno compartido con el enfoque de sistemas separados que utiliza o propone utilizar actualmente, aplicando los mismos flujos reales. Una plataforma compartida es una forma de gestionar varias entidades jurídicas, no una garantía de que sea adecuada para todas las organizaciones. (Rand Group: https://www.randgroup.com/insights/services/evaluation-selection/best-multi-entity-accounting-software-and-erp-systems-for-growing-businesses/)

• Enumere todas las entidades jurídicas incluidas en el alcance, su función en la organización y los equipos que utilizan sus registros.
• Identifique los procesos contables y operativos que deben funcionar entre entidades, no solo dentro de cada una.
• Anote los resultados necesarios: libros e informes por entidad, vistas de grupo, evidencias de auditoría y cualquier informe externo.
• Clasifique cada requisito como esencial, deseable o pendiente de resolver. Distinga las interpretaciones legales y contables de las preguntas sobre configuración del software.

Distinga las entidades jurídicas de las ubicaciones, los departamentos y las monedas

Una entidad jurídica no equivale a un departamento, una sucursal, un proyecto, un almacén o una moneda. Todas estas dimensiones pueden ser importantes en un ERP, pero usar una en lugar de otra puede hacer que no quede claro qué organización es propietaria de una transacción y a qué libros corresponde.

Prepare un mapa breve de las entidades antes de las demostraciones. Para cada entidad, anote las actividades empresariales que realiza, los registros que debe mantener y su relación con las demás. Después, enumere las dimensiones que no son entidades y por las que necesita generar informes, como el departamento o la ubicación.

Pida al proveedor que muestre cómo representa el sistema cada concepto y qué ocurre cuando un usuario introduce una transacción. No deduzca el tratamiento legal o contable a partir de la etiqueta de una pantalla. Consulte con asesores cualificados para confirmar qué entidades y tratamientos de informes necesita su organización.

• ¿Se puede asignar una transacción a la entidad jurídica correcta de forma independiente de su departamento, ubicación o proyecto?
• ¿Puede una misma ubicación o departamento ser pertinente para más de una entidad, si así corresponde a su estructura?
• ¿Cómo distingue el sistema la moneda de la transacción de la moneda de los informes de cada entidad y del grupo, si procede?
• ¿Qué campos son obligatorios para evitar que los usuarios registren actividades en la entidad equivocada?

Compruebe qué debe mantenerse separado: libros, períodos, numeración y acceso

No dé por sentado que un sistema compartido implica controles contables totalmente compartidos o totalmente separados. Para cada requisito, pida al proveedor que identifique el ajuste o flujo de trabajo que lo admite, lo demuestre en un entorno de prueba y explique cualquier limitación o dependencia.

Confirme el comportamiento necesario con su equipo contable. La necesidad de diferenciar períodos, secuencias de numeración, libros mayores u otros controles puede depender de sus políticas contables, jurisdicciones y obligaciones de información.

• Libros: ¿Puede identificar qué registros pertenecen a cada entidad y generar las vistas contables que esta necesita?
• Períodos: ¿Puede cada entidad seguir los controles de período y la secuencia de cierre que requiere el equipo de finanzas? ¿Qué ocurre si una entidad está lista para cerrar antes que otra?
• Numeración: ¿Pueden los identificadores de las transacciones seguir las políticas que necesita por entidad o tipo de transacción? Pregunte qué ocurre si se anula un número o se corrige un registro.
• Permisos: ¿Se puede limitar a los usuarios a las entidades y los registros adecuados para sus funciones? Compruebe qué pueden consultar, crear, editar, aprobar o exportar.
• Rastro de auditoría: Pregunte qué evidencias se conservan de los cambios en las asignaciones de entidades, los registros contables y los accesos de usuario, y cómo pueden obtenerlas los revisores autorizados.

Pruebe los datos maestros compartidos de clientes, proveedores, productos y otros registros

Un registro compartido de cliente o proveedor puede reducir la duplicación del mantenimiento, pero también puede plantear preguntas sobre titularidad, visibilidad, condiciones específicas por entidad y calidad de los datos. No dé por sentado que el ERP comparte automáticamente los datos maestros ni que compartirlos sea adecuado para todos los registros.

Use registros representativos de su propia empresa. Pida al proveedor que muestre si un cliente, proveedor, producto o servicio puede utilizarse en varias entidades, si pueden variar los detalles específicos de cada entidad y qué puede consultar o modificar un usuario de una entidad. Confirme el comportamiento en un entorno de prueba.

• ¿Puede una misma contraparte operar con más de una entidad y cómo se distingue esa actividad en el registro y en los informes?
• ¿Qué campos de los datos maestros se comparten y cuáles pueden variar según la entidad?
• ¿Cómo se identifican y resuelven los registros duplicados o contradictorios?
• ¿Se puede restringir el acceso cuando un registro se comparte entre entidades?
• ¿Qué efecto tiene modificar un registro compartido en las transacciones existentes y futuras?

Recorra las transacciones entre empresas desde el inicio hasta la liquidación

La conciliación entre empresas es un aspecto pertinente que conviene evaluar en la contabilidad multientidad, pero una descripción general de las capacidades de un producto no demuestra cómo gestiona los tipos de transacciones de su organización. (Rillet, “Multi-Entity, Multi-Currency ERP for Scale-Ups”: https://www.rillet.com/blog/multi-entity-multi-currency-erp-global-expansion)

Evalúe el flujo de trabajo completo, no solo una casilla o una pantalla de transacciones. Incluya la transacción que inicia el proceso, el asiento o documento correspondiente en la otra entidad, la revisión y aprobación, la conciliación, la liquidación y los informes que utiliza el equipo de finanzas para confirmar que se ha completado. Pida al proveedor que distinga el comportamiento estándar de la configuración, los pasos manuales, las integraciones y los productos adicionales.

• Pruebe una venta o un servicio que una entidad presta a otra: ¿quién lo inicia, qué registros se crean y cómo se revisan ambas partes?
• Pruebe un gasto que una entidad paga en nombre de otra: ¿cómo se registra, aprueba y concilia la asignación?
• Pruebe una transferencia de inventario, activos u otros artículos si se producen en su organización.
• Pregunte cómo se gestionan los tipos de cambio, las diferencias de fechas, los importes que no coinciden y los asientos de contrapartida rechazados, cuando corresponda.
• Siga el saldo hasta la liquidación. Identifique quién es responsable de cada paso y cómo se ponen de manifiesto las diferencias pendientes.
• Pregunte si el flujo está automatizado, parcialmente automatizado o es manual, y qué controles siguen siendo responsabilidad del cliente.

Verifique los informes por entidad y las vistas de grupo, incluidas las eliminaciones

Pida al proveedor que genere el mismo informe representativo a nivel de entidad y para el grupo. Confirme el alcance, los filtros, la presentación de las monedas, los datos de origen y el momento de cada vista, en lugar de confiar en una pantalla de resumen pulida.

Si necesita informes consolidados, pregunte cómo trata el sistema los saldos y las transacciones entre empresas, incluido si las eliminaciones se representan y de qué manera. No dé por sentado que una vista consolidada equivale a un proceso de consolidación completo. Consulte con sus asesores contables para confirmar el tratamiento contable necesario, los controles de revisión y los resultados de los informes.

• ¿Pueden los usuarios autorizados generar los informes necesarios para una entidad sin mezclar en ellos la actividad de otra?
• ¿Se puede rastrear la vista de grupo hasta las entidades que contribuyen a ella y los registros subyacentes?
• ¿Cómo se identifican, revisan y concilian los saldos entre empresas para la presentación de informes?
• Si se requieren eliminaciones, ¿dónde se registran, se revisan y se reflejan en los resultados?
• ¿Pueden los usuarios consultar el período del informe, el alcance por entidad y los demás filtros que lo determinaron?
• ¿Qué aspectos no consolida ni calcula el producto sin configuración adicional o trabajo manual?

Pruebe las excepciones, no solo el caso ideal

Las demostraciones rutinarias suelen usar datos limpios y un flujo de trabajo sencillo. Su evaluación también debe mostrar qué ocurre cuando un registro es incorrecto, llega tarde, tiene acceso restringido o ya forma parte de un proceso cerrado. Estos casos pueden revelar dependencias operativas que una lista de funciones no explica.

Use sus propias políticas para definir los resultados esperados. Las preguntas siguientes son sugerencias para las pruebas, no afirmaciones sobre cómo gestiona estos casos cada ERP.

• Corrección: ¿Qué pasos se pueden seguir si una transacción se asignó a la entidad equivocada? ¿La corrección conserva un historial comprensible?
• Registro tardío: ¿Cómo gestiona el sistema una transacción tardía correspondiente a un período cerrado o cuyo cierre está en curso?
• Cambio de entidad: ¿Se puede modificar la asignación de una entidad después de introducir o aprobar una transacción? ¿Quién puede hacerlo y qué registros o informes se ven afectados?
• Acceso restringido: ¿Qué ocurre si un usuario intenta consultar, editar, aprobar o exportar un registro fuera de su ámbito de permisos?
• Descuadre: ¿Cómo se identifican, asignan y supervisan las parejas incompletas de transacciones entre empresas o los saldos sin conciliar?
• Fallo o excepción: ¿Qué evidencias están disponibles cuando un flujo de trabajo no puede completarse según lo previsto?

Use un guion de evaluación repetible y conserve las evidencias

Aplique el mismo guion a cada sistema candidato. Use escenarios representativos, funciones de usuario realistas y datos de ejemplo que reflejen la estructura de sus entidades. Pida al proveedor que muestre el flujo de trabajo y, cuando sea posible, solicite a su equipo que lo repita en un entorno de prueba.

Para cada requisito, registre el resultado, las evidencias y las preguntas pendientes. Las evidencias pueden incluir un documento del producto con fecha, una pantalla de configuración, el resultado de una prueba o una aclaración por escrito del proveedor. Considere no verificadas las afirmaciones verbales hasta que se confirmen.

• Cree un escenario para cada flujo de trabajo prioritario: registro específico por entidad, datos maestros compartidos, actividad entre empresas, informes y al menos una excepción.
• Para cada escenario, documente los datos iniciales, la función del usuario, el resultado esperado, el resultado real y cualquier solución manual alternativa.
• Indique si el comportamiento es estándar, configurado, dependiente de otro producto o proceso, o si aún no está confirmado.
• Registre las limitaciones, las decisiones que debe tomar el cliente, las dependencias de implementación y la persona responsable de cada seguimiento.
• Evalúe la adecuación según sus requisitos, no según la cantidad de funciones. Considere el fallo de un flujo esencial como un problema que afecta a la decisión, no como una pequeña carencia de la demostración.
• Pida a los equipos de finanzas y operaciones que revisen juntos las evidencias; remita a asesores cualificados las preguntas sobre tratamiento contable y estructura legal.