Why Pillar Two Is a Data Problem Before It Is a Calculation Problem

Pillar Two is often presented as a complex tax calculation. In practice, that is only part of the story. The harder problem is often whether the organisation can produce the required inputs in a consistent, supportable, and repeatable way.

The rule logic is demanding, but it is structured. Once the inputs are available, the harder problem is usually no longer the formula. It is whether the organisation can produce those inputs in a consistent, supportable, and repeatable way.

That is where many Pillar Two projects slow down.

The real implementation pressure tends to emerge not in the calculation itself, but in the work required to source, align, adjust, and govern the underlying data. OECD guidance on the GloBE Information Return points in the same direction: groups need accounting systems and processes that can support jurisdictional reporting, identify relevant adjustments, and maintain contemporaneous supporting information, even where transitional simplifications are available.

The Formula Is Only One Part of the Problem

At a high level, the Pillar Two process follows a defined sequence:

• determine GloBE income or loss
• determine adjusted covered taxes
• calculate the jurisdictional ETR
• compute and allocate top-up tax

That sequence is not the main source of implementation difficulty.

The problem is that the required inputs do not usually exist in one place, in one format, or under one owner. Producing them in a way that can withstand review is often harder than applying the calculation itself.

Where the Real Problem Sits

The pressure in Pillar Two implementation emerges in the data layer.

Fragmented source data

The inputs required for Pillar Two rarely sit in a single system.

They are typically spread across:

• financial consolidation systems
• local statutory accounts
• tax reporting tools
• manual files and workpapers

Each source reflects a different purpose, a different level of granularity, and often a different definition of income or tax. Bringing them into a single jurisdictional view requires reconciliation, not just extraction.

Inconsistent ownership

Pillar Two does not sit neatly within one function.

• Tax teams understand the rules.
• Finance teams own much of the underlying data.
• IT teams manage the systems and data flows that support reporting.

In many groups, no single team owns the end-to-end process.

That creates predictable problems:

• data is extracted differently across jurisdictions
• adjustments are applied inconsistently
• validation responsibility is unclear
• issues sit in the gaps between functions

Without clear ownership, the process does not stabilise.

Local adjustments and interpretation

Moving from accounting data to GloBE-ready inputs requires adjustments.

Those adjustments are often not system-driven. They sit in local processes and may include:

• deferred tax adjustments
• local accounting-to-GloBE treatments
• reclassifications
• intra-group positions
• manual overlays needed to align with group methodology

These adjustments are necessary, but they introduce variability. They also create dependence on local interpretation, which makes consistency harder to maintain across the group.

Lack of audit trail

Pillar Two is not just about producing a number. It is about being able to support that number.

Groups need to explain:

• how GloBE income was derived
• how covered taxes were adjusted
• how the jurisdictional ETR was calculated
• how manual adjustments were identified and reviewed

Where calculations rely on multiple systems and local workarounds, the audit trail quickly becomes fragile.

System limitations

Most existing systems were not built for Pillar Two.

They were built for:

• financial reporting
• statutory tax compliance
• management reporting

Pillar Two cuts across all three.

As a result:

• required data fields may not exist
• jurisdictional aggregation may not align with system structures
• adjustments may need to be layered outside core systems
• entity-level traceability may be weak even where jurisdiction-level reporting looks manageable

Pillar Two often exposes the gap between systems designed to record transactions and processes needed to defend a jurisdictional tax position.

A Practical Way to Approach Data Assessment

This is where many groups need a more practical assessment methodology.

A useful Pillar Two data assessment should not begin with a long theoretical list of data points. It should begin with a smaller set of operational questions.

1. Can the group identify the source of each critical input?

Not in general terms, but in working terms.

Which system, report, file, or local process produces the number? If the answer is "the local team can provide it" or "it should be somewhere in the consolidation pack", that is not yet a controlled source.

2. Can the data be produced at the level Pillar Two actually requires?

Some groups can produce high-level jurisdictional data reasonably well, but struggle once items need to be traced to specific entities, permanent establishments, or adjustment categories.

That distinction matters. OECD GIR guidance also reflects that, during the transitional period, simplified reporting may still sit on top of underlying calculations that need to be performed with sufficient discipline at the relevant level.

3. Can the group explain the adjustment layer, not just the starting numbers?

The starting point is rarely the hardest part.

The harder issue is the adjustment layer:

• what has been changed
• why it has been changed
• who made the change
• whether the treatment is applied consistently elsewhere

This is often where implementation risk actually sits.

4. Can the process be repeated under time pressure with a clear audit trail?

A process is not ready because one workbook can be completed once.

It is ready only when the data can be sourced, adjusted, reviewed, and explained repeatedly across reporting periods, with enough structure to survive staff turnover, timing pressure, and follow-up questions.

What a Practical Assessment Should Test

In my view, a practical Pillar Two data assessment should test five things:

Source

Where does the data come from?

Granularity

Does it exist at the level Pillar Two actually needs?

Ownership

Who provides it, validates it, and signs off on it?

Adjustment logic

What needs to happen before it becomes GloBE-ready?

Evidence

How will the result be explained and supported later?

That is why a good data assessment is not just a data inventory exercise. It is closer to an operational stress test.

Its job is not only to confirm whether data exists. Its job is to show where the process will break, where manual dependency is too high, and where future control design or automation effort should focus.

Why This Changes the Implementation Approach

If Pillar Two is treated mainly as a calculation problem, the natural instinct is to design the model first.

In practice, that often leads to rework.

A more effective starting point is to understand:

• where the required data sits
• how it is currently produced
• what adjustment layer is needed
• which parts are manual
• who is responsible for each component
• how the result will be supported

Only once that is clear does the calculation design become truly meaningful.

What This Means in Practice

Data readiness comes first

Before building calculation models, groups need to assess whether they can produce:

• GloBE income on a jurisdictional basis
• adjusted covered taxes
• consistent ETR calculations
• supporting information that can withstand review

That is the real starting point.

Process repeatability matters more than one-off completion

Pillar Two is not a one-time exercise.

The process needs to be repeatable across reporting periods. That requires:

• consistent definitions
• controlled adjustments
• clear ownership
• documented support

Timelines are driven by data, not just rules

The rules are already defined.

What takes time is:

• mapping source data
• aligning systems
• clarifying ownership
• designing the adjustment layer
• building enough control and documentation around the process

This is why implementation timelines are often underestimated when the discussion stays too close to the calculation.

Bridge to Data Readiness

This is where the next layer of work begins.

The key questions are no longer only: how is top-up tax calculated?

They become:

• where does the data come from
• how reliable is it
• how is it adjusted
• who owns it
• how is it evidenced

Those are data readiness questions.

They sit at the centre of any workable Pillar Two implementation approach, and they are the reason this topic deserves its own pillar rather than a passing mention in a technical rules discussion.

Conclusion

Pillar Two is often presented as a technical tax calculation.

In practice, the calculation is the visible part of a deeper implementation problem.

The real constraint is whether the organisation can source, adjust, govern, and evidence the data needed to support that calculation in a repeatable way. That is also consistent with the direction of OECD reporting guidance, which places real weight on process, supporting information, and the ability to produce defensible GloBE data under operating conditions.

For multinational groups, the implication is straightforward: understanding the rules is necessary, but it is not enough. The harder question is whether the data needed to apply those rules actually exists in a usable form.