ERP and accounting software for Poland - KSeF clearance, FA(3) XML and PLN accounting

Clearance is a different kind of obligation

KSeF went live in February 2026 after several pilot phases, and it operates as a clearance system. The invoice goes to the authority and is approved before it reaches the buyer, and KSeF assigns the invoice its identifier. Every other consequence on this page follows from those two facts.

Businesses used to post-audit environments consistently underestimate what this changes. In a post-audit country you issue an invoice and find out years later whether anything was wrong with it. Under clearance, the verdict is immediate. A document with a malformed field does not become a small problem for the future; it does not become an invoice at all until it is fixed.

That is not only a burden. Immediate rejection is a very effective quality control, and businesses operating under clearance often end up with cleaner invoice data than their counterparts elsewhere, because errors cannot accumulate quietly. The cost is that the error has to be resolved now, by someone, during the working day.

Confirm your own scope and obligations with Krajowa Administracja Skarbowa or the Ministry of Finance. Which taxpayers and which transactions are in scope is a question about your business, and the answer should come from the authority rather than from a summary page.

• KSeF live since February 2026, after several pilot phases.
• The authority approves the invoice before the buyer receives it.
• KSeF assigns the invoice identifier.
• A rejected document is not a late invoice; it is not yet an invoice.
• Confirm scope with Krajowa Administracja Skarbowa or the Ministry of Finance.

The invoice is no longer a document you send

The most useful way to think about KSeF is that issuing an invoice has stopped being a single act and become a short process with an external step in the middle. You prepare the invoice, you submit it, the authority responds, and only then does the document have standing. Businesses that model this as printing with extra steps get into trouble at the third stage.

Concretely, your system needs states that a paper process never needed. Prepared but not submitted. Submitted and awaiting response. Accepted with an identifier. Rejected with a reason. Each of those states has to be visible to a finance user, and each has to be reportable, because at month end somebody will ask how much of what was raised actually cleared.

It also needs someone to own rejections. This is the single most common operational gap. The technical connection works, the format is right most of the time, and then a percentage of documents fail for reasons specific to individual customers or items, and nobody has been made responsible for clearing the queue. Two weeks later the receivables ledger and reality have drifted apart.

Skyline Nexus keeps submission state on the invoice record itself, alongside the identifier returned and the reason for any rejection, so that the accounting view and the transmission view are the same view rather than two systems that have to be reconciled.

• Model issuing as a process with states, not as a single act.
• Prepared, submitted, accepted with identifier, rejected with reason.
• Make submission state visible to finance users, not only to IT.
• Name an owner for the rejection queue before go-live.
• Report at period end on what was raised versus what actually cleared.
• Keep the identifier returned by KSeF on the invoice record.

Living with an identifier you did not assign

KSeF assigns the invoice its identifier. That sounds administrative and turns out to be structural, because a great many downstream processes were built on the assumption that the seller names the document. Customer queries, remittance advice, credit note references, dispute correspondence and audit trails all have to work with an identity that arrives from outside.

The practical requirement is that both references live together. Your internal number does not disappear; it remains how your own staff find things and how your subledger hangs together. The KSeF identifier is how the document is identified authoritatively. A system that stores only one of the two forces someone to keep a spreadsheet mapping them, and that spreadsheet becomes a single point of failure.

The same applies to corrections. A credit note has to point at the invoice it corrects using an identity both parties recognise. If your correction workflow references only your internal number, you have built a reconciliation problem for the customer to discover.

Support processes need the same treatment. When a customer telephones about an invoice, they will quote whichever reference is in front of them, and that will not reliably be yours. A finance user should be able to search on either identity and land on the same record, without knowing in advance which kind of reference they have been given. This is a small design decision that is expensive to retrofit once the ledger has volume in it.

• Store the KSeF identifier and your internal reference together.
• Show the identifier on customer-facing renderings and correspondence.
• Reference corrections by an identity the customer also recognises.
• Do not let a mapping spreadsheet become the system of record.
• Make both references searchable for support and audit.

FA(3) XML rewards systems that hold data as data

Invoices are submitted in FA(3) XML. A defined structured format is unforgiving in a specific way: every value must be in its own field, of the right type, in the right place. There is no equivalent of writing an explanation at the bottom of the page and expecting the reader to work it out.

This exposes a weakness that is invisible in a PDF world. Many businesses keep genuinely important information in free-text: delivery terms in a notes box, a customer purchase order reference typed into a description, a discount explained in a sentence rather than recorded as an amount. All of that renders perfectly and none of it survives translation into a structured format.

So the honest preparation question is not whether a vendor supports the format. Formats are the last mile and are usually the fastest part of an implementation. The question is whether the information you actually need on an invoice exists as fields in your system today, or whether it lives in prose that a human has been silently interpreting for years.

Item-level tax classification belongs in the same discussion. With a standard rate of 23 percent and reduced rates of 8 and 5 percent, a mixed catalogue needs the rate as a property of the item rather than a choice made at the counter, so that the same product is treated the same way in every channel.

• Every value needs its own typed field; free text does not translate.
• Audit what currently lives in notes boxes and descriptions.
• Record discounts as amounts, not as explanations.
• Hold customer purchase order references as fields.
• Set tax classification at item level for 23, 8 and 5 percent.
• Format support is the fast part; data structure is the slow part.

The zloty is a real design constraint

Poland uses the zloty, not the euro. For a purely domestic business this is unremarkable. For a group operating across Europe or between Europe and the Gulf, it is one of the more common sources of accounting mess, because it forces a distinction that euro-only groups never have to make.

Four things are separate and are routinely conflated. The currency the transaction happened in. The rate applied and the date it was taken. The functional currency of the Polish entity. The presentation currency of the group. A system that stores only a converted amount has thrown away the first two, and no amount of later reporting can recover them.

The visible symptom is exchange differences that nobody can explain: a receivable raised at one rate, settled at another, and a difference posted somewhere that does not reconcile to either. The underlying cause is almost always that the original currency and applied rate were not stored on the transaction. Skyline Nexus records every transaction in its original currency with the rate applied and the date, and keeps entity and branch as dimensions on the posting, so that translation is a reporting step rather than a lossy conversion at entry.

This matters more under a structured invoicing regime, because the currency and amounts on the cleared document are fixed and public. Reconstructing them afterwards from a converted figure is not an option.

• Poland transacts in zloty; the euro is not the domestic currency.
• Store transaction currency, applied rate and rate date on every entry.
• Keep functional and presentation currency as separate concepts.
• Translate at reporting time, not at data entry time.
• Expect exchange differences; make sure they are explainable.

Where Poland sits among its neighbours

Poland is the clearance case in a group of four European markets that have each chosen differently, and the comparison is the fastest way to understand what clearance means. In Poland the tax authority is inside the transaction path: the invoice reaches it before it reaches the buyer, and the identifier comes back from it.

Belgium made structured B2B e-invoicing mandatory in January 2026 but built it on the Peppol network, where documents move between trading partners over shared infrastructure and the authority is not in the middle of each one. Spain has moved first on the integrity of billing records through VeriFactu, which is phasing in, while its Crea y Crece B2B mandate is approved but not yet in force. The Netherlands has no domestic B2B mandate at all and a design framework targeting 2030.

Four member states, four architectures, and no sign of a single European behaviour that a system could implement once. For a group with a Polish subsidiary, the practical implication is that country behaviour has to be configuration on the entity. A product that offers one European mode is describing a continent that does not exist.

It also means the Polish implementation is not reusable as-is elsewhere, and that is worth saying to a board before it is discovered mid-project. What is reusable is the master data, the item-level tax classification and the currency discipline underneath.

• Poland: clearance through KSeF, identifier assigned by the authority.
• Belgium: Peppol network exchange, mandatory since January 2026.
• Spain: VeriFactu billing rules phasing in, B2B mandate approved not in force.
• Netherlands: no domestic mandate, framework targeting 2030.
• Country behaviour belongs on the entity, not in a single global setting.
• Master data and tax classification are the reusable part.

What clearance does to accounts receivable

Under clearance, the receivables process acquires a dependency it never had. An invoice that has not cleared is not a document you can chase, and a customer who has not received it has a legitimate reason not to pay. Collections conversations therefore have to start from submission state rather than from invoice date.

The reporting implication is specific: aged receivables reported on issue date alone will overstate what is genuinely collectable if a meaningful number of documents are sitting rejected. A business needs to see raised, cleared and rejected as distinct populations, and needs the rejection reasons grouped so the pattern is visible rather than anecdotal.

The patterns are usually boring and fixable: one customer whose registration data is wrong, one product with a bad tax classification, one branch entering a field inconsistently. They are only invisible when rejections are handled one at a time by whoever happens to notice.

Cash forecasting inherits the same dependency. A forecast built from invoiced amounts assumes every invoice reached its customer, and under clearance that assumption is no longer safe without checking. The correction is small once the state is stored on the invoice record: forecast from cleared documents, and treat the rejected population as a separate, visible number that somebody is accountable for reducing each week.

• Aged receivables should distinguish cleared from rejected documents.
• Chase on submission state, not on issue date alone.
• Group rejection reasons so patterns are visible.
• Most causes are a handful of bad master records, not random failures.
• Review the rejection queue on a schedule, not opportunistically.

Reporting frameworks for a Polish entity

Listed companies in the European Union report consolidated accounts under IFRS as adopted by the EU, while individual entities commonly prepare statutory accounts under local generally accepted accounting principles. A Polish subsidiary of a foreign parent will normally serve both: local statutory accounts and a group reporting package.

Where the parent is outside the EU, the group framework may differ again, which is a common situation for Gulf-headquartered groups with European operations. The point is not which framework wins but that one set of transactions has to be detailed enough to support more than one presentation without manual rebuilding.

The currency question compounds it here. A Polish entity keeping its books in zloty inside a group reporting in another currency needs translation that is reproducible and explainable, which returns to the same requirement: original currency, applied rate and rate date stored on the transaction, and entity and branch as posting dimensions. The framework determination itself is for your auditor.

• EU listed companies: IFRS as adopted by the EU for consolidated accounts.
• Individual entities: commonly local GAAP for statutory accounts.
• A non-EU parent adds a third framework to the same transactions.
• Translation must be reproducible from stored rates, not re-derived.
• Framework determinations belong to your auditor.

Questions worth asking a supplier about Poland

With a clearance system in production, demonstrations are more informative than documents. Ask to see the states, not the diagram. A supplier who can show you a rejected invoice, its reason, and how a finance user resolves it has built the thing. A supplier who shows you a successful submission has shown you the easy case.

Ask where the KSeF identifier is stored and where it appears. Ask what a correction references. Ask how aged receivables treat an uncleared document. Ask whether tax classification lives on the item. Ask what is stored when a sale is made in a currency other than zloty, and whether the rate and date survive.

Then ask the group question. What does this same system do in Belgium, in Spain and in the Netherlands? If the answer is the same in all four, it is not an answer.

Be equally direct about what the supplier will not do. Ask whether they claim any certification for KSeF, and treat an enthusiastic yes as a prompt to ask who issued it and for what. A supplier describing capability accurately, and telling you to confirm scope with Krajowa Administracja Skarbowa, is giving you more usable information than one offering a compliance guarantee that no software can honestly provide.

• Show a rejected invoice and how a finance user resolves it.
• Show where the KSeF identifier is stored and displayed.
• Show what a credit note references.
• Show aged receivables with uncleared documents distinguished.
• Show tax classification held on the item across all three rates.
• Show original currency, rate and rate date stored on a non-PLN sale.

Confirm the position with the tax authority

This page reflects the position as confirmed on 7 September 2026: KSeF live since February 2026 after several pilot phases, FA(3) XML as the format, clearance before the invoice reaches the buyer, and the invoice identifier assigned by KSeF.

Scope, exemptions, transitional arrangements and the treatment of particular transaction types are questions about your business rather than facts about the country. Krajowa Administracja Skarbowa and the Ministry of Finance are the authorities, and the current position should be confirmed with them or with a Polish adviser before you commit to a design.

A software supplier can describe what its system holds, produces and enforces, and can demonstrate it. It cannot certify you against a national regime, and any claim of that kind is a reason to look more carefully at the rest of what you have been told.

• Authority: Krajowa Administracja Skarbowa and the Ministry of Finance.
• Position stated as confirmed on 7 September 2026.
• Confirm scope and any transitional arrangements for your own business.
• No software certifies you as compliant with KSeF.

Common questions

Is e-invoicing mandatory in Poland?

Yes. The KSeF national e-invoicing system went live in February 2026 after several pilot phases. It operates as a clearance model: the invoice goes to the tax authority and is approved before it reaches the buyer. Confirm your own scope with Krajowa Administracja Skarbowa or the Ministry of Finance.

What does clearance mean in practice?

It means issuing an invoice is no longer something your business completes alone. The document is submitted, the authority responds, and only then does it have standing with the buyer. Your system needs visible states for prepared, submitted, accepted and rejected, and someone has to own the rejection queue.

What format do Polish e-invoices use?

Invoices are submitted as FA(3) XML. Because every value must sit in its own defined field, information that currently lives in free-text notes, descriptions or explanatory sentences does not survive the translation. Auditing what your invoices keep in prose is usually more work than adding format support.

Who assigns the invoice number under KSeF?

KSeF assigns the invoice its identifier. Your internal reference still exists and is still how your own staff find documents, but the authoritative identity comes from the system. Both should be stored together and both should be searchable, so that corrections and customer queries reference an identity the other party recognises.

Does Poland use the euro?

No. Poland uses the zloty, which makes multi-currency handling a genuine requirement for any group trading into Poland from the eurozone or elsewhere. Store the transaction currency, the applied rate and the rate date on each entry, and keep translation as a reporting step rather than converting at data entry.

Rates, regimes and deadlines in this summary change, and many countries are actively legislating on e-invoicing. This is general information, not tax or legal advice — confirm the current position with the authority named above or with your tax adviser before you rely on it.