10 razones para cambiarse, explicadas al detalle.

Expandimos cada razón con la decisión de diseño concreta: la tabla, el principal SQL, el estado de la máquina, el permiso, el componente de Hangfire. Si usted viene de otro ERP y quiere saber si esto es marketing o arquitectura real, aquí tiene el detalle para evaluarlo. Las páginas de Plataforma y Producto desarrollan cada dominio en profundidad.

1. 01 Diseñado para LATAM, no traducido

   ITBMS panameño, retenciones al proveedor y reporte DGI son parte del núcleo del motor contable, no un módulo opcional de localización. El cálculo corre al postear la factura, con la tasa y la categoría del producto resueltas en el mismo commit que crea las líneas de impuesto. Los reportes 05, 06, 07 se generan desde las mismas tablas — no hay sincronización nocturna ni exportación intermedia. México, Colombia y Costa Rica siguen el mismo patrón: el país es un dominio de primera clase, no un pack instalable.
2. 02 Aislamiento físico por tenant

   Cada cliente vive en su propia base de datos SQL Server, agrupada en elastic pools de Azure. No hay TenantId compartido ni filtro de fila: la consulta física a otra compañía es imposible. Eso significa respaldo y restauración punto-en-tiempo por tenant, residencia de datos predecible para regulaciones nacionales, y offboarding limpio — exportar una base y desprovisionarla es la operación natural, no una migración forzada.
3. 03 Multi-moneda con preservación de origen

   Toda línea de asiento guarda <code>OriginalCurrency</code> y <code>OriginalAmount</code> junto al valor en la moneda base del tenant. El reporte en dólares es una vista de conversión — la verdad siempre es la moneda en la que ocurrió la transacción. FOREX se actualiza a medianoche UTC vía Hangfire, y la varianza FX se configura como ganancia/pérdida realizada o como cargo bancario unificado, por tenant. Sin "redondeo misterioso" al cambiar la vista.
4. 04 Comisiones avanzadas listas

   Motor de reglas versionado con modo preview: cambie la regla, córrala contra el período pasado en simulación y vea exactamente quién gana más, quién gana menos, cuánto cuesta el cambio. Cuotas multi-tier con aceleradores y deceleradores graduales, splits de territorio priorizados, clawback automático en notas de crédito. El dominio existe completo en la plataforma — no es un reporte de BI ni una hoja de cálculo pegada al ERP.
5. 05 Costo aterrizado con 5 métodos

   Asignación por valor, peso, volumen, cantidad o una función custom — elegida por recepción, no hardcoded globalmente. Soporta multi-recepción (una compra que llega en tres contenedores separados) con resolución de varianza real entre PO, recepción y factura del forwarder. El costo final aterriza en la valoración del inventario y en el COGS del próximo posting, con trazabilidad por línea. No más "costo promedio ponderado cerrando el año".
6. 06 Multi-entidad real

   Jerarquía de grupos con configuración en cascada: el holding define la política, la subsidiaria la hereda y la puede sobrescribir explícitamente donde el contexto local lo exige. v1 incluye asiento espejo intercompany con conciliación automática de cuentas espejo; v1.5 añade eliminación de consolidación. El cierre de período puede ejecutarse por entidad individual o por el grupo completo, con el estado de cada entidad visible desde el dashboard del CFO.
7. 07 Cierre de período como máquina de estados

   Seis estados formales: <code>Open</code>, <code>SoftClose</code>, <code>HardClose</code>, <code>Locked</code>, <code>AuditHold</code>, <code>Reopened</code>. Cada transición requiere el permiso asociado y emite un evento de auditoría inmutable. El año fiscal se maneja como un contenedor de 12 períodos con reglas de carryover y entrada de ajuste post-cierre explícita. Una vez que un período entra en <code>HardClose</code>, las cuentas de resultado no aceptan un posting más — el control está en la base de datos, no en el UI.
8. 08 SOC 2 desde el día uno

   Dual audit trail: eventos de aplicación en <code>AuditEvents</code> más log de SQL a nivel de base de datos. El principal <code>app_rw</code> no tiene <code>UPDATE</code> ni <code>DELETE</code> sobre la tabla de eventos — el propio esquema rechaza la manipulación. Los secretos viven en Azure Key Vault con rotación automatizada, y cada principal SQL (<code>audit_admin</code>, <code>readonly_investigator</code>) tiene scope mínimo auditable. SOC 2 Type I está en progreso con auditor independiente.
9. 09 API-first con OpenAPI público

   El contrato está publicado en <code>/swagger</code> y versionado con el release: auto-save por documento, control de concurrencia con <code>RowVersion</code>, webhooks con retry exponencial y firma HMAC. Nada que suplicar a un account executive — el integrador baja el spec, genera el cliente y conecta. Los mismos endpoints que usa el front-end Blazor están disponibles para su ERP de campo, su portal de socios o su automatización interna.
10. 10 Integra con P4 Warehouse

    cifraHQ Enterprise traza una frontera explícita: el maestro de producto, el inventario valorizado y el costo aterrizado viven en el ERP; la operación física de bodega — recepción con scanner, pick-pack-ship, ciclo de conteo — vive en P4 Warehouse. Los dos sistemas se sincronizan por eventos bien definidos. No le encierra en un WMS mediocre empotrado ni le deja huérfano cuando el volumen operativo crece; el contrato de integración está documentado y es la misma API pública que usa cualquier otro integrador.