If your Polish subsidiary still invoices out of a spreadsheet, you are not unusual. Excel survived longer than most ERP rollouts because invoicing used to mean producing a document a human reads.
That stopped being true on 1 April 2026, when KSeF became mandatory for all active Polish VAT payers. One narrow exemption remains: until 31 December 2026, invoices may still be issued outside KSeF if the total monthly gross value documented by such invoices does not exceed PLN 10,000 (Ministry of Finance guidance). That is five months, and the exemption is lost from the invoice that crosses the threshold, not from the following month.
This is not an argument that Excel is bad software. It is a list of the specific points where it breaks when you connect it to KSeF.
KSeF does not accept tables, only FA(3) XML
Polish VAT law defines a structured invoice (faktura ustrukturyzowana) precisely: an invoice issued through KSeF to which the system has assigned an individual identifying number (Article 2 point 32a of the VAT Act). Both conditions apply at once. A file that never reached KSeF is not a structured invoice, however correct it looks.
All structured invoices issued from 1 February 2026 use the FA(3) schema (Ministry of Finance briefing on the FA(3) logical structure). It is a hierarchical XML document with several hundred fields, organised into Naglowek (header), Podmiot1 (seller), Podmiot2 (buyer) and Fa (invoice body), with nested line items, closed value dictionaries, and firm rules about which field may appear in which context.
A spreadsheet is a flat table. No nesting, no types, no XSD validation. You can of course write a macro that concatenates XML from strings. At that point you no longer have a spreadsheet, you have an unmaintained parser that has to track every schema change the Ministry of Finance publishes.
<Faktura xmlns="http://crd.gov.pl/wzor/2025/06/25/13775/">
<Naglowek>
<KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0">FA</KodFormularza>
The namespace and schema version are the first two lines where a hand-assembled file falls over. KSeF validates the XML against the XSD structure automatically and rejects non-conforming documents outright, with no server-side correction (KSeF 2.0 Handbook, part II). A rejection means the invoice was never issued.
Sequential numbering is the first thing to blow up
Article 106e(1)(2) of the Polish VAT Act requires a sequential number, assigned within one or more series, that uniquely identifies the invoice. The KSeF number does not replace it: KSeF assigns its number after accepting the document, while your own number has to exist before you send it.
In a spreadsheet, that number comes from something like =MAX(A:A)+1. Fine for one user. The failure starts with two people in the same file on a shared drive: both read the same maximum, both get the same next number, one save overwrites the other, and a "conflicted copy" appears. In a proper invoicing system, number assignment is atomic: the counter row is locked for the duration of the transaction, so two concurrent issues physically cannot receive the same number. A spreadsheet has no such mechanism and never will.
A concrete case from a Polish accounting bureau: a client issued twelve invoices a month from a file on a shared drive. In May, the bookkeeper and the owner worked in parallel. Result: two invoices numbered FV/2026/05/007, and a correction to a document that had already been accepted by KSeF.
Excel quietly corrupts the data KSeF will not forgive
Spreadsheets are designed to guess what the user meant. For fiscal data that is a defect, not a feature.
NIP treated as a number. Entered without a leading apostrophe, a Polish tax ID loses leading zeros and can flip into scientific notation (
5.26E+09). The buyer's NIP must land in theNIPfield specifically, because that is the only way the invoice is correctly made available to the buyer inside KSeF.Dates. CSV import auto-conversion turns
2026-08-04into04.08.2026,08/04/2026, or a serial number. FA(3) expects ISO format.Rounding. Floating-point sums drift by fractions of a grosz. KSeF checks internal consistency, so a one-grosz gap between the sum of line items and the declared total is enough for a rejection.
Autocorrect. Product codes, internal indexes and account numbers get silently reinterpreted as dates or formulas.
Executable cells. This one is not theoretical. In a CSV file, any value starting with
=,+,-or@is treated by Excel as a formula. That is why every such value in a Biurko register export is prefixed with an apostrophe before it is written to file. A contractor list downloaded from an untrusted source is an attack vector, not an accounting document.
A spreadsheet cannot hold the KSeF number, the UPO, or the submission state
Issuing through KSeF does not end when the file is sent. Once the document is accepted, the system assigns a KSeF number and makes a UPO (Urzędowe Poświadczenie Odbioru, the official acknowledgement of receipt) available. The UPO, not your copy of the XML, is the proof that the invoice was effectively issued.
So the whole document lifecycle has to live somewhere: session, submission, intermediate status, retry after an error, UPO retrieval, signature verification on the UPO, archiving. Then the exceptional modes: offline24, where the invoice must reach KSeF no later than the next business day, and emergency mode, with seven business days from the end of the declared outage. Each has its own deadline, and missing one has to be detectable in advance.
There is one more consequence. From 1 January 2027, the KSeF number is to appear in the payment transfer reference for an invoice. A number your spreadsheet never captured cannot reach the payment, or the reconciliation that follows it.
This is a state machine, not a column. A manually maintained "sent Y/N" column stops being true in week two.
When Excel is still fine
Honestly: the spreadsheet has legitimate uses alongside KSeF, just not as the sales ledger.
Sales under the PLN 10,000 monthly threshold until 31 December 2026, provided somebody actually tracks the running total.
B2C invoices, which are outside the KSeF submission obligation.
Price lists, margin models, budgets, scenario work. Excel beats every system here.
Analysis of data already issued. Exporting a purchase register or sales summary to XLSX for the accountant is an ordinary workflow.
One-off migration: cleaning up contractor and product data in a sheet before loading it into a system.
The rule is simple: Excel as input and output, never as the ledger. If you are not ready to pay for software, the Ministry of Finance provides a free KSeF Taxpayer Application in web and mobile versions (details on ksef.podatki.gov.pl). It is limited, but it produces valid XML, and that is the current minimum.
Checklist before you close the spreadsheet for good
Confirm whether the exemption still applies to you: calculate gross invoiced sales for each month of 2026 separately.
Export the contractor list and verify every NIP before importing it. Watch for lost leading zeros and scientific notation.
Fix one numbering format per document type, then check the current period for duplicates and gaps.
Decide who in the company may issue invoices. In a spreadsheet the question did not exist; KSeF verifies permissions on every submission.
Set up KSeF authentication for the entity and test a submission on the demo environment before touching production.
Plan UPO archiving alongside the XML. A PDF visualisation is not proof of issuance.
Keep Excel where it is genuinely good: analysis, not issuance.
Conclusion
Excel does not lose to KSeF because it is old. It loses because KSeF demands three things a spreadsheet structurally lacks: a rigid XML structure, a guarantee of number uniqueness, and durable document state after submission. Each can be worked around with a macro. None can be worked around for long.
Biurko issues invoices directly in the FA(3) structure, enforces numbering continuity, retrieves and verifies UPO receipts, and exports registers back to CSV and XLSX if your accountant prefers to work in a sheet. Create a free account at biurko.io and test a submission with your own data. The free plan is permanent, not a trial period.
FAQ
Can I still issue invoices in Excel in 2026? Yes, but only outside KSeF and only while you qualify. Until 31 December 2026 this covers taxpayers whose monthly gross value of invoiced sales does not exceed PLN 10,000. Once you cross the threshold, the KSeF obligation applies from the invoice that crossed it.
Can I import an invoice from Excel into KSeF? Not directly. KSeF accepts only XML files conforming to the FA(3) structure. A spreadsheet can feed data into software that generates the XML, but an XLSX or CSV file will not be accepted by the system itself.
Does the KSeF number replace my own invoice numbering? No. The KSeF number is assigned by the system after the document is accepted. The obligation to assign your own sequential identifying number comes from Article 106e(1) of the VAT Act and stays with the issuer.
What happens if KSeF rejects my XML file? The invoice was not issued. The system does not correct documents on its side: you fix the cause of the rejection and resubmit. The KSeF number and UPO arrive only after the document is successfully accepted.
Do I need paid software to invoice through KSeF? No. The Ministry of Finance provides a free KSeF Taxpayer Application in web and mobile versions. Paid tools earn their place at higher document volumes, across multiple entities, and where batch submission and automatic UPO retrieval matter.