Swedish law gives every cash register two separate jobs: signing each receipt, and keeping a journal — a running record of everything the register does. This page explains what the journal is, why it exists alongside signing, and how fiskaly keeps and exports it for you. If you only remember one thing: signing proves a single sale happened; the journal is the complete, tamper-proof history of the register, and fiskaly maintains it on your behalf.
Why journaling exists
Section titled “Why journaling exists”When Skatteverket audits a business, they need to reconstruct everything that happened on a register — not just its sales. That includes actions that never produce a receipt at all: opening the cash drawer, correcting an order mid-transaction, starting up or shutting down the register, or running an end-of-day report.
A signed receipt only proves that one specific sale was recorded. It says nothing about the activity around it. To close that gap, Swedish regulation SKVFS 2021:16 (Skatteverkets föreskrifter om journal- och kontrolldata från kassaregister) requires every register to keep a separate, complete journal of its activity.
What a journal is
Section titled “What a journal is”Think of the journal as the register’s flight recorder — a black box that continuously logs what happens, in order, for later review.
Two properties make it trustworthy:
- Append-only — entries can only be added, never edited or deleted. Once something is recorded, it stays exactly as it was.
- Tamper-evident — because history can’t be rewritten, an auditor can rely on the journal as a faithful account of what really happened.
In short: the journal is the independent, cumulative record of every event on the register, kept in a way that nobody can quietly change after the fact.
A day in the life of a register
Section titled “A day in the life of a register”The easiest way to picture journaling is to follow a single register through one day. Notice that some actions print a receipt and some don’t — but all of them land in the journal:
| Event | Prints a receipt? | In the journal? |
|---|---|---|
| Register starts up in the morning | No | Yes |
| Customer buys a coffee | Yes | Yes |
| Customer returns an item | Yes | Yes |
| Cashier opens the drawer to give change (no sale) | No | Yes |
| End-of-day Z report is run | No | Yes |
The receipt-producing rows are also signed (see below). The others — like opening the drawer — are never signed and never printed, yet they still belong in the audit trail. That is exactly what the journal captures.
Journaling vs. signing
Section titled “Journaling vs. signing”Signing and journaling are two distinct legal obligations, and they’re easy to confuse. Keep them separate in your integration model:
| Signing | Journaling | |
|---|---|---|
| Regulation | SKVFS 2020:9 | SKVFS 2021:16 |
| Scope | Per receipt | Cumulative, across all activity |
| Output | A control code (kontrollkod) printed on each receipt | An append-only ledger, exported as XML on demand |
| Purpose | Proves an individual transaction was recorded | Provides the full audit trail of the register |
Using the day above: the coffee sale is both signed (it prints a control code on the receipt) and journaled. Opening the cash drawer is only journaled. A receipt’s control code is produced during signing — it is not the journal.
Signing and journaling run independently. A receipt can be signed and also produce a journal entry, but many journal events (for example, opening the cash drawer) are never signed and never printed.
What fiskaly handles vs. what you do
Section titled “What fiskaly handles vs. what you do”Journaling is a compliance-as-a-service capability: fiskaly does the heavy lifting of keeping and formatting the journal, so your integration only has to report what happens.
fiskaly handles:
- Storing every event as an immutable, append-only ledger.
- Guaranteeing the format stays compliant over time.
- Compiling the journal into a standards-compliant XML export that validates against Skatteverket’s official schema.
- Retaining the ledger server-side for the full history of the register.
You (the POS) handle:
- Sending events to the Unified API as they happen, in real time.
- Triggering an export when Skatteverket requests journal data.
You never build, format, or validate the export yourself.
How it works under the hood
Section titled “How it works under the hood”fiskaly ingests your events as a continuous stream and appends them to a per-register ledger, keyed by the register’s technical_security_system_id. Because the ledger is append-only:
- Entries are never edited or deleted once recorded.
- Corrections are expressed as new, later events — not by changing history.
- The ledger always reflects the complete, unaltered history for the register.
When Skatteverket requests journal data, you trigger an export for the requested period. fiskaly compiles the relevant ledger entries into XML 1.0 (UTF-8) that validates against Skatteverket’s official journal schema — ready to hand to an auditor without further processing on your side.
Offline journaling
Section titled “Offline journaling”Non-fiscal journal events (INTENTION::EVENT) may be buffered locally while the register is offline and sent once connectivity is restored, preserving their original occurred_at timestamps. Signing has no offline buffering — receipts cannot be signed offline, so there are no offline receipts to journal.
Working with the journal in the API
Section titled “Working with the journal in the API”When you’re ready to integrate, you interact with the journal through a small set of record intentions in the Unified API. This page stays at a conceptual level; see the SIGN SE API specification for full field definitions and payloads.
INTENTION::EVENT— records a non-fiscal journal event. Key fields includecode(the event code), an optionaldescription,occurred_at(when the event happened), anddetails.creators(who triggered it).INTENTION::CLOSING— records a register closing, such as a Z-day report.INTENTION::EXPORT— requests a journal export over a given time range, optionally filtered.
Fiscal events (receipts, returns, copies, and so on) are journaled as part of the signing flow and do not require a separate event call.
If an action changes the state of the register or could be relevant to an auditor, assume it should be journaled — even when it never results in a printed receipt.