Fiscal Receipts in the CRM: What Prints Itself and What Waits for a Click

The payment arrives through a card link, the invoice flips to paid, and a minute later the customer has a fiscal receipt with a code and a link. Nobody opened the cash register. That is the normal path in Firmspace when three conditions meet: the Ukrainian PRRO is connected, the payment counts as a card payment, and automatic fiscalisation is switched on. Remove any one of them and the same payment is recorded without a receipt — correctly, but not fiscally.

The integration is called Checkbox, and it is optional. A firm connects it in Settings → Integrations with the cash key, the cashier login and password, the cashier name and the department. The credentials are checked by a real cashier sign-in before they are saved, so a wrong key fails at the connection step instead of at the first sale. The secrets are stored encrypted and are not shown again in the interface.

Fiscalisation is a Ukrainian requirement, not a universal CRM feature. The platform guards the operation by market: a firm outside Ukraine gets a clear refusal instead of a broken receipt. Inside Ukraine the rule is narrower than "every payment needs a cheque". A card payment through acquiring — monobank, LiqPay, WayForPay or crypto — is treated as a card sale, and the receipt is expected. A bank transfer against an invoice is usually covered by the invoice and the act; the receipt can still be printed, but nothing forces it.

There are two entry points. The automatic one runs after a full payment: the invoice is marked paid, and if the advice says a receipt is needed and the automatic mode is on, the receipt is printed. A partial payment does not trigger it, because the invoice stays open. The manual one is a button on the invoice — the same code path, with a person deciding the moment.

A sale at the POS is fiscal by nature. The cashier scans or picks goods, chooses cash or card, and the CRM creates a paid retail invoice and writes off the stock. When Checkbox is connected and automatic fiscalisation is on, the receipt is printed in the same flow. If it fails, or if the automatic mode is off, the sale is not lost: the error or the reason is stored on the invoice, and the cashier can retry. That division — money and stock first, fiscal proof second — is deliberate.

What goes on the receipt comes from the invoice, not from a separate cash-register catalogue. Each line carries its description, quantity and price; the amount is what was actually paid, or the full total if nothing has been paid yet. The tax rate on the line is matched to the cash register's tax list: twenty percent maps to the letter A, seven percent to B, and anything else falls back to the VAT entry. An invoice without items cannot become a receipt, and the refusal says so.

The shift is the part most people forget. The first receipt opens a shift automatically; the Z-report closes it and stores the turnover and the receipt count in the CRM journal. The cash register's own shift history can be pulled back for reconciliation, so the CRM and the PRRO can be compared instead of trusted blindly. Closing a shift in the CRM is a deliberate action, not a side effect of closing the browser.

The customer copy is sent by Checkbox itself, not by the CRM's mail module. The address and phone come from the linked contact first, then from the company; if neither exists, the receipt stays in the cash register and the invoice still holds the code and the link. The CRM stores the fiscal code, the receipt URL, the date and the pay type — enough to find the document later without logging into the cash register.

Failure is treated as data, not as a rollback. If Checkbox rejects the call, the message — up to three hundred characters — is written onto the invoice, the payment remains recorded, and the accountant can see what happened. A receipt is issued once per invoice; a second attempt is refused rather than duplicated. If the link was lost, it can be re-read from Checkbox by the receipt id, which is how old receipts get their clickable URL back.

Returns follow the same discipline. A credit note is created, the goods return to stock, and a return receipt is printed with a reference to the original sale receipt. It only works if a sale receipt exists; a bank-transfer invoice with no fiscal receipt has nothing to return fiscally. And it works once: the CRM refuses a second return against the same receipt.

The AI assistant touches this process with one tool and a confirmation card. You say "print the receipt for invoice RE-2026-5", and the assistant finds the invoice — including the Cyrillic lookalikes people type or dictate, so РЕ-2026-5 lands on RE-2026-5 — and proposes the action with the invoice number and the pay type. Nothing is printed until the person confirms. Cash or card is a choice on the card, not a guess hidden in the model.

That confirmation is not red tape. A fiscal receipt is a legal event with a number, a shift and a tax consequence; undoing it means a return receipt, not a delete button. The assistant is allowed to prepare the operation, choose between cash and card when asked, and report the fiscal code afterwards. It is not allowed to decide that a receipt is unnecessary, to issue a second one, or to work around the market guard.

The practical setup list is short. Connect Checkbox and test the cashier sign-in. Decide whether automatic fiscalisation should be on. Check the tax rate on the products and services that actually appear on invoices. Make sure the contacts you invoice have an email or a phone, otherwise the customer copy has nowhere to go. And keep the shift discipline: an open shift at midnight is a question for the accountant, not for the AI.

What this article cannot tell you is how much time a particular firm saves, how many of its payments are card payments, or how often receipts fail in practice. Those numbers live in the firm's own invoices and cash-register reports, and without access to them any figure would be invented. The mechanism is verifiable in the code; the value depends on the volume and on how the firm works today.

The point of the automation is not that a receipt appears by magic. It is that the routine click moves to the system, while the obligation, the confirmation and the exception stay with a person. That is a smaller promise than "fully automatic accounting", and a more useful one: the receipt prints itself when the conditions are right, and asks when they are not.