An online store needs a fiscal printer less often than people think - but once it has to have one, everything else arranges itself around that single decision. It determines whether the receipt prints itself when an order changes status, or whether somebody retypes the line items by hand. And whether the JPK file that goes to the tax office every month agrees with the sales in the store.
Two terms first, for readers outside Poland. A fiscal printer is a certified device that records every retail sale in tamper-proof memory and prints a fiscal receipt - Polish law requires it for most sales to private individuals. JPK is the standardised sales and purchase ledger file (SAF-T) that every Polish VAT payer files monthly. Below: when a fiscal device is compulsory, how to wire it to BaseLinker (the order-management hub most Polish stores run on) or to WooCommerce, and where the discrepancies in JPK come from.
I write this as the person who implements these integrations, not as the one who settles the taxes - confirm the interpretations with your accountant.
When an online store really needs a fiscal device
A fiscal device is needed when you sell to private individuals and do not qualify for the mail-order exemption. The exemption rests on two conditions at once: the whole payment goes to a bank account (not into someone’s hand), and the records plus proof of payment show who the transaction concerns and what address the goods went to. On top of that there is a list of goods where the exemption does not apply at all.
| Situation in the store | Fiscal device | How you document the sale |
|---|---|---|
| Sales to businesses only, always with a VAT number | usually not needed | invoice |
| Private individuals, payment only online or by transfer, full records | usually not needed | invoice or sales document |
| Cash on delivery, paid into the courier’s hand | check with your accountant | receipt |
| Click and collect with payment on the spot | needed | receipt |
| Goods on the exclusion list: electronics, perfumes and eaux de toilette, car parts, alcohol, tobacco products | needed from the first sale | receipt |
The exemption regulation is issued for a few years at a time and the exclusion list gets amended - before you buy hardware, or before you decide to skip it, ask your accountant to confirm the position as of today.
Fiscal printer or an online till - what works in e-commerce
A fiscal printer is a device with no keyboard and no product database of its own: it receives ready-made receipt content from a computer and only fiscalises and prints it. A fiscal till is standalone, operated by hand by the seller. In an online store the printer almost always wins, because you already have the order data in your system - there is no point retyping it with your fingers.
| Criterion | Fiscal printer | Online till with a keyboard |
|---|---|---|
| Data source | order from the system | keyed in manually |
| Works well for | mail-order sales | pickup points, over-the-counter sales |
| Needs a computer | yes, running the connector app | no |
| Automation | receipt fires on a status change | none |
Every new device today is an online device: it reports to the Central Repository of Cash Registers and needs a permanent internet connection. Prices change, so check the amounts with the hardware vendor, and on a first purchase ask your accountant about the tax relief available for buying an online device.
How to connect BaseLinker to a fiscal printer
BaseLinker does not talk to the printer directly over the internet - it needs a small application on a computer standing next to the printer. The app pulls print jobs from your account and sends them to the device over USB, over a serial port or over the local network. The rollout order looks like this:
- Check the printer’s protocol before you buy. BaseLinker supports the protocols of the most popular manufacturers, including Posnet, Novitus and Elzab (the three names you meet most often on the Polish market), but a specific model can differ. Compare the model against the current list of supported devices before you spend money.
- Install the connector application on a computer that stands where shipping happens and is switched on during packing hours. Not on the laptop that goes home in the evening.
- Run a test print in non-fiscal mode. If the test does not pass, the problem is in the driver or in the port - there is no point configuring anything further.
- Map the VAT rates. The printer has letters A, B, C, D; the store has percentages. That mapping is done once and it is where most of the silent errors are born.
- Shorten the product names. Fiscal devices have a character limit on line item names, and long names with variants get cut off halfway. Set a separate, shortened name format for receipts.
- Set the trigger. It is safer to fiscalise on the status that means “parcel packed” than on order placement alone - otherwise you will print receipts for orders that are never paid for.
- Plan for failure. Decide what staff do when the printer does not respond: does the queue wait, or does the parcel go out without a receipt. Without that decision you find out about the problem at month-end close.
If you are simultaneously fighting the problem that some orders never reach the system at all, close that subject first - it is a different failure and it will distort every count below. I wrote it up in the piece on what to do when BaseLinker is not downloading orders.
An invoice against a receipt - when it is allowed and when it is an expensive mistake
An invoice can be issued against a receipt for a business only if the buyer’s VAT number was already printed on the receipt itself. If the customer bought as a private individual and asks for a company invoice a day later, adding the VAT number after the fact fixes nothing. Issuing an invoice with a VAT number against a receipt without one carries an additional tax liability under Polish rules.
The second trap: a receipt carrying a VAT number up to 450 PLN (or 100 EUR) already counts as a simplified invoice. You do not issue a second, “normal” invoice against it, because then the same sale appears twice in the ledger.
The conclusion for a store is simple: the VAT number field has to be filled in before the order is placed and travel onwards with it. If your checkout does not have it, or the number gets lost along the way, adding that field is usually a few hours of work, not a store rebuild. The rules for issuing the documents themselves I gathered in the piece on invoicing from BaseLinker with KSeF.
Where JPK comes from and why it drifts away from the store
JPK is the file containing the sales and purchase ledger, generated by the accounting software - not by the store and not by BaseLinker. The store supplies the data: till reports, invoices and corrections. The drift almost always appears in one of four places.
| Ledger element | What it means | Typical mistake |
|---|---|---|
| Aggregate till report | daily or monthly receipt-based sales | booked alongside individual receipts instead of replacing them |
| Invoice against a receipt | a document for a sale already included in the report | missing the right marker, so the sale counts twice |
| Return and complaint | a separate returns ledger kept at the till | the return is processed in the store but never recorded at the till |
| Advances and prepayments | when the tax obligation arises | fiscalised at shipping rather than at payment |
The most common scenario I see at clients: the store exports a list of all orders to accounting, while in parallel the accountant enters the till report. The same sale goes in twice and somebody then subtracts the difference in a spreadsheet. The cure is not a better spreadsheet, it is one source of truth per sales type - I described that in the piece on WooCommerce, ERP and e-invoicing integration.
KSeF, Poland’s mandatory e-invoicing system, is already live: the largest taxpayers entered in February 2026, everyone else from April 2026. Invoices issued against receipts follow the same rules, and receipts treated as simplified invoices are excluded from the system.
Selling abroad: OSS and one threshold for the whole EU
When selling goods to consumers in other EU countries, one shared annual threshold of 10,000 EUR applies, counted across all countries together. Below the threshold you settle VAT as if it were a domestic sale. Above it, VAT is due to the consumer’s country, and the simplest route is the OSS procedure - one consolidated return instead of registering in each country separately.
For the store that means three requirements: recognising the delivery country, applying the right VAT rate for that country, and separate numbering and export of foreign documents so they do not land in the Polish ledger. In BaseLinker you do this with document series and automation rules; in WooCommerce with rate configuration and a separate export.
What to check once a month
- Number of receipts versus number of shipments - a difference points to orders the automation skipped.
- Till report versus sales in the store - a gap larger than the value of returns means a mapping error.
- Invoices against receipts - does each one have a counterpart in the report, and does none of them relate to a simplified invoice.
- Returns - do they all have an entry in the returns ledger at the till.
- VAT rates on new products - a product left on the default rate corrupts the ledger for a whole month.
- The printer connector app log - are there jobs stuck in the queue.
When it is worth handing over
I start with a free diagnosis: I look at where sales flow from, where the document is created and where data gets duplicated. Out of that comes a short list of things to fix, ordered by how much manual work each one costs - useful even if we then do nothing together.
If the diagnosis points to a larger job - wiring the store to accounting, automation rules, a VAT number field in checkout, an export for OSS - you get a fixed bid in writing before we start. Projects like that usually land in the 5,000-10,000 PLN net range (Polish market rates). When it is only a matter of keeping the whole thing working after updates, ongoing technical support from 1,000 PLN net per month makes more sense.
Frequently asked questions
BaseLinker - which fiscal printer will fit? One whose communication protocol is on BaseLinker’s supported list and which is an online device. I most often come across Posnet, Novitus and Elzab models, but compatibility is checked per model, not per brand. Ask the vendor about the protocol outright and compare it with the list before buying.
Will BaseLinker generate my JPK file? No. JPK is produced in the accounting software from the sales and purchase ledger. BaseLinker is a data source: it issues documents, keeps a sales register and lets you export it or push it to accounting. The job of the integration is to make sure that export is complete and does not duplicate the till report.
Does the receipt have to physically go in the parcel? With sales recorded on a fiscal device, the receipt is issued to the buyer and the simplest route is putting it in the box. The rules also allow an electronic form with the buyer’s consent, but that requires a suitable device and an agreed delivery channel.
Can I fiscalise without a computer running all the time? Not with a classic fiscal printer, because it is the computer that sends the receipt content to it. You can queue instead: jobs wait and print in batches when packing starts in the morning. One computer switched on in the warehouse is enough for the whole store.
Running a store where something does not work the way it should? I build and rebuild WooCommerce stores - from a single fix to reworking the whole sales flow. Tell me what you are dealing with and I will send back a scope and a price.