Receipts That Satisfy the Law

Romanian retail law requires that a sale produces a fiscal receipt from a certified device. The device keeps its own tamper-evident record, reports to the tax authority, and is the legal account of what the shop sold. Software does not replace it and cannot overrule it.

This inverts the usual relationship. In most integrations the system you are building holds the truth and the peripheral is an output. Here the printer holds the truth and the application has to agree with it.

The device is the authority

A fiscal printer holds its own article table: the products it will print, each bound to a tax group. A sale can only reference articles the device already knows. So the catalogue has to be projected onto the device and kept in step as products change.

Tax groups are the second half. The catalogue stores VAT rates as the business thinks about them; the device stores lettered groups. That mapping is fixed by the device and by law, not chosen. Get it wrong and receipts print with the wrong VAT. Which is not a display bug but an accounting one, discovered at the end of the fiscal period.

Reconciliation is the real feature

The device reports daily totals. The application holds its own sales records. Those two numbers must agree, and when they do not, the device wins.

Building for that changes the design. A sale is posted atomically, so there is never an application record without a corresponding fiscal one. Failures during printing have to resolve to a known state rather than leaving a half-recorded sale. And a discrepancy has to surface immediately, because a divergence found a week later cannot be traced back to a transaction.

Partial correctness has no value here. A receipt is valid or it is not.

Build against the hardware

We integrated against a real device from the first day rather than a simulator. Fiscal devices have behaviour no specification captures: how they respond mid-transaction, what happens when paper runs out during a print, how they recover from a power cut with a sale open.

A simulator encodes what the documentation says. The bugs live where the documentation is wrong, which is the same reason our database tests run against a real database instead of a mock.

What this means for a shop

The operator sees none of it. They scan a barcode, take cash or card, and a receipt prints. The work is in making sure that receipt is one the tax authority accepts, every time, and that the shop's own records match what the device reported.