# Intercompany Elimination Intercompany Elimination is the month-end process that strips internal trading out of consolidated financial reports in multi-company groups. When companies inside the same group sell to each other, those internal transactions inflate revenue, expenses, receivables and payables on the consolidated view. NexWave's Intercompany Elimination doctype creates three Journal Entries inside a dedicated **elimination company** that net out the internal positions for the period. This page is the conceptual reference. For the step-by-step monthly walkthrough, see [Run a monthly intercompany elimination](/doc/041b834b-0bf5-4ead-b662-da57180b609f). :::info Looking for the step-by-step walkthrough? See [Run a monthly intercompany elimination](/doc/041b834b-0bf5-4ead-b662-da57180b609f). ::: ## Key concepts ### Group structure (recommended, not enforced) The standard pattern is a parent group company with operating children and one dedicated elimination company: ``` Parent Group (Is Group) ├── Operating Company A ├── Operating Company B └── Elimination Company ``` Creating a child company under a parent group clones the parent's chart of accounts into the child, so account names and numbers line up across siblings. That CoA inheritance is what makes the elimination matching logic work out of the box. The Intercompany Elimination engine itself does NOT enforce this group structure. The validation only checks that source company and elimination company are different and that the elimination company has the **Is Elimination Company** flag set. A standalone source company can elect any flagged elimination company. The reason groups are recommended is that the consolidated financial reports (Balance Sheet, P&L, Trial Balance with consolidated=1) only net out the elimination JEs against the operating companies' books when both sit under the same group. ### Elimination company A dedicated entity used solely for consolidation entries. The custom field **Is Elimination Company** on Company makes the company eligible to receive elimination JEs, and the custom field **Intercompany Elimination Account** designates the CTA (Cumulative Translation Adjustment) account used to balance the BS journal and the P&L journal's tax lines. The system does not enforce that this company is non-operating. By convention you should never post operational transactions to it, otherwise its standalone reports become unreadable. ### Balance sheet elimination For each account in the source company with **Include in Elimination** ticked, NexWave computes the **period movement** (closing balance at To Date minus opening balance at From Date) using the account's own currency, then proposes the negative of that movement as the elimination amount. The `Include in Elimination` flag is restricted at field level to Asset, Liability and Equity accounts. Income and Expense accounts cannot be flagged: P&L elimination is driven by the Internal Customer flag on the customer side instead. For accounts of type **Receivable** or **Payable**, NexWave breaks the movement down by party. Each (account, party) pair becomes its own row in the BS Elimination Details table, with **Party Type** and **Party** populated. The corresponding lines on the BS Elimination JE also carry that party info (required for posting to a sub-ledger account). For non-party BS accounts (intercompany loans, intercompany equity, etc.), one row per account. ### Profit & loss elimination NexWave finds every voucher posted in the period to a customer with **Is Internal Customer** ticked, then sums the GL entries on those vouchers grouped by account. Accounts whose **Root Type** is *Income* and whose **Account Type** is one of *Income Account*, *Direct Income* or *Indirect Income* become rows in the P&L Eliminations table, with the negative of net amount as the elimination figure. For Sales Invoices specifically, the engine also picks up every account on the invoice's **Sales Taxes and Charges** table, sums their GL entries within the period scoped to those Sales Invoices, and adds them as additional rows with the **Tax** column ticked. This means GST output tax on internal sales is also reversed on consolidation. > **Important:** the Internal Customer match is global. The engine selects every customer where **Is Internal Customer** is ticked, without scoping to the source company's siblings or checking the **Represents Company** value. If a customer is mistakenly flagged Internal, their sales are eliminated as if they were intercompany. Audit your Internal Customer set periodically. ### Generated journal entries On submit, three Journal Entries are created in the elimination company. All three carry **Entry Type** = *Intercompany Elimination Entry* so they are easy to filter in any GL report. | Journal | Posting Date | What it posts | |---------|--------------|---------------| | **BS Elimination** | **To Date** | One line per BS detail row in the elimination company's matching account, debit/credit reversed; the **CTA account** absorbs any net debit-credit difference | | **BS Reversal** | The day after **To Date** | The BS Elimination JE with debit and credit swapped on every line, so the next period's opening balance is restored | | **P&L Elimination** | **To Date** | One line per P&L detail row in the elimination company's matching account, debit/credit reversed; the **Intercompany COGS Account** absorbs the income side, and the **CTA account** absorbs the tax-line side | The BS Reversal date is the calendar day after **To Date**, *not* the first day of the next month. For a normal month-end run those line up. For a custom mid-period range they don't: an elimination for 1–15 March produces a reversal posted on 16 March. The BS pair zeroes out across two days; the P&L journal stands. P&L accounts roll into Retained Earnings at year-end through the Period Closing Voucher anyway, so the one-shot P&L elimination doesn't need a reversal. BS accounts persist across periods, so eliminating a movement without reversing it would corrupt the next period's opening balance. ### Cumulative Translation Adjustment (CTA) The **Intercompany Elimination Account** on the elimination company is the CTA sink. It does two jobs: * In the **BS Elimination JE**, it posts the difference between total debits and total credits on the marked-account lines, so the journal balances. In single-line cases (one BS account), it carries the full counter-balance. In multi-line FX cases, it absorbs translation rounding. * In the **P&L Elimination JE**, it balances the sum of tax-line reversals (the Intercompany COGS Account balances the income-line reversals). If the CTA balance accumulates over time (typically from intercompany GST suspense), it is normally cleared annually via a manual Journal Entry. ### Internal customer setup On the source company, each related-company customer needs **Is Internal Customer** ticked and **Represents Company** pointing to the related company. Optionally, the customer's **Accounts** override can map a dedicated intercompany receivable account on the source company; otherwise the standard Debtors account is used and the entire Debtors movement gets eliminated, which is rarely what you want. ### Naming and lifecycle * Documents are named *ICE-YYYY-NNNNN* (where YYYY is the calendar year of creation). * **Status** moves *Draft* → *Calculated* → *Submitted* → *Cancelled*. * Drafts do not enforce; only submitted documents post Journal Entries. * The overlap validation prevents two non-cancelled documents with overlapping date ranges for the same source company. * Cancelling a submitted Intercompany Elimination automatically cancels all three linked Journal Entries. * Amending creates a fresh draft pre-filled from the cancelled doc but with empty detail tables and Journal Entry links: re-run **Calculate Eliminations** and submit to create three new Journal Entries. ## Calculation engine When a user clicks **Calculate Eliminations**, the engine runs both calculations in sequence and writes results to the **Balance Sheet Eliminations** and **P&L Eliminations** child tables on the form. On save, NexWave also runs date validation, source-vs-elimination company validation, and the no-overlapping-periods check. ### BS calculation For each account in the source company where **Include in Elimination** is ticked, **Root Type** is one of *Asset*, *Liability* or *Equity*, and **Is Group** is unticked: * If **Account Type** is *Receivable* or *Payable*, NexWave finds every distinct (Party Type, Party) combination on the account's GL entries within the period (excluding cancelled entries), then computes the period movement for each party. Rows with zero movement are skipped. * Otherwise, the period movement is computed once for the account, with no party filter. Rows with zero movement are skipped. The period movement is the net of debits and credits on GL entries with **Posting Date** between **From Date** and **To Date**, expressed in the account's own currency. ### P&L calculation 1. Find every customer with **Is Internal Customer** ticked (system-wide, not scoped to source company). 2. Find every voucher (by Voucher Type and Voucher No on the GL Entry list) where **Party Type** is *Customer*, the party is one of those internal customers, **Posting Date** is in the period, **Company** is the source company, and the entry is not cancelled. 3. For those vouchers, sum debit and credit per account from GL Entry. Keep only accounts where **Root Type** is *Income* and **Account Type** is *Income Account*, *Direct Income* or *Indirect Income*. The net (credit minus debit) becomes the **Original Amount**; its negative becomes the **Elimination Amount**. 4. For Sales Invoices specifically, also find every entry on the **Sales Taxes and Charges** table (the **Account Head** column), sum their GL entries within the period scoped to those Sales Invoices, and add them as additional rows in the **P&L Eliminations** table with the **Tax** column ticked. ### Account matching When generating any of the three Journal Entries, the engine maps each source-company account to its match in the elimination company: * If the source account has an **Account Number**, match by **Account Number + Account Name + Company**, with **Is Group** unticked on the elimination-company account. * Otherwise, match by **Account Name + Root Type + Company**, again with **Is Group** unticked. If no match is found, NexWave aborts with a hard error pointing at the missing account. There is no soft-fallback or "ignore missing" option. ### Multi-currency behaviour The engine works in each account's own currency throughout. The Journal Entry lines populate the **Debit** and **Credit** columns of the Accounting Entries grid in account currency. This means: * Account currencies must match exactly between source and elimination for any account that gets eliminated. A USD source account requires a USD elimination-company account; a Journal Entry submission with mismatched currencies fails. * For groups operating in multiple base currencies (NZD parent, AUD subsidiary, etc.), the practical setup is one elimination company per source-company currency, OR one elimination company carrying a multi-currency CoA replicated for each currency you trade in. * The CTA account also acts as a rounding sink for sub-cent translation differences in the BS journal across multi-currency lines. ### Accounting Dimensions The doctype has Cost Centre, Project, and any custom Accounting Dimensions in the **Accounting Dimensions** section on the parent doc. Whatever values you set there are stamped onto every line of every generated Journal Entry. ### Cancellation flow Cancelling a submitted Intercompany Elimination automatically cancels all three linked Journal Entries (**BS Journal Entry**, **BS Reversal Journal Entry**, **P&L Journal Entry**) in turn. Any Journal Entry that has already been cancelled (for example, manually by a user) is skipped silently. ## Field reference | Field | Description | Required | |-------|-------------|----------| | **Source Company** | The operating company whose internal trading is being eliminated | Yes | | **Elimination Company** | Must have **Is Elimination Company** ticked on the Company record | Yes | | **From Date** | Start of the elimination period | Yes | | **To Date** | End of the elimination period | Yes | | **Intercompany COGS Account** | Expense account (leaf) in the elimination company; balances the income-side P&L elimination | Conditionally (required if any P&L lines are produced) | | **Balance Sheet Eliminations** (table) | One row per (account, party) for Receivable/Payable, one row per account otherwise | Auto-populated | | **P&L Eliminations** (table) | One row per income or tax account from internal Sales Invoices in the period | Auto-populated | | **Accounting Dimensions** | Cost Centre, Project, custom dimensions stamped on every JE line | Optional | | **BS Journal Entry** | Link to the BS Elimination JE | Auto on submit | | **BS Reversal Journal Entry** | Link to the BS Reversal JE | Auto on submit | | **P&L Journal Entry** | Link to the P&L Elimination JE | Auto on submit | | **Status** | *Draft* → *Calculated* → *Submitted* → *Cancelled* | Auto-managed | ## View Source helpers The form exposes two **View Source** helpers for verifying numbers before submit. * **BS Source Ledger** routes to the standard General Ledger report, scoped to the source company, the document's date range, and the list of BS-eliminated accounts. Only accounts that produced non-zero rows in the **Balance Sheet Eliminations** table are included in the report filter. * **P&L Source Ledger** opens an in-form dialog listing the GL entries from internal-customer vouchers in the period, restricted to the income and tax accounts that appear in the **P&L Eliminations** table. ## Troubleshooting ### "Account ... not found in Elimination Company" A source-side account doesn't have a matching account in the elimination company. Create it (matching by **Account Number + Account Name** if numbered, otherwise **Account Name + Root Type**), then re-run **Calculate Eliminations**. ### "Period overlaps with existing Intercompany Elimination ..." A submitted or draft Intercompany Elimination for the same source company already covers part of your selected period. Adjust the dates, or cancel the prior document first. ### "Please calculate eliminations before submitting" You're trying to submit without having clicked **Calculate Eliminations**. NexWave requires at least one of the **Balance Sheet Eliminations** or **P&L Eliminations** tables to be populated before submit. ### Empty tables after Calculate Eliminations Check that: * At least one source-side account has **Include in Elimination** ticked (for BS). * At least one customer has **Is Internal Customer** ticked AND that customer has invoices in the period (for P&L). * All transactions in the period are submitted, not draft (drafts don't post GL entries). ### "Date ... is not in any active Fiscal Year for ..." The fiscal year covering the Journal Entry posting date is not linked to the elimination company. Open the relevant **Fiscal Year** and add the elimination company to its **Companies** table. This commonly bites the BS Reversal because it posts on **To Date** + 1, which can fall in the next fiscal year. ## Related documentation * [Run a monthly intercompany elimination](/doc/041b834b-0bf5-4ead-b662-da57180b609f): step-by-step walkthrough of the month-end process including a worked example. * [Intercompany Journal Entry](/doc/851028fb-d5cd-49cc-b002-acdc855f3094): the source-side trading mechanism that creates the receivables/payables this elimination then nets out. * [Accounting](/doc/85b00666-859d-4e2b-9bac-6c1dd3848464): financial management overview. * [Accounts Payable](/doc/684be9e0-cf69-4927-b3b9-bc01f6392a92): bills and supplier payments, the source of intercompany payables. * [Accounts Receivable](/doc/5fc8e8da-974e-475f-a50d-4964865567be): customer invoicing, the source of intercompany receivables.