Intercompany Transactions Automation: Record Both Sides of Every Deal Once

Intercompany transactions automation records the second half of every deal between related companies for you. When Alpha Wholesale posts a sales invoice to Beta Retail, the purchase invoice appears in Beta's books with the same amount, date and reference, without anyone typing it twice. The result is intercompany balances that agree every day, not just after a painful month-end hunt.

This guide shows how it works in practice with a complete worked example, both vouchers, the workflow that connects them, and how to test and reconcile it. If you are still deciding how to structure your entities, start with the multi-entity accounting guide.

#What are intercompany transactions?

Intercompany transactions are sales, purchases, loans, service charges, cost recharges or payments between two entities that belong to the same group. Each one must be recorded twice: once in the seller's ledger and once in the buyer's ledger.

Common examples in a small group:

• A wholesaler sells inventory to a sister retail company.
• A head office recharges rent or payroll to operating subsidiaries.
• A parent lends cash to a subsidiary and charges interest.
• One company pays a supplier invoice on behalf of another.
• A service company bills a management fee every month.

In the group's consolidated statements, all of these are eliminated. In each company's own statements, they are real revenue, cost, receivables and payables, and they must match.

#Why manual intercompany accounting breaks

Manual intercompany accounting fails because two people record one event at different times, from different documents, in different ledgers. The mismatches are predictable:

Each difference has to be found before consolidation and eliminations can happen. With 50 intercompany invoices a month, that is hours of matching.

#How intercompany automation works in Ledgeriano

Ledgeriano automates intercompany journal entries with workflows: rules that watch one business and write to another. A workflow has three parts.

1. Trigger. An event in the source business: an entry is created, posted or reversed. Most intercompany rules use "posted", so drafts that are still being reviewed do not create anything.
2. Conditions. Filters that decide whether this particular entry should be copied. You can match all conditions or any of them.
3. Actions. What to do in the target business: create an entry from a template, mirror the entry through an account map, or call a URL (a webhook to another system).

#Condition fields you can use

#Amount formulas and template tags

Template lines take an amount expression instead of a fixed number. The most useful ones:

• total: total debits of the source entry.
• credit("4101"): sum of credits on accounts whose code starts with 4101.
• debit("11"), net("11"): debits, or debits minus credits, for a prefix.
• round(x, 2), abs(x), min(a, b), max(a, b), percent(x, 9).

Descriptions and references accept tags such as {{entry.number}}, {{entry.reference}}, {{entry.date}} and {{source.business}}. See the workflows page for the full list.

#A worked example: wholesaler sale to a retail sister company

Here is the full chain, using the IFRS chart of accounts template and two businesses: Alpha Wholesale LLC (the seller) and Beta Retail Store (the buyer). In Alpha's books, Beta is customer C001. In Beta's books, Alpha is supplier S001.

#Step 1: Alpha posts the sales voucher

On 5 March Alpha sells goods to Beta for 36,000 USD on invoice INV-1001. The goods cost Alpha 24,000 USD. The accountant posts one SAL voucher:

Alpha Wholesale LLC, voucher type SAL, reference INV-1001, status posted

Notice that the voucher total is 60,000, not 36,000, because it includes the cost of sales. That is why the workflow below uses credit("4101") rather than total: Beta owes the sale price, not the sum of all debits.

#Step 2: the workflow that connects them

The workflow is defined once:

• Source business: Alpha Wholesale LLC
• Trigger: entry posted
• Conditions (match all): voucher type equals SAL; entry has party C001
• Action: create entry in Beta Retail Store
  • Voucher type: PUR, status: posted, date: same as source
  • Description: Purchase from {{source.business}}, invoice {{entry.reference}}
  • Reference: ALPHA-{{entry.number}}
  • Line 1: account 1124, debit, amount credit("4101"), description "Merchandise received"
  • Line 2: account 2111, credit, amount credit("4101"), party S001, description "Payable to Alpha"

#Step 3: Beta receives the purchase voucher automatically

Seconds after Alpha posts, this appears in Beta's journal:

Beta Retail Store, voucher type PUR, reference ALPHA-{Alpha's entry number}, status posted

The entry carries the tag "workflow" and stores the source business and source entry number, so anyone looking at it in Beta can trace it back. Beta's inventory is recorded at 36,000, which is Beta's cost. The 12,000 margin is Alpha's profit and would be eliminated only in consolidated statements if Beta still held the goods.

Tip: Keep the COGS lines out of the target entry. The buyer's cost is the seller's selling price, so formulas based on the revenue account (41 or 4101) are almost always right, while total would double count.

#Template vs mirror: which action should you use?

A template action builds a new entry from lines you define, while a mirror action copies every line of the source entry and translates each account through a map. Use templates when the two sides look different (sale vs purchase), and mirrors when the target entry should look like the source.

The same Alpha to Beta rule could be written as a mirror: map 1111 to 2111 and 4101 to 1124, turn on "swap sides" and "skip unmapped" (so the COGS lines are ignored), and set party S001. It works, but the template is easier to read six months later.

A mirror with a multiplier shines for allocations. Example: head office recharges 40% of every rent voucher to a subsidiary with multiplier 0.4 and a map 6205 to 6205, 1103 to 2113 (due to related parties).

#Other intercompany flows worth automating

Almost any recurring deal between group companies can be automated, as long as the source entry has something reliable to match on (a voucher type, a party or an account). These are the patterns we see most often:

Two habits make these flows reliable. First, use dedicated "due to" and "due from" accounts (2113 and 1115 in the IFRS template) for anything that is not a trade invoice, so the balances are easy to find. Second, tag entries with "intercompany" when the account alone is not enough to identify them; a tag condition is cheap and explicit.

#Different currencies on each side

If Alpha keeps USD books and a subsidiary keeps AED or IRR books, the target entry keeps the source currency by default and the target converts it with its stored exchange rate for that date. You can instead record the target entry directly in the target's base currency. Either way, differences caused by rate movements belong in 7103 foreign exchange gains and losses, not in the intercompany account; the multi-currency accounting guide covers revaluation.

#Loop protection, permissions and idempotency

Automation between companies must never create an endless chain or a duplicate. Ledgeriano builds several guards in:

• Workflow-created entries do not trigger other workflows unless you switch on "allow chained" for that workflow.
• Maximum depth of 3. Even with chaining allowed, a chain stops after three hops.
• No self-triggering. A workflow never runs on an entry that it created itself.
• Idempotency. Each action uses a key made of workflow, action, source entry and event, so running it again for the same entry returns the existing entry instead of a second copy.
• Permissions. The workflow runs as the user who created it. That user needs view access in the source business and create access in the target. If they lack permission to post in the target, the entry is saved as a draft for someone else to review.

Warning: If Beta also has a workflow that turns purchases from S001 into something in Alpha, do not enable "allow chained" on both. Design each flow to go one way, and use a separate workflow for the return path (for example payments).

#Testing a workflow before it goes live

Every workflow can be dry-run against an existing entry without writing anything. Pick an entry by number (or use the latest one) and Ledgeriano shows:

1. Each condition and whether it passed.
2. The exact payload of each action: date, voucher type, lines, amounts and parties.
3. Any error, such as an account code that does not exist in the target or a missing party.

When the preview looks right, you can run the workflow once for real against that entry, then turn it on. Each run is logged with its status (success, partial, failed or skipped), the entries it created, the duration and the credits used. Failed runs show the error in plain language, for example "lines.1.party_code: party S001 was not found".

#Intercompany reconciliation: keeping both sides equal

Intercompany reconciliation compares what one company says the other owes with what the other company says it owes, and it should produce a difference of zero. With automation the difference is usually zero, but you still check, because people can post manual entries.

#A monthly routine

1. In Alpha, run the party balances report for customer C001 at month end.
2. In Beta, run the party balances report for supplier S001 on the same date.
3. Compare the two figures and list any differences.
4. Investigate each difference in the general ledger of 1111 (Alpha) and 2111 (Beta), filtered by party.
5. Fix with a correcting entry or a reversal in the side that is wrong, never by editing a posted entry.

#Automating the payment side too

Sales are only half the flow. Add a second workflow in Beta: when a PAY voucher with party S001 is posted, create an RCT voucher in Alpha that debits 1103 bank and credits 1111 for party C001, using the amount debit("2111"). Now receipts and payments stay matched as well, and the reconciliation above stays at zero.

#What about reversals?

If Alpha reverses INV-1001, a third workflow triggered on "entry reversed" can record the opposite purchase entry in Beta (debit 2111, credit 1124). Keep the conditions the same so only intercompany sales are affected.

#Costs, limits and a quick checklist

Each workflow run uses credits, and each entry it creates is a normal entry, so it is billed like one. The actual credit costs are set by the administrator and shown on the pricing page.

Before you switch a workflow on, check:

• Both businesses use the account codes named in the template (1124 and 2111 here).
• The parties exist in both ledgers (C001 in Alpha, S001 in Beta).
• The voucher types exist in the target (PUR).
• The dry run shows the right amounts on at least two past entries.
• You have decided who reviews drafts if the entry is not posted automatically.

If another system (an online store or ERP) creates the original sale, combine this with the accounting API so that the whole chain runs without manual entry. The developer documentation also explains how to receive workflow webhooks in your own code, and the glossary defines terms like due to, due from and elimination.