Adjustment Ledgers for Pillar Two: How to Track GloBE and Covered Tax Adjustments

Repeatable GloBE reporting depends on more than a calculation model. It needs a structured adjustment ledger that shows what changed, why it changed, who owns it, and what evidence supports it.

Why Adjustment Ledgers Matter

Pillar Two reporting often starts with accounting data, but it rarely ends there.

To produce GloBE income, adjusted covered taxes, and jurisdictional outputs, groups usually need to apply a series of adjustments. Some are rule-driven. Some arise from differences between accounting, consolidation, local tax, and reporting definitions. Some are temporary workarounds while systems mature.

The problem is not that adjustments exist. The problem is when they are managed as disconnected spreadsheet tabs, local notes, or individual judgement calls.

• the same adjustment may be applied differently across jurisdictions
• reviewers may not know whether the treatment has changed
• evidence may sit outside the reporting process
• manual work may become embedded without an automation path
• future periods may depend on the memory of one preparer

An adjustment ledger solves a practical governance problem. It gives the group a single, controlled place to track the movement from source data to GloBE-ready data.

What the Ledger Should Track

A useful adjustment ledger should be simple enough to maintain and structured enough to support review.

At minimum, it should track:

• the entity, jurisdiction, and reporting period
• the source system or workpaper used
• the original account, line item, or data field
• the adjustment category and GloBE treatment
• whether the adjustment affects GloBE income, covered taxes, deferred tax, or another input
• the adjustment amount and direction
• the rationale for the treatment
• the evidence reference
• the preparer, reviewer, and approver
• the status of review, control, and automation

This does not mean every group needs a sophisticated tool on day one. The important point is that the ledger should be designed as a repeatable control record, not just as a calculation tab.

Ownership and Review

Adjustment ledgers work only when ownership is explicit.

In many multinational groups, the information needed to support a GloBE or covered tax adjustment sits across tax, finance, consolidation, local controllers, and sometimes technology teams. A ledger should make this visible.

For each recurring adjustment, the group should know:

• who prepares the amount
• who validates the source data
• who owns the technical treatment
• who reviews consistency across jurisdictions
• who approves changes to methodology

Without this structure, the adjustment process can become a hidden dependency. The calculation may still run, but the group may struggle to explain whether the treatment was applied consistently or reviewed by the right people.

Evidence and Control Status

The adjustment ledger should also function as an evidence map.

For a recurring covered tax adjustment, for example, the ledger should point to the source schedule, explain how the amount was derived, show who reviewed it, and identify whether the evidence is retained centrally or locally.

A practical status model can be simple:

• draft: treatment identified but not reviewed
• approved: treatment reviewed and accepted
• evidenced: supporting documentation retained
• controlled: preparation and review steps are embedded in the close process
• automated: source, logic, and posting are system-supported

This helps teams avoid a common problem: treating every adjustment as complete simply because it has been included in the calculation. Inclusion is not the same as readiness.

Automation Readiness

The ledger should also show which adjustments are candidates for automation.

Not every adjustment should be automated immediately. Some may depend on judgement, policy interpretation, or local facts that are still being stabilised. Others may be recurring, rules-based, and suitable for system logic once the source data is reliable.

A useful ledger can classify adjustments by automation status:

• manual and temporary
• manual but recurring
• partially system-supported
• ready for automation
• automated with review control

This classification gives technology and process teams a realistic roadmap. It also prevents the group from trying to automate unstable treatments before the underlying ownership, evidence, and logic are mature.

Practical Design Principles

The best adjustment ledgers are not overly complicated. They are disciplined.

In practice, a multinational group should design the ledger around a few principles.

• Use consistent adjustment categories across jurisdictions.
• Separate GloBE income adjustments from covered tax adjustments.
• Capture both the amount and the reason for the treatment.
• Link every material adjustment to evidence.
• Assign ownership at the adjustment level, not only at the entity level.
• Track whether the adjustment is recurring or one-off.
• Maintain status fields for review, control, and automation.
• Keep the ledger close to the reporting process so it is updated every period.

The objective is not to create documentation after the fact. The objective is to make the adjustment process itself visible, reviewable, and repeatable.

Conclusion

Pillar Two adjustments are where technical requirements meet operating reality.

If they are tracked informally, the group may be able to complete an initial calculation but struggle to repeat it under reporting deadlines, answer review questions, or move toward automation.

A structured adjustment ledger gives tax, finance, local controllers, consolidation teams, and technology teams a common operating record. It shows what changed, why it changed, who owns it, what evidence supports it, and whether the process is ready to scale.

For multinational groups, this is a practical foundation for repeatable GloBE reporting. The ledger turns adjustment logic from scattered knowledge into a controlled part of the reporting model.