A group close is only as reliable as the entity submissions on which it is built. Yet many reporting packages are designed as large spreadsheets rather than as controlled processes. The parent circulates a workbook, subsidiaries populate it using local interpretations, files are returned by email, and the group team spends days identifying missing schedules, mismatched versions and unexplained changes. The spreadsheet may contain useful data, but it does not establish who prepared the submission, what validations were passed, which evidence supports the numbers or whether the entity reviewer accepted the package.
A controlled entity reporting package is a released set of data, schedules, questions, evidence requests and certifications linked to a specific entity, reporting period and rule-pack version. It is not merely a template. It defines what the entity must provide, how the information will be validated, who may prepare and approve it, when the group may accept it and under what conditions it can be reopened. The package creates a formal boundary between entity responsibility and group responsibility.
This boundary is especially important for IFRS 18 and proposed Ind AS 118 readiness. Profit-or-loss category assignments, main-business-activity questions, specified expense allocations, MPM inputs and disaggregation assessments may require information that is not visible in the trial balance. If the group requests those inputs informally after the close, answers will be inconsistent and difficult to audit. Embedding them in the controlled package makes transition work part of the reporting cycle.
The package should collect enough information to prepare the entity and group financial statements without turning every subsidiary into a miniature consolidation department. The entity is responsible for the completeness and accuracy of its local balances, statutory adjustments, schedules and explanations. The group is responsible for the group reporting taxonomy, consolidation methodology, eliminations, group-only conclusions and final statutory presentation.
This division prevents two common problems. First, the group should not have to reconstruct local accounting from raw files. An entity that submits a trade receivable total should also provide the structured ageing, related-party identification and intercompany counterparty information required for group disclosures. Second, the entity should not be asked to decide group-only matters, such as the final group MPM definition or whether an investment activity is a main business activity at the consolidated level.
A successful package also reduces ambiguity. Each requested field should have a definition, data type, period, currency, source expectation, aggregation method and validation rule. Narrative questions should state the decision required and provide relevant guidance. Supporting evidence requests should specify acceptable documents and due dates. When package design is precise, the group spends less time interpreting what subsidiaries meant and more time reviewing the substance.
The trial-balance component should use a controlled template or reusable import profile. At minimum it captures account code, description, signed amount or debit and credit, current and comparative period, entity, currency and optional dimensions such as department or segment. The package should identify whether the balances are local ledger amounts, locally adjusted statutory amounts or already translated group-currency amounts. The group reporting model should require foreign-currency entities to submit balances already translated into the group presentation currency because automated translation is outside the scope described here.
The mapping component should show the entity's local accounts and the inherited group mappings. New or unmapped accounts require action. Local overrides should be permitted only with a reason, effective period and reviewer approval. The entity should be able to see the reporting concept and related note impact so that mapping is treated as a reporting decision rather than a data-entry chore.
The note-schedule component should include structured templates relevant to the entity. Examples include property, plant and equipment movements, receivable and payable ageing, borrowings, lease liabilities, revenue disaggregation, commitments, contingencies, tax, related parties and segment information. The package should not send every possible schedule to every entity. Applicability rules and group instructions should determine the required content.
The intercompany component should collect reporting entity, counterparty, account, transaction category, receivable or payable, income or expense, amount, currency, difference explanation and resolution status. Balance-level detail is sufficient for the group reporting workbench. Invoice-level matching can remain outside scope. The purpose is to allow reciprocal comparison and controlled elimination, not to build a transaction-processing system.
The narrative and questionnaire component should request information that cannot be derived from balances. This may include going-concern matters, covenant breaches, litigation, events after the reporting period, changes in accounting policy, unusual transactions and proposed Ind AS 118 classification questions. A main-business-activity questionnaire can ask whether the entity invests in assets or provides financing to customers as a main business activity and whether the conclusion differs from the group view.
The evidence and certification component should identify required attachments and representations. Evidence may include legal confirmations, debt agreements, board minutes, tax reconciliations and impairment assessments. The certification checklist should require authorised entity personnel to confirm completeness, mapping review, reconciliation, intercompany identification, disclosure submission and communication of subsequent changes.
A status should reflect a real control state. "Not opened" means the package has been released but no work has begun. "In progress" indicates that the entity is preparing data. "Validation failed" means required checks have not passed and submission is blocked. "Submitted" is a representation by the preparer that the package is ready for entity review. "Under entity review" identifies active reviewer responsibility.
"Approved by entity" means the designated entity reviewer has accepted the submission. It does not mean the group has accepted it. The group may identify mapping, intercompany or disclosure issues and return the package. "Accepted by group" means the package is available for group aggregation and statutory reporting. "Locked" means changes are prevented except through a controlled reopening process.
The status flow should be enforced by permissions. A preparer should not approve their own package. An entity reviewer should not post group consolidation journals. The group should not silently change entity facts after acceptance. If a correction is needed, the package should be reopened or a separately identifiable group adjustment should be posted, depending on the nature of the change.
Statuses must also be visible at the component level. A package may be broadly complete while one note remains under review. The dashboard should show trial balance, mapping, note schedules, intercompany, questionnaires, evidence and certification separately. This helps the group identify the real bottleneck rather than relying on a single percentage complete.
The entity should see validation results before it submits. Basic checks include a balanced trial balance, duplicate and blank account codes, invalid amounts, missing comparatives, unexpected signs, unmapped material accounts and changes from the previous upload. Schedule checks should test totals against mapped statement lines, opening-to-closing movements, ageing totals, current and non-current splits, and required dimensions.
Validation should distinguish errors from warnings. An unbalanced trial balance or missing mandatory schedule may block submission. A material current-versus-prior movement may require an explanation but not prevent submission once the explanation is provided. A new account mapped differently from a similar account in another entity may be a group-review warning. The severity model should be configurable and linked to materiality.
The system should retain validation results by package version. If the entity replaces an upload, the prior results remain available for audit. The new upload should be compared with the previous one, showing changed rows and material impacts. This prevents a late replacement file from entering the group close without focused review.
For proposed Ind AS 118, package validations can flag unclassified income and expense concepts, accounts containing mixed categories, material "other" balances, missing specified expense allocations and inconsistent entity classification. These flags support review; they should not make the accounting judgement automatically.
Late changes are inevitable, but uncontrolled late changes are not. Once a package is accepted by the group, reopening should require a reason, authorised approver, date and time, and identification of the affected reports. The system should show whether the change affects aggregation, consolidation journals, notes, transition analysis or a generated report snapshot.
The reopening process should create a new package version. The prior accepted version remains available. The entity makes the correction, reruns validation, obtains entity approval and resubmits. The group then reviews the delta rather than repeating the entire review. Any dependent tasks should be marked for reperformance. If the change affects an already approved final report, a new report version is required.
Some changes are better handled as group adjustments. If the local books are closed and the issue is a group-only presentation reclassification, a controlled consolidation journal may be more appropriate than reopening the entity package. The policy should define when to correct at source and when to adjust at group. The key is transparency: the final amount must show whether it comes from the entity or a group adjustment.
Entity packages should support comments and queries attached to specific fields, schedules or validations. A group reviewer can ask why a receivable is classified as non-current, and the entity can respond with evidence in the same context. This is more effective than email because the query remains linked to the fact and package version.
Collaboration should not blur accountability. The entity preparer owns the response, the entity reviewer confirms it, and the group reviewer decides whether the package can be accepted. Comment closure should require a resolution and reviewer confirmation. A discussion thread alone is not evidence that the issue was resolved.
Disclosure owners may need access across entities for a particular note, such as tax or pensions. Section-level permissions allow them to review assigned schedules without seeing unrelated data. External auditors can receive read-only access and raise queries, while posting and approval remain with management.
At the entity level, Repositora provides the essential building blocks: trial-balance import, mapping, adjustments, structured notes, disclosure checklist, preparer-reviewer workflow and locked outputs. These capabilities establish the data and control discipline needed for a reporting package.
For multiple entities, Repositora packages those capabilities into a controlled group process. The group administrator can release standardised but entity-specific packages, monitor status, compare submissions, enforce certifications and accept data into the group process. Reusable import profiles accommodate different source systems while preserving a common output model.
The design should allow entities to reuse prior-period mappings and narratives, but it should reset evidence and approvals. It should also support group instructions and versioned amendments. When a package template changes after release, affected entities need a visible notice and the system should identify whether completed work must be revisited.
Consider a parent with five subsidiaries. The group releases packages six weeks before year-end. Each package includes a trial-balance profile, local mapping review, PPE and receivable schedules, intercompany balances, commitments, related parties, a main-business-activity questionnaire and certification. One financing subsidiary receives additional questions because it provides financing to customers as a main business activity.
Subsidiary A uploads its trial balance and receives three errors: an imbalance caused by a sign convention, two unmapped accounts and a missing comparative. After correction, the package passes core validation. The receivable schedule does not reconcile by a material amount, so submission remains blocked. The entity fixes the schedule and submits. Its reviewer asks for evidence supporting a covenant classification, then approves the package.
The group identifies that one revenue account is mapped differently from the same business activity in another subsidiary. The package is returned with a mapping query. After approval of the override, the group accepts and locks the package. Later, a legal settlement is recorded. The entity requests reopening, the controller approves the request, the package is versioned and the affected contingency note and profit-or-loss classification are flagged for reperformance.
Design the package from the final reporting requirements backwards. List each statement line, note, group conclusion and validation, then identify which entity facts are needed. Avoid asking entities for data that the group does not use. Every field increases preparation and review effort, so each should have a purpose.
Pilot packages with entities of different maturity and systems. Observe where definitions are misunderstood, where data is unavailable and where validations create false positives. Refine guidance and materiality thresholds before broad rollout. Training should explain the reporting purpose of each schedule rather than only how to populate the form.
Useful metrics include packages opened on time, validation errors per entity, average resubmission count, time in entity review, time from entity approval to group acceptance, late reopenings, unresolved intercompany differences and fields completed through manual overrides. Trends reveal which entities need process support and which package requirements need redesign.
A controlled entity reporting package turns the group close into a series of explicit representations. The entity confirms its balances, mappings, schedules and disclosures; the group confirms acceptance and performs group-only work. Statuses, validations, evidence and reopening controls make that responsibility visible.
For IFRS 18 and proposed Ind AS 118, packages provide the mechanism for collecting the judgements and dimensions that a trial balance alone cannot supply. They also establish a repeatable path for comparative and transition data. The group gains more than standardisation: it gains a reliable, auditable contract between local finance and group reporting.
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
