Grzegorz Giewon · UnitSoftware · Warsaw
Your ERP speaks XRechnung. Poland only accepts KSeF.
I build the connector between them. Both directions, validated against EN 16931, in .NET, inside the system you already run. I have written it once already — you are not paying for my first attempt. Most often I do it as a subcontractor to the partner running the rollout: the implementation and the client relationship stay theirs.
- Poland · KSeF
- mandatory since
- Penalties
- suspended until
- Germany · issuing
- from above €800k
- Working model
- subcontractor to implementation partners
- Availability
- a standing block of 10–15 h/week · remote · CET
What KSeF is, in four sentences
KSeF is Poland’s national e-invoicing system. Since 1 April 2026, invoices between Polish businesses are not valid unless they are issued as structured XML through a government API — email and PDF no longer count on their own. Every invoice receives a KSeF number assigned by the system. From 1 January 2027 there are penalties: up to 100% of the VAT on an invoice issued outside it.
Two mandates land on the same date. A German group with a Polish plant hits Polish KSeF penalties and the German obligation to issue XRechnung on 1 January 2027 — one ERP, one IT department, two national formats sitting on the same EN 16931 standard.
Who this is for
- You are rolling out SAP or another large ERP and hit something it will not do. The release is too old for native KSeF, the standard has no XAdES signing or document rendering, and upgrading is not on the table for this project. I build the satellite that closes the gap and hand it over with documentation — as a subcontractor, under your brand if you prefer. The implementation, the contract and the client relationship stay yours. Terms, scope and billing →
- You sell software into Poland and your customers are asking for KSeF. You need a KSeF module inside your product, not a Polish invoicing product next to it. The pieces already exist — authentication, FA(3), XAdES signing, QR codes, retry logic.
- You have a subsidiary, plant or branch in Poland that issues invoices. A Polish VAT number alone does not put you in KSeF — a fixed establishment taking part in the supply does. Once your advisor confirms you are in scope, what is left is a software problem, and that one is mine.
- You are German or Austrian and both mandates land on the same day. Same EN 16931 base underneath, two different national layers on top. I have built the converter between them.
What I don’t do. I don’t sell my own invoicing product and I don’t implement accounting packages. I work on what you already have.
I am not a tax advisor. Whether your Polish operation is a fixed establishment is a tax question, and your advisor answers it. I build what follows from the answer.
Where this already runs. Every tool listed below was built this way — for implementation partners who deliver it onward as part of their own project. They are in production today at Polish entities of international industrial groups: automotive, packaging, renewable energy, measurement instruments, electronics.
How this differs from a subscription
You do not pay per invoice
Intermediaries and the KSeF modules bundled into off-the-shelf systems bill by document count: the tier grows with your invoice volume and you keep paying it every month for as long as you keep invoicing. Here you pay once to have the integration built, then only for maintenance if you want it. Invoice volume does not change the bill.
Source, documentation and full rights are assigned to you in writing. You stay on maintenance, carry on alone, or hand it to another contractor — with no proprietary format and no dependency on my infrastructure after handover.
Invoices never leave your infrastructure
The integration runs inside your network or your cloud and talks to the KSeF API directly. There is no third party in the document path: no sub-processor to add to your record of processing activities, no data processing agreement with an intermediary, and no new cloud vendor for your security team to approve. For a group where onboarding a processor into an invoicing flow is a multi-week procedure, that is usually the deciding difference.
If a hosted setup suits you better, I will say so on the first call — not every scenario needs something built on your side.
Services
XRechnung ↔ KSeF
Conversion between XRechnung and KSeF in both directions, plus sending and receiving through the KSeF API: authentication, KSeF numbers, QR codes. Both formats sit on EN 16931 — the hard part is the national layer on top, and that is the part I have already solved. Validation against EN 16931 is built in, so you find out an invoice is wrong before the tax office does.
KSeF integration for an existing system
First I work out how your system issues and receives invoices today. Then I connect it: certificate-based authentication, structured invoices out, supplier invoices in, KSeF numbers, QR codes, XAdES signing. Built to survive what actually fails in production — timeouts, API outages, validation rejections. No system replacement, no rewrite.
SAF-T (JPK) reporting
Poland’s SAF-T files — JPK_V7M and the rest — generated and filed straight from your system, validated before submission, with the official confirmation (UPO) captured automatically. No Excel exports, no pasting into a government application, and nobody on your finance team needs to read Polish to file.
Maintenance and .NET modernisation
I take over software left behind by a previous supplier, and move older systems — .NET Framework, WinForms, WCF — onto current .NET. In stages, with production running throughout.
Tools I have built
I don’t start from zero on every engagement.
XRechnungKsefConnector
Converts invoices between XRechnung and KSeF in both directions, and handles sending and receiving through the KSeF API — authentication, KSeF number handling.
XRechnungVisualizer
XRechnung in CII and UBL, validated against EN 16931, with PDF export. The document your accounts-payable team can actually read.
XMLVisualizer
Readable rendering of Polish SAF-T files and KSeF invoices, with PDF export, as a desktop app and in the browser. Nobody in finance verifies raw XML.
RSAHelper
XAdES signing, KSeF certificates, invoice-to-HTML/PDF conversion, QR codes and XML validation. Runs as a REST service; Docker and Podman images available.
JPK WysyłkaXML
Full SAF-T application: generation, validation, editing the file contents before submission, and filing to the government gateway. Built on .NET 10.
WysylkaJPK
The same filing path without the editor, but with automatic document repair — missing fields get sensible defaults instead of bouncing off gateway validation.
NipService / WhiteListChecker
Polish VAT number and bank account verification against the official taxpayer whitelist, exposed as a REST service and resilient to registry downtime.
Try one now: XRechnungVisualizer runs in the browser — drop in an XRechnung file (CII or UBL) and see whether it passes EN 16931 validation, no account needed. The rendered invoice and PDF come out in German or English; the surrounding interface is still Polish. Manuals and installers for the other tools are on the downloads page, also without signing in.
How it works
The connector sits beside your system, not inside your invoicing logic. Your ERP keeps issuing invoices the way it does today.
The same invoice, both formats
Both sit on EN 16931. The difference is the national layer — which is exactly the part the mapping has to get right.
<ram:SpecifiedTradeSettlement>
<ram:InvoiceCurrencyCode>
EUR
</ram:InvoiceCurrencyCode>
<ram:ApplicableTradeTax>
<ram:CalculatedAmount>190.00</…>
<ram:TypeCode>VAT</ram:TypeCode>
<ram:RateApplicablePercent>
19.00
</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
</ram:SpecifiedTradeSettlement><Fa>
<KodWaluty>PLN</KodWaluty>
<P_13_1>1000.00</P_13_1>
<P_14_1>230.00</P_14_1>
<StawkaPodatku>
23
</StawkaPodatku>
<P_15>1230.00</P_15>
</Fa>Field names are not the hard part. Rounding rules, tax categories, exemption reasons and what counts as a valid correction differ between the two, and that is where mappings break.
What it looks like
Screens from software that is in production. The data on them is test or default data — nothing belonging to a client. The interface is in Polish, because these tools were built for Polish finance teams; the documents they produce come out in German or English, and an English interface is a matter of translation, not rework.
Invoices and returns, made readable
Nobody in finance verifies raw XML. These render it — and validate it — before it reaches a tax authority.
Polish SAF-T (JPK), end to end
What your Polish entity files every month. Two interfaces over the same logic, because finance teams work differently.
Technology
Working with clients outside Poland
The things a Polish client never has to ask, and a foreign one cannot look up.
UnitSoftware Grzegorz Giewon is a registered Polish sole proprietorship, EU VAT registered as PL5732296089 — verifiable in VIES. My own invoices go through KSeF; I am not selling you something I have not had to run myself.
How we work
1. A call, 20 minutes. You describe how you invoice today and in what. I tell you whether this is a week of work or a quarter — and whether I am the right person at all.
2. Analysis and quote. You get the scope, an estimate and the commercial terms in writing, in EUR, before anything starts.
3. Delivery in stages. Test environment first, then production. Something working at the end of each stage, with progress visible in your tracker or mine.
4. Handover. Code, documentation and full rights assigned to you in writing, under the governing law of the contract. You stay on maintenance or you carry on without me.
Questions
Does KSeF apply to my company?
A Polish VAT registration on its own does not put you in scope. The test is a fixed establishment in Poland that actually takes part in the supply being invoiced — which requires people, technical resources, sufficient permanence and involvement in the transaction. A postal address or a passive warehouse is not enough. Whether you have one is a tax question, and your advisor answers it. I build what follows from the answer.
We are not in scope, but our Polish suppliers are. What changes for us?
They still have to issue through KSeF, and then hand the invoice to you by an agreed channel — PDF by email, paper, or a visualisation carrying a QR code and a download link. Nothing forces you into the system. If you want that inbound flow automated into your accounts-payable process, that is a build.
We integrated in early 2026. Is anything about to break?
Possibly. The FA(2) schema was replaced by FA(3) on 1 February 2026 — if you integrated before that, you have already felt it. Anyone starting now should build against FA(3) directly.
We need XRechnung as well. Can you do both?
Yes, and that is the reason to talk to me rather than a general KSeF vendor. Germany has required the ability to receive EN 16931 invoices since January 2025, and issuing becomes mandatory from 1 January 2027 above €800k turnover. Same EN 16931 base underneath, two different national layers on top. I have built the converter between them and it runs in production.
Do I have to replace my system?
No. KSeF talks over an API, so in most cases the integration is built into the system you already run. Replacing working software to satisfy a reporting obligation is almost never the cheap option.
What happens when the KSeF API stops responding?
That is a scenario to design for from the start, not to discover in production. I build with queueing, retries and an offline mode, so an outage on the government side does not stop you invoicing. The regulation itself provides for offline issuing — the software has to know how to use it.
How long does an integration take?
Four to six weeks from analysis to production for a typical company system. The biggest unknown is rarely KSeF — it is the state of the code being connected, and, on cross-border projects, how the Polish entity’s data reaches the group ERP.
Our finance team does not read Polish. Are the tools usable in English?
Ask me before you commit to anything on this. The applications were built for Polish deployments and the screenshots on this site show a Polish interface. English localisation is a scoped item, not something I will claim is already done.
Are you a tax advisor?
No. I do not determine whether you have a fixed establishment, and I do not give tax advice. I write the software that implements the answer your advisor gives you.
You are one person. What happens if you become unavailable?
A fair question, and the answer is what I already do from day one rather than an assurance. Code lands in your repository from the start — it is not handed over at acceptance. Copyright is assigned to you in writing. The integration is built on components with public documentation: the manuals are downloadable from this site without an account, so you can judge in advance whether an outsider could follow them. There is no proprietary format and no dependency on my infrastructure after handover. In the worst case you are left with working .NET code that another developer can pick up — not a service that expires with the contract.
Let’s talk about your invoices
Twenty minutes, no commitment. Tell me what you invoice in and where your Polish entity sits — we can work out the rest. I reply in English.
Booking times are shown in Warsaw time (CET/CEST) — the same working day as Berlin, Vienna and Stockholm. Already know what you need? Book an hour of technical consultation instead — code review, integration design, or taking apart the specific problem that is blocking you.
Existing clients: installers, builds prepared for your deployment and documentation are in the client area. Sign-in is by a code sent to your email address — no account to create, no password to remember. Access is granted to the addresses you nominate, and each client sees only their own files.
Support requests: support@unitsoftware.com.pl