Poland made e-invoicing through KSeF mandatory for the largest taxpayers on 1 February 2026 and for the remaining active VAT payers on 1 April 2026. The smallest taxpayers join on 1 January 2027, the same date administrative penalties under Article 106ni of the VAT Act start applying.
At the same time, roughly one in seven new sole proprietorships registered in Poland in 2025 belonged to someone who is not exclusively a Polish citizen. Add foreign groups running Polish subsidiaries, and you get a large population of businesses that must operate a Polish-only tax system correctly, in a language they do not fully control.
Here is where interface language turns into real money, and where a multilingual tool still cannot help you.
KSeF speaks Polish and always will
The FA(3) logical structure uses Polish field names: Podmiot1, DataWytworzeniaFa, P_13_1, Adnotacje. API errors come back in Polish. The UPO (official confirmation of receipt) is a Polish administrative document. The free Taxpayer Application released by the Ministry of Finance guides users in Polish.
This is not a complaint about the Ministry. Every national fiscal system works this way. The practical conclusion is different: since the official layer is Polish by definition, the only place a user's own language can exist is the software sitting on top of the API.
Invoicing software is therefore not a thin API wrapper. It is the translation layer between a Polish tax regime and the person who has to operate it without mistakes.
Where the language gap becomes a cost
Business-level English is enough for a client email. It is not enough to separate Polish tax concepts that are precise and counterintuitive. The recurring failure points:
Field or concept What gets confused Consequence Issue date vs sale date Treated as the same field Wrong VAT period, JPK correction Split payment (MPP) Ticked "just in case" Incorrect invoice content, buyer disputes Reverse charge Mixed up with 0% rate and exemption Cross-border transaction booked wrong Correction vs duplicate vs cancellation Wrong document type chosen Unfixable once submitted to KSeF Subjective vs objective VAT exemption Legal basis missing on the invoice Buyer rejects the invoice
A concrete support case: a construction business owner applies reverse charge to a domestic Polish client, because that is how it worked in the country they came from. The Polish label on screen is understood only partially, so the most neutral-sounding option wins. The invoice goes to KSeF. After submission the only repair path is a correction invoice, not an edit.
At that point the difference between a Polish and an English interface is not convenience, it is your monthly count of correction documents.
KSeF error messages are a second language inside the language
Even a native Polish speaker does not immediately know what to do with a message stating that a given tax context is not authorised to issue an invoice on behalf of the seller. For a non-native speaker it is a wall of text, and the natural response is to retry the submission, then retry again.
Biurko passes every KSeF error code through a translation layer. Placeholders such as the NIP (Polish tax ID) or the offending field are extracted from the raw Polish message, and the user receives a description in their own language together with the next action. Purely infrastructural codes the user cannot act on are replaced in notifications by a generic "retry or contact support" message, while the full diagnostic detail stays in the invoice activity log for whoever is technical.
That distinction is the actual product difference. A translated button helps once. A translated error message helps every time something breaks.
Language belongs to the user, not to the company
The most common mistake in multilingual B2B apps is storing language on the company account. Real companies are several people with several languages.
A typical setup: the bookkeeper works in Polish, the business owner in Ukrainian, the financial controller of the foreign parent in English. All three work on the same invoices.
In Biurko, language is a user attribute. Within a single company that means:
the panel, forms and dictionaries render in the language of the signed-in person,
in-app and push notifications are generated in the recipient's language, not the language of whoever triggered the action,
transactional emails (KSeF acceptance, rejection, team invitation) are sent in the recipient's language,
live events such as a KSeF transmission status change are broadcast per locale, so an open invoice screen repaints in that specific person's language.
Practical effect: the bookkeeper does not have to translate a notification for the client, because the client already received it in their own language.
What multilingual does not solve
Better said up front than discovered after the subscription starts:
The invoice PDF is generated in Polish. That is deliberate: the document goes to a Polish counterparty, a Polish tax office and Polish bookkeeping. A bilingual PDF layout does not exist yet and is a known limitation, not a hidden feature.
The XML sent to KSeF is Polish. FA(3) has no language variants, so we translate the layer around the document, never the document itself.
The UPO and official documents stay Polish. Their content comes from the Ministry's system.
An interface does not replace an accountant. Understanding the words "reverse charge" in English does not tell you whether it applies to your transaction. That question belongs to your accountant or to a binding individual tax ruling.
Translation does not move deadlines. Obligations and dates are identical in every language.
Checklist: how to test a tool for language quality
Switch the interface to your target language and issue a complete VAT invoice from scratch, not just look at the landing page.
Check the dictionaries, not the menu: VAT rates, units of measure, document types, invoice annotations.
Trigger a KSeF error on purpose, for example by submitting an invoice with an invalid buyer NIP, and see which language the message comes back in.
Invite a second user with a different language and confirm they receive notifications in theirs, not yours.
Open the transactional emails, the most commonly untranslated layer of any SaaS.
Ask directly which language the invoice PDF is generated in, and whether a bilingual version exists.
Check the language of support. An English interface with Polish-only support is half a solution.
Conclusion
KSeF is mandatory, Polish-only, and unforgiving once a document is submitted. Interface language is therefore one of the few remaining places where you can prevent errors instead of correcting them afterwards. What counts is not translated buttons but translated difficulty: error messages, tax dictionaries and notifications, resolved separately for every person in the company.
Biurko runs in Polish, English and Ukrainian, translates KSeF error codes, and stores language per user. Create a free account at biurko.io and test the panel in your language before you test it on a real invoice.
FAQ
Is there KSeF invoicing software in English? Yes. Biurko provides the full panel in English, including translated KSeF error messages and notifications. The XML submitted to KSeF and the UPO receipt remain in Polish, because the national FA(3) schema is defined that way.
Does the Ministry of Finance Taxpayer Application have an English version? The free Taxpayer Application published by the Ministry of Finance guides users in Polish. A non-Polish interface is available only through commercial software integrated with the KSeF API.
Is an invoice issued through an English interface valid in Poland? Yes. The panel language does not affect the document. The invoice is built against the FA(3) structure and submitted to KSeF in exactly the same form as one issued in Polish.
Can users in the same company use different languages? Yes. In Biurko language is a user account setting, not a company setting. A Polish bookkeeper and an English-speaking controller work on the same data, each receiving notifications in their own language.
Can the invoice PDF be bilingual? Not currently. The PDF is generated in Polish because it is addressed to Polish counterparties and bookkeeping. A bilingual PDF layout is not yet available.