Chapter 2 — Normalizing the numbers

Making numbers comparable before trying to understand them

At this stage, the data exists. It has been collected. It is technically readable. It is usable, source by source. Each entity is consistent. Each system does what it should. And yet, as soon as you try to produce a consolidated reading, something gets stuck. The numbers are not wrong. They are simply not comparable.

Data can be correct without being usable

Normalization often starts very low, at the finest level. A professional fees account, for instance. From an accounting standpoint, it is perfectly correct. It groups fees together and fulfills its regulatory function. But from an analytical standpoint, that same account may contain:

• marketing fees,

• sales fees,

• IT fees,

• HR fees,

• finance fees.

The data is correct. But it doesn't allow you to read the business. To analyze by department, you have to break apart what was grouped together. This isn't a correction. It is a translation.

Aligning entities that aren't telling the same story

The same problem appears quickly between legal entities. Same country. Same regulatory framework. Same currency. And yet:

• different charts of accounts,

• different practices,

• accounts that carry different realities.

Each entity is consistent on its own. But adding them up mixes concepts together. Adding without normalizing means aggregating things that aren't talking about the same object. You then have to:

• define a target structure,

• establish mappings per entity,

• sometimes reclassify or clean up certain accounts.

Not to correct the accounting. But to make the overall reading possible.

When there is no longer a common language

As soon as you go beyond a single country, the question becomes even more visible. Charts of accounts differ. Naming conventions change. Sometimes there isn't even a mandatory structure. There is no natural common reference. To read the whole, you have to create one. A chosen nomenclature. An imposed common language.

A framework that is perfectly native to no one. This framework is neither true nor false. It is necessary.

Normalizing time before talking about performance

Normalization isn't only about structures. It is also about time. Regulatory constraints mostly operate on long horizons. Year. Half-year. Sometimes quarter. Steering, on the other hand, runs on a shorter rhythm. Some entries are therefore recorded according to logics that don't match the expected reading rhythm. From an accounting standpoint, everything is correct. But without a common time framework, comparisons become unstable. Before any performance analysis, you therefore have to align time. Decide on a reading unit. Realign certain entries. Neutralize purely calendar-driven effects.

This isn't an interpretation. It is bringing things into compatibility.

Normalization as a silent framework

At each level, the mechanism is the same. Normalization doesn't seek to explain. It seeks to make comparable. It:

• aligns,

• homogenizes,

• simplifies.

But in doing so, it imposes a common framework. This framework:

• precedes any analysis,

• structures the possible comparisons,

• defines the language of steering.

Normalization doesn't lock in the conclusions. It locks in the framework within which they can be formulated.

The invisible condition for steering

Without normalization:

• the numbers don't speak to each other,

• comparisons make no sense,

• analysis is impossible.

It is a necessary step. Rational. Indisputable. But it sets, very early on, a common framework within which everything else will have to fit.