ERP Business Analyst, Poland

Writing KSeF requirements a vendor cannot misread

Poland's national e-invoicing system, KSeF, changes what an invoicing requirement has to look like. A line saying the system must support e-invoicing tells an implementer almost nothing. Scope and phasing have been revised over time, so your tax advisor confirms what applies to your company. My part is to describe your own invoice traffic precisely enough that each vendor's answer can be checked.

In the BRD I split the topic into separate, testable requirements:

• Outbound sales invoices, including corrective invoices and the reference each one carries to its original.
• Inbound purchase invoices retrieved from the platform and matched to orders or goods receipts.
• Who triggers submission, and what a user sees when a document is rejected.
• Where the identifier returned by the platform is stored and how it appears on reports.
• A written procedure for periods when the connection is unavailable.
• Invoices to foreign buyers and any documents your advisor says fall outside the national system.

Each requirement gets an owner on your side and an acceptance condition, for example that a corrective invoice can only be raised from a submitted original and stays linked to it in the ledger. Requirements written this way keep a demo honest, because the vendor has to walk through the exact flow rather than show a slide. The document structure follows my BRD consulting approach.

JPK files as a data requirement, not an export feature

The structured JPK files your accountant submits draw on large parts of the ledger: sales and purchase registers, VAT markings, customer and supplier tax identifiers and, for some files, warehouse or fixed asset data. Which files apply and in what form is decided by your accountant. What a business analyst can do is make sure the data behind them is requested in the requirements instead of being discovered after go-live.

I build a simple lineage table for this. Each item your accountant relies on is traced to its source, whether that is a customer master field, a document type, a posting rule or a warehouse transaction. Next to it I record who maintains the data, which screen captures it and what validation should prevent a document from being saved while it is incomplete.

The table tends to surface awkward decisions early. Should sales staff create new customers, or does finance own that master? Do manual journals need a VAT marking field? Are warehouse documents produced in the ERP or in a separate system that feeds it? Settling these questions during analysis is far cheaper than repairing files each period. The lineage table becomes an appendix to the BRD and a checklist for test cases, in line with my ERP requirements gathering method.

Mapping processes between a Polish entity and its parent

For a Polish company inside a foreign group, a process rarely stops at the border. An order may be taken by a sales office elsewhere, produced in a Polish plant, invoiced locally in PLN and reported to the parent in EUR. Mapping only the Polish half hides the handoffs where most errors begin.

I draw end-to-end flows with a swimlane for each organization involved: the Polish entity, the parent's finance function, any shared service center and outside parties such as the accounting firm or a logistics provider. Typical maps cover:

• Order to cash for goods sold both to group companies and to external customers.
• Procure to pay where purchasing is centralized but supplier invoices arrive locally.
• Intercompany recharges for services, management fees and shared costs.
• Month-end close, with Polish statutory steps running alongside group reporting deadlines.

On each map I mark pain points, manual re-keying and approvals that happen outside any system. The future-state version then shows which steps move into the ERP, which stay in the parent's tools and where an interface is required. Group controllers and Polish finance leads review the same diagram, which brings disagreements into the open while they are still cheap to resolve. My ERP process mapping service describes the notation and workshop format.

Shared service centers: separating the standard from the local

A shared service center in Poland may post invoices, run payments or close the books for entities in several countries. Its requirements differ from a single company's, because one team follows many sets of rules. Writing a separate BRD per entity multiplies the effort, while a single generic BRD hides real differences.

I therefore structure the requirements in two layers. The core layer holds what every entity does the same way, such as invoice capture, three-way matching, approval routing and payment proposals. The variation layer lists, per entity or country, what must differ: tax codes, document numbering, local e-invoicing channels, approval limits, bank file formats and reporting calendars. Every variation carries a recorded reason, so the group can challenge differences that come from habit rather than legal need.

Role design belongs in the same exercise. I document which teams may create, approve and post in each company, how segregation of duties holds when one person works across several entities, and what service level reporting the center owes its internal customers. The result is a clear brief for implementers and a standard that the center's leadership can defend to the parent. My ERP business analysis page explains how this layered approach fits into a wider engagement.

English documents, Polish artifacts and acceptance testing

The BRD, process maps, fit-gap matrix and test scripts are written in English, usually the working language between a Polish entity and its parent. Some artifacts, however, must exist in Polish: printed invoice and delivery note layouts, statutory field labels and work instructions for warehouse or production staff. I list these in the BRD as distinct deliverables with a named reviewer from your team or accounting firm, so someone fluent checks them instead of everyone assuming they are right. A short glossary pairing each English term with the Polish one your staff use also prevents confusion in workshops.

The fit-gap analysis scores each shortlisted platform against the numbered requirements, noting whether a need is met by standard features, a localization module, a third-party connector or custom work. My Poland pages for Odoo, Dynamics 365, ERPNext and Zoho explain what I look at in each. Acceptance scripts then replay your transactions in a test environment, including e-invoice submissions where a test channel is available, and your accountant reviews sample statutory files before sign-off. Details of the scoring are on my ERP gap analysis page. For engagement options, see freelance ERP consultant in Poland or the main Poland ERP consultant page.