Group reporting

Late entries after group reporting sign-off

Sumledger · September 22, 2026

The group report has been approved. Then a subsidiary posts an invoice to the period already reported. Which version now applies, and who decides whether the report needs to be reissued?

Sumledger editorial hero about late entries after group reporting sign-off. Preserve the basis, explain the change, record the decision.

The group report has been approved. Then a subsidiary posts an invoice to the period already reported. Which version now applies, and who decides whether the report needs to be reissued?

Here, a late entry means an entry that reaches the reporting data after a particular report version has been approved. It is not necessarily posted to the wrong period. The control question is whether it changes the figures or explanations recipients have already received.

For private groups with several entities and accounting systems, the answer should be a simple change process: preserve the approved basis, identify the difference, assess its effect, repeat the relevant checks and record the decision. Do not overwrite the report before someone has assessed what actually changed.

An approved report and an updated ledger are different things

Approval applies to a particular set of data at a particular time. A new extract may contain additional entries, changed posting status or revised mapping. Using the same entities and period does not ensure that two reports use identical data.

Distinguish three points: the accounting period to which the entry belongs, the time the data was retrieved and the time the report was approved. Record the report version and entity scope too. The controller can then investigate a change without first reconstructing the entire close.

A locked period in one accounting system does not mean group reporting is locked. Other entities may still make corrections, and group adjustments may sit outside local ledgers. Local period close and group report approval need clear, separate owners.

A practical scenario: the intercompany invoice arrives later

This is an illustrative scenario, not a customer case. The CFO has approved the monthly report. The receiving entity then posts an intercompany invoice to the reported period. The issuing entity’s income was already included in the approved data.

The controller should not simply add the difference as a new elimination. First establish whether the expense was already accrued, whether the counterparty is correctly identified and whether the existing elimination covers some or all of the transaction. Otherwise, an apparently simple correction can duplicate an expense or create an incorrect elimination.

The check therefore follows both entities: original income, any accrual, the new invoice and the previous group adjustment. Only once that relationship is explained can the controller calculate the change to group profit and the balance sheet. The local movement and the group effect are not necessarily the same amount.

1. Preserve what was actually approved

Keep the report version and enough supporting data to verify it. Record entity scope, period, currency, extraction time, posting status and relevant mapping and elimination assumptions. Preserve the comments explaining variances at sign-off.

This does not have to start with a new system. A controlled archive with named versions and a simple change log can be sufficient for a small process. The point is that the next refresh must not erase the basis on which the CFO made a decision.

Clarify who can update working data and who can approve a new report version. These are different actions. If the reporting tool does not retain the history you need, your process must provide it separately.

2. Identify the difference before explaining it

Compare the new data with the approved version by entity and account, then by relevant dimensions and transactions. First check that the filters match. Different posting statuses or entity selections can look like an accounting change without actually being one.

Classify genuine changes: new entry, amended or reversed entry, changed mapping, or changed group adjustment. Moving an account between report lines should not be described as new business activity. Also distinguish changes to source data from changes to calculation logic.

Assign a named owner to each exception. The local accounting lead explains the source entry; the group controller assesses the reporting consequences. The CFO determines further action within the group’s approval authority and reporting procedures.

3. Assess the consequence, not just the amount

A small amount can matter if it changes a KPI explanation, affects an intercompany counterparty or exposes a systematic error. A larger amount may already be covered by a documented accrual. Assess the amount, its nature and how the recipient uses the report.

Apply the group’s agreed materiality thresholds and internal reporting requirements. This process does not prescribe a universal amount, nor does it replace accounting judgement or requirements for statutory reporting.

Record one of three outcomes: no effect on the approved report, exception recorded without redistribution, or a new report version required. Even a decision not to reissue needs a brief explanation and an accountable owner.

4. Repeat the affected checks

A late entry can affect more than the report line where it first appears. Check relevant counterparties, accruals, eliminations, currency assumptions and KPIs. The scope should follow the change, not an automatic rule to restart the entire close.

For intercompany entries, understand both sides before updating the elimination basis. Identifiable counterparties, accounts, dimensions or other source-data markers make that control possible. An integration alone does not establish what an entry means for the group.

Correct source errors where they belong and document specific group adjustments separately. Avoid an unexplained adjustment in the report file simply to bring the total back to the previously approved figure. The objective is correct, explainable reporting, not an unchanged number.

5. Make the decision clear to recipients

If the report must be reissued, assign a new version and state what it replaces. Explain which figures or comments changed, why they changed and who approved the new version.

Do not rely on a shared link with continuously changing numbers as the only record of what the board or management received. Recipients must be able to distinguish the earlier report from the current one. Retain history according to the group’s procedures.

A change log you can start using

Use these fields in your next month-end close:

  • Approved report version, period and extraction time.
  • Affected entity, account, dimension and journal reference.
  • Change type and explanation from the source-data owner.
  • Local and group effects, including relevant eliminations.
  • Checks repeated and available supporting evidence.
  • Decision, rationale, approver and date.
  • Replacement report version and recipients, if reissued.

Start with one closed period and test the process on a known exception. Can another controller follow the explanation without a verbal walkthrough? If not, the missing piece is usually a clear version, a source reference or a decision owner.

When is Excel enough, and when do you need a control layer?

Excel can be sufficient when a small team handles a few changes with consistent version control. That changes when multiple entities and accounting systems turn comparison, mapping and explanation into recurring manual work.

Sumledger is a shared financial control layer across entities and ERP systems, supporting group reporting, consolidation and analysis into available underlying data. Confirm which data and voucher attachments your systems make available. The process above is a working method, not a claim that Sumledger includes built-in version locking, alerts or approval workflows.

Read eight checks before sign-off and from system integration to an explainable group number.

Want to see where a shared control layer fits into your reporting? Book a short demo and bring a specific exception from your last month-end close.

Take control of your group reporting data

See how a shared control layer can support reporting and explanation across your entities.

Book a short demo

Read next

Related articles

Sumledger blog hero showing eight checks a CFO should complete before group reporting sign-off.
Group reportingSumledger

Group finance reporting: 8 checks before sign-off

A practical CFO and controller sign-off: eight checks that make group numbers comparable, traceable and explainable.

Sumledger blog hero about five control steps from system integration to an explainable group number.
Financial controllingSumledger

From system integration to an explainable group number

Five control steps that make ERP data comparable, reconciled and explainable in group reporting.