Intercompany differences are among the most predictable causes of delay in a group close. One entity reports a receivable while the counterparty reports a different payable; one records income in December and the other records the expense in January; balances are posted to different accounts or currencies; and explanations circulate through email until the consolidation team decides what to eliminate. The group may ultimately post an adjustment, but the resolution history is often incomplete.
A balance-level intercompany matching process provides a proportionate solution. It compares reciprocal balances by reporting entity, counterparty, account or transaction category, applies tolerances, identifies one-sided submissions and supports comments and resolution. It can propose an elimination amount, but a reviewer approves the proposal before a journal is posted. Invoice-level matching, automated settlement and transaction processing remain outside the scope.
This design is appropriate for Repositora because the objective is controlled statutory reporting rather than operational intercompany accounting. The workbench needs enough detail to prepare consolidated statements and notes, preserve evidence and identify unresolved differences. It does not need to reproduce a dedicated intercompany transaction platform.
A reliable process starts with a controlled entity and counterparty master. Each reporting entity uses the same counterparty identifiers, even if local systems use different codes. The reporting package should require intercompany balances to be tagged with the counterparty, transaction category and balance type.
The minimum fields include reporting entity, counterparty entity, account, transaction category, receivable or payable, income or expense, amount, currency, difference, explanation and resolution status. The group may also capture due date, ageing, document reference or responsible owner, but these should not become a substitute for invoice-level detail.
The matching population should include balance sheet and profit-or-loss relationships relevant to elimination. It may exclude immaterial or centrally eliminated categories based on group policy. The scope and materiality threshold should be documented and applied consistently.
Data quality is critical. An untagged intercompany account cannot be matched. Mapping rules should identify accounts expected to carry counterparty information and flag missing tags. New counterparties or relationships should require master-data review.
The system compares Entity A's balance with Entity B against Entity B's reciprocal balance with Entity A. Sign conventions and account types are normalised. The match may be exact, within tolerance, outside tolerance or one-sided. Tolerances can be absolute, percentage-based or category-specific.
Matching should account for currency. Within the group reporting workbench, reporting amounts are expected in the group presentation currency, but the package can retain transaction currency and submitted currency for explanation. Automated foreign-exchange translation is outside scope, yet currency differences can be identified as a reason category.
Account matching may use defined reciprocal pairs. Trade receivables match trade payables, loans receivable match borrowings, and intercompany income matches intercompany expense. Where local accounts differ, the group account mapping provides the common category.
The process should not automatically net unrelated balances. A receivable and payable may be legally or operationally distinct. The matching rule should follow the group's elimination policy and preserve categories required for notes.
A difference becomes manageable when it is classified. Timing differences arise when entities recognise the same transaction in different periods. Cut-off differences may require one entity to adjust. Currency differences arise from rates or remeasurement. Mapping differences occur when reciprocal amounts are reported in incompatible categories. Scope differences occur when one entity includes tax, freight or other components that the counterparty excludes.
Other categories include unrecorded transactions, disputed amounts, local statutory adjustments, consolidation-only entries and simple data errors. The entity should select a reason and provide an explanation and expected action. Free-text explanation alone makes group analysis difficult.
The system should identify which differences require entity correction before submission and which can be resolved through a group journal. A data-entry error should be corrected at source. A genuine cut-off difference may require an entity adjustment or a group entry depending on policy and timing. The resolution should be approved and documented.
Ageing the differences helps prioritise recurring issues. A difference carried over for several periods may indicate a process or dispute problem rather than a close timing issue. Dashboards should show old unresolved items and entities with repeated mismatches.
Comments should be exchanged within the match record. Each side sees the submitted balances, difference, attachments and proposed resolution. Owners and due dates make responsibility clear. The group team can intervene where entities do not agree.
A match should have statuses such as open, under entity discussion, proposed resolution, approved resolution, elimination proposed, journal posted and closed. Closure requires more than a comment; it should identify the action taken and the reviewer who accepted it.
Entity reviewers should certify that material intercompany balances are complete and counterparties are correctly identified. The group reviewer approves unresolved exceptions and elimination proposals. Segregation of duties prevents one preparer from both proposing and posting a material elimination.
The process should not encourage entities to force balances to agree without evidence. A match within tolerance may be automatically marked for low-risk review, but material balances and unusual categories still require assurance over completeness and classification.
The system can propose an elimination amount based on confirmed reciprocal balances and the group policy. The proposal identifies entities, counterparties, reporting concepts, amount, period and statement or note impact. It remains separate from the posted journal until approved.
Where balances differ, the proposed elimination may use the lower confirmed amount, the amount approved by the group or a corrected entity balance. The rationale should be explicit. The residual difference remains open or is addressed by a separate adjustment.
The posted journal should link back to the match records. Drill-down from the consolidated line shows the elimination and the underlying reciprocal submissions. This connects the operational resolution to the statutory result.
Note impacts should also be linked. Removing intercompany receivables from the balance sheet does not automatically remove them from ageing tables. The match data contains counterparty and category detail that can support note-level elimination.
Intercompany elimination affects more than receivables and payables. Revenue, costs, loans, interest, guarantees, commitments, cash flows, segments and related-party disclosures may require adjustment. The reporting model should identify which note schedules include intercompany dimensions.
Some group disclosures may still describe transactions with entities that are related parties but not eliminated because they are outside the consolidated group, such as associates or key management relationships. The system should distinguish consolidation counterparties from broader related parties.
The note aggregation rule may be "sum with eliminations," and the elimination can use matched balances. Where the note has different dimensions from the journal, a note-level adjustment is required and reconciled to the statement elimination.
For IFRS 18 or proposed Ind AS 118, intercompany income and expense eliminations can affect operating, investing or financing categories and defined subtotals. Category assignments should be consistent on both sides of the elimination, or the journal should document the group classification.
Matching analytics should show total submitted balances, matched amounts, differences, one-sided balances, items by reason, ageing and entity. The group can identify systemic issues such as cut-off delays, inconsistent mapping or poor counterparty tagging.
Recurring differences should lead to process changes. If one entity consistently records management fees a month late, the solution may be a common cut-off timetable. If currency differences are frequent, the group may need rate guidance. If mappings differ, the group account taxonomy should be clarified.
A close process improves when the number of manual elimination journals declines for avoidable reasons. The metric should not reward zero differences if entities are netting or omitting data. Completeness and evidence remain essential.
Predictive or AI-assisted suggestions can identify likely reason categories or matches, but they should not post eliminations. Human review is required because contractual and accounting facts may not be visible in the data.
The standalone reporting scope does not include group intercompany matching. It can collect related-party schedules and accept a pre-consolidated balance, keeping the single-entity workflow focused.
A proportionate group reporting design introduces balance-level matching after the core group process is stable. Entity packages collect reciprocal balances, the dashboard compares them, comments support resolution and approved proposals create journals. Invoice-level matching can remain a later enhancement.
The design integrates with account mapping, entity workflow, consolidation journals, group notes and source lineage. It is not a stand-alone reconciliation screen; it is part of the statutory reporting chain.
Entity A reports a Rs 75 million receivable from Entity B, while Entity B reports a Rs 72 million payable. The system matches the reciprocal records and shows a Rs 3 million difference outside tolerance. Entity B explains that an invoice received after local cut-off will be recorded in the next period.
The group decides that the transaction belongs in the current reporting period. Entity B reopens its package, records the adjustment and resubmits. The match then agrees at Rs 75 million. The system proposes the elimination, the group reviewer approves it and the journal is posted.
The linked note adjustment removes Rs 75 million from trade receivable and payable ageing. The final consolidated line drills to both entity submissions, the match discussion, the approved journal and the note adjustment. The resolution is complete and auditable.
Start with material balance sheet categories and a small number of entities. Standardise counterparty codes and reciprocal account pairs. Define tolerances, reason categories, due dates and escalation. Do not attempt invoice-level matching unless the business case and source data support it.
Pilot the process before year-end. Matching during monthly or quarterly closes helps identify master-data and cut-off problems. The annual close should not be the first time entities use the workflow.
Useful metrics include matched percentage, one-sided value, differences above tolerance, average resolution time, items by reason, repeat differences and eliminations posted without matched support. The objective is timely, evidenced resolution-not cosmetic agreement.
Balance-level intercompany matching is a pragmatic control for statutory group reporting. It provides visibility, accountability and evidence without the cost and complexity of invoice-level automation. It also creates the dimensions required to eliminate intercompany amounts from group notes, not only the face statements.
The process succeeds when matching is connected to entity submissions, mapping, journals and disclosures. A difference is not resolved until the underlying data, approved action, posted elimination and affected notes all agree. That end-to-end view is what turns intercompany reconciliation into a reliable part of the group close.
A controlled process begins with an explicit inventory of the data objects that drive group note aggregation. For this subject, the core objects are note templates and disclosure fields, entity disclosure facts, aggregation methods, group-only facts and conclusions, note-level adjustment journals, statement-note relationships, narrative blocks and variables, and note validation results and approvals. Each should have a business definition, source, owner, effective period, version, status and relationship to the reporting output. That metadata is what allows the team to distinguish a valid change in policy or business activity from an unexplained movement in a spreadsheet.
Evidence should be captured as part of the workflow rather than attached after the reviewer asks for it. Each note total should expose its entity facts, aggregation rule, note adjustments and related statement concept. A note-level adjustment should identify whether it reconciles to a statement journal or why a difference is appropriate. Any manual narrative overwrite should retain the original dynamic value, editor, reason and reviewer approval. For group note aggregation, the reviewer should be able to move from the reported result back through the decision, rule or mapping to the complete source population without changing systems or requesting an offline reconstruction.
A practical design workshop for group note aggregation should use one completed reporting period and one difficult entity or disclosure population. Bring together group reporting, entity finance, accounting policy, tax, treasury, investor relations, internal audit, external-audit liaison and technology as relevant. Reconstruct the path from source file or manual schedule to the final statement, note and approval. Mark every copied value, mixed account, offline adjustment, unversioned judgment, repeated reviewer query and late document edit. The purpose is to identify where the statutory fact or conclusion leaves the controlled model.
Test the proposed design against group notes are prepared by copying and summing entity tables without a field-level aggregation rule and narrative values are typed into text and remain unchanged after underlying facts or note numbers move. For each break, agree the accountable owner, preventive or detective control, source evidence, materiality or tolerance, reviewer, escalation route, affected reports and acceptance test. Assign structured company-level note schedules to the standalone foundation and introduce entity-to-group field-level aggregation methods only after the underlying concepts and evidence are stable. The output should be a prioritised backlog with rule, data, workflow and report-design decisions-not a generic list of desired features.
Official materials checked on 25 June 2026: IFRS Foundation - IFRS 18; issued IFRS 18 text; IFRIC Update - March 2026; ICAI Accounting Standards Board.
This article is educational and does not replace applicable standards, final MCA notifications, professional advice or entity-specific judgment. Product capabilities should be verified against the approved release scope before publication.
Explore how Repositora can connect entity submissions, group reporting, statutory notes, source lineage and Ind AS 118 transition readiness across standalone, group and transition reporting. Visit repositora.com
