What a Pillar Two Data Assessment Should Actually Cover

A Pillar Two data assessment is often treated as a high-level mapping exercise. In practice, that is not enough. A useful assessment tests whether the organisation can produce GloBE inputs in a consistent, supportable, and repeatable way.

A Pillar Two data assessment is often treated as a high-level mapping exercise.

In practice, that is not enough.

The purpose of the assessment is not simply to identify where data exists. It is to determine whether the organisation can produce the inputs required for GloBE calculations in a consistent, supportable, and repeatable way.

That means going beyond system lists and into how data is created, adjusted, governed, and evidenced across jurisdictions.

A good assessment does not just answer whether the data exists.

It answers whether the data can actually support Pillar Two reporting in practice.

What the Assessment Is Trying to Answer

At a minimum, a Pillar Two data assessment should answer four practical questions:

• where the required data sits
• how that data is produced
• what adjustments are required before it becomes GloBE-ready
• who is responsible for each step

If any of these remain unclear, the assessment is incomplete.

In practice, the assessment should also test a fifth question:

• whether the process can be repeated under reporting timelines with a workable audit trail

That is the difference between a useful assessment and a theoretical one.

The Core Areas the Assessment Should Cover

A structured Pillar Two data assessment should cover five areas.

1. Source data and system mapping

The first step is to identify where relevant data originates.

This typically includes:

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

The point is not just to list systems. It is to understand:

• which source is the source of record
• which sources are supplementary
• where data is extracted from
• where aggregation takes place
• where data is already transformed before tax teams see it

This creates the baseline view of how jurisdictional data is actually constructed.

A weak assessment stops at "these are the systems involved."

A stronger one asks:

• which system actually drives the number
• whether that source is stable
• whether the extraction is repeatable
• whether there is dependence on local manual intervention

2. Data definitions and alignment

Pillar Two does not use data exactly as it appears in standard financial reporting.

The assessment therefore needs to identify:

• how accounting income maps to GloBE income
• how tax expense maps to covered taxes
• where definitions diverge across jurisdictions
• where group methodology needs to override local treatment

This is where many implementation issues start to appear.

Two jurisdictions may use similar source systems and still produce data that behaves differently because:

• accounting policy application differs
• tax reporting conventions differ
• local interpretation differs
• the same label means different things in practice

A proper assessment should therefore test not only whether a number exists, but whether it means the same thing across the group.

3. Adjustment requirements

This is usually where the real implementation pressure begins.

Moving from accounting data to GloBE-ready inputs requires an adjustment layer. The assessment should identify:

• which adjustments are needed
• where those adjustments are currently performed
• whether they are system-driven or manual
• whether they are standardised across jurisdictions
• whether they can be traced and reviewed later

Typical areas include:

• deferred tax adjustments
• reclassifications
• alignment of local accounting treatments
• intra-group positions
• other manual overlays needed to move from accounting outputs to Pillar Two inputs

This matters because an organisation may appear data-ready at the source level, but still be heavily dependent on uncontrolled adjustment logic.

That is not a stable reporting process.

4. Data quality, granularity, and availability

The existence of data does not mean the data is usable.

The assessment should evaluate:

• whether the required data is available at the right level of granularity
• whether it is complete across jurisdictions
• whether it is consistent period to period
• whether it can be produced within reporting timelines
• whether it can be tied back to a reliable supporting source

This is often where false confidence gets exposed.

A group may be able to produce a number for modelling purposes, but still struggle to:

• reproduce it consistently
• break it down to the required level
• support it under review
• deliver it on time

Data that exists but cannot be produced reliably does not support a repeatable Pillar Two process.

5. Ownership and process mapping

A Pillar Two data assessment is not complete without process ownership.

For each major component, it should be clear:

• who extracts the data
• who performs the adjustments
• who validates the output
• who reviews exceptions
• who signs off at group level

This is especially important because Pillar Two usually cuts across tax, finance, consolidation, and sometimes IT.

If ownership is vague, the process becomes fragile very quickly.

In practice, this is where delays, duplication, and inconsistent treatment often start.

The assessment should not just record names. It should map the operating process:

• what happens
• in what sequence
• by whom
• using what source
• with what evidence

That is what turns a data assessment into something useful for implementation planning.

What a Practical Assessment Methodology Looks Like

A practical Pillar Two data assessment should not try to solve everything in one pass.

A better approach is to assess each major data area across a small number of dimensions.

For each input or adjustment area, ask:

Source

Where does the number come from?

Definition

What exactly does it represent, and is that definition consistent across jurisdictions?

Transformation

What happens to the number before it becomes GloBE-ready?

Owner

Who is responsible for producing and validating it?

Evidence

How would the group support it later?

This is usually a better methodology than trying to start with an overly detailed data-point inventory alone.

The point is to identify where the process is stable, where it is manual, and where it is dependent on local interpretation.

That gives the organisation a much more realistic basis for prioritising remediation.

What an Incomplete Assessment Looks Like

In practice, many early assessments fall short in predictable ways.

Common patterns include:

• high-level system inventories without real data flow mapping
• assumptions that accounting data can be used without further adjustment
• limited visibility over local processes
• no distinction between system data and manual overlays
• unclear ownership across functions
• no view of whether the process can be repeated under reporting timelines

These issues do not always appear immediately.

They tend to become visible later, when the organisation attempts to run a full calculation and discovers that key parts of the process rely on local memory, spreadsheets, or inconsistent assumptions.

What a Complete Assessment Enables

A well-executed Pillar Two data assessment provides a much clearer view of:

• which data can be used as-is
• where definitions are inconsistent
• where adjustments are required
• where system limitations exist
• where manual processes need to be controlled
• where ownership needs to be clarified

That allows the organisation to:

• prioritise remediation logically
• separate short-term workarounds from long-term design
• build a more realistic implementation plan
• reduce rework later in the process

A strong assessment does not eliminate complexity.

But it does make the complexity visible early enough to manage properly.

Link to the Next Layer

Once the assessment is complete, the next question is not simply what data exists.

It becomes:

• how does the data move through the organisation
• where is it transformed
• where does aggregation happen
• how are jurisdictional outputs actually built

That is the next layer of analysis.

It is the reason source systems and data flows need to be examined separately, rather than treated as a footnote to the assessment.

Conclusion

A Pillar Two data assessment is not a checklist exercise.

It is a practical review of whether the organisation can produce the data required for GloBE calculations in a consistent and controlled way.

For multinational groups, the implication is straightforward: if the assessment stays too high-level, the real implementation risks will surface later, when they are harder and more expensive to fix.

A useful assessment does not just confirm where data sits.

It shows whether the organisation can actually operate Pillar Two on top of it.