One subsidiary records a $25,000 intercompany receivable, and another records the matching payable. The amounts agree in the transaction currency, while the two records carry different document references, posting dates and functional currencies.

Are they correctly matched? Is this a timing difference? Or has one entity recorded something wrong?

Intercompany reconciliation answers those questions before the group relies on its consolidated results. If subsidiaries run different ERP systems, the job also means bringing their records into one matching and review process, while keeping the accounting detail that explains each transaction.

Below, you'll find the reconciliation process, how matching differs from elimination and settlement, and how to evaluate automation across several ERPs, with a worked NetSuite–Business Central example and an acceptance checklist for testing the result.

What Is Intercompany Reconciliation?

Intercompany reconciliation compares the matching transactions and balances that related legal entities record, to confirm both sides of each intercompany relationship are recorded as they should be and to surface differences that need investigating.

Take a group with two subsidiaries. Company A provides services to Company B and records an intercompany receivable and the revenue. Company B records the matching payable and an expense, or another entry that fits the transaction. Both sets of records describe one business event, held in different accounting systems or ledgers, and reconciliation establishes whether they agree under the group's accounting policies.

What Types of Intercompany Transactions Are Reconciled?

The exact entries depend on the transaction and the group's accounting policies. A loan follows different rules from a service invoice, and a transfer between entities can be a loan, a settlement or a capital movement with no revenue involved. The reconciliation rules have to reflect what each transaction is.

Why Reconciliation Matters Before Consolidation

A group preparing consolidated statements has to understand every transaction between its subsidiaries. If Company A records a receivable and Company B has no payable, someone investigates. If both records exist in different periods, the group decides the right accounting treatment.

ERPs build this order into their own guidance. Oracle's documentation for NetSuite's Intercompany Reconciliation report describes it as the tool for finding unmatched or incorrectly matched intercompany transactions, including paired transactions with different amounts or currencies, and tells users to run it before intercompany elimination. Oracle also recommends running it periodically, so problems surface before month-end.

That sequence carries a principle: reconciliation establishes that reciprocal records can be explained and agreed, which is a stronger finding than two totals happening to match.

How Does the Intercompany Reconciliation Process Work?

The process follows the same six steps in one ERP or several. Spreading records across different platforms makes each step harder to carry out.

Step 1: Identify the Relevant Transactions

Collect the records tied to intercompany activity: invoices, bills, credit notes, journal entries, loans and settlements. Link each one to the right legal entity and intercompany counterparty, and define the period you're reconciling. A March reconciliation, for example, has to tell transactions posted in March apart from documents dated March and recorded in April, because that difference matters even when the amounts agree.

Step 2: Normalize the Records for Comparison

Systems use different identifiers, account codes, date formats and transaction statuses. One ERP might hold the internal counterparty as a customer record, and another as a vendor linked to an intercompany partner. Before matching, represent the relevant information the same way, in a separate comparison layer that keeps the original values, identifiers, currencies and periods. The source accounting records stay as they are.

Step 3: Match Corresponding Transactions

Start with the strongest evidence. A shared invoice reference, a verified counterparty relationship, the transaction type and the currency amount together make a far better basis than an amount alone.

Some transactions match one-to-many or many-to-one where the approved process allows it. An intercompany charge might be one invoice at the selling entity and several allocated entries at the receiving entity. Cases like that need explicit rules.

Step 4: Investigate Differences

Common discrepancies include:

• A missing invoice or payable.
• Different posting dates or accounting periods.
• Wrong counterparty mapping.
• Duplicate transactions.
• Credit notes or adjustments recorded on one side only.
• Amount differences.
• Currency translation or revaluation differences.
• Partial settlements.

The distinction that matters is between a difference you can explain and one that needs correcting. A posting-period difference may be legitimate, and it still has to be identified and handled under the group's policies.

Step 5: Resolve and Approve Exceptions

Unmatched transactions go into a controlled review. The responsible finance professional investigates, determines the cause, and approves the action: correcting a transaction, obtaining a missing document, accepting an approved timing difference, or asking another subsidiary for information. A matching system can flag the disagreement, and the posting decision stays with that person.

Step 6: Confirm Reconciliation Status

The final result separates verified matches, explained differences, unresolved exceptions and items awaiting approval, and the people responsible for the close can see it, along with the original records, the rules used and the decisions made. Finance needs evidence it can review, and an automatic match percentage is only one input to that.

Intercompany Reconciliation vs. Elimination vs. Settlement

The three activities are related, and each has its own purpose.

Why a Match Leaves the Elimination Open

Say two subsidiaries hold matching records for an internal service charge. Reconciliation can establish that both refer to the same transaction and that the amounts are explainable. The correct consolidation entries depend on further questions: the accounting rules, the classification of the transaction, the consolidation scope and the period.

NetSuite's Automated Intercompany Management already generates elimination journal entries for configured intercompany transactions during period close. A separate matching engine should leave that work to the ERP, unless the organization has identified a specific requirement and authorized the design.

Settlement Is a Separate Financial Action

Two entities can reconcile an outstanding balance and settle it later, through payments, netting or another approved process. NetSuite, for example, offers intercompany netting for settling mutual open balances. Reconciliation results support those activities, and releasing funds or executing a settlement needs its own authorization.

Matching, eliminating and settling are three separate controls. Combining them without clear ownership adds financial risk the group doesn't need.

Why Intercompany Reconciliation Gets Harder Across Different ERP Systems

Within one ERP with intercompany set up, the system may already link intercompany partners and their transactions. Across different platforms, those links have to be built across separate data models.

Different Record Structures and Identifiers

An invoice created in NetSuite and the matching payable in Microsoft Dynamics 365 Business Central will carry different internal record IDs, and in many cases different account codes, document statuses and entity references. The matching process has to know which fields establish the relationship, and that takes a reliable representation of the source entity, counterparty, document and accounting context. A shared spreadsheet won't provide it.

Transaction Currency and Functional Currency

Currency is the next source of difficulty. A US subsidiary issues a $25,000 invoice to a European subsidiary. The invoice is in USD, the US entity's functional currency is USD, and the European entity's is EUR. The European subsidiary may record the payable in USD as the transaction currency, while recognizing the accounting amounts in EUR. The local-currency balances can differ even when the USD transaction amounts agree.

So the reconciliation compares transaction-currency amounts with each other and treats functional-currency values under the group's currency policy. Amounts in different currencies are never compared as though they should be equal, and an apparent currency difference triggers a review before anyone posts a correcting journal.

Different Posting Dates and Periods

Company A records an intercompany invoice on March 31, and Company B records the payable on April 1. The amounts agree, and the records sit in different accounting periods. The matching process should detect that, and the finance team decides whether it's a valid timing item, needs an accrual or correction, or affects the current close. The posting date stays as recorded until someone with authority changes it.

Different Access and Integration Capabilities

ERPs differ in how outside systems retrieve records, authenticate and perform operations. One may offer suitable APIs, and another may rely on a supported export or reporting interface. Establish what information is available, how complete it is, and how you'll detect an interrupted extraction.

Incomplete input does particular damage in reconciliation. A record missing from the extract can look identical to a missing accounting transaction, when the real problem was a failed data pull. A cross-ERP process needs a shared comparison model that keeps the accounting context of both systems.

Example: Matching an Intercompany Invoice Across NetSuite and Business Central

Take a group with two subsidiaries:

• Entity A, based in the US, uses Oracle NetSuite, with USD as its functional currency.
• Entity B, based in Europe, uses Microsoft Dynamics 365 Business Central, with EUR as its functional currency.

Entity A provides internal services to Entity B and issues an invoice for $25,000. Both sides intend to record it in USD as the document currency, and their functional-currency amounts may differ. The group needs to confirm that the receivable and payable represent the same transaction, and whether any difference needs action. The workflow is illustrative, and no native NetSuite–Business Central integration of this kind exists.

Step 1: Retrieve the Relevant Records

The process starts by pulling the authorized records from both ERPs. From NetSuite, that may include the intercompany invoice, the partner reference, the amount, currency, posting date and period. From Business Central, the matching information comes from the vendor bill or payable record.

The extract keeps every source identifier, so each match traces back to its original transaction. It also records whether each extraction succeeded.

The exact APIs, fields, permissions and extraction methods need validating against each deployment.

Step 2: Establish a Common Comparison Model

The records then go into one consistent structure:

These are the attributes the design compares, and the API field names differ between the two systems. The model makes the records comparable while keeping their meaning: a EUR amount stays separate from the agreed USD transaction amount, and neither value overwrites the other to make matching easier.

Step 3: Apply Matching Rules

The process starts from the entity relationship and the document reference. If both sides identify the same intercompany transaction and agree on the transaction currency and amount, the approved rules may treat that as a verified match.

Now change one fact. Entity A issued two separate $25,000 invoices to Entity B in the same month, and Entity B recorded one payable for $25,000.

The extra evidence might be a document reference, the underlying agreement, the service period, or another approved relationship. If it can't establish a unique match, the result stays ambiguous and goes to review. For transaction types where one-to-many matching is expected, separately approved aggregation rules apply.

Step 4: Classify the Differences

Say the process flags three exceptions, and each needs a different investigation.

Missing counterpart. Entity A recorded the invoice, and no matching payable appears in Entity B's retrieved records. First confirm the extraction was complete. If it was, investigate whether the invoice was received, approved, posted in another period, or left out.

Different posting periods. Both records exist, with Entity A in March and Entity B in April. The process flags the period difference, and Finance decides the accounting response. Neither record counts as reconciled for March in the meantime.

Functional-currency difference. Both records agree on $25,000, and their functional-currency amounts differ. That alone proves no error. The group reviews the exchange-rate and accounting treatment before deciding whether anything needs correcting.

A blanket rule such as "adjust the smaller balance to match the larger one" would get all three wrong.

Step 5: Route Exceptions to the Correct Owner

Every unresolved difference gets a record explaining why it was flagged:

• Both source transaction references.
• The entities and accounting periods involved.
• The matching rule attempted.
• The values that differ.
• Relevant supporting evidence.
• The responsible finance reviewer.
• The current status and required action.

The reviewer works from the original transactions, with the summarized difference as a guide. For a missing payable, that may mean confirming whether the document arrived and should be posted. For a timing difference, it means deciding the period-end treatment. The matching layer organizes the questions, and the reviewer makes the accounting decisions.

Step 6: Record the Resolution and Reconcile Again

After review, the responsible professional may approve a correction in one of the ERPs or document a valid difference. Any ERP posting follows the organization's normal permissions and approval controls.

The reconciliation then refreshes the records and runs the matching rules again. A rerun must never create a duplicate match, repeat an adjustment or erase earlier evidence. If a posted correction resolved the original discrepancy, the history keeps the link between the exception, the approved correction and the updated source record, so Finance can explain why the status changed.

Step 7: Determine Close Readiness

The final output separates five statuses:

The Group Controller can then see which items are resolved, which remain open, and which affect the close. A high automatic matching rate feeds that review and never replaces it. The goal is a verified relationship between the right transactions, backed by evidence, and two amounts that agree are only the starting point.

Cross-ERP Reconciliation Acceptance Checklist

Before an automated matching process joins the financial close, test it well beyond the transactions that succeed. This Cross-ERP Reconciliation Acceptance Framework is an engineering checklist of our own, built for that purpose.

Separate Verified Matches From Ambiguous Candidates

A possible match becomes an accepted match only when the evidence supports it. If a system finds several transactions with similar amounts and dates and can't tell which ones correspond, it keeps the candidates for review. That matters most for recurring intercompany charges, allocations and similar invoices, where a false match can be costly, so set automatic matching to be conservative there.

Test the Matching Rules Against Known Exceptions

Before production, run controlled scenarios:

Include these cases in acceptance testing whether the solution uses native ERP features, specialized software or custom development.

Preserve Evidence When Reconciliation Runs Again

Reconciliation repeats every period, so the process has to carry forward earlier decisions and unresolved differences. If a correction resolves an exception, keep both the original discrepancy and the approved action. If a source transaction changes after it was matched, detect the change and review the match. Each new run adds to the evidence that explains earlier financial decisions and leaves it intact.

Automation should cut the work of finding corresponding records, and keep incorrect matches as easy to spot as ever.

Native ERP Features vs. Reconciliation Software vs. Custom Integration

Many ERP systems already handle much of intercompany reconciliation, and specialized platforms add matching, central reporting and exception management across systems. Start with what your current environment supports.

What NetSuite Already Supports

NetSuite's Intercompany Reconciliation report identifies unmatched or incorrectly matched transactions between subsidiaries, and Automated Intercompany Management generates configured elimination entries at close.

A group running NetSuite across its subsidiaries should evaluate these before building another matching or elimination workflow. The report covers subsidiaries inside NetSuite, so records in a separate Business Central environment need their own validation.

What Business Central Already Supports

Business Central has native intercompany functionality. Once partners are set up as customers and vendors, a document entered at one company creates the matching document at the partner, with mapped charts of accounts and dimensions. It works across multiple Business Central databases, including companies in different countries, with different currencies, charts of accounts and item numbers.

A group of Business Central companies may find this covers much of its need. The pairing works between Business Central companies, so a mixed-ERP group should confirm what remains unsupported before adding another system.

When Specialized Reconciliation Software Makes Sense

Platforms such as BlackLine and HighRadius offer dedicated intercompany management. BlackLine's Intercompany Balance & Resolve describes centralized transaction information across ERPs, matching, exception management and supporting documentation, and HighRadius Intercompany Management offers transaction matching and discrepancy workflows. They already solve many problems companies might otherwise consider building.

Their fit depends on actual connector coverage, financial requirements, commercial terms and implementation scope. Treat vendor-reported performance figures as claims to verify for your own environment.

When Additional Custom Integration Is Justified

Custom engineering deserves a look when an important requirement stays unsupported: an ERP source the chosen platform can't reach, a specialized mapping rule, an exception workflow involving another internal system, or a control configuration can't provide. The answer may be a small extension to an existing reconciliation platform, well short of a separate application. Choose the option that supports the financial process with the right controls and an owner who can maintain it.

How Should Intercompany Exceptions and Corrections Be Managed?

A reconciliation process is only as good as what happens after it finds a difference. A list of unmatched transactions helps once someone can investigate and resolve each item.

Give Every Exception an Owner

Each material difference needs an assigned reviewer, and the exception record names the entities, source transactions, period and nature of the discrepancy. A missing payable may belong to the receiving entity's accounting team. A dispute over the service charge itself may need both entities. A currency translation issue may need the Group Controller. Make those responsibilities explicit in the workflow.

Keep Matching Separate From Financial Posting

Identifying a discrepancy and authorizing a correction are two separate acts. A reconciliation system may propose an adjustment or point to the record that needs attention, and creating or changing an ERP posting stays under the organization's normal authorization, segregation of duties and review. If the integration can write to an ERP, limit it to approved operations and roles. For matching and exception reporting alone, a read-only process may be enough.

Measure Resolution Quality Along With Matching Volume

The automatic match rate is useful and can mislead. A system that accepts ambiguous matches reports a higher rate while making the reconciliation less trustworthy. A more balanced set of measures:

Define the measures before automating, collect a baseline, and compare after a meaningful period. The aim is fewer unresolved issues and more reliable close evidence. For the wider close, see our guide to automating month-end close. Supplier-side reconciliation, which compares your records with an outside vendor's, follows different rules, covered in our guide to vendor statement reconciliation.

When Does Custom Intercompany Reconciliation Development Make Sense?

A custom integration is worth evaluating when the current ERP or reconciliation platform can't meet an essential requirement. For a multi-entity group, the gap tends to sit in the data sources, the matching rules or the workflow around them. Consider custom engineering when:

• Required intercompany records sit in separate systems with no suitable existing connection.
• The business needs entity mappings or transaction relationships the current configuration doesn't support.
• The process needs extra evidence collection, exception routing or approval integration.
• Existing tools fall short of a defined monitoring or recovery requirement.
• The organization needs maintained connectivity between a reconciliation platform and one or more ERPs.

Each of these justifies investigation, and the decision to build still needs its own case. Before you ask for estimates, define the source systems, legal entities, transaction types, currencies, volumes and existing reconciliation capabilities, along with what the solution must produce: verified matches, exception records, reviewer decisions, financial reports or another agreed output. Then weigh the build against the alternatives already available.

Intercompany Reconciliation: Frequently Asked Questions

Reconciling Intercompany Transactions Across Different ERP Systems?

With subsidiaries on different financial platforms, matching records is one part of the work. The process also needs consistent entity mappings, reliable transaction data, clear exception ownership, and controlled approval of corrections.

Codebridge helps companies design and build software integrations and custom workflows around their existing systems. If your intercompany reconciliation still depends on manual exports, inconsistent mappings or repeated investigation across separate ERPs, start with one defined process: what your platforms already support, what information has to move between systems, and where more engineering is justified.

Book a 30-minute call