Is your company's foundation ready for pay transparency?

When it comes to the question of Pay Transparency, the challenge is rarely a lack of willingness to be open. It is a lack of the fundamental structures and systems needed to make that openness possible. This article provides you with a concrete starting point to assess whether your company has the foundation in place before the Danish legislation is implemented in January 2027.

Most companies we speak with agree that pay transparency is a good idea. The discussion is rarely about the principle, but about the practice. Because when the directive truly takes effect, and employees gain the right to inquire about pay level comparisons, it is not the attitude that will be put to the test. It is the foundation.

And that is exactly where many companies face a critical task and a challenge they have not yet recognised.

In this article, we take a closer look at the structure and system foundation of your company, which you need to have in order if you are to fully benefit from your ambitions within the area of Pay Transparency.

The directive requires companies to explain pay differences based on objective, gender-neutral criteria across employees performing "the same work or work of equal value". That sounds simple. It is not.

Because "work of equal value" is neither about titles, organisational charts, nor who reports to whom. It is about a structure that makes it possible to compare pay levels across categories based on an objective foundation. We call that structure a job architecture.

A job architecture typically consists of at least three fundamental elements:

• Job families: The professional groups that the company consists of, e.g. finance, IT, sales, HR, or supply chain.

• Job levels: A number of levels across the families (typically 8–12), where each level is described based on objective criteria.

• Job functions: The specific functions within the job family and job level.

The point is that two employees can be at the same job level even though they work in very different parts of the organisation.

Take a concrete example: In a management team, the CFO, Head of HR, Supply Chain Director, Sales Director, and IT Manager all report to the CEO. On the organisational chart, they appear to be at the same level. But when assessed against the directive's four objective criteria — skills, effort, responsibility, and working conditions — the picture may be quite different. The CFO and Supply Chain Director may be at level A, while the IT Manager is actually at level C, and thus should be compared with, e.g., the HR Business Partner and the Financial Controller further down in the organisation.

That is the exercise that is crucial. And that is what creates the foundation for being able to explain pay differences when the employee knocks on the door after January 2027 and requests information.

A piece of good advice: Start from the top. Many companies start at the wrong end with detailed job descriptions and drown in complexity. Instead, take your starting point in the overall structure: What job families do we have, and which job levels make sense for us? Only then is it relevant to go into depth.

The Danish bill provides for the use of DISCO codes as a starting point for the grouping, as they constitute an international standard for the classification of job functions. However, DISCO codes often do not have the necessary level of detail for the required categorisation, just as it requires that the quality of the reporting is in order. And that is where, in our experience, many companies fall short, as DISCO codes have lived a quiet life as a statutory formality without genuine maintenance.

1. Excel. It is perfectly legal to maintain your job architecture in a spreadsheet. There are no formal system requirements in the directive. But it requires a discipline that many underestimate. Every time an employee changes role, every time a position is created or adjusted, Excel must be updated in parallel with the HR and payroll system. It is possible, but it is vulnerable.

2. The existing HR system. If the company already has a larger HR solution, the job architecture can in many cases be added as an additional dimension on top of master data. But, and this is important, there does not yet exist a "Pay Transparency module" that you can simply switch on. The large providers can offer fields and structure, but the actual definition of the job architecture must be carried out by the company itself.

3. Best-of-breed solutions. Today, there are a handful of dedicated solutions, often developed by compensation specialists, that are built specifically for pay transparency. They can, to a certain extent, solve the structural work for you, and once the structure is in place, they can handle data analysis, pay gap calculations, and reporting at an entirely different level than general HR systems.

4. Custom-built solutions. With modern tools, it has become significantly cheaper to build tailored solutions for specific processes. We at Basico have had good experiences with this within pay adjustment in recent years, and the same can be done here. But it requires that the company's data ecosystem is coherent, because the solution needs to draw on both current and historical data from HR and payroll.

Regardless of which path you choose, the same fundamental rule applies: There must be a clear definition of which pay elements are to be included in your basis for comparison. Data quality is key. If the job categorisation used is not updated and maintained, or if the history is incomplete, then it does not matter which system support is used.

Although the EU directive effectively enters into force on 7 June 2026, the legislative implementation date in Denmark has been postponed to January 2027, and the first reporting for the largest companies must be submitted the same year. That sounds like a long time, but when you consider how much needs to be in place, it is not. A job architecture is not built in an afternoon. Data quality does not come by itself. And the discussion about centralised versus decentralised pay setting is a strategic conversation that must be anchored in the executive management and board, not an HR task alone.

So ask yourself four questions:

1. Can we today explain why two employees at the same "level" are paid differently, based on objective criteria?

2. Do management, HR, and employee representatives know how to handle and respond to enquiries from employees when the right to information takes effect?

3. Do we have a structure that makes it possible to compare positions across professional groups?

4. Can our systems deliver the data needed, both for employee enquiries and for reporting?