Enfinity ERP treats your group as a company master with named operating units, not separate installations stitched together at month-end. Inter-company transactions, elimination drafts and transfer pricing run against reviewable policy, and consolidated statements come off the same ledger every entity posts to.
A group with two or three legal entities usually ends up with separate ledgers and one exhausted controller stitching them together in a spreadsheet at period end — re-typing balances, guessing which should net to zero, and applying last quarter's exchange rate because nobody wrote down which one was used. Transfer pricing between entities is a verbal understanding, not a policy anyone can point to.
Set up each legal entity as an operating unit under one company master, rather than a separate installation — the group structure is configured once and reused every period.
Transactions between group entities are captured as first-class inter-company documents, with a transfer-pricing policy applied consistently rather than negotiated line by line.
Each entity's foreign-currency balances are revalued under a named revaluation policy at document date, and group-wide FX exposure is reported before it becomes a surprise.
An elimination draft nets out inter-company balances against a named elimination policy, so the same rules apply period after period instead of being reassembled from memory.
Consolidation runs across subsidiary ledgers, and the resulting group journals post through the same shared GL posting service every entity uses — one write path, one group ledger.
Consolidated statements, custom statement layouts and a full inter-company audit trail give a controller a group view they can defend, backed by AI-explained readiness and variance ahead of the close.
Multiple legal entities live under one business as a company master with named operating units, replacing the pattern of standing up a separate installation per entity. Onboarding a new entity into the group is a configuration step, not a re-implementation.
Transactions between group entities are recorded as a first-class document type in their own right, not a memo journal bolted onto the ledger, giving each entity its own clean trail of what it owes or is owed within the group.
Elimination drafts are prepared against a named, reviewable elimination policy rather than reassembled from a spreadsheet convention each period, so the group's consolidation logic is documented and repeatable, not tribal knowledge held by one person.
A transfer-pricing policy applies consistently to transactions between entities, so pricing between group companies follows a documented rule rather than an informal understanding that shifts depending on who is asked.
Consolidation runs across subsidiary ledgers as a dedicated capability, pulling each entity's posted position into one group view rather than asking a controller to copy trial balances into a master file by hand.
Consolidated financial statements and custom statement layouts run through the same statements designer used for a single entity, so a group's reporting format stays consistent whether the reader is looking at one company or the whole structure.
Inter-company records carry a full audit trail, so a group's inter-company balances can be traced back to the originating transaction and the elimination applied to it, not just the net figure that landed in the consolidated statement.
The same report builder, analytics, dashboards, listings and saved views a single company uses extend across the group, so a controller builds one saved view of group receivables or group cash rather than stitching entity-level reports together by hand.
Consolidation and elimination journals post through the same shared GL posting service every sub-ledger uses, and sub-ledger postings from other Enfinity products arrive per entity through the shared posting port, so a group ledger never has a second, undocumented way something can land in it.
Group budget-versus-actual variances are computed deterministically first; the model re-flags which variances are material and explains them in plain language, over figures the controller already trusts.
The variance figures themselves are never computed or rewritten by the model — it only explains numbers a deterministic engine already produced. The feature works with no AI provider configured, falling back to the deterministic figures alone, and every explanation is logged to an advisory ledger with an audit event that a finance controller reviews before relying on it.A cross-module, cross-entity executive summary reads already-computed figures from every connected module and drafts a narrative a group CFO can scan in minutes instead of assembling from separate entity packs.
The summary narrates figures computed elsewhere and never generates or alters a number itself. With no AI provider configured, the module simply omits the narrative and still shows the underlying figures. Every generated summary is logged to an advisory ledger with an audit event, and a finance or executive reviewer reads it before it is shared outside the group.Posted group transactions are scanned for statistical anomalies — an inter-company entry far outside its usual pattern, for example — surfacing candidates for a controller to look at rather than requiring a manual scan of every entity's postings.
Anomaly candidates are flagged, never auto-corrected, reversed or blocked by the model. The feature degrades gracefully with no AI provider configured, and every flagged anomaly is written to an advisory ledger with an audit event for a finance controller to investigate and decide on.Before a group consolidates, each entity can check its own month-end close readiness — outstanding reconciliations, unposted journals, open exceptions — so a consolidation is only ever run against entities that are actually ready.
Readiness is assessed against deterministic checks the model narrates rather than invents; it never marks an entity ready or closes a period on its own. With no AI provider configured the checklist itself still works, just without the narrated summary, and every readiness read is logged to an advisory ledger with an audit event for the controller who ultimately signs off the close.Every AI-assisted feature across the group's consolidation and reporting workspace follows one rule: the deterministic engine runs first, the model explains second, and every advisory is visible in one place rather than scattered across separate screens.
The model never substitutes for the deterministic result and every module built on this base degrades to the deterministic-only outcome with no AI provider configured. Each advisory is logged to a shared advisory ledger with its own audit event, reviewed by the relevant finance or ops role before any figure derived from it is acted on.Each entity trades in its own currency against a shared exchange-rate master, with the applicable rate resolved at document date rather than looked up after the fact from memory or a stale spreadsheet tab.
Foreign-currency balances revalue under a named revaluation policy with the maths kept pure and testable, and group-wide FX exposure reporting shows where the group is actually exposed rather than leaving it to be discovered at consolidation.
Every entity resolves its own VAT profile and e-invoicing obligation from its own country and registration, rather than inheriting the parent company's tax setup. Saudi Arabia, the UAE, Bahrain and Oman are active VAT countries in Enfinity ERP today; Kuwait and Qatar are ready to configure when their VAT regimes take effect — Kuwait has no VAT in force at present.
Entity names, operating unit names and account names carry a second-language field with right-to-left rendering, so a group spanning Arabic- and English-speaking readers works from the same master data rather than a translated copy.
An owner running several entities switches between them from a mobile company switcher, seeing the right entity's numbers on the move. Consolidation itself stays a back-office workspace, not a portal feature.
| Small | Standard | Professional |
|---|---|---|
| One legal entity, with multi-currency transactions but no group consolidation — right-sized for a single company not yet operating as a group. | Up to three legal entities under one company master, with inter-company transactions, transfer pricing and consolidation available across them. | Uncapped legal entities, which is where this module lives most naturally — full elimination-policy consolidation, transfer pricing and group reporting across as many entities as the group operates. |
Payroll postings from HCM arrive per entity through the shared sub-ledger posting port, so a group with staff split across companies still closes payroll into the entity that actually employs them.
When a deal closes under one group entity but the customer relationship spans the group, CRM's own entity context keeps the commercial record aligned with the legal entity the invoice will actually post against.
A group running shared projects across entities relies on the same GL posting path this module uses, so project costs and inter-company recharges land against the correct entity rather than a shared catch-all account.
The platform's company dimension is what lets one login see the right entity's numbers and one group master hold several legal entities without any of them leaking into another's ledger — the foundation this whole module is built on.
A controller who moves between entities signs in once through centralized Identity, with MFA protecting access to consolidated group figures.
An elimination draft or a group consolidation run can be routed through the shared workflow engine for review before it posts, giving a group the same approval discipline it applies to any other high-value transaction.
One entity is included on the Small tier with no consolidation. Standard supports up to three entities under one company master. Professional is uncapped, which is where full multi-entity consolidation is meant to run.
That is the point of it. Inter-company transactions, elimination policy and transfer pricing all live as configuration in the system, so a close runs against documented rules instead of a workbook one person maintains.
Exchange rates resolve at document date from a shared rate master, and foreign-currency balances revalue under a named revaluation policy with the underlying maths kept pure and independently testable.
No. Consolidation, elimination and revaluation are deterministic engines that run with no AI provider configured. AI only adds explanation on top — variance narration, an executive summary, an anomaly flag — and never finalises a consolidation itself.
Yes, through a mobile company switcher that moves an owner between entities and always shows the correct entity's own numbers. Full consolidation reporting stays a back-office capability rather than a portal or mobile feature.
Consolidation and elimination journals post through the same shared GL posting service every sub-ledger in Accounting uses, so the group ledger is a natural extension of each entity's own ledger rather than a parallel system to reconcile against.
Yes. Each entity resolves its own VAT profile and e-invoicing obligation from its own country registration, so a group spanning Saudi Arabia, the UAE and a Kuwait entity with no VAT yet can each be configured correctly rather than inheriting one parent setup.
Yes, Migration Center loads each entity's history from its previous system independently, so bringing a second or third entity into the group does not require re-keying its opening position by hand.
