ERP Requirements Consultant, Poland

Chapters of a Polish specification and the group template

Many Polish companies are subsidiaries, so the requirements document often has two jobs: describe what the business needs, and show where the parent's ERP template falls short for Poland. I structure it to do both:

• Scope: entities, plants and warehouses, shared service activities, currencies and which processes are in this phase.
• Process chapters: order to invoice, purchasing and incoming invoices, stock and production, payments, intercompany and the close.
• Statutory chapter: KSeF, JPK data, split payment, the white-list check, books kept in PLN and retention, confirmed by your accountant or tax advisor.
• Non-functional chapter: data location, GDPR, permissions, change history, speed and service terms.
• Connected systems and data takeover.

Where a group template exists, every Polish line is marked as covered by the template, needing configuration, needing a local add-on or not covered. That delta view gives group IT and the Polish finance team one list to negotiate over, instead of a series of emails during rollout.

Each requirement follows a fixed pattern: reference, one statement, reason, owner, priority and a proof step. The interviews and process maps behind the document are described on my ERP business analyst page for Poland; this page is about the specification and how it is used afterwards.

KSeF, JPK and split payment as testable lines

Polish compliance topics are often written as one word each, which leaves an implementer free to interpret them. Your tax advisor or accountant decides what applies to your company and when; I turn that guidance into statements paired with the step that proves them:

• KSeF sending: a posted sales invoice is sent to the national platform, the returned reference is stored on the invoice, and a rejection shows its reason to a named role who corrects and resends. Proof: run it in the test environment during the demo.
• KSeF receiving: purchase invoices are retrieved from the platform, matched to orders and receipts, and routed for approval. Proof: import a set of test invoices with deliberate differences.
• Platform unavailable: the system supports the procedure your advisor confirms for periods when the platform cannot be reached, and reconciles afterwards.
• JPK data: registers, VAT markings, counterparty tax numbers and, where required, stock or asset data are captured at posting so files can be produced without manual edits. Proof: a sample file from test data reviewed by your accountant.
• Split payment: invoices that require it carry the correct marking, and the payment run produces split payment transfers for them.
• White-list check: supplier bank accounts are checked against the official list before payment release, with the result stored.

Because KSeF scope and phasing have changed over time, a further line asks how future changes are delivered and who pays for them.

Permissions, hosting and shared service performance

Non-functional requirements carry particular weight in Poland because some of them touch tax exposure. I write them as a chapter of their own, so they are scored and contracted like features:

• Platform permissions: which people or system accounts may send and retrieve invoices on the national platform for each entity, how those permissions are granted and withdrawn, and how that matches roles in the ERP.
• Access control: separation between entering suppliers, changing bank accounts and releasing payments, with approval limits that reflect board resolutions.
• Audit trail: a readable history of changes to bank accounts, VAT markings, tax numbers and posted documents, available to your auditor.
• Hosting and GDPR: the location of live data and backups, subprocessors with access, the route for support logins and the export at exit, reviewed by your data protection advisor.
• Shared service performance: teams in a Polish service center posting for several countries must complete high-volume tasks without delay, described as working scenarios.
• Support: end-user help in Polish and escalation routes that cover the JPK and month-end period.

Specified this way, promises about security and service stop being slides and become lines that can be tested and referenced in the agreement.

Connections, data takeover and the path to a signed contract

For each interface the specification states direction, trigger, format, owner and error handling: domestic and SEPA payment files with split payment transfers, bank statements, the white-list service, KSeF itself where a connector is used, the payroll journal from your provider or accounting office, and links to e-commerce, CRM or a group consolidation tool. Migration requirements list the masters, open items, history and numbering moving from packages such as Comarch ERP, Symfonia or InsERT, who cleans each set and how reconciliation is signed.

Owners then rank their lines as must, should, could or not now. A must needs a reason: a statutory duty confirmed by the accountant, a group reporting obligation or a control the company cannot drop. The management board resolves conflicts between local and group priorities.

Traceability ties each line to the demo step, the fit-gap answer (standard, configuration, add-on or development), the clause in the statement of work and the acceptance test. When offers are invited, the frozen document is the annex implementers answer line by line; the method is under ERP RFP consulting, and choosing between template, local system and hybrid is covered on my ERP selection page for Poland. In the contract, the agreed version is named in the statement of work so acceptance depends on the linked tests.

Gaps that weaken Polish specifications

Certain gaps recur in Polish requirement documents and tend to surface late, during configuration or the first JPK period:

• KSeF described only for sales, with incoming invoices and their approval left out.
• No line on what happens when the national platform is unavailable.
• Platform permissions handled informally, so nobody knows who can send on behalf of each entity.
• Split payment and white-list checks assumed to be standard, then found to depend on a bank file format or an add-on.
• JPK treated as an export, without requirements on the data captured at posting.
• A group template accepted without a written Polish delta.
• Migration that ignores invoice numbering and the history your accountant must still access.

The document is maintained like any controlled record. A revision log captures each change with its requester and reason; one issue is released for offers and another for the contract, and later edits travel through change requests showing their effect on cost and plan. Sign-off starts with each process owner and ends with the management board.

All sessions run remotely on video calls with shared drafts, and in-person meetings are possible by arrangement. You keep the specification, the delta list and the traceability matrix. See the Poland overview or my ERP gap analysis service for related work.