In rollout plans, Poland may appear to be just another country to be launched within a global template. On a formal level, everything usually seems straightforward: a ready-made template, established processes, local tax configuration, testing, and launch. In practice, however, a Dynamics 365 rollout to Poland rarely goes so smoothly. Most often, the problem begins when head office realises too late that Polish requirements concern not only settings, but also the specifics of reporting, document workflows, payments and the quality of source data.
For implementation partners, this is a significant difference. The rollout in Poland is complicated by a series of minor assumptions which seem reasonable at the start of the project, but later resurface as amendments, delays and tension between head office, the local business and the implementation partner.
Poland isn’t just another country in the global template
One common mistake is to treat Poland as a mere extension of an existing model. In practice, it turns out that a Polish company requires more than simply rolling out the same processes in a new entity. There are local obligations that affect not only the final reports, but also data management and the day-to-day work of the finance department.
This is important right from the planning stage. If headquarters assumes that Poland will simply ‘tag along’ at the end, the project ends up operating reactively. The team does not adapt the project to local requirements, but instead tries to tack them onto the finished structure.
JPK starts earlier than many people expect
The JPK is sometimes mistakenly treated as a local report that simply needs to be generated. In reality, the problem rarely arises at the very end, with the file itself. It usually starts much earlier: with transaction classification, tagging, mapping, document logic and the quality of the source data.
This means that a rollout in Poland requires advance preparation. If data is not managed in a way that allows for accurate reporting later on, the system itself will be of little help. Technically, everything may work, but the local company will still not be ready to operate safely.
KSeF (National e-Invoicing System) changes not only the invoice itself, but the entire document workflow
The second area, which is often underestimated but is currently very much in the spotlight, is KSeF. It is sometimes the case that e-invoicing is treated merely as another integration that can be added later. In practice, it is about much more than that. KSeF affects the way invoices are issued and received, document workflows, testing, permissions and the team’s operational readiness.
This cannot be treated as just another add-on to the final phase of the project. If the rollout does not incorporate KSeF at a sufficiently early stage, the organisation will very quickly find itself having to make up for this with manual workarounds and additional fixes.
Split payment and the white list affect day-to-day operations
Another surprise may lie in the area of payments. A global procurement and payment model may look good from head office perspective, but in Poland there are additional rules that have a real impact on day-to-day operations. These include, amongst other things, split payment and the white list of VAT taxpayers.
These are not merely peripheral aspects of the configuration. They affect controls, payment processing and the extent of automation. When a project puts them on the back burner, the local team usually reverts to manual checks and workarounds to address process gaps.
Local data must be established before the tests, not after them
The same problem often crops up in rollouts to Poland: the local team is brought into the data discussion too late. On paper, everything may seem fine. The chart of accounts works, documents are being posted, and the purchasing and sales processes follow a logical sequence. It is only during reporting or testing that it becomes apparent that something is missing after all.
At that point, the project ceases to be about implementing a system and becomes about sorting out issues that should have been resolved much earlier. And at this stage, time pressure, changes and tension on the business side begin to emerge.
We recommend involving local teams right from the process design stage.
The greatest risk lies not in the system, but in the project’s assumptions
Many problems can be avoided, but on one condition: Poland must be treated as a country requiring prior preparation, rather than as a local add-on to a global model. The sooner the team asks itself which elements of the template are truly suitable for implementation without modification, the lower the risk of costly adjustments at the end of the project.
For implementation partners, this is one of the most important skills today. It is essential to identify, at a sufficiently early stage, the areas where a standard rollout plan fails to highlight all the risks.
What you should do before the rollout in Poland
Before launching the project, it is worth sorting out a few areas that will later determine whether the rollout goes smoothly or turns into a series of fixes.
The first step is to audit local processes and responsibilities. The aim is to identify in detail, before any configuration takes place, which areas affect reporting, document workflows, payments and finance operations. The purpose of this is to pinpoint as accurately as possible where global guidelines do not align with Polish requirements.
The second step is to verify the data and mappings. If the team puts this off until later, problems usually resurface during testing or reporting. It then becomes apparent that the documents are being posted correctly, but the data has not been prepared in accordance with local requirements.
The third element is deciding what remains in the global template and what should be included in the local extension. It is here that the decision is made as to whether the project will attempt to fit Poland into a universal model, or whether it will allow for local variations where necessary.
The next item on the agenda is the UAT involving Polish businesses and financial institutions. Without this, the rollout looks good only from the project’s perspective. Only local users are truly able to reliably verify whether the solution works in day-to-day operations.
Finally, it is worth planning for post-go-live support. It is often after the launch that process exceptions and local requirements that were not identified earlier come to light. Without such a plan, the organisation will quickly revert to manual workarounds.
Poland requires preparation in advance, not amendments afterwards
If you are planning to roll out Dynamics 365 in Poland and want to identify in advance which areas require local adaptation, it is worth analysing them before moving on to the final configuration and testing phase. This is the best time to minimise risks, which can otherwise resurface later as project costs and operational issues.
At this stage, we can help you organise the key areas of the project: from verifying local requirements, through assessing the readiness of data and processes, to identifying areas where the global template needs to be adapted to the Polish context. This makes it easier to identify risks early on, rather than having to rectify them under time pressure.
If you’d like to gain a better understanding of the scope of the Polish Localisation in Dynamics 365 and which areas most often require preparation during implementation or roll-out, download our e-book on the Polish Localisation. There you’ll find clearly organised information on requirements, modules and project preparation stages.
FAQ
Can the roll-out of Dynamics 365 in Poland be based solely on a global template?
Not usually. A global template typically requires prior verification in relation to Polish tax, reporting and operational obligations.
Is KSeF just another integration?
No. Although the KSeF is, by definition, a report based on data in the system, it can fairly quickly verify current business processes related to invoicing. It may turn out that some of these processes will require improvements (e.g. turnover-based discounts).
Should the local team be involved before the UAT?
Definitely. This needs to happen during the process design phase. Involving local business and finance teams too late often results in last-minute changes under time pressure, as it is only then that gaps in data, processes and reporting become apparent.
What should you check before rolling out an ERP system in Poland?
It is worth analysing local obligations, data and mapping, the impact of Polish requirements on payments and documentation, and the local team’s involvement in process workshops and testing.
Don’t delay! Register now.
About us
GO-ERP is a Microsoft Dynamics 365 Partner with offices in Lithuania, Poland and the United Kingdom. We offer a wide range of services and solutions for customers around the world. GO-ERP provides services such as implementation, migration, support and development of D365 applications. As a Microsoft Gold Partner, we provide high-quality services and customised solutions based on the innovative Dynamics 365 platform.
