Skip to main content
DualEntry’s multi-entity module lets you manage multiple legal entities within a single tenant, record intercompany transactions, automate eliminations, and produce consolidated financial statements.

Defining the entity hierarchy

You manage your entity structure from the Company menu in the left navigation (the company icon at the bottom of the left nav) → Companies. Each entity (company) has a name, functional currency, a fiscal year-end month, its own chart of accounts or a shared one, and its own approval workflows. You define parent-child relationships between entities by assigning a parent company. DualEntry allows only one top-level company (without a parent) per organization. Each company also has a numeric company ID that integrations, the API, and imports use to identify it; see How to Find Your Company ID. The API exposes entities at /public/v2/companies/, where you can list, filter, and retrieve entity details programmatically.
Each entity operates as a self-contained set of books. Entity scoping restricts which companies a user can reach, not what they can do there: roles are organization-wide, so a user’s permission level is the same in every company they can access.

Changing a subsidiary’s parent

You can reassign a subsidiary’s parent only if both conditions hold: the subsidiary has no non-elimination children of its own, and no transactions have been posted to it. Open the company record and choose a new parent. DualEntry updates the hierarchy immediately, so any report you run afterward groups the subsidiary under its new parent. Reparenting is blocked as soon as either condition fails:
  • The subsidiary has children. A company with any non-elimination child companies can’t be moved under a different parent, regardless of whether it has posted transactions.
  • The subsidiary has posted transactions. This preserves the integrity of historical consolidated financials, elimination entries, and intercompany balances that were computed against the original hierarchy.
If you need a different hierarchy once either restriction applies, the supported workaround is:
  1. Create a new subsidiary under the target parent.
  2. Redirect new activity (integrations, recurring transactions, users) to the new subsidiary.
  3. Inactivate the original subsidiary.
Posted history stays with the original subsidiary. Transactions do not migrate to the new one. Consolidated reports for periods before the switch continue to reflect the original hierarchy; reports for periods after the switch reflect the new one. If you need historical balances re-presented under the new parent, that is a manual rebooking exercise, typically handled through opening balance journal entries in the new subsidiary. There’s no supported way to introduce a new top-level parent above your organization’s existing root company. DualEntry allows only one root company, and reparenting is blocked for any company that has non-elimination children. The existing root almost always has children by the time you’d want to restructure above it, so the only path that can establish a different root is the bulk company-structure setup tool. That tool is used exclusively from the onboarding flow and is not available to users with restricted company access.

Intercompany transactions

You record transactions between entities using intercompany journal entries (IJEs). An IJE has two or more companies, each with its own block of lines, and you can add more than two when a transaction touches more than one counterparty. Each company’s own lines must balance on their own, debit total equal to credit total within that block, which in turn means the entry balances in aggregate across every company involved too. To carry the intercompany side of the transaction, add a line in each company’s block to the IC Accounts Receivable or IC Accounts Payable system account, whichever matches that company’s side of the relationship. An IC Accounts Receivable line requires a Customer; an IC Accounts Payable line requires a Vendor. For example, when a parent company charges a management fee to a subsidiary: the parent’s block gets a credit to a revenue account plus a debit to IC Accounts Receivable, choosing the subsidiary’s intercompany customer; the subsidiary’s block gets a debit to an expense account plus a credit to IC Accounts Payable, choosing the parent’s intercompany vendor. IJEs have their own approval workflow, configured separately from single-entity journal entries. This gives you control over who can initiate and approve cross-entity entries.

Cross-company (intercompany) billing

Beyond intercompany journal entries, invoices and bills can carry line items assigned to a different company than the document header. When a line’s company differs from the header company, DualEntry treats it as a cross-company (intercompany) line. On posting, DualEntry automatically generates the matching entries on the counterparty entity, including intercompany receivable and payable balances (Due To / Due From) and the corresponding elimination transactions. Every generated entry links back to the source record. This lets a shared-services or parent entity bill costs or revenue to another entity directly from a single invoice or bill, without hand-keying both sides. Payments follow the same model: cross-company vendor and customer payments post the intercompany accounting automatically, including any foreign-exchange gain or loss, which books to the entity that holds the original invoice or bill. The counterparty amounts post as intercompany AR/AP and elimination entries rather than as a separate standalone document; the source invoice or bill keeps its own document and PDF.

Configuring eliminations

Intercompany balances have to be eliminated so they do not inflate consolidated figures. DualEntry does this with a dedicated elimination company rather than with rules evaluated at report time. DualEntry creates the elimination company for you: the moment you add a parent’s first subsidiary, it automatically creates a paired elimination company beneath that same parent, named “Elimination company for [Parent].” There is no setting to designate one yourself. It sits beneath the parent alongside that parent’s trading subsidiaries and exists only to carry the offsetting entries. An elimination company cannot hold default AR or AP accounts, since it is not a trading entity. DualEntry blocks deactivating it while its parent still has active non-elimination children, and removes it automatically once the last one is removed or reparented. This prevents you from removing the offsets while the balances they cancel are still live. Elimination entries are posted when the intercompany transaction is recorded, not generated at consolidation time. An intercompany journal entry or a billable expense billed across companies writes its elimination entry then and there, so a consolidated report is already net of eliminations because they are ordinary posted entries in the ledger. Each line on an intercompany transaction carries its own Elimination toggle, which controls whether that line’s amount counts toward the elimination company’s offsetting entry. It defaults on for every account type except Bank and Credit Card, which default off, since real cash movements between entities aren’t automatically netted out of consolidated cash balances. The practical consequence is that eliminations are auditable the same way any entry is: you can open them, see what produced them, and reconcile them. It also means a missing elimination is a posting problem to trace at the source transaction, not a rule to correct in a settings screen. This describes eliminations for transactions recorded in DualEntry. If you migrated from another system, DualEntry does not regenerate historical intercompany eliminations: they carry over exactly as the source system recorded them. See migration data scope for how migrated eliminations are handled.

Removing an entity from consolidation

When a subsidiary is dissolved, divested, or no longer managed, deactivate the company rather than deleting it. An inactive company is excluded from consolidated reporting, while all of its historical transactions, balances, and audit trail are preserved and remain drillable for prior periods. Deleting a company is only possible when no posted records reference it, so deactivation is the standard treatment once an entity has transaction history. Before deactivating, post the entity’s final closing or transfer entries for its last period. Eliminations post automatically along with those entries, so there’s no separate step to run.

Consolidated reporting

You run any standard financial statement across multiple companies by selecting them in the report’s company filter. Selecting a parent surfaces an Include children action that adds every one of its subsidiaries to the selection for you, so you don’t have to check each one by hand. You can also select any subset of the hierarchy, consolidating a regional parent with its own subsidiaries, for example, without pulling in the rest of the organization. There is no separate consolidation step to run: a report reflects consolidated figures as soon as the relevant companies, elimination company included, are part of the selection, the same as it would for any other set of companies. DualEntry doesn’t show a per-entity breakdown by default. To see each company’s contribution next to the elimination entries, use Pivot to add Company as a row or column dimension. To walk through running a single-entity report versus a consolidated one and see an elimination change the numbers, see Your First Consolidated Report.

Currency translation for consolidation

When child entities have different functional currencies than the parent, DualEntry translates their financials to a common reporting currency automatically, using one fixed method: income statement accounts translate at the average rate for the period, equity and investment accounts translate at their historical rate, and every other balance sheet account translates at the period-end rate. There’s no per-entity setting to choose a different translation method. The cumulative translation adjustment (CTA) posts to a dedicated equity account, and appears as its own line on the balance sheet whenever companies with different functional currencies are combined in a report. For details on configuring exchange rates and rate types, see multi-currency setup. For currency-specific report formatting, see multi-currency reporting.
Ensure each child entity’s period is closed before running consolidation. Consolidating with open periods may produce incomplete results.
Last modified on October 10, 2026