Why one record cannot cover both entities
A group operation happens once but lands in two sets of books. The entity that provides the service carries a receivable; the entity that receives it carries a payable. Those two balances are reciprocal, and the group later confronts them. If only one side is posted, the other entity’s books are incomplete, and the group’s figures carry a balance with nothing facing it. These records are also called intercompany accounting journal entries.
How each side of the pair is built
- Name both entities. The record identifies the entity that originates the charge and the entity that receives it. That dual entity identification is what a record inside one legal entity does not need.
- Use reciprocal accounts. One entity carries an intercompany receivable, the other an intercompany payable, and the two accounts belong to the same reciprocal pair so the balances can be confronted later.
- Match amount and period. Both sides represent the same operation in the same period, compared in a common currency basis when their functional currencies differ. A match in amount with a mismatch in period still leaves the two books apart at the cut-off.
- Balance inside each book. Each side has to balance in the ledger of the entity that posts it. An imbalance must be investigated and corrected. A clearing account is used only for a documented purpose under the posting policy, not as an unexplained plug.
Example: a shared services charge recorded on both sides
Selby Shared Services provides payroll and technology support to Thornbury Operations, an operating subsidiary in the same group. For March, Selby charges Thornbury USD 67,400: USD 41,900 of allocated personnel cost and USD 25,500 of allocated technology cost. The figures are illustrative and in US dollars.
In Selby’s books, the entry debits intercompany receivable for USD 67,400 and credits service revenue in two lines, USD 41,900 and USD 25,500. The credits add up: USD 41,900 + USD 25,500 = USD 67,400, so the record balances inside Selby’s own ledger.
In Thornbury’s books the same charge is a cost: the entry debits service expense in two lines, USD 41,900 and USD 25,500, and credits intercompany payable for USD 67,400. It balances the same way: USD 41,900 + USD 25,500 = USD 67,400.
Each side balances only in its own book. Selby’s record shows that Selby posted the charge; it does not show that Thornbury posted its side, for the same amount, in the same period. That gap is what the control on reciprocal balances is for.
Typical intercompany scenarios
| Scenario | One entity records | The other entity records |
|---|---|---|
| Sale of goods | A receivable from the buyer and revenue | A payable to the seller and inventory at cost |
| Service charge | A receivable and service revenue | A service expense and a payable |
| Loan or advance | A loan receivable | A loan payable |
| Shared cost allocation | A receivable for the allocated share | An expense for the allocated share and a payable |
The pair changes with the operation, but the shape holds: one entity carries a receivable or a cost, the other a payable or revenue.
Each row is one operation recorded twice, once in each entity’s ledger.
Same period, and the record that will not balance
Two correct amounts posted in different periods still leave the two books apart at the cut-off, because one entity shows the balance and the other does not yet. That is why the pair belongs in the same period.
Within each entity, debits must equal credits. The team investigates missing lines, incorrect mappings and amounts before posting. A temporary clearing account requires a documented purpose and follow-up; it does not establish that the underlying transaction is correct.
Controlling each posting and its counterpart
Simetrik can generate journal entries from operational sources or reconciliation results and send them to the ERP under a configured posting model. For an intercompany flow, that model needs the legal entity, reciprocal accounts, currency basis and period for each side. A successful posting in one ERP does not confirm that the counterpart has posted.
The source-to-entry accounting workflow describes generating entries directly from source records. Validation, version history and ERP synchronization status help the team investigate a failed posting before resending it. AI can assist with basic model fields; the team defines the accounting treatment and verifies both records.