ERP Rescue Consultant, Poland

When the sponsor sits in another country

Many Polish ERP projects belong to a wider program. A group team owns the template, a central or external implementer configures it, and a local partner may handle Polish features. When the project struggles, decisions bounce between these parties. Local finance raises an issue, the program team logs it, the implementer waits for a priority call, and the Polish entity keeps working around the gap.

So the first step in a Polish rescue is governance, not technology. I agree with group and local management:

• who has the final say on Polish scope, priorities and go-live readiness;
• which items are urgent because they carry legal or cash consequences in Poland, and who owns each;
• how quickly a local issue must receive a decision from the group;
• which changes pause until the facts are established.

This is written down in a page or two and confirmed by both sponsors. It sounds modest, but it is often what has been missing, and it immediately shortens the time between a problem appearing and someone being allowed to fix it.

The general recovery approach is described under ERP recovery. If an independent view is all you need for now, my second opinion offer is a lighter starting point.

Stabilizing KSeF, payments and a month in two systems

With decision rights settled, the urgent list is worked through by cause. In Poland three areas tend to need immediate attention.

KSeF. Incoming supplier invoices may have accumulated on the platform without being registered in the ERP, which means missing costs, missing input VAT and suppliers chasing payment. I organize a backlog run: retrieve, register, match to orders and receipts, approve. On the outgoing side, refused submissions are grouped by cause, the cause is fixed in data or configuration, and corrected invoices are sent again with numbering intact. Someone is named to watch the connector daily until it settles.

Payments. When supplier accounts fail the VAT payer register check or split payment flags are wrong, batches stall or need manual edits in the bank portal. I trace failures to supplier master data and invoice settings and fix them there, so the next batch passes without hand editing.

The split month. If go-live fell mid-period, the JPK submission for that month draws on two systems. With your accountant I agree which system supplies which records, how totals are combined and who reconciles them against the ledger before submission. Treatment and filing remain their decision.

Salary postings arriving from the payroll bureau or accounting office are mapped to the new accounts and checked against the payroll summary as part of this work, so no cost is missing from the close.

Fixing data where errors start, not in the ledger

Troubled Polish go-lives often carry data problems from migration: customer and supplier NIP numbers missing or mistyped, supplier bank accounts copied without checks, opening balances that do not agree with the previous package, intercompany positions that sister companies do not recognize, and an exchange rate setup that differs from what the accountant requires for PLN books.

The temptation is to correct each symptom with a journal. That keeps the close moving for one month and guarantees the same work the next. Instead I group errors by origin and fix them at the source:

Every correction is logged with its reason, so your accountant and auditor can follow it later. The approach matches my ERP data migration method, applied after the event rather than before it.

A neutral account for group, local team and implementer

While operations steady, I document the path that led here. That means reading the contract, the template design, the Polish requirements, the change log and the test evidence, and holding separate conversations with the Polish finance and operations leads, the group program manager, the implementer's lead and, where one exists, the local localization partner.

The resulting account usually shows shared causes rather than one failure: Polish needs raised after the template was frozen, decisions waiting between group and local teams, compliance features treated as a late add-on, data quality underestimated. Writing this down neutrally lets the parties stop defending positions.

Next, group, local and implementer representatives go through the open list together, marking each entry as needed now, needed later, no longer wanted or contested. For contested entries the signed papers decide, not the loudest voice. Whatever remains receives an owner on the group, local or implementer side and a test that proves it complete.

If the implementer or local partner cannot continue, I prepare a handover: configuration and extension documentation, who maintains the KSeF and JPK components, credentials, open defects and test material. Contract questions, which may sit between the group and the implementer rather than with the Polish entity, go to your legal team. My contribution there is a dated chronology and a side-by-side of promised and delivered scope; I offer no legal opinion. My implementation oversight in Poland describes the client-side role that keeps a reset project on course.

Template, local system or a phased path

With operations stable and the account agreed, leadership decides how to proceed. The options paper usually covers:

• Continue the group template with the reset plan and clearer local decision rights, when the platform suits the entity and the problems were governance, scope or data.
• Add a Polish layer, such as a maintained localization extension or connector, where the template is sound but local compliance features were thin.
• Run a local system for Poland that feeds group reporting, when the entity's needs differ too much from the template to close the gap sensibly.
• Phase the rollout, putting finance and purchasing live first and leaving production or warehouse functions for a later wave.

For every option the paper names what can be carried over, where the danger lies and which factors push cost up or down; it quotes no figures. A local system is sometimes the right call, but it brings its own integration and governance burden, and the paper says so.

No new go-live is scheduled until KSeF, payment and JPK scenarios pass fresh end-to-end tests and both sponsors sign a readiness checklist; my ERP go-live support page describes that gate. Calls sit in the Polish morning and early afternoon. Once stable, an ERP audit in Poland checks what is left. If a new platform is needed, my Polish ERP selection page explains the next step, and the Poland hub covers the rest.