Repositora AI - Ind AS 118 / IFRS 18
Knowledge Base
Disclosure & Lineage

Group Notes Aggregation: Turning Entity Schedules into Consolidated Disclosures

A framework for aggregating entity note schedules into group disclosures using explicit methods, eliminations, group-only conclusions and face-to-note reconciliation.

Group Notes Aggregation: Turning Entity Schedules into Consolidated Disclosures knowledge base article illustration
12
series article
17
article sections
Ind AS 118 / IFRS 18
reporting focus
Short Summary

Executive perspective

Consolidated primary statements can often be produced from a consolidated trial balance. Consolidated notes cannot. Notes require movements, maturities, counterparties, jurisdictions, segments, narratives and qualitative conclusions that are not contained in a single balance. As a result, group reporting teams collect dozens of entity schedules and manually combine them into disclosure workbooks.

The central problem is that not all note fields aggregate in the same way. Property, plant and equipment additions may be summed. Receivables may be summed and then reduced for intra-group balances. Subsidiary names form a distinct list. Basis of consolidation is a group-only narrative. Commitments may require entity detail plus a total. Going concern requires a manual group conclusion. Ratios may be calculated from final group facts.

A controlled group notes model assigns an aggregation method to every structured field. Entity submissions feed the group schedule, approved eliminations and adjustments are applied, and the final note reconciles to the related consolidated statement line. This makes notes part of the consolidation architecture rather than a separate document-production exercise.

Why notes are the real consolidation challenge

A statement line contains a total. A note explains its composition and movement. Two entities may use the same face classification but different detail structures. One subsidiary may classify debt by contractual maturity, another by current and non-current portions, and a third may omit covenant data. Summing the submitted tables will not produce a reliable group note.

Notes also contain information that must be eliminated differently from the face statements. Intra-group receivables must be removed from ageing buckets. Intra-group revenue must be removed from product or geography tables. Related-party disclosures must distinguish transactions eliminated on consolidation from relationships that remain reportable. PPE movements may require group adjustments for acquisition accounting.

Narratives introduce another risk. Entity policies and descriptions cannot simply be concatenated. The group needs one approved policy and a basis-of-consolidation explanation. Changes in group composition, business combinations and NCI require group-level information.

The notes process therefore needs data modelling, ownership and adjustment logic comparable to the primary statements. Treating it as word processing underestimates the accounting work.

Aggregation methods

"Sum" applies where entity values can be added without elimination, such as certain asset additions or employee counts, subject to consistent definitions. The system should still validate units, periods and classifications.

"Sum with eliminations" applies to receivables, payables, revenue, expenses, loans and other intra-group amounts. The final group value equals entity totals plus approved note eliminations. The elimination should link to the related consolidation journal or explain why the note scope differs.

"Distinct list" applies to subsidiaries, associates, related parties, locations or categories where duplicate names should appear once. The system needs stable identifiers and review of naming differences. A list is not complete merely because duplicates are removed; scope and attributes must be checked.

"Group-only" applies to basis of consolidation, group capital management and other disclosures prepared centrally. Entity packages may provide inputs, but the group owns the final fact or narrative.

"Entity detail plus total" presents the group total while retaining entity information, as may be useful for commitments, contingencies or jurisdictional tax. The note template controls whether entity detail is displayed or used only for support.

"No aggregation" applies to accounting-policy narratives and other text where one group conclusion is required. "Manual group conclusion" applies to judgements such as going concern. "Formula" applies to ratios, subtotals and maturity totals calculated from approved facts.

Designing structured note fields

Each field should have a reporting concept, data type, period, currency or unit, dimensions, source owner, aggregation method and validation. Dimensions may include entity, asset class, movement type, ageing bucket, counterparty, geography, segment, maturity band or related-party category.

The field should link to a statement line or another note where relevant. A PPE closing balance links to the balance sheet; depreciation expense may link to the profit-or-loss and specified expense schedule. Cross-note relationships can be validated.

Definitions must be consistent across entities. Ageing buckets, maturity bands and asset classes should be controlled by the group. Where local data uses different categories, the entity package should map to group categories. Free-form columns undermine aggregation.

Materiality can determine detail. The system may allow entity-specific rows while preserving a group taxonomy. A new material category can be proposed and approved rather than placed indefinitely in "other."

Note-level adjustments

A note adjustment changes a structured disclosure fact without necessarily changing the statement. It may allocate a statement elimination across ageing buckets, reclassify maturity categories, adjust a group movement table or remove intra-group related-party amounts.

Every adjustment should identify the note, field, dimensions, amount, period, reason, source journal or explanation, preparer, reviewer and status. Posted note adjustments affect the group note. Draft adjustments do not.

The system should validate the relationship between statement and note adjustments. If an intercompany receivable elimination is Rs 100 million, the ageing note adjustments should normally total Rs 100 million. A difference may be valid because of note scope, rounding or a separate item, but it requires explanation and approval.

Note adjustments should be visible in drill-down. A reviewer sees entity totals, eliminations, group-only entries and final amount. This prevents manual plugs from disappearing into a final table.

Group note templates

The group note architecture should include templates for subsidiaries, associates and joint ventures; basis of consolidation; changes in group composition; business combinations; goodwill and impairment; NCI; segment reporting; group related parties; intercompany eliminations; debt covenants; liquidity and maturity; revenue disaggregation; tax by jurisdiction or entity; commitments and contingencies; MPMs; and specified expenses by nature.

Templates should be structured but configurable. The group can add rows, suppress immaterial categories and reorder sections through the report composer. The underlying reporting concepts remain stable.

Narrative variables should insert company name, reporting date, currency, revenue, operating profit and other approved facts. When facts change, variables refresh. Manual overwrites are highlighted and require review.

The generic note builder remains important for uncommon disclosures. It should support user-defined rows and columns, formulas, narratives, attachments and links to statement lines while preserving version control.

Face-to-note reconciliation

Every note linked to a face line should reconcile after all entity and group adjustments. The system should show source entity total, note eliminations, other note adjustments and final note total beside the final statement amount.

Reconciliation should use full precision, with presentation rounding handled separately. Small rounding differences can be managed by controlled presentation logic, not hidden plugs. The validation should distinguish precision differences from substantive differences.

Some notes reconcile to multiple face lines or vice versa. Borrowing notes may cover current and non-current liabilities; tax notes may reconcile current and deferred components. The linkage model should support formulas and mappings rather than assuming one-to-one relationships.

Review should not stop at numerical agreement. The composition, comparative completeness, labels and disclosures must also be assessed. A reconciled note can still omit a material category.

IFRS 18 and proposed Ind AS 118 implications

Specified expense disclosures require companies presenting operating expenses by function to disclose amounts of depreciation, amortisation, employee benefits, impairment losses and inventory write-downs included in each applicable operating line. Entity schedules must therefore collect nature-by-function allocations that can be aggregated and reconciled to ledgers and notes.

MPM disclosures are usually group-only but require data from consolidated facts, tax calculations and NCI allocations. The MPM note should be generated from a structured register and reconciliation, not manually typed into the report.

Aggregation and disaggregation principles affect note design. Material items hidden in "other," dissimilar items combined in one row and inconsistent current-versus-comparative detail should be flagged. The group must decide where information belongs-face or note-based on the role of the primary statements and notes.

Revenue and expense classifications may differ across entities because of main-business-activity conclusions. Group note aggregation should use the approved group reporting concepts and overrides, ensuring consistency with the final profit-or-loss categories.

Workflow and ownership

Entity preparers complete applicable schedules and evidence. Entity reviewers approve them. Disclosure owners monitor the group note, resolve definition questions and prepare group-only content. Consolidation teams post eliminations and provide note impacts. Group reviewers approve the final note.

Review comments should attach to fields or rows. A note can have component statuses so that one unresolved schedule does not hide behind a general "in progress" label. The final report should not be generated while mandatory note validations or critical review points remain unresolved.

Reopening an entity package should identify affected group notes. If a receivable schedule changes, the ageing and credit-risk notes are marked for reperformance. This dependency management reduces the risk of stale disclosures.

Application in Repositora

For a single entity, Repositora makes notes central to the reporting process, with system-calculated, structured, narrative and hybrid types. It provides templates, applicability, tie-outs, variables and review.

For group reporting, Repositora adds entity-to-group aggregation, field-level methods, note eliminations, group-only conclusions and consolidated validations. It reuses the same note taxonomy for standalone and group packs, enabling consistent definitions and comparative roll-forward.

The product's value is not merely that it can render notes. It is that it can show how entity facts, eliminations and group judgements produced the final disclosure.

Group Notes Aggregation: Turning Entity Schedules into Consolidated Disclosures knowledge base article illustration
Group Notes Aggregation: Turning Entity Schedules into Consolidated Disclosures knowledge base article illustration

Illustrative note aggregation

A group has five subsidiaries with gross trade receivables of Rs 900 million. Entity schedules include ageing and counterparty tags. Rs 120 million is intra-group. The consolidated balance sheet shows Rs 780 million after elimination.

The group note uses "sum with eliminations." Entity ageing rows are aggregated, and note adjustments remove the Rs 120 million from the relevant buckets. The adjustment links to the statement elimination journal. The final ageing total agrees to Rs 780 million.

One subsidiary has Rs 25 million in a generic "other" bucket. The system flags it as material. The disclosure owner reviews the detail and creates a more informative category. The current and comparative note is updated, and the decision is approved.

Implementation guidance and metrics

Inventory the notes in the signed financial statements and classify every field by aggregation method. Identify source owners, dimensions, statement links and eliminations. This exercise often reveals why existing spreadsheet packages are difficult to maintain.

Pilot high-volume notes first: PPE, receivables, payables, borrowings, revenue, tax and related parties. Validate definitions with entities and auditors. Build group-only narratives after the structured facts are stable.

Useful metrics include note fields submitted on time, face-to-note exceptions, manual group totals, note adjustments without journal links, material "other" categories, reopened schedules and time from entity acceptance to note approval. These measures focus attention on disclosure quality.

Closing perspective

Group note aggregation is a distinct accounting process, not a formatting step. It requires explicit methods, consistent dimensions, controlled eliminations, group-only conclusions and reconciliation to final statements. When those elements are structured, the group can produce disclosures that are complete, traceable and easier to review.

The importance grows under IFRS 18 and proposed Ind AS 118 because the notes carry MPM reconciliations, specified expenses and disaggregation detail. A statutory reporting platform that governs notes from entity submission to final document solves one of the most persistent gaps in the group close.

Evidence architecture for implementation

A controlled process begins with an explicit inventory of the data objects that drive dual-basis reporting and transition readiness. For this subject, the core objects are reporting basis, regulatory rule pack, financial fact, presentation assignment, profit-or-loss category assignment, transition adjustment, comparative scenario, applicability evaluation, report version, and rule-pack change record. 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 transition difference should reconcile to approved facts and a specific rule or classification decision. Each report should identify whether it applies current Ind AS, proposed Ind AS 118 or IFRS 18 and the exact content version. Each rule-pack update should retain technical review, approval, effective date and impact assessment. For dual-basis reporting and transition readiness, 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

A practical design workshop for dual-basis reporting and transition readiness 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 future presentation is created by copying and manually editing the current statutory workbook and rule-pack changes are published without identifying affected mappings, notes, policies and validations. 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 current notified Ind AS and Schedule III Division II reporting to the standalone foundation and introduce current Ind AS, proposed Ind AS 118 and IFRS 18 views from the same fact population 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.

Technical Source Note

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.

Suggested Website CTA

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

Contact

Take this reporting issue into a focused implementation conversation.

Start with this article topic, or move straight into entity packages, mapping, consolidation evidence, group notes, transition views, and final report governance.

Entity-package design, mappings, and group-close hand-offs
Consolidation evidence, note logic, and transition reporting scenarios
Maker-checker approval, report composition, and immutable output governance
Group Notes Aggregation: Turning Entity Schedules into Consolidated Disclosures | Repositora AI - Ind AS 118 / IFRS 18