Intercompany Transactions in Business Central

Ask any group finance controller what they dread most about the close, and a surprising number will say the same thing: intercompany. Not the tax, not the accruals, not even the consolidation itself, but the tedious, error-prone work of making sure that what one company in the group recorded as a receivable exactly matches what the other company recorded as a payable. Get it wrong and you carry unexplained differences into the consolidated accounts. Get it right by hand and you spend days chasing spreadsheets and emails. Business Central was built by people who understood this problem, and its intercompany functionality is a real answer to it. This guide walks through what that functionality does, how the moving parts fit together, and the honest boundary where a group has grown past what it can reasonably do.

The message up front: Business Central intercompany is not about consolidation. It is about making sure the two sides of every transaction between related companies are recorded consistently and can be agreed without manual reconciliation. If you understand that distinction, everything else in this guide falls into place. Consolidation is a separate, later step that becomes far easier once intercompany is under control.

1. What intercompany functionality solves

Most growing organisations do not start as a single legal entity. They accumulate them. A holding company here, an operating company there, a separate entity for a different country because the tax and regulatory rules demand it, a shared-services company that employs the group's back office and recharges its cost. Before long you have five, ten, twenty legal entities that are one economic group but many separate sets of books. Business Central models this cleanly: each legal entity is its own company inside the environment, with its own chart of accounts, its own posting, its own reporting, and its own statutory obligations.

The trouble begins the moment those companies trade with each other, and in a real group they trade constantly. The manufacturing entity sells finished goods to the distribution entity. The shared-services company invoices the operating companies for IT and HR. The parent charges a management fee. One entity pays a supplier invoice on behalf of another and recharges it. Every one of these is an intercompany transaction, and every one of them has to appear on both sets of books: as revenue and a receivable in the selling company, and as a cost and a payable in the buying company.

Without a system to help, that double recording is done by hand. Someone in company A posts an invoice and then emails company B to say "please book this". Someone in company B keys it in manually, hopefully to the right account, hopefully with the right amount, hopefully in the right period. At month-end a controller runs an intercompany reconciliation, discovers the two sides do not agree because of a keying error or a timing difference or a missed transaction, and the hunt begins. This is not a rare problem. It is the single most common source of unexplained differences in group accounts, and it scales badly: the more entities and the more intercompany volume, the worse it gets.

Business Central intercompany solves this by letting one company originate a transaction and send it directly to the partner company, where it arrives ready to be posted with the amounts, accounts and dimensions already carried across. Instead of two people independently keying two versions of the same event and hoping they match, one event flows from originator to partner as structured data. The matching is designed in, not reconstructed afterwards. That is the whole point, and it is why groups that adopt it properly stop treating intercompany as a month-end fire drill. For the wider picture of how the finance module holds all of this together, the Business Central financial management pillar is the companion piece to this one.

2. Intercompany setup: partners, the intercompany chart of accounts, and dimension mapping

Intercompany in Business Central rests on three pieces of setup, and understanding them is understanding the whole mechanism. Skip past the configuration and the flow will feel like magic; take the time to grasp it and you will be able to diagnose almost any intercompany problem yourself.

The first piece is the intercompany partner. Each company that participates gets its own intercompany partner code, and every other company in the group registers that partner in its list of intercompany partners. A partner definition tells your company two things: who the counterparty is, and how transactions reach them. In the common case, the partner is simply another company living in the same Business Central environment, and transactions move between them directly inside the database. Business Central also supports partners that exist outside your environment, where transactions are exchanged as files, but for a group whose entities all sit in one Business Central tenant the in-database route is far simpler and is what most implementations use. Each customer and vendor card that represents a group company is then linked to its intercompany partner code, so the system knows that an invoice to "Distribution Co" is not an ordinary sale to an external customer but an intercompany transaction bound for a partner.

The second piece, and the one people underestimate, is the intercompany chart of accounts. This is a separate, shared chart that acts as a common language between companies that each have their own local chart. Company A might record intercompany management-fee income in account 4400 and company B might record the corresponding expense in account 6120, but neither company needs to know the other's account numbers. Instead, each company maps its own local accounts to the shared intercompany accounts. When a transaction is sent, it travels tagged with the shared intercompany account, and the receiving company translates that back into its own local account through its own mapping. This indirection is what lets entities with completely different charts of accounts trade cleanly. It is also the piece most likely to be set up incompletely, because it takes deliberate work to map every account that will ever appear in an intercompany transaction. A gap in the mapping is where transactions get stuck.

The third piece is intercompany dimension mapping. Business Central makes heavy use of dimensions for analytical reporting, and different companies frequently define their dimensions differently. One company's "Department" dimension might be another company's "CostCentre". Intercompany dimension mapping translates dimension codes and values between companies the same way the intercompany chart translates accounts, so that a transaction carrying a department dimension in the originating company arrives with the correct corresponding dimension in the partner. Without this mapping, dimensions either fail to carry across or arrive as codes the receiving company does not recognise, which quietly undermines the analytical reporting that the group probably adopted dimensions to get in the first place.

The honest caution on setup: intercompany setup is front-loaded work that pays off only if it is done completely. A half-mapped intercompany chart or a partial dimension mapping does not fail loudly. It fails quietly, leaving transactions parked in the inbox with a mapping error, or dimensions dropping silently. Budget the time to map every account and every dimension that intercompany traffic will touch, and treat the mapping as a living thing that gets updated whenever a new account or dimension is added to the group.

3. The inbox and outbox: how intercompany transactions flow between companies

The heart of the mechanism is a pair of queues that every intercompany-enabled company has: an outbox and an inbox. Once you picture transactions moving through these two trays, the whole flow becomes intuitive.

When your company originates an intercompany transaction, whether that is a general-journal line, a sales invoice or a purchase order bound for a partner company, it does not vanish straight into the partner's books. It lands first in your outbox as an outbound transaction. The outbox is your holding tray of things you have created and are about to send. From there the transaction is sent to the partner, at which point it moves out of your outbox and appears in the partner's inbox as an inbound transaction. The inbox is the partner's tray of things that have arrived and are waiting to be dealt with. The partner reviews each inbound transaction and decides to accept it, which posts it into their books, or to return it, which sends it back if something is wrong.

This queue model is deliberate and it is what makes intercompany controllable. Nothing posts into another company's ledger without that company's own acceptance. The originator proposes; the partner disposes. That preserves the accounting principle that each legal entity remains in control of its own books while still removing the manual re-keying that used to be the only way to get the transaction there. A transaction in the outbox has not yet reached the partner and can still be managed. A transaction in the inbox has arrived but has not yet posted, so the receiving company still has the chance to review it, check the account and dimension mapping resolved correctly, and either accept or reject it.

There is a symmetry worth noticing. Every outbound transaction in one company corresponds to an inbound transaction in exactly one partner, and vice versa. When something looks wrong, the first diagnostic question is always "which tray is it in, and in which company?" A transaction stuck in a sender's outbox never reached the partner. A transaction sitting unhandled in a receiver's inbox reached them but nobody acted on it. A transaction that was returned went back to the sender for correction. Learning to read the two queues turns intercompany from a black box into a flow you can follow step by step.

Company A originates transaction
  ↓
Company A OUTBOX (outbound, awaiting send)
  ↓ send
Company B INBOX (inbound, awaiting decision)
  ↓ accept
Company B ledger (posted)   |   or return → back to Company A

4. Intercompany general journals

The simplest and often most-used intercompany tool is the intercompany general journal. It is the right instrument for the many intercompany events that are pure accounting entries rather than trade documents: a cost allocation, a management-fee charge, a recharge of a shared expense, an intercompany loan movement, an interest accrual between entities. Anything that in a single company would be a journal entry, but that needs to hit two companies' books, is a candidate for the intercompany general journal.

The mechanics mirror an ordinary general journal, with one crucial addition. You post the lines that affect your own company as normal, and on the intercompany side of the entry you specify the intercompany partner and the intercompany account that the partner should post to. When you post the journal in your company, your side goes to your ledger immediately, and the partner side is placed into the intercompany flow: it lands in your outbox and travels to the partner's inbox. The partner then accepts the inbound transaction, and it posts to their books using their own mapping to translate the intercompany account into their local account.

The elegance here is that a single journal entry, prepared once by the person who understands the transaction, produces correct and consistent entries in both companies. The originator does not need to know the partner's chart of accounts, and the partner does not need to re-key anything. Consider a shared-services company recharging its monthly IT cost to three operating companies. Rather than posting three sales invoices manually and then emailing three counterparts to book the matching expense, the finance team can post an intercompany general journal that debits each operating company's intercompany balance and credits its own recharge income, and the three expense entries flow to the three partners ready to accept. What used to be six manual postings across four companies becomes one journal and three acceptances, with no risk that the amounts diverge.

5. Intercompany sales and purchase documents

Journals handle pure accounting movements, but a great deal of intercompany activity is genuine trade: one entity selling goods or services to another, with all the document structure that trade implies. For this, Business Central extends its ordinary sales and purchase documents into the intercompany flow. When you raise a sales order, invoice or credit memo for a customer that is linked to an intercompany partner, the document can be sent to that partner as a corresponding purchase document, and vice versa. A sales invoice in the selling company becomes a purchase invoice waiting in the buying company's inbox, carrying the lines, amounts, accounts and dimensions across.

This matters because the two sides of an intercompany trade are structurally different documents. The seller has a sales invoice with revenue lines; the buyer needs a purchase invoice with expense or inventory lines. Doing this by hand means someone in the buying company reads the seller's invoice and constructs a matching purchase invoice from scratch, which is exactly where line-level errors creep in. The intercompany document flow constructs the buyer's document from the seller's automatically, so the two documents describe the same transaction by construction rather than by careful re-typing.

Where intercompany trade involves physical goods, the document flow becomes especially valuable, because it keeps the inventory movements consistent. The selling company ships and invoices; the buying company receives and records the corresponding purchase. Item numbers, quantities and values stay aligned across the two companies instead of drifting apart through independent data entry. For groups where entities genuinely move stock between themselves, this alignment is the difference between clean intercompany inventory reconciliation and a perpetual investigation into why the goods one company shipped do not match the goods the other company thinks it received.

It is worth being clear about scope. The intercompany document flow handles the transactional accounting and inventory record cleanly. It does not, on its own, resolve every operational complexity of intercompany trade, such as transfer-pricing policy, customs and cross-border logistics, or the transfer of items between locations that sit in different companies. Those need their own design decisions. What intercompany documents guarantee is that once you have decided what to charge and what to move, both companies' books reflect it consistently.

6. Automatic versus manual transaction handling

A recurring question in every intercompany implementation is how much of the flow to automate. At one extreme, every transaction is handled manually: someone sends each outbound transaction, and someone at the partner reviews and accepts each inbound one. At the other extreme, the system is configured to send outbound transactions automatically as they are created, and to accept inbound transactions automatically as they arrive, so that intercompany entries flow end to end with little human touch. Business Central supports the range, and the intercompany setup governs how far toward automatic you go.

The temptation is always to automate fully, because manual handling feels like exactly the tedious work intercompany was supposed to remove. Resist that temptation until you have earned it. Automatic acceptance means a transaction posts into a company's ledger without a human at that company reviewing it first. That is fine, and genuinely valuable, once the account mapping and dimension mapping are complete and proven and the transaction types are well understood and routine. It is dangerous while the setup is still maturing, because a mapping gap that a human would have caught in the inbox instead becomes a posting error that has already hit the ledger.

The practitioner's sequence: start manual, automate gradually. Run intercompany with manual send and manual accept for the first few cycles, watch what lands in the inboxes, fix the mapping gaps you find, and only then move the routine, high-volume, low-risk transaction types to automatic. Keep manual review on the transaction types that are irregular or high-value. Automation should be a reward for a mapping you trust, not a substitute for building one.

The right end state for most groups is a hybrid. The predictable recurring traffic, monthly recharges, standard intercompany sales between the same entities, flows automatically because it has proven itself reliable. The unusual or material transactions still pass through a human review in the inbox because a person's judgement is worth more there than the few minutes it saves to skip it. Deciding which transactions deserve which treatment is a control decision, not a technical one, and it belongs with the group controller rather than the system administrator.

7. Intercompany and dimensions, currencies and pricing

Real groups are rarely tidy. Their entities use different charts of accounts, different dimension structures, different currencies, and different pricing between each other. Intercompany has to cope with all of that, and understanding how it does clarifies both its power and its limits.

Dimensions are handled through the intercompany dimension mapping described earlier. Because dimensions carry the analytical meaning of a transaction, department, project, cost centre, region, getting them across correctly is what preserves the group's ability to report intercompany activity by those analytical axes. When the mapping is complete, a transaction tagged with a project dimension in one company arrives correctly tagged in the partner. When it is not, the analysis breaks silently, which is why the dimension mapping deserves the same discipline as the account mapping.

Currencies are where cross-border groups meet reality. Two entities in different countries frequently keep their books in different local currencies, and an intercompany transaction between them has a currency on each side. Business Central handles the transaction in the relevant currencies and applies exchange rates, but the group has to decide and document its conventions: which currency the transaction is denominated in, which exchange rate applies, and how the inevitable small exchange differences between the two sides are treated. The system will do the arithmetic, but the exchange difference between what one company records at its rate and what the other records at its rate is a real accounting item that has to be owned and posted somewhere. Groups that ignore this find their intercompany balances failing to net to zero by exactly the exchange difference, which then muddies reconciliation and consolidation.

Pricing between related companies is partly a system matter and partly a policy matter. Business Central will carry whatever price the intercompany sales document specifies across to the purchase side, so the two documents agree. What it will not do is decide your transfer-pricing policy for you. The price at which one entity charges another has tax and regulatory consequences in most jurisdictions, and that policy has to be set by the group's finance and tax function and then reflected in the prices the documents carry. The system enforces consistency between the two sides of a transaction; it does not enforce that the price is defensible. Keep the distinction clear, because auditors and tax authorities care intensely about the second question and not at all about the first.

8. Reconciliation between entities

The payoff of doing intercompany properly shows up at reconciliation. The classic intercompany reconciliation asks a simple question with a historically painful answer: does what company A shows as owed by company B match what company B shows as owed to company A? In a manual world the two figures drift apart through keying errors, timing differences and missed transactions, and closing the gap is detective work.

Because the intercompany flow originates each transaction once and carries it to the partner as structured data, the two sides are consistent by construction rather than by coincidence. When company A sends an intercompany invoice and company B accepts it, the receivable and the payable derive from the same source event, so they agree on amount and, where the mapping is complete, on the analytical detail too. The reconciliation shrinks from reconstructing two independently keyed sets of figures to confirming that both sides have processed the same set of flowed transactions.

The differences that remain in a well-run intercompany setup are almost always timing differences rather than errors, and timing differences are benign and explainable. A transaction that company A has sent but company B has not yet accepted will show on A's side and not yet on B's. That is a legitimate difference with a known cause: it is sitting in B's inbox waiting to be handled. This reframes the reconciliation task from "find the error" to "clear the inbox and identify what is in transit", which is a vastly more tractable job. The controller's month-end intercompany routine becomes: make sure every inbox is emptied, confirm the in-transit items, and the balances agree.

This is the practical benefit that justifies the setup effort. Groups that run intercompany manually spend the close chasing differences; groups that run it through Business Central spend the close confirming there are none. The work moves from reactive investigation to a proactive control, and the difference in stress at month-end is not subtle.

9. Consolidation: how intercompany relates to group reporting and eliminations

It is essential to separate two ideas that people constantly conflate: intercompany and consolidation. They are related but they are not the same thing, and confusing them leads to disappointment. Intercompany, everything discussed above, is about recording transactions between companies consistently. Consolidation is about combining the separate companies' financial statements into a single set of group accounts, which is a later and separate process.

Business Central does provide consolidation functionality. In the typical approach you designate a consolidation company, define each participating entity as a business unit within it, and import each entity's balances into the consolidation company, translating currencies where entities report in different currencies. The result is a combined view that sums the group's companies. This is real and it works for groups of modest structural complexity.

The link between intercompany and consolidation is the elimination. When you simply add up the group's companies, you double-count everything that the companies did with each other. The intercompany receivable in company A and the intercompany payable in company B are the same debt seen from two sides, and the consolidated group owes nothing to itself, so both must be removed. The same is true of intercompany revenue and the matching intercompany cost, and of intercompany profit sitting in inventory that has not yet been sold outside the group. Elimination is the process of stripping all of this out so the consolidated accounts show only the group's dealings with the outside world.

Here is where clean intercompany pays a second dividend. Eliminations are only as easy as the intercompany records are consistent. If the two sides of every intercompany balance agree because they flowed from the same source event, the elimination is a clean removal of matching amounts. If the two sides disagree because they were keyed independently and never fully reconciled, the elimination leaves a residual difference that has to be investigated and forced, and that residual is exactly the kind of unexplained item that makes group accounts hard to defend. Disciplined intercompany is the foundation that makes consolidation and its eliminations straightforward rather than fraught. The two are a sequence: get intercompany consistent first, and consolidation becomes a reporting step rather than a reconciliation battle.

10. Limits: when a group has outgrown Business Central intercompany

I would not be an honest guide if I pretended Business Central intercompany scales indefinitely. It is genuinely good for small and mid-sized groups with a manageable number of entities and reasonably clean structures. There are recognisable signs that a group has grown past it, and recognising them early saves a lot of pain.

The first sign is sheer entity count and volume. The inbox-and-outbox model is elegant with a handful of trading entities. With dozens of entities and high daily intercompany volume, the per-transaction handling, even automated, and the mapping maintenance across every pairing become a heavy operational load. The model does not break, but it starts to feel like it is being asked to carry more than it was designed for.

The second sign is consolidation complexity beyond the basics. Business Central consolidation handles straightforward group structures. Once you need sophisticated multi-tier consolidation, complex minority-interest and partial-ownership treatment, layered sub-consolidations, currency translation with intricate reserve accounting, or a heavy regime of standardised elimination and adjustment entries, you are into the territory of dedicated consolidation and group-reporting tools. Many well-run groups deliberately use Business Central as the transactional and intercompany engine and then feed a specialised consolidation tool for the group close, and that is a sensible architecture rather than an admission of failure.

The third sign is the pull toward the larger Dynamics platform. Microsoft positions Dynamics 365 Finance, the larger enterprise ERP, for organisations whose scale, entity count, cross-company process complexity and centralised shared-services model exceed what Business Central targets. Finance offers deeper multi-entity capabilities suited to large, complex groups. The decision to move is not a small one and should be driven by genuine need rather than aspiration, but for a group that has genuinely outgrown Business Central, continuing to force intercompany through it becomes a false economy. For a structured way to think about that scale threshold and whether the platform still fits, the is Business Central right for your organization pillar works through exactly this judgement.

The honest boundary: outgrowing Business Central intercompany is not a criticism of the product, it is a sign the group has scaled past the segment the product serves. The mistake is not choosing Business Central; it is refusing to acknowledge when the group has moved beyond it and bolting ever more workarounds onto a tool that was right at a smaller scale. Know the boundary, watch for the signs, and plan the transition deliberately rather than in a crisis.

Final thoughts

Intercompany is one of those areas where the technology is genuinely useful and the discipline around it decides whether that usefulness is realised. Business Central gives you a real engine: partners that identify the counterparties, a shared intercompany chart and dimension mapping that lets entities with different structures trade cleanly, an outbox-and-inbox flow that moves transactions from originator to partner as structured data, general journals for accounting movements, sales and purchase documents for genuine trade, and the choice of how much to automate. Used with discipline, it turns intercompany from the worst part of the close into a controlled flow that reconciles itself, and it lays a clean foundation for consolidation and its eliminations.

The discipline is the unglamorous part: map every account and dimension completely, start manual and automate only what you have proven, own your currency and transfer-pricing conventions, clear the inboxes as a monthly control, and keep intercompany and consolidation clearly separated in your mind. Do that and a mid-sized group runs its intercompany without drama. And when the group grows past what the tool serves, read the signs honestly and plan the move rather than piling workarounds on a foundation that has done its job well. For the broader tour of what else the platform covers, the complete features guide puts intercompany in the context of the whole system.

Related reading: Business Central financial management, Business Central features: the complete guide, Is Business Central right for your organization?.