Ukrainian law requires giving the buyer a fiscal receipt. A software-based cash register (ПРРО) is the way to do that without physical hardware: the program builds the receipt and registers it with the tax service.
The boundary of responsibility first: the store does not sign receipts. It passes the data to a fiscalisation service, and that service talks to the tax authority. The store keeps only the service credentials (encrypted) and a receipt log.
This is a capability of the CMS itself, delivered by a free plugin — not a marketplace service. Basic fiscalisation has no edition gate: it is available in the free build.
What happens on payment
- The order becomes paid — and the fiscal obligation is recorded together with it. A payment without a receipt is impossible: either both, or neither.
- Registration with the tax service runs right after payment; if the service did not answer, a background job keeps retrying until the receipt is registered.
- The buyer gets a receipt with a fiscal number and a QR code to verify it in the tax service cabinet.
Retries always carry the same receipt identifier, so the «Retry» button can never create a duplicate.
Provider: Checkbox and the alternatives
The base provider is Checkbox. The architecture is not nailed to it: any REST-API service that works on the «cash register licence key + cashier» model can be connected. Nothing changes for the merchant — same screen, same form; only the field names follow whichever service you chose.
| Service | State | Note |
|---|---|---|
| Checkbox | connected | The CMS base provider |
| Vchasno.Kasa | planned | Free up to roughly 300 receipts a month, paid above that |
| Cashalot | planned | Local storage with automatic sync to the tax service |
The free state-provided ПРРО cannot be connected at all — it is a standalone application with no API, so there is nowhere to send a receipt from outside. That is a property of the tool, not a limitation of the CMS.
One more limit worth knowing upfront: a provider cannot be added from the admin panel. A new service means a new plugin written by a developer; only then does the provider appear in the list.
Setup — three steps
- Register with Checkbox and create a cash register. Register type — «online store».
- Create a cashier and take two values: the cash register licence key (Registers → your register) and the cashier PIN (Employees → cashier). The cashier must be signed with a qualified or cloud signature.
- Put the keys into the store and switch fiscalisation on.
Where exactly the keys go
Not on the fiscalisation page, but in the Checkbox plugin settings. The form has three fields:
| Field | Source in the Checkbox account | What it is |
|---|---|---|
| Cash register licence key | Registers → your register → «Licence key» | Identifies the register on every request |
| Cashier PIN | Employees → cashier → PIN | How the store authenticates as the cashier, without login and password |
| API address | Pre-filled | Production address; for testing, the sandbox address from the Checkbox documentation |
Secret fields are encrypted and never returned to the form — after saving you see «Value saved». Leaving a field empty does not erase the stored value: to change it, type a new one over it. If you ever see your PIN in plain text somewhere, that is not the store interface.
The «Sales → Fiscalisation» screen
This is where you switch fiscalisation on, pick the provider, set the shift auto-close time and fill in the payment method map. A «Provider ready» badge should appear at the top — if it does not, the keys are empty or could not be decrypted.
The payment method map
For every payment method you must say how it is fiscalised:
| Type | What it is | When to choose it |
|---|---|---|
| Cashless | Card through a payment gateway | Any online card payment |
| Cash | Cash that the store itself fiscalises | Cash on delivery when the store issues the receipt |
| Do not fiscalise | The receipt is issued by someone else | Carrier cash-on-delivery; invoices for companies |
Nova Poshta cash-on-delivery is normally fiscalised by the carrier, not by the store. In that case pick «do not fiscalise», otherwise the receipt is issued twice.
Shifts and the Z-report
Receipts live inside a shift, but you barely need to manage it by hand:
- Opening is lazy — the first receipt of the day opens the shift by itself.
- Closing is automatic — the Z-report is produced at the configured time, and forcibly if the shift has been open for more than 23.5 hours: the tax service does not allow a shift to run longer than a day.
- The «Opening…» and «Closing…» states are the provider signing asynchronously, not an error. The very first receipt after opening may not go through on the first attempt — the store recognises this state and retries.
Test mode versus production
Before going live, test with a test cashier: those receipts never reach the tax service.
| Sign | Test | Production |
|---|---|---|
| Cashier signature | test | real qualified or cloud signature |
| Fiscal receipt number | prefixed with TEST- | no prefix |
| Receipt at the tax service | no, training only | yes, legally binding |
A production receipt is irreversible. It reaches the tax service and can only be cancelled by a separate return document — which is why end-to-end testing is done with a test cashier or in the provider sandbox.
Returns
A return receipt is a separate fiscal document. The button appears on the order card once the sale receipt is registered. Currently one full return per order is created.
If something goes wrong
| Symptom | What it means | What to do |
|---|---|---|
| Provider list is empty | The plugin is not active | Enable the plugin under «Plugins» |
| «Secret unavailable» badge | The encryption master key changed | Re-save the licence key and PIN in the plugin settings |
| Receipt in «Rejected» state | Final registration failure | Check the «Error» column, fix the cause, press «Retry» |
| «Accepted, awaiting tax service» | The provider took the receipt asynchronously | Nothing — the number arrives on its own |
| Shift stuck at «Opening» | Asynchronous provider signature | Wait: the background job will finish the state |
Limits worth knowing before launch
- VAT. Line items currently go out in «no VAT» mode. If you are VAT-registered, the tax rates have to be mapped — a separate step before going live.
- Partial returns are not implemented: one full return per order.
And separately: this material describes technical setup, not tax obligations. Whether you need a ПРРО at all, at which rate and with which exemptions, is a question for your accountant and for the official sources: tax.gov.ua and the documentation of your chosen provider, for example checkbox.ua.