Under the hood of the international payroll integration platform Epix

The evolution of business applications

It all started a few years ago when we observed that there are 2 major scenarios in the business application world, including the established payroll environment.

‍

First, there are companies that have been around for a medium to long time, have a certain size and have grown from an almost manual process until they started developing a software somewhere in the 90s or 2000s. These softwares typically have several characteristics:

• They are quite complete because of years of software development.
• They contain a load of know-how that has been built up throughout the years.
• They usually have many customers and users and have proven themselves over time.
• They very often started from a client-server setup at one time or another, which means that the underlying code is not optimized for the cloud.
• They nearly always contain logic that is not used today but is part of the application due to historical reasons and therefore must be maintained.
• They are usually created single tenant, and sometimes modified to operate in a multi-tenant environment. This is an environment where multiple customers are served with the same application. In many cases, several customers are in 1 database.
• These applications are usually built around the specifications for 1 country, making it difficult to open them up to multiple countries afterwards. Especially for a payroll application, there are many local aspects built in it such as legislation, wage codes and logic that only apply in 1 country.

‍

The second type of companies are the technology scale-ups that started more recently.
We can identify the following differences between them and the first group of companies:

• They tend to be smaller and younger with thus fewer customers and users.
• They do not always solve all the edge cases of a seasoned application.
• They were able to start from a blank canvas, so can use the latest development methodologies.
• The development started cloud-ready right away, so they included this in the architectural drawing from the beginning.
• Multi-tenant setup and data separation are considered a must in development.
• Multilingualism, currencies and other multi-country issues can be factored into product development from day one.
• Development is typically faster as they have less legacy.
• User-friendliness of an application today is considered core functionality and thus included from the start in the application build as well.

‍

Since all this evolves in time, we might rewrite this theory in 10 or 15 years and most likely the companies that are now in the 2^nd group will have shifted to the 1^st group . So, this is not a question of right or wrong because both groups have pros and cons. But in today's world we can make this distinction.

Why is this approach important? Well, our story is built from the experience we have as a company in the 2nd approach. And because we started from a blank canvas, some core issues were prioritized in the development of our international payroll integration platform. So, we had to take several features into account from the very beginning in order to have international success.

AI or IA

An important idea is the concept of IA or Intelligent Automation. Contrary to what you hear everywhere today about AI, Artificial Intelligence, and how it should be incorporated into business applications.

Apart from the fact that AI will definitely have a place within business applications in the long run, we do feel that the importance of IA is still higher today.

A great post on the difference can be found at Differentiating Intelligent Automation from Artificial Intelligence by Cognitive automation

The following quote says it all:

"While artificial intelligence has become a buzz word used in many contexts, intelligent automation is very pragmatic and practical. As brilliantly put by Dr. Mary Lacity, professor at the University of Arkansas, "While AI is ensconced with Hollywood-levels of fear and hype, IA is a realistic Wall Street-to-MainStreet business strategy supported by a collection of tools to redesign knowledge work."

International platform requirements

Returning to the topic of features which we think should be part of an international payroll integration platform (combined with intelligent automation), we believe several things are primordial in the development of such a product.

Sidenote: we were awarded a VLAIO grant for our innovative approach in tackling some issues linked to the international nature of our application.

We believe that these days a platform should be able to provide uniform input, output and reporting across countries. And that you should always be able to compare apples to apples, no matter how different the local implementations of countries are.

To accomplish this, it’s important to distinguish several things at a high level while simultaneously localizing. For many software providers, this proofs to be very challenging (if not impossible) as they usually start from 1 country and then have to expand to other countries(with their own peculiarities).

Let's go over these topics one by one in the following chapters.

Languages

One of the most obvious issues, is the fact that your application must be multilingual for the end user.

This is a well-known and widely used functionality, but it also entails the complexity of making data translatable for the end users. We will not elaborate on that in this article, because that topic requires a more general approach and is thus less relevant to the topic of this post.

Currencies

Another rather obvious item is the use of different currencies. However, in an international payroll application this has a different approach since one application contains several countries and it’s important that the right currencies are attributed to the different countries. So if you enter an amount for a certain employee it is needed that this amount is entered in the local currency to avoid rounding errors. So for every contract the system should be linked to a provider, making it clear which currency to use.

And although a lot of countries use Euro today, in Europe and beyond, a lot of other currencies are used. It would be very useful if the system would help you as a user to not make any mistakes adding amounts in a currency that you don’t use every day. So it should show a converted amount in the currency of your choice to avoid simple errors putting the comma at the wrong place.

Another challenge here is the choice of the conversion rate. Do you take the current one or do you take the one that was valid at the time of entry? There is something to be said for both, depending on the situation you are in. We chose to keep the rate stable so that if you look at the same data at different dates in time, the outcome is always the same. However, there are cases with customers who want to see it differently.

Localization of the data

This component is the largest and most important part of the platform. As such, it affects several components that we will cover separately.

We preferred to use a powerful localization engine that we can deploy per ICP (In Country Payroll Provider) and therefore not simply per country. One country contains multiple providers.  The reason behind this is, that indeed there are social and valuation laws per country, but different payroll calculators sometimes implement them differently or use different data fields or wage codes. Hence, even within a country we wanted to be able to deviate which fields and validation rules should be valid.

Split contracts

Something that many systems struggle with, is overlapping contracts. Keeping track of overlapping contracts for one person (for different countries) is usually out of the question.  But a platform with an international focus should be able to deal with this and ensure that the input is limited to the input that is needed. To be able to manage split pays as one example.

‍

Country specific selection lists

Our localization engine includes a powerful element, and that is our so-called sub-choices structure based on the ICP that applies. The topics ‘gender’ and ‘marital status’ are 2 great examples to illustrate how this works.

Gender can be a sensitive topic. And especially if you want to umbrella register this in an international context. Hence, in our system we have a general choice list, which is used for all countries with the basic options: Male, Female, X/Other and 'I don't want to tell'. This choice will be shown everywhere and appear in reporting. However, for payroll purposes this is not always enough information. In fact, it depends on the country in which this employee works whether all these choices are even valid. For example, in Belgium it is still necessary to make a choice between Man or Woman. Other options are currently not allowed, regardless of the sensitivities involved.

The platform however, will guide the user through this question and if the main choice is not allowed for the country where that person has a contract, an extra field will appear, displaying a list with more specific values to choose from. Linking back to our previous example, this list will only contain ‘Man’ and ‘Woman’. For the Netherlands (where the 4 main options are allowed), the platform will not display an extra field for sub choices since the main choice suffices.

As mentioned earlier, this will not appear anywhere and will only be used in communication with the local payroll provider.

When we take a look at ‘marital status’, the setup is even more complex because this field contains historical data, which includes a start and end date. And again, we start from a number of main choices with the most complicated being the fact that someone is single. This can be truly single, but it also includes various forms of cohabitation that vary from country to country. So, in this situation, the system has to check which contract is linked to the selected historical period so that only relevant subfields are shown (with the right corresponding sub values).

This way, the localization engine can be configured for each ICP without additional programming.

Payroll codes

Of course, each payroll engine has its own set of payroll codes and it is crucial that the payroll code list can differ per ICP and even per legal entity. Again, it is important to be able to compare apples to apples but still achieve localization.

To counter this challenge, we have created a structure with different code groups in our localization engine, where we can categorize wage codes across countries in different levels. That way you can use the real local wage code for a specific contract and the local calculator can also return the calculated data in the wage codes he knows. But by reporting at the code group level, comparisons can still be made across entities and countries.

And it becomes possible to quickly answer questions like “What was the amount of bonuses that we’ve paid in all countries last year”. Because now that answer is only 1 click away.

Country specific fields

The platform should contain a huge number of fields that are needed to capture all the payroll specific information. But of course, there can always be a need for very (ICP) specific payroll data which can’t be included in the general setup.

And yet again, our localization engine proves its strength, by determining for each ICP if additional fields are needed. If so, an additional tab will appear for the relevant contracts to handle the input of this information that will be sent along to the local payroll provider.

Validations

Of course, the platform contains several validations to keep the data consistent and complete. For example, if you indicate that the person wants to see the partner's name appear instead of his/her own last name and the partner's name is not entered, a notification will appear.

But in addition to these general rules, ICPs can also pass on specific validation rules. Again, this can be completely different for each ICP. For example, for a certain country the partner data is mandatory if a person is married, but for other countries that’s not always the case.

Closure

An important aspect of a payroll environment is obviously the monthly closure and transfer of data to the local payroll provider.

To manage this, all the historical values of the necessary data are stored so that there is always a tracking of the values that have existed and by whom (and when) they have been modified. But even more important is the fact that for all the data there must be a tracking that reflects to which ICP this has already been sent (or not).

If, in this context, we look back on the issue of the multiple contracts, an additional challenge pops up. In the situation where there are multiple active contracts, you need to know per contract whether certain person data (such as a new bank account number), has already been forwarded to the relevant local payroll provider(s). So it is crucial that that registration is done properly so that the situation of each ICP can be reconstructed at any given time.

Additionally, it is also important that, next to the generic format (readable by a human), for commonly used ICPs there is also the possibility of a localized export which enables a smooth data transfer with little or even no manual work on the other side.

Import and export

Along the import side, it is crucial that all data is assigned to the right person. In other words, a person requires a unique id to change personal data. But at the contract level, unique numbers must also be available to modify or add certain information at that level.

Likewise, to get data to a particular software, be it a local payroll provider or another HCM system, it is always necessary to ensure uniqueness of individuals and contracts.

Reporting

Behind it all, in addition to simplifying the input, it remains important to be able to report across countries at different levels.

‍

One of the crucial questions for an HR department is: how many people or FTE do we employ in all of our countries? And how is our population and the composition (permanent employees or external workers) of that population evolving?

Other questions could be about (net) wages or bonuses paid out across countries.

Even in this case, the smart localization engine makes it possible (in a very simple way) by centralizing this information in 1 screen, using the mapping of the local wage codes in the general code groups. And this by country, by month and even by person!

Conclusion

All things considered, there is a lot under the hood of an international payroll tool.

The user values simplicity and user-friendliness but the tool must also be able to contain the complexity to handle all types of cases.

Or as is often said in the software world: "There is always complexity but there are 2 options:  1) Either you give the complexity to the end user or 2) you give it to the developer". And I hope that with our platform we have succeeded in giving it to the developer, so the end user can just sit back and enjoy the ride.

If you want more information about our platform, please contact us or check out our website.

About the author Bart Slaets

Bart is CTO at Paybix and has already a long career in the development and product management world of payroll and time and attendance applications. He is used to create and manage products with an international orientation in a SaaS environment.

‍