> ## Documentation Index > Fetch the complete documentation index at: https://docs.alforse.com/llms.txt > Use this file to discover all available pages before exploring further. # Intercompany accounting > Match a sale in one company against the purchase in its sibling, then eliminate the pair for consolidated reporting. Intercompany accounting pairs reciprocal transactions between companies in the same group and eliminates them from consolidated reporting. One company records a receivable and the other a payable; elimination removes the duplicated group-level balance. The feature is scoped to a **company group** and appears only when the group has multiple companies. Configure the group and its members before using it; see [Companies](#prerequisite-a-multi-company-group). The screen is under Accounting and is available once accounting is enabled for the company. ## What a transaction is An intercompany transaction records one company's side of a trade with another company in the same group. It points at a posted journal line on that company's declared **intercompany receivable** or **intercompany payable** control account, and its amount must equal that line. A transaction raised on a receivable account is a *Receivable* side; one on a payable account is a *Payable* side. A customer or supplier counts as a sibling when it is linked to another company in the group. Alforse creates those links the moment a company joins the group. Sales and purchase invoices posted to a sibling tag the lines with the sibling as the intercompany partner. Each company raises only **its own side**. The seller records a receivable toward the buyer; the buyer records the mirror payable toward the seller. NOTE **The journal is the source of truth** The transaction does not post anything of its own when it references an existing journal line. It remembers which sibling the line was with, so matching and elimination can find the pair later. ### Recording one by hand You can also create a transaction directly from the accounting **Intercompany** screen with **IC Transaction** (the form is titled **New IC Transaction**). Choose a **Source Company** and a **Target Company**, an **Amount**, a **Description**, a **Debit Account**, a **Credit Account**, and a **Posting Date**. The posting date defaults to today in the source company's time zone, and the currency is the source company's base currency. This posts a balanced journal on the source company, a debit line to one account and a matching credit to the other, tagged with the target as the **intercompany partner**, plus the tracking record. Use it for an adjustment, or for a position no invoice created. The rules, enforced by the server: * The source must be the company you are working in; you cannot raise the other company's side. * The target must be a different company that belongs to the same group. * The amount must be positive, and the debit and credit accounts must differ. * The journal must touch the company's declared intercompany receivable or payable control account, for the same amount. ## The matching lifecycle Every intercompany transaction carries a **status**. It starts life at **"Unmatched"**, is paired to its counterpart by matching, and is retired by elimination.
**Unmatched** The transaction has been created and posted on its source company, but Alforse has not yet found the mirror-image transaction on the other company. This is the default on creation.
**Matched** Matching found the counterpart: a transaction in the reverse direction (its source is this one's target, and vice versa, one a receivable and the other a payable) for the **same currency and amount** in the same group. Both sides flip to Matched together and each records the other's journal line.
**Eliminated** Elimination has posted the reversing journal for the transaction. It stops counting toward the intercompany balance.
These are the only three statuses. ## How a pair gets matched Matching is a manual group-wide operation. Select **Run Matching** on the Intercompany screen. It needs approve access on intercompany control. The rule is deliberately strict. Two **Unmatched** transactions match only when they are true mirror images: company A → B pairs with company B → A, for the **exact same amount and currency** (to five decimals), within the same group. When Alforse finds such a pair it sets both to **"Matched"** in one step and links each to the other's journal line. The result toast tells you how many matched and how many are still unmatched. If a transaction stays **Unmatched** after a run, its mirror does not exist yet. The usual cause is that the sibling company has not posted its invoice yet, or the two invoices are for different amounts. Post or correct the counterpart, then run matching again. NOTE Matching pairs the two sides. It does **not** post anything new or touch either company's ledger. The journals were written when you created each transaction; matching only records that they belong together and advances their status. ## Elimination **Elimination** removes matched balances from consolidated reporting. Select **Generate Eliminations** to process every **Matched** transaction in the group. It needs post access on intercompany control. For each matched transaction, Alforse posts one **elimination journal** in that transaction's own company: the exact negation of the journal lines the transaction references, described as "Eliminate intercompany …". Because it reverses every line of that journal, a multi-line invoice is cleared in full and both control accounts clear to their exact balance. The seller's receivable and the buyer's payable are equal and opposite, so the group nets to zero. A matched transaction with no captured elimination lines is skipped rather than invented. Once the reversing journal is posted, the transaction flips to **"Eliminated"** and records the elimination journal, who eliminated it, and when. The run returns a count of the journals it created. **Regenerate** reverses the eliminations that already exist (with reversing entries, never deletes) and posts them again from the current state, so a correction can flow through without manual surgery. HEADS UP Elimination writes real reversing journal entries. Generate eliminations only when the matched pairs are correct; **Regenerate** is the way to correct an elimination after the fact. ## The intercompany balance The Intercompany screen also shows a **from / to balance matrix** across the group's companies and a running count of how many transactions sit at each status. The balance sums **non-eliminated** transactions only (receivable sides positive, payable sides negative): once a transaction is eliminated it drops out of the matrix. So a clean, fully-consolidated group shows zeros, and any non-zero cell is an intercompany position that hasn't been matched and eliminated yet. ## Prerequisite: a multi-company group Intercompany is only meaningful with a group of companies: * **The company group** ties the members together. The chart of accounts, currencies, and dimensions are shared at the group level, so every company posts against the same accounts. Members and their parent-child hierarchy are managed under company settings. * **Control accounts.** Each company declares its intercompany receivable and payable accounts in accounting defaults; transactions must post to them. When a company joins a group, Alforse automatically creates the reciprocal intercompany customer and supplier records between it and each sibling, so the trading relationships exist as soon as the group does. ## Related **Accounting & the ledger** The journal, accounts, and periods that intercompany transactions post into. [Open](/docs/reference/accounting.md) **Period close** Closing the books, one period at a time. [Open](/docs/reference/period-close.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.