Why cifraHQ
10 reasons to switch, explained in detail.
The same ten reasons from the home page, now with the mechanism behind each one. Architecture, not marketing — if a reason cannot be backed by a table name, a SQL principal, or a formal state, it is not on this list.
Each with the underlying mechanism
Each reason is expanded with the concrete design decision: the table, the SQL principal, the state machine, the permission, the Hangfire component. If you are coming from another ERP and want to know whether this is marketing or real architecture, the detail is here. The Platform and Product pages develop each domain in depth.
-
01 Designed for LATAM, not translated
Panama ITBMS, supplier withholdings and DGI reporting sit inside the core accounting engine, not inside an optional localization module. The calculation runs at invoice post time, with rate and product category resolved in the same commit that creates the tax lines. Reports 05, 06 and 07 are generated from the same tables — no nightly sync, no intermediate export. Mexico, Colombia and Costa Rica follow the same pattern: the country is a first-class domain, not an installable pack. -
02 Physical isolation per tenant
Every customer lives in its own SQL Server database, grouped into Azure elastic pools. There is no shared TenantId and no row filter — a physical query against another company is simply impossible. That means per-tenant backup and point-in-time restore, predictable data residency for national regulations, and clean offboarding: exporting a database and deprovisioning it is the natural operation, not a forced migration. -
03 Multi-currency with origin preservation
Every journal line stores <code>OriginalCurrency</code> and <code>OriginalAmount</code> alongside the value in the tenant base currency. The USD report is a conversion view — the truth is always the currency in which the transaction happened. FOREX refreshes at midnight UTC via Hangfire, and FX variance is configured per tenant as realized gain/loss or as a unified bank-fee charge. No "mysterious rounding" when you flip the view. -
04 Advanced commissions out of the box
Versioned rules engine with preview mode: change the rule, run it against the previous period in simulation and see exactly who earns more, who earns less, and what the change costs. Multi-tier quotas with gradual accelerators and decelerators, prioritized territory splits, automatic clawback on credit notes. The domain exists complete on the platform — not as a BI report or a spreadsheet taped to the ERP. -
05 Landed cost with 5 allocation methods
Allocation by value, weight, volume, quantity, or a custom function — chosen per receipt, not hardcoded globally. Supports multi-receipt (one purchase arriving in three separate containers) with real variance resolution across PO, receipt, and forwarder invoice. The final cost lands in inventory valuation and in COGS on the next post, with per-line traceability. No more "weighted average catching up at year-end". -
06 True multi-entity
Group hierarchy with cascading configuration: the holding defines the policy, the subsidiary inherits it, and can explicitly override where local context demands it. v1 includes intercompany mirror postings with automatic mirror-account reconciliation; v1.5 adds consolidation elimination. Period close can run per individual entity or across the whole group, with each entity status visible from the CFO dashboard. -
07 Period close as a state machine
Six formal states: <code>Open</code>, <code>SoftClose</code>, <code>HardClose</code>, <code>Locked</code>, <code>AuditHold</code>, <code>Reopened</code>. Every transition requires the matching permission and emits an immutable audit event. Fiscal year is modeled as a container of 12 periods with explicit carryover rules and post-close adjusting-entry handling. Once a period hits <code>HardClose</code>, income and expense accounts refuse another posting — the enforcement is in the database, not in the UI. -
08 SOC 2 from day one
Dual audit trail: application events in <code>AuditEvents</code> plus SQL-level database logging. The <code>app_rw</code> principal has no <code>UPDATE</code> or <code>DELETE</code> on the event table — the schema itself rejects tampering. Secrets live in Azure Key Vault with automated rotation, and each SQL principal (<code>audit_admin</code>, <code>readonly_investigator</code>) carries minimum auditable scope. SOC 2 Type I is in progress with an independent auditor. -
09 API-first with public OpenAPI
The contract is published at <code>/swagger</code> and versioned with the release: per-document auto-save, concurrency control via <code>RowVersion</code>, webhooks with exponential retry and HMAC signing. Nothing to beg an account executive for — integrators pull the spec, generate the client and connect. The same endpoints the Blazor front-end uses are available for your field ERP, your partner portal or your internal automation. -
10 Integrates with P4 Warehouse
cifraHQ Enterprise draws an explicit boundary: product master, valued inventory and landed cost live in the ERP; the physical warehouse operation — scanner receiving, pick-pack-ship, cycle counting — lives in P4 Warehouse. The two systems synchronize over well-defined events. It neither locks you into a mediocre embedded WMS nor leaves you stranded when operational volume grows; the integration contract is documented and is the same public API any integrator would use.
Bring your current ERP to the table.
A 60-minute technical session. We walk through your real flow — close, commissions, multi-entity — against cifraHQ. No generic slides.