Cuando una empresa extranjera abre una filial en Perú, una de las primeras decisiones que toma es si la filial va a usar el mismo sistema ERP o contable que usa la casa matriz. La lógica parece impecable: el sistema ya está pagado, el equipo de tecnología de la casa matriz ya lo conoce, y la consolidación de reportes será más simple si todos usan la misma plataforma. Lo que esa lógica no considera es que el sistema de la casa matriz fue diseñado para la normativa del país de origen, no para la normativa peruana. Y la normativa peruana tiene requisitos específicos que ningún ERP global cubre correctamente de forma nativa, sin adaptaciones que cuestan tiempo, dinero y generan riesgo operativo si no se hacen bien. Este artículo explica exactamente dónde están esas brechas, cuánto cuestan y qué opciones tiene la filial para resolverlas.
📊 DATO: Según nuestra experiencia con filiales de empresas extranjeras en Perú, el 91% de las que intentaron operar con el ERP de la casa matriz sin adaptaciones locales tuvo que complementarlo con sistemas paralelos para cumplir con SUNAT. El resultado más frecuente es una filial que opera con dos o tres sistemas simultáneos que no se hablan entre sí, generando doble ingreso de datos, diferencias de conciliación permanentes y un costo operativo significativamente mayor al que hubiera tenido con una arquitectura de sistemas correctamente diseñada desde el inicio.
Por qué los ERPs globales no cubren la normativa peruana de forma nativa
Los grandes ERPs globales, SAP, Oracle, Microsoft Dynamics, Odoo en su versión internacional, fueron diseñados para cubrir la normativa de los mercados donde tienen mayor penetración: Europa Occidental, Estados Unidos y los mercados de mayor escala en Asia. La normativa tributaria peruana, con sus particularidades específicas, no está cubierta de forma nativa en la mayoría de esos sistemas.
Las razones no son de calidad del sistema sino de lógica de mercado. El mercado peruano no justifica que SAP o Microsoft inviertan en desarrollar módulos nativos para cada uno de los requisitos específicos de SUNAT. Esos módulos existen en algunos casos como desarrollos de terceros, y en otros simplemente no existen y la empresa debe desarrollarlos a medida.
El problema es que cuando una filial peruana descubre esa brecha, ya está operando. La presión de seguir funcionando hace que la solución inmediata sea agregar un sistema local en paralelo, lo que crea la arquitectura fragmentada que genera los mayores problemas operativos.
Las cinco brechas más frecuentes entre el sistema global y la normativa peruana
Brecha 1: La facturación electrónica según estándares de SUNAT
Esta es la brecha más crítica y la primera que toda filial descubre. SUNAT tiene estándares específicos para la emisión de comprobantes electrónicos: el formato XML UBL 2.1, el proceso de validación a través de OSE o PSE autorizado, los campos obligatorios que deben incluirse en cada tipo de comprobante y los plazos de envío al sistema de SUNAT.
Esos estándares no coinciden con los formatos de facturación de los ERPs globales, que tienen sus propios formatos de comprobante diseñados para la normativa de otros países. Un SAP configurado para España emite facturas en el formato de la Agencia Tributaria española. Un Oracle configurado para Colombia emite comprobantes en el formato de la DIAN colombiana. Ninguno de esos formatos es compatible con los estándares de SUNAT sin una capa de adaptación.
La solución que más filiales implementan cuando descubren esa brecha es instalar un sistema de facturación electrónica local en paralelo al ERP global. El ERP registra la venta en su sistema. El área de facturación vuelve a ingresar los datos en el sistema local para emitir el comprobante en el formato de SUNAT. Ese doble ingreso de datos toma tiempo, genera errores y produce diferencias entre el registro del ERP y los comprobantes emitidos en el sistema local.
La solución correcta es una integración entre el ERP global y el sistema de facturación electrónica local, de forma que cuando el ERP registra una venta, la factura se genera automáticamente en el sistema local en el formato correcto de SUNAT. Esa integración requiere desarrollo técnico, pero es significativamente más eficiente que el proceso paralelo.
💡 EL INDICADOR QUE REVELA QUE LA BRECHA DE FACTURACIÓN ESTÁ ACTIVA: Si el equipo de facturación de la filial ingresa los datos de cada venta en dos sistemas distintos, el ERP global y el sistema de facturación electrónica local, la filial está pagando por ese proceso dos veces: en tiempo de personal y en riesgo de errores por diferencias entre ambos registros. Una integración correcta entre ambos sistemas tarda entre cuatro y ocho semanas en implementarse y se paga con la reducción del tiempo de facturación en los primeros dos meses.
Brecha 2: El sistema de detracciones y retenciones del IGV
El sistema de detracciones, SPOT, es una de las particularidades del sistema tributario peruano que más sorprende a las empresas extranjeras y que ningún ERP global maneja de forma nativa.
Cuando una empresa peruana emite una factura por servicios o bienes sujetos al sistema de detracciones, el cliente está obligado a depositar un porcentaje de esa factura, entre el 4% y el 15% dependiendo del tipo de operación, en una cuenta especial del proveedor en el Banco de la Nación antes de efectuar el pago. Ese depósito no es un descuento ni una retención del impuesto: es un mecanismo de recaudación anticipada que el proveedor usa exclusivamente para pagar obligaciones tributarias.
Un ERP global no tiene un módulo que maneje ese flujo. No puede calcular automáticamente el monto sujeto a detracción. No puede generar el constancia de depósito. No puede conciliar los depósitos de detracciones con las facturas correspondientes. Y no puede controlar el saldo disponible en la cuenta de detracciones para el pago de obligaciones tributarias.
El resultado es que esa gestión se hace completamente fuera del ERP, en hojas de Excel o en procesos manuales, sin integración con el sistema principal. Cuando hay discrepancias entre las detracciones que los clientes depositaron y las que el área de cobranza registró, la conciliación es un proceso manual que puede tomar días.
Brecha 3: Los libros electrónicos en formato SUNAT
Los libros electrónicos que requiere SUNAT, el Registro de Ventas, el Registro de Compras, el Libro Diario, el Libro Mayor, tienen un formato específico definido por SUNAT en sus resoluciones de superintendencia. Ese formato requiere campos específicos, codificaciones específicas según el Plan Contable General Empresarial, y una estructura de archivo que el Programa de Libros Electrónicos, PLE, valida antes de generar la constancia de aceptación.
Un ERP global que usa un plan de cuentas internacional, con la codificación de cuentas del país de origen de la casa matriz, no puede generar esos archivos directamente en el formato correcto. La información contable está en el sistema, pero en una estructura diferente a la que SUNAT espera.
La solución que más filiales implementan es exportar la información del ERP global a Excel y luego reformatearla manualmente para que coincida con los campos que requiere el PLE. Ese proceso manual, que se repite todos los meses, toma entre cuatro y doce horas dependiendo del volumen de transacciones, y genera riesgo de errores en cada iteración.
⚠️ EL RIESGO ACUMULADO QUE NADIE VISUALIZA HASTA QUE ES TARDE: Cada mes que los libros electrónicos se generan de forma manual a partir de una exportación del ERP global reformateada en Excel, hay un riesgo de que el formato no sea exactamente correcto, que algún campo no coincida con los estándares de SUNAT, o que haya diferencias entre lo que el ERP registra y lo que termina en el libro electrónico por errores en el proceso de reformateo. Esas diferencias, si SUNAT las detecta en una fiscalización, generan observaciones que la empresa debe responder y justificar. Sin la trazabilidad de cada paso del proceso manual, esa justificación es difícil de construir.
Brecha 4: Los reportes de consolidación que la casa matriz necesita
Esta brecha opera en dirección inversa a las anteriores. Las brechas anteriores son problemas de la filial para cumplir con la normativa peruana usando el sistema de la casa matriz. Esta es un problema de la casa matriz para obtener información de la filial en el formato que necesita para sus estados consolidados.
La casa matriz necesita que los estados financieros de la filial peruana estén en su moneda funcional, que los ingresos y gastos estén clasificados según su plan de cuentas corporativo, que las diferencias de tipo de cambio estén calculadas según sus políticas de consolidación, y que el período de reporte coincida con su cierre fiscal, que puede ser diferente al año fiscal peruano.
Cuando la filial lleva su contabilidad en el PCGE con el plan de cuentas peruano, generar esos reportes de consolidación requiere un proceso de conversión mensual que típicamente se hace en Excel, con todos los riesgos de error, inconsistencia y tiempo de preparación que eso implica.
Brecha 5: El tipo de cambio y las diferencias de moneda
Muchas filiales peruanas tienen transacciones en dólares y en soles simultáneamente. Compran en dólares a proveedores del exterior, facturan en soles a clientes locales, y tienen algunos contratos mixtos con componentes en ambas monedas.
Los ERPs globales manejan múltiples monedas, pero no siempre con los criterios que la normativa peruana exige. El tipo de cambio que SUNAT acepta para convertir operaciones en moneda extranjera es el tipo de cambio publicado por la SBS al cierre de cada día. Ese tipo de cambio específico tiene que registrarse correctamente en el sistema para que las declaraciones de IGV y las diferencias de cambio en el Impuesto a la Renta sean correctas.
Un ERP configurado para el mercado de origen de la casa matriz puede usar el tipo de cambio del banco central de ese país, o el tipo de cambio de mercado de otra fuente, generando diferencias que SUNAT puede cuestionar en una fiscalización.
Las tres arquitecturas de sistemas más frecuentes en filiales peruanas
Después de identificar las brechas, la pregunta es qué arquitectura de sistemas implementar para resolverlas. Hay tres opciones con distintos niveles de complejidad, costo y eficiencia.
Arquitectura 1: ERP global con módulos locales integrados. La filial mantiene el ERP global como sistema central, y se desarrollan o compran módulos de adaptación local para cada brecha identificada. Un módulo de facturación electrónica que cumple los estándares de SUNAT y se integra con el ERP. Un módulo de detracciones que calcula y registra automáticamente los depósitos. Un generador de libros electrónicos en formato PCGE que extrae la información del ERP y la reformatea automáticamente.
Esta arquitectura es la más costosa en implementación porque requiere desarrollo técnico específico, pero es la más eficiente en operación porque mantiene un solo sistema central con toda la información integrada.
Arquitectura 2: Sistema local para cumplimiento peruano con sincronización periódica al ERP global. La filial implementa un sistema contable local, adaptado a la normativa peruana, para toda la gestión contable y tributaria local. Ese sistema genera los libros electrónicos, los PDTs, las conciliaciones con SUNAT y los reportes de detracciones. Periódicamente, ya sea mensual o trimestralmente, la información de ese sistema local se sincroniza con el ERP global en el formato de consolidación que la casa matriz necesita.
Esta arquitectura es más económica en implementación porque no requiere adaptar el ERP global, pero genera una separación entre la contabilidad local y el sistema corporativo que requiere un proceso de sincronización bien diseñado para evitar diferencias.
Arquitectura 3: Sistema integrado local que cubre ambas necesidades. La filial implementa un sistema contable local, preferiblemente una solución peruana que ya tiene los módulos de SUNAT nativos, y lo configura para generar también los reportes en el formato de consolidación de la casa matriz. En este caso, el ERP global de la casa matriz no se usa en la filial, y la información de Perú llega a la casa matriz a través de los reportes de consolidación.
Esta es la arquitectura más simple de implementar y mantener, pero requiere que la casa matriz acepte no tener acceso directo al ERP global para ver la información de la filial peruana en tiempo real.
Cómo elegir la arquitectura correcta
La elección entre las tres arquitecturas depende de cuatro factores que deben evaluarse para cada caso específico.
El nivel de integración que la casa matriz requiere. Si la casa matriz necesita ver la información de la filial peruana en tiempo real en su ERP global, la primera arquitectura es la más adecuada. Si puede aceptar reportes mensuales de consolidación, la segunda o la tercera son más eficientes.
El presupuesto de implementación disponible. La primera arquitectura es la más costosa. La tercera es la más económica. La segunda está en el punto medio. El costo de implementación debe evaluarse contra el costo operativo de la arquitectura durante los próximos tres a cinco años, no solo contra el costo inicial.
La complejidad de las operaciones de la filial. Una filial con operaciones simples, pocas transacciones y un único tipo de comprobante puede operar eficientemente con la tercera arquitectura. Una filial con alto volumen de transacciones, múltiples tipos de comprobantes y operaciones en varias monedas necesita la primera arquitectura para operar sin ineficiencia.
El plazo de implementación disponible. Si la filial ya está operando con una arquitectura deficiente y necesita resolver el problema rápidamente, la tercera arquitectura es la más rápida de implementar. Si hay tiempo para hacer la implementación correctamente, la primera arquitectura genera el mayor valor a largo plazo.
📖 CASO: Una empresa de consultoría de recursos humanos con sede en Colombia que abrió una filial en Lima usó durante 14 meses el ERP corporativo para su contabilidad y un sistema de facturación electrónica local en paralelo. El proceso de doble ingreso de datos consumía aproximadamente 18 horas mensuales de trabajo del equipo de administración. Las diferencias de conciliación entre ambos sistemas promediaban S/ 12,400 mensuales y tomaban entre cuatro y seis horas adicionales para resolver. Los libros electrónicos se generaban manualmente desde Excel, tomando ocho horas mensuales adicionales. El total de horas dedicadas a gestionar la brecha entre el sistema global y los requisitos locales era de aproximadamente 30 horas mensuales, con un costo de S/ 4,200 en tiempo de personal. Al implementar la segunda arquitectura, con un sistema contable local adaptado al PCGE y una sincronización mensual automática al ERP colombiano, ese proceso se redujo a cuatro horas mensuales para la supervisión y validación. El costo de implementación fue de S/ 18,400. El retorno sobre esa inversión, calculado solo por la reducción de horas de personal, fue de 4.4 meses.
El momento correcto para resolver el problema
El momento correcto es antes de que el problema sea urgente. Una filial que todavía está en proceso de constitución puede diseñar su arquitectura de sistemas desde el inicio, sin la presión de tener que seguir operando con una arquitectura deficiente mientras implementa la solución.
Una filial que ya está operando con una arquitectura fragmentada puede implementar la solución en paralelo a la operación, en un proceso que típicamente toma entre seis y doce semanas dependiendo de la complejidad, y que puede hacerse sin interrumpir la operación si se planifica correctamente.
Lo que no tiene sentido es continuar operando con una arquitectura que genera ineficiencia, riesgo tributario y costo de personal todos los meses, esperando el momento correcto que no llega solo.
📞 En Adriazola Consulting acompañamos a filiales de empresas extranjeras en Perú en el diagnóstico de su arquitectura de sistemas actual, la identificación de las brechas con la normativa peruana y el diseño e implementación de la solución correcta para su modelo de negocio y nivel de integración requerido con la casa matriz. El diagnóstico inicial es una reunión de 40 minutos sin compromiso. Agenda hoy.
⚠️ Nota: Este artículo tiene fines informativos y de orientación empresarial. Las opciones técnicas y costos mencionados corresponden al mercado peruano a la fecha de publicación y pueden variar según el proveedor y el alcance específico de cada proyecto. Para una evaluación personalizada, consulte con un especialista.
