Intercompany accounting
Match a sale in one company against the purchase in its sibling, then eliminate the pair for consolidated reporting.
When two companies under the same owner trade with each other, each books its own side: one records a receivable, the other a payable. On a consolidated statement those two entries are the same money counted twice. Intercompany accounting is how Carbon pairs them up and cancels them out.
The whole feature is scoped to a , and it only appears once a group has more than one company. If you run a single company, there is nothing here to do. Set up the group and its members first (see Companies); everything below assumes they exist.
What a transaction is
An intercompany transaction records that one company in the group owes or is owed by another. Most are created for you: when you post a sales or purchase invoice whose customer or supplier is a sibling company in the group, Carbon writes the matching intercompany transaction as part of posting the invoice.
A customer or supplier counts as a sibling when it is linked to another company in the group. Carbon creates those links the moment a company joins the group, so a normal invoice between two group members is intercompany without any extra flagging.
- Posting an intercompany sales invoice books the receivable to the group's Inter-Company Receivables control account instead of regular AR, and records a transaction from the seller to the buyer for the invoice's pre-tax total.
- Posting an intercompany purchase invoice books the payable to the Inter-Company Payables control account instead of regular AP, and records the mirror transaction from the buyer to the seller for the invoice's pre-tax total.
Both control accounts come from the group's accounting defaults, so members that have them configured post against the same two accounts. A company that hasn't configured them falls back to its regular receivables or payables account.
The invoice posting is the source of truth
The transaction is a byproduct of posting the invoice, not a separate step. The receivable or payable is already on the ledger the moment the invoice posts. The transaction record just remembers which sibling it 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 New IC Transaction, choosing a source company and a target company (they must be different), an amount, a description, and the two accounts to hit. This posts a balanced on the source company — a debit line to one account and a matching credit to the other, both 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 source and target are picked from the group's active companies, and elimination entities are excluded from that list. You transact between real operating companies. The is where the cancelling entries land later, not a party to the trade.
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.
These are the only three values, enforced by a database check constraint on the transaction's status.
How a pair gets matched
Matching is a manual, run-on-demand step, not something that happens as you post. On the Intercompany screen, Run Matching sweeps the whole group.
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, within the same group. When Carbon 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.
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
Matching sets the stage. Elimination is what actually removes the double-count for consolidated reporting. It, too, is a manual sweep: Generate Eliminations processes every Matched pair in the group.
For each matched pair, Carbon posts a single elimination journal that reverses the intercompany control-account entries on both sides. Each transaction points at one control line; from it, Carbon takes that line's account and document and reverses every line the same invoice posted to that account — the seller's Inter-Company Receivables and the buyer's Inter-Company Payables — booking the sign-reversed amounts. Because it reverses the actual ledger lines for the whole document, a multi-line invoice is cleared in full, not just its first line, and both control accounts clear to their exact balance with no rounding residual. The seller's receivable and the buyer's payable are equal and opposite, so the elimination journal balances. Each reciprocal pair is processed once.
That journal is booked not on either operating company but on a dedicated elimination entity — a special company in the group flagged for this purpose. Carbon routes the entry to the elimination entity belonging to the lowest common parent of the two transacting companies, which is what makes multi-tier hierarchies (parent-child, sibling, cousin) consolidate correctly; if there isn't one at that level it falls back to any elimination entity in the group, and if the group has none the run fails.
Once the reversing journal is posted, the pair flips to "Eliminated" and the elimination journal is recorded on each transaction. The run returns a count of the journals it created.
Elimination writes real reversing journal entries on the elimination entity. There is no one-click undo. Generate eliminations only when the matched pairs are correct, and confirm you have an elimination entity in the group before you run it.
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: once a pair 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 and at least one elimination entity:
- 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.
- The elimination entity is a company in the group marked as such. It holds no operating activity; it exists to receive the elimination journals. Without one, Generate Eliminations has nowhere to post and the run fails.
When a company joins a group, Carbon 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.