This article describes special features that must be taken into account in the context of Lithuanian fiscalisation, or that arise from the laws and technical requirements. An overview of the terms used in this article and their meanings can be found in the article Terms of Lithuanian fiscalisation.

Contents overview:

• Prerequisites – what is required for compliant cash register operation?
• Security module – what is it and what special functions are associated with it?
• iEKA communication – what needs to be considered?
• Special processes – what are the special features of:
  • Returns/exchanges
  • Technical journal
  • Totals in reports
  • Deposits and withdrawals
  • Transaction cancellation
  • Sale of special goods
• Reports – which reports must be generated and what data must they contain?
• EKJ – what is it and what are the requirements?

Prerequisites

In order for a cash register to be put into operation in Lithuania, the following is required:

Service Company

Only representatives of a certified service company may commission cash registers and connect them to the iEKA service and the security module.

You can define a service company via the configuration Lithuania. A contract between the distributor and the service company is required in order for a service company to be selected (available as a drop-down element in the configuration). Once the contract has been stored/activated in the RetailForce portal, an entry for the service company is available in the configuration.

Security module

Every cash register must be equipped with a certified security module. The security module is only loosely related to the service company. However, when purchasing a security module, please ensure that it is also supported by the RetailForce system.

The tasks of the security module include signing transaction data, managing grand total counter, and securely storing private and public keys and digital certificates.

Service Company parameter

Once a service company has been selected in the configuration and assigned to an entity (organisation, company, store, terminal), an employee of the service company can enter the service company parameters (see Terms of Lithuanian fiscalisation) for each terminal.

If the cash register has a security module and the service company parameters have been entered, the cash register (the client) can be put into operation.

Security module

Data from fiscal transactions is automatically signed by the RetailForce fiscalisation service via the security module.

The security module is activated automatically during initialisation. The necessary digital certificates are also loaded into the security module during this process.

Digital certificates

Certificates used for signing data and other purposes must be renewed before they expire.

To exchange certificates, the fiscalisation service provides the function:

• POST /api/v1/management/lithuania/{clientId}/certificate-update

When the endpoint is called, the fiscalisation service (middleware) checks whether the certificates need to be replaced. If a certificate is nearing the end of its validity period, it is replaced with a newer one.

Update necessary

A certificate exchange is only possible after a daily close/report (Z) (EndOfDay document). For each EndOfDay document, the property "certificatesUpdateRequired" is returned in the fiscalResponse.

If the value of "certificatesUpdateRequired" = true, the upstream system must initiate a certificate exchange using the endpoint POST /api/v1/management/lithuania/{clientId}/certificate-update.

Values Security module

Values stored in the security module (sales counter, cash register ID, number of signed documents, and others) can be read using the endpoint

• GET /api/v1/management/lithuania/{clientId}/param-stick 

Reset Test-Security module

Unlike security modules for live operation, test security modules can be reset to factory defaults. This is particularly important during the implementation phase if errors have occurred (e.g. in iEKA communication – see below).

A reset is performed using the endpoint

• DELETE /api/v1/management/lithuania/{clientId}/reset-stick

iEKA communication 

In addition to signing transaction data via the security module, data transfer to the online system of the tax authorities (iEKA) is one of the key requirements of Lithuanian fiscalisation.

The RetailForce system handles automatic communication with iEKA. iEKA limits the number of data records that can be transferred within a certain period of time, as well as the frequency of transfers/requests within a period of time. For this reason, the fiscalisation service does not transmit data to iEKA in real time, but rather asynchronously.

Debugging

Data used as the basis for data transmission is stored by the fiscalisation service in the folder (e.g. on Windows systems) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Process

The folder described above usually contains three subdirectories:

• send - Data to be transferred to iEKA (data that has not yet been transferred).
• accepted - Data that was sent to iEKA and was accepted by the system.
• 20xy - Response from iEKA after data validation for each individual data record (represents the year in which the transaction was recorded)

Data transmission to iEKA undergoes the following process:

1. RetailForce Client receives data from the upstream system ("cash register") and
2. converts it into the iEKA format (but as a JSON file).
3. This JSON file is stored in the \\lithuaniaFiscalFiles\send folder.
4. Files in the \\send folder are periodically (asynchronously) transferred to the iEKA service. Before transmission, the JSON files are converted to iEKA XML format.
5. Once the data has arrived in the iEKA system, iEKA confirms receipt.
6. At this point, the transaction data is moved from the \\send folder to the \\accepted folder, together with confirmation received from iEKA.
   1. If data could not be transferred to iEKA, it remains in the \\send folder and the fiscalisation service attempts to transfer it at a later point in time.
7. The iEKA system now validates the transferred data. The validation status must be actively queried by the data transfer module (fiscalisation service)
8. This query is also performed periodically due to communication restrictions on the part of iEKA (see above).
9. The result of the validation status query is stored to the 20xy folder (data is moved from \\accepted to \\20xy).

Transaction status

Upstream systems ("cash registers") can check the status of individual transactions using the following functions:

• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-ieka-document-number/{iekaDocumentNumber} and
• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-document-number/{documentNumber}

Special processes

Returns / exchanges of goods

Returns (e.g. exchange of goods) are considered non-fiscal documents in Lithuania, i.e. non-fiscal transactions. They are transmitted to the iEKA system but are not signed via the security module. This also means that return documents do not affect the security module's sales (grand total) counters.

In order for the RetailForce system to correctly recognise returns as such, the following properties must be set:

• "documentType": 0 / "[0] = Receipt"
• "cancellationDocument": true
• "documentReference" - reference to another document (the original sales document) must be set
• Negative transaction values ("GrossValue", "NetValue", "TaxValue", "Amount")

Technical journal

Technical processes must be recorded in Lithuania. As in other countries, this is done using the Technical Event Log / Technical Journal or AuditLog.

The following events in particular must be recorded:

• Cash drawer opening (DrawerOpen) – must be transmitted by the upstream system.
• Document cancellation (DocumentCancelDocument) – is recorded automatically.

For more details, see the article Technical Events Lithuania.

Totals in reports

In reports (report (Z) – daily fiscal report, report (X) – daily interim report), certain (grand) totals must be shown separately. To ensure this, certain rules must be observed when transferring data between the source system ("cash registers") and the fiscalisation service.

For details, see the article Summation in reports Lithuania.

PayIn & PayOut

Lithuanian fiscalisation requires that cash balance in the cash register (drawer) be transmitted to iEKA. To ensure this, pay in and pay our transaction (e.g. change deposits) must also be transmitted from the upstream system to the RetailForce fiscalisation service (middleware) in the form of PayIn and PayOut documents ("documentType": 11 / "[11] = PayIn" and "documentType": 10 / "[10] = PayOut" with "businessTransactionType": "[90] = MoneyTransfer").

The following must be noted for PayIns and PayOuts:

Examples JSON payloads

PayIn:

(Release: 1.11.4; DOM-Version 1.6.2)

{
	"ModelVersion": "1.6.2",
	"UniqueClientId": "bef09871-a19b-4eba-9f88-f14e0b482ab3",
	"UniqueCashRegisterId": "0001-0007",
	"FiscalModuleVersion": "1.11.4.593",
	"FiscalCountryModuleVersion": "0.9.7",
	"SoftwareName": "RetailForce NeverPOS",
	"DocumentGuid": "da8e52c6-fb33-4b07-8f9b-7962bc0a0002",
	"DocumentId": "PI001",
	"DocumentNumber": "PI202500001",
	"CreateDate": "2025-12-16T14:43:08.6110527+02:00",
	"BookDate": "2025-12-16T14:43:08.6110527+02:00",
	"DocumentType": 11,
	"User": {
		"Id": "7b1e3d67-25d0-4ad1-a230-5264b3aa1fca"
	},
	"PositionCount": 1,
	"DocumentIssueType": 0,
	"FiscalDocumentNumber": "0",
	"FiscalDocumentStartTime": 0,
	"Positions": [
		{
			"Type": "[3] = Booking",
			"Caption": "Pridėti grynuosius pinigus",
			"BusinessTransactionType": "[11] = PayIn",
			"VatIdentification": 10,
			"VatPercent": 0.0,
			"NetValue": 20.0,
			"GrossValue": 20.0,
			"TaxValue": 0.0,
			"PositionNumber": 0,
			"DeletedPosition": false,
			"AdditionalFields": {},
			"ExternalIdentifier": []
		}
	],
	"Payments": [
		{
			"Amount": 20.0,
			"CurrencyIsoCode": "EUR",
			"UniqueReadablePaymentIdentifier": "CashMovement",
			"AdditionalFields": {},
			"PaymentType": 0,
			"ExternalIdentifier": []
		}
	],
	"AdditionalHeader": [],
	"AdditionalFooter": [],
	"FiscalAdditionalFields": {}
}

PayOut:

(Release: 1.11.4; DOM-Version 1.6.2)

{
	"ModelVersion": "1.6.2",
	"UniqueClientId": "277a1220-5af4-4fc4-900f-694dcc0a6227",
	"UniqueCashRegisterId": "0001-0007",
	"FiscalModuleVersion": "1.11.4.593",
	"FiscalCountryModuleVersion": "0.9.7",
	"SoftwareName": "RetailForce NeverPOS",
	"DocumentGuid": "da8e52c6-fb33-4b07-8f9b-7962bc0a0002",
	"DocumentId": "PO0002",
	"DocumentNumber": "PO202500001",
	"CreateDate": "2025-12-16T12:08:08.6110527+02:00",
	"BookDate": "2025-12-16T12:08:08.6110527+02:00",
	"DocumentType": 10,
	"User": {
		"Id": "7b1e3d67-25d0-4ad1-a230-5264b3aa1fca"
	},
	"PositionCount": 1,
	"DocumentIssueType": 0,
	"FiscalDocumentNumber": "0",
	"FiscalDocumentStartTime": 0,
	"Positions": [
		{
			"Type": "[3] = Booking",
			"Caption": "Grynųjų pinigų išėmimas",
			"BusinessTransactionType": "[10] = PayOut",
			"PayOutType": null,
			"VatIdentification": 10,
			"VatPercent": 0.0,
			"NetValue": -12.0,
			"GrossValue": -12.0,
			"TaxValue": 0.0,
			"PositionNumber": 0,
			"DeletedPosition": false,
			"AdditionalFields": {},
			"ExternalIdentifier": []
		}
	],
	"Payments": [
		{
			"Amount": -12.0,
			"CurrencyIsoCode": "EUR",
			"UniqueReadablePaymentIdentifier": "CashMovement",
			"AdditionalFields": {},
			"PaymentType": 0,
			"ExternalIdentifier": []
		}
	],
	"AdditionalHeader": [],
	"AdditionalFooter": [],
	"FiscalAdditionalFields": {}
}

Abortion / Abandonment of transactions

Any abandonment of a transaction prior to its completion must be recorded in Lithuania. The endpoint

• POST /api/v1/transactions/cancelDocument

is used for this purpose.

The transmitted JSON payload should contain

• all positions recorded up to the point of abandonment, but
• an empty "Payments" object.

Example:

(Release: 1.11.4; DOM-Version 1.6.2)

{
	"ModelVersion": "1.6.2",
	"UniqueClientId": "bef09871-a19b-4eba-9f88-f14e0b482ab3",
	"UniqueCashRegisterId": "T001-1502",
	"FiscalModuleVersion": "1.11.4.593",
	"FiscalCountryModuleVersion": "0.9.7",
	"SoftwareName": "x x 1.0",
	"AutomaticVatCalculation": 0,
	"DocumentGuid": "da8e52c6-fb33-4b07-8f9b-7962bc0c0002",
	"DocumentId": "0002",
	"DocumentNumber": "202500001",
	"CreateDate": "2025-12-16T15:19:08.6110527+02:00",
	"BookDate": "2025-12-16T15:19:08.6110527+02:00",
	"DocumentType": 0,
	"User": {
		"Id": "7b1e3d67-25d0-4ad1-a230-5264b3aa1fca"
	},
	"PositionCount": 2,
	"DocumentIssueType": 0,
	"FiscalDocumentNumber": "0",
	"FiscalDocumentStartTime": 0,
	"Positions": [
		{
			"ItemCaption": "Testavimo prekė 222",
			"Discounts": [],
			"Type": "[0] = Item",
			"Quantity": 1.0,
			"QuantityUnit": {
				"Id": null
			},
			"ItemId": "8639d547-3db3-4a44-e0c3-08de3c72db58",
			"ItemType": 0,
			"BaseNetValue": 1.77686,
			"BaseGrossValue": 2.15,
			"BaseTaxValue": 0.37314,
			"BaseTaxValue2": null,
			"BusinessTransactionType": "[0] = Revenue",
			"VatIdentification": 1,
			"VatPercent": 21.0,
			"NetValue": 1.78,
			"GrossValue": 2.15,
			"TaxValue": 0.37,
			"ItemTaxType": 0,
			"PositionNumber": 0,
			"DeletedPosition": false,
			"AdditionalFields": {},
			"ExternalIdentifier": []
		},
		{
			"Type": "[10] = Total",
			"Rounding": 0.0,
			"BaseValue": 2.15,
			"Value": 2.15,
			"Discounts": [],
			"PositionNumber": 1,
			"DeletedPosition": false,
			"AdditionalFields": {},
			"ExternalIdentifier": []
		}
	],
	"Payments": [],
	"AdditionalHeader": [],
	"AdditionalFooter": [],
	"FiscalAdditionalFields": {}
}

Data on transaction abandonment must be sent to iEKA and also shown on reports (see the following chapter).

Audit log entry abortion / abandonment of transactions

If a payload is sent to POST /api/v1/transactions/cancelDocument the RetailForce fiscalisation service automatically generates an entry in the technical event log / technical journal ("audit log") of the type:

• DocumentCancelDocument

The entry contains the total (GrossValue) of the individual items in the transmitted payload, as this information

• must be transmitted to iEKA and
• also reported in the report (Z) and
• the report (X).

The data is transmitted to iEKA via the EndOfDay document. When a daily closing is posted, the following values are returned in the FiscalResponse Lithuania:

• "DayCanceledReceiptsDocumentsQuantity" - number of transaction abortions / abandonments per day
• "DayCanceledReceiptsDocumentsAmount" - (gross) total of all transaction abortions / abandonments

Sale of special goods

In Lithuania, the sale of certain goods must be specifically labelled. These sales are reported to the iEKA system as separate totals and are also included in reports (Report (X), Report (Z)).

These so-called "Special Goods Sales" comprise the following product groups:

• Alcohol and
• Fuel

In RetailForce DOM, the relevant items can be marked accordingly using the property "itemTypeClassification". The product groups classified as "Special Goods" in Lithuania can be queried via the "FiscalCountryProperties" (property: "supportedItemTypeClassification").

Reports

Cash register systems must be able to generate the following reports:

• Report (X) – daily interim report (also known as Report (X))
• Report (Z) – daily fiscal report (also known as Report (Z))
• Detailed fiscal report
• Summary fiscal report

For more information on what data must be included in the respective reports, please refer to the article Document requirements Lithuania.

EKJ