Process Overview

The SIGN SE API enables POS systems to create fiscally compliant transaction records. Your POS sends business data to the API, and receives back signed compliance data (control code, status) ready to be printed on the receipt.

How it works

For each fiscal transaction, the POS sends a record request to the SIGN SE API. The API handles signing and compliance processing internally, and returns the control code and status back to the POS.

┌─────────────┐              ┌──────────────────┐
│   Your POS  │────────────▶ │  SIGN SE API     │
│             │◀──────────── │  (fiskaly UAPI)  │
└─────────────┘              └──────────────────┘
  You send:                    You receive:
  • INTENTION record           • Control Code (113 chars)
  • TRANSACTION record         • Status code
                               • Compliance artifacts

Supported document types

SIGN SE supports the following Swedish fiscal document types as defined in SKVFS 2021:16:

Swedish Name	English Name	UAPI Record Type	Control Code
Kassakvitto	Cash register receipt	TRANSACTION::RECEIPT	Yes
Returkvitto	Return receipt	TRANSACTION::CANCELLATION / CORRECTION	Yes
Kvittokopia	Receipt copy	INTENTION::DUPLICATE → TRANSACTION::RECEIPT	Yes
Pro forma-kvitto	Pro forma receipt	TRANSACTION::PRO_FORMA_INVOICE	No (empty)
Övningskvitto	Training receipt	TRANSACTION::RECEIPT with RecordTrainingOption	No (empty)

Two-call record pattern

Each business operation requires two subsequent API calls:

1. INTENTION — Records the intent to start a transaction in the system
2. TRANSACTION — Provides the transaction data; triggers signing

This pattern ensures an unbroken audit trail from the moment a sale begins to the moment it is fiscally signed.

VAT structure

Sweden applies four VAT rates. The UAPI uses the breakdown array with VAT_RATE entries for taxable items and VAT_EXEMPTION entries for exempt items.

Rate	Description	UAPI code	Breakdown type
25%	Standard — general goods and services	STANDARD	VAT_RATE
12%	Reduced 1 — food, hotels, restaurants	REDUCED_1	VAT_RATE
6%	Reduced 2 — books, newspapers, transport, culture	REDUCED_2	VAT_RATE
0%	Zero-rated — some financial, insurance, medical	REDUCED_3	VAT_RATE
N/A	Exempt — outside the scope of VAT	NOT_SUBJECT	VAT_EXEMPTION

💡VAT exemptions

Items fully exempt from VAT (not just zero-rated) must use the VAT_EXEMPTION type with an appropriate exemption code (e.g. NOT_SUBJECT, NOT_TAXABLE, or a numbered CAUSE_1 through CAUSE_22). Do not use VAT_RATE with 0% for truly exempt items.

Offline mode (Kontantnota)

⚠️POS provider responsibility

Offline handling is the responsibility of the POS provider. When the API returns status NO_CONTACT_WITH_KS (status code 2), the POS may issue a receipt without a control code — called a kontantnota. The receipt must display the mandatory text: “Kvitto får skrivas ut - ej registrerat i kontrollservern”.

A kontantnota is a manual handwritten cash invoice — it is not an electronic receipt. When the signing service is unreachable, the POS prints/displays the mandatory offline text and the merchant must issue a handwritten kontantnota to the customer per SKVFS 2014:9.

💡No automatic replay

Unlike SIGN FR, SIGN SE does not define a UAPI-level offline replay protocol. The kontantnota is a manual fallback document. When connectivity is restored, the POS should resume normal electronic operation — previously missed transactions are not retroactively sent.

Response status codes

The API returns one of seven status codes after processing a signing request. Only codes 1 and 2 permit receipt printing:

Code	Name	Receipt Permitted
1	STATUS_OK	Yes — with control code
2	NO_CONTACT_WITH_KS	Yes — without control code (offline)
3	CONTACT_WITH_KS	No
4	NOT_CONFIGURED	No
5	CONTACT_MANUFACTURER	No
6	REPORT_ERROR_24H	No
7	ANMAL_FEL_48H	No

💡Tip

At every POS startup, a status check is performed via INTENTION::OPENING. The system must not proceed to sales mode unless STATUS_OK is returned.

Startup gate (INTENTION::OPENING)

Before issuing any sale receipts, the POS must perform a startup check by creating a record of type INTENTION::OPENING. This verifies the system is properly enrolled and the signing service is reachable.

The startup sequence:

1. POS sends INTENTION::OPENING record to the API
2. API verifies system enrollment and signing service connectivity
3. Response includes the current status code
4. If STATUS_OK (code 1) — POS may proceed to normal operation
5. If any other code — POS must display the appropriate error and must not issue receipts

At the end of the business day, the POS should send an INTENTION::CLOSING record to mark the register as closed.

⚠️Mandatory startup check

A POS that begins issuing receipts without first performing the INTENTION::OPENING check is non-compliant. The status must be verified at every startup before any sales activity.

Refund handling

Returns and cancellations use the RETURN entry type within a TRANSACTION::RECEIPT or TRANSACTION::CANCELLATION record. Key rules:

• Positive absolute values only — refund amounts in entries must always be positive. Negative values are rejected.
• Return entries update the cumulative return amount counter and receipt count.
• The original receipt number should be referenced in the document.references field for audit traceability.

Mandatory receipt fields

Swedish cash register regulations (SKVFS 2021:17) require the following fields on every printed receipt:

#	Field	Description
1	Business name	Company or individual name as registered with Skatteverket
2	Organisation number	Organisationsnummer or personnummer
3	Address	Business location address
4	Receipt date and time	Timestamp of the transaction
5	Receipt number	Sequential number within the register
6	Item descriptions	Description of each good or service sold
7	Item prices	Price per item including VAT
8	Total amount	Total amount paid including VAT
9	VAT per rate	VAT amount broken down by rate (25%, 12%, 6%, 0%)
10	Payment method	How the customer paid (cash, card, etc.)
11	Kassabeteckning	Cash register designation (tillverkningsnummer)
12	Control code	The 113-character avstämningskod
13	Control Server ID	The 17-character identifier of the signing server

💡Receipt copy requirements

A receipt copy (kvittokopia) must additionally display the text “Kopia” at double the standard font size. Only one copy per original receipt is permitted. The copy carries its own control code.

Skatteverket registration

After system commissioning, the merchant must register with Skatteverket within 14 days. This is a three-step process:

1. Register the kontrollenhet — The control system. fiskaly provides the manufacturer, model, and address details.
2. Register the cash register — Using the 16-character tillverkningsnummer as kassabeteckning, and the location address where the register operates.
3. Enrollment — Automatic via the UAPI commissioning step. No manual action required.

The merchant completes steps 1 and 2 via Skatteverket’s online portal using BankID authentication. The POS provider must communicate the tillverkningsnummer and Control Server ID to the merchant.

See the Skatteverket Registration Guide for detailed instructions.

Error handling

When the API returns an error or the signing service rejects a request, the POS must handle it appropriately:

Scenario	API Response	POS Action
Successful signing	200 with compliance data	Print receipt with control code
Signing service offline (status 2)	200 with status NO_CONTACT_WITH_KS	Print with offline text, issue kontantnota
Signing service error (status 3-7)	200 with error status	Do not print receipt; display error to cashier
Validation error	400	Fix request payload and retry
Authentication expired	401	Re-authenticate and retry
Rate limited	429	Exponential backoff retry
Server error	5xx	Retry with exponential backoff

⚠️Never print a receipt on signing error

If the response returns status codes 3-7, the POS must not issue a receipt. These codes indicate configuration errors, enrollment issues, or critical failures that require intervention.

Legislation reference

Reference	Title	Scope
SFS 2007:592	Lag om kassaregister (Cash Register Act)	Defines who must use a cash register and the obligation to connect to a certified control system
SFS 2011:1244	Lag om kontrollsystem (Control System Act)	Establishes the legal framework for cloud-based control systems
SKVFS 2020:9	Föreskrifter om kontrollsystem	Technical requirements for the control system, including signing, counters, and enrollment
SKVFS 2021:16	Föreskrifter om dokumentationstyper	Defines the five fiscal document types (kassakvitto, returkvitto, kvittokopia, pro forma, övning)
SKVFS 2021:17	Föreskrifter om kassaregister	Requirements for receipt content, printing, and cash register operation
SKVFS 2014:9	Föreskrifter om kontantnota	Rules for the manual handwritten cash invoice (kontantnota) when the control system is unreachable

Server-side counters (background)

The signing service maintains cumulative counters per registered cash register. These are managed entirely server-side — the UAPI does not expose or modify them directly. They are relevant for Skatteverket audits:

Counter	Meaning
A	Cumulative sale amount (SEK)
B	Cumulative return amount (SEK)
C	Cumulative VAT for receipts (SEK)
E	Normal receipt count (kassakvitto + returkvitto)
F	Receipt copy count (kvittokopia)
G	Training receipt count (övningskvitto)
H	Pro forma receipt count