ERP Implementation Consultant, Poland

What derails ERP rollouts in Poland

Polish implementations that run into trouble usually do so for local reasons that were visible months earlier. The ones I look for first:

• KSeF treated as an interface task. Sending works in a demo, but rejections, offline situations and corrections have not been designed, and nobody owns the monitoring.
• Purchase invoices without a process. Invoices arrive through KSeF, yet there is no agreed route for matching, approval and posting, so they pile up.
• JPK left to the export routine. The file is produced, but its totals have never been reconciled to the ledger and VAT registers.
• Group templates designed elsewhere. A parent's rollout team treats Polish needs as a late localization, and local finance learns of design choices during testing.
• Payment controls missing. Split payment flags and supplier account checks are not part of the payment approval workflow.
• Exchange rates set up generically. The rate source your accountant requires for PLN books is not the one configured.

Each of these needs a client-side owner who sees the Polish picture as a whole and insists on evidence. That is the role I fill, building on the requirements and vendor answers from ERP selection in Poland or, if the system was chosen by the group, on a short review of the template and the local gaps.

When the implementer is your parent's IT team

Many Polish entities receive their ERP from the group. A central team brings a template, a timeline and a rollout method built for several countries, and the Polish finance team has limited time to influence it. Local needs are then handled as exceptions, often by a Polish partner hired late to fill the gaps.

I work for the Polish company within that structure. Early in the project I turn local requirements into a short, numbered list the template team can plan for: KSeF exchange, JPK data, split payment, account checks, PLN reporting and the outputs your accountant needs. I join design sessions where Polish topics come up, make sure decisions are written down and ask the local finance lead to sign them off.

When the group brings in a Polish partner for localization, I coordinate between them and the template team, so responsibilities for connectors, updates and support are clear. Change requests from the Polish side go into the group's change process with their reason and impact, rather than being negotiated informally.

The same approach works with a Polish implementer delivering a local system. Either way, I do not configure the system myself or replace the implementer's accountability; I keep the Polish company's side organized and its decisions on record. For the general model behind this role, see ERP implementation.

Bringing data across from Polish packages

Companies in Poland commonly migrate from domestic products such as Comarch ERP, Symfonia or InsERT programs, from a system run by their accounting office, or from spreadsheets kept beside them. The implementer supplies templates and runs loads; your team cleans the source data and proves the result.

The checks concentrate on records that Polish compliance and payments depend on:

• Customer and supplier NIP numbers, addresses and status, since invoices, KSeF and JPK depend on them.
• Supplier bank accounts, so the first payment run passes the VAT register checks.
• Open receivables and payables in PLN and foreign currencies, with the exchange rates used at booking.
• General ledger opening figures equal to the final trial balance exported from the previous package.
• Inventory per warehouse in units and PLN, tied to the latest physical count.
• Balances with sister companies confirmed by the counterparty before loading.

Each trial load is accepted only when the person owning that data confirms the totals. Fixes are made in the source or in the mapping rules. Retention of older books and documents follows your accountant's guidance, and the plan states where the archive lives. See ERP data migration and the ERP migration checklist for detail.

Testing KSeF, JPK and payments end to end

In Poland, acceptance testing must follow documents out to the tax platform and the banks and back again. The scenarios are drafted together with each department and executed by the staff who will own those tasks:

1. A sales order invoiced and sent to KSeF in the test environment, with the reference stored against the invoice.
2. An invoice that KSeF refuses because of a data error, fixed and sent again with the numbering sequence intact.
3. A correcting invoice that adjusts price and quantity, linked to the original.
4. A purchase invoice received from KSeF, matched, approved and posted.
5. A payment run including an invoice under split payment and a supplier account checked against the VAT register.
6. A euro transaction booked in PLN using the rate your accountant requires, followed by revaluation.
7. A period close producing JPK files that reconcile to the ledger.

Your accountant reviews the tax-related outputs and decides on treatment. My job is to keep the test data close to real life, log every outcome and give each problem an owner. Together with the implementer I sort problems into configuration faults, gaps in user knowledge and fresh requests, and acceptance closes only when the criteria set beforehand are met. The wider testing approach is described under ERP testing and UAT.

The go-live month: two systems, payroll and hypercare

Unless the switch falls exactly on a period boundary, the go-live month in Poland has data in two systems, and the JPK file for that period must still be complete and consistent. The plan agreed with your accountant states which system produces which part, how totals are combined and who reconciles them. Many companies prefer to switch after a period-end for exactly this reason.

Payroll in Poland often runs in a separate payroll package or with an accounting office, which also handles social insurance submissions. That usually stays as it is. What changes is the monthly payroll journal: its layout, account and cost center mapping, the person who imports it and the reconciliation against the payroll summary are agreed and trialled before go-live.

The cutover runbook gives every step an owner, from closing entries in the old system to confirming the first KSeF submissions and the first payment run. Hypercare starts with the first invoice: a brief daily review with key users, one issue list, and priority for anything blocking invoicing, receipts or payments. It continues through the first close and its JPK submission. My part is delivered online while your key users support colleagues in person; travel to Poland happens only when agreed in advance. More about my work in Poland is on the Poland overview and the Polish ERP consultant page.