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. You create one 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.
Creating it does real bookkeeping on the source company. Carbon writes a balanced on the source: a debit line to the account you pick and a matching credit line, both tagged with the target company as the intercompany partner. The currency defaults to the source company's base currency. So an intercompany transaction is not a note. It is a posted journal on one company, plus a tracking record that remembers which sibling it was with.
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 booked its side, or booked it for a different amount. Create 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 whose lines are the sign-reversed copies of both sides' original journal lines. 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.