Navigation:

Greece

Fiscalisation for Greece

Helps POS software vendors comply with fiscalization laws and VAT reporting for B2C, B2B and B2G sales across Europe via a single, lightweight app.

Overview
Benefits
POS Integrations
Examples of Usage
- Json Object for Cloud REST API and Local Terminal API integrations
- Base64 encoded format for interapp integration
Fiscalisation response and receipt handling
E-commerce
Account setup
Get Support

Overview

Viva Fiscal API is designed to help businesses comply with fiscalization laws, especially in countries with strict regulations on tax reporting and cash register security. It acts as an intermediary between a company’s point-of-sale (POS) system and government tax authorities, ensuring that all transactions are accurately recorded, securely signed, and transmitted in compliance with legal requirements.

Benefits

Legal Compliance – Many countries, such as Germany and Austria, enforce strict fiscal laws requiring businesses to securely record transactions. The Viva Fiscal API ensures businesses meet these regulations seamlessly.
Security & Integrity – Protects against tax fraud by ensuring all sales data is securely stored and transmitted in an immutable format.
Automation & Efficiency – Reduces manual errors and administrative burdens by automating tax reporting.
Seamless Integration – Enables businesses to integrate fiscal compliance into their existing POS systems with minimal effort.
Handle Government-Mandated Requirements – Some countries require certified fiscalization solutions for all POS systems.

POS Integrations

Viva offers Auto Fiscalization functionality within its POS integrations, providing an electronic fiscalization service that allows businesses to record, process, and store transactions digitally. This ensures transparency, accuracy, and compliance without complex procedures.

Fiscalization is available through:

Local Terminal API – Local ECR integration
InterApp Integration – Terminal/SoftPos Interapp integration
Cloud Terminal API – POS integration via Cloud Terminal API

Merchants and ISV partners do not need to allocate resources for fiscalization integration, as all transactions are automatically fiscalized during payments.

Partners working with other PSPs can also use Viva’s standalone Fiscal API to transmit data to regulators and receive valid receipt information.

The fiscalisation feature is currently available exclusively on our SoftPOS for Android. Please use this link to download the demo version of the Viva Terminal app with fiscalisation enabled and try it out in demo environment.

How to Fiscalize POS Payments

Ensuring that a payment is tax-compliant is quite straightforward. Your integration remains the same, with just one additional object added to your sale requests. This object(fiscalisationData) contains essential data, including the items sold, the payment amount for each item, and the corresponding VAT details. You can find the object structure and its parameters here.

The fiscalisationData is same across all types of POS integrations. By understanding what to include in your requests, you can seamlessly integrate fiscalisation into Viva’s any POS integration. Viva Fiscalisation handles the compliance process by signing the transaction with the relevant authorities. It then returns the receipt details, including the required signature for tax authorities. This information must be printed on the receipt and provided to the customer.

Fiscalisation Data Object

The table below presents the parameter details for the fiscalization data. The fiscalization data object comprises three main components.

Fiscalisation Data Parameters: Contains the core details required for tax compliance.
LineItems Array: An array of objects, each representing an individual item sold, including details such as description, quantity, price, and VAT.
Payment Array: An array of objects specifying the payment details, including payment method, amount, and references.

The fiscalisationData object consists of the below parts:

Fiscalisation Data Parameters

The fiscalisationData object contains the below parameters.

Value	Description	Example	Max Length	Required
processingIndicator	You can find all possible values of the Receipt Processing Indicator under each country’s Receipt Processing Indicator section	5139205309155246081	50 characters	✅
customerVatNumber	The Vat Number to which the invoice is linked to	EL036098541	50 characters	✅ Required only if the receipt is about B2B services/items
customerName	The customer’s name	Professional Services LTD	50 characters	✅ Required only if the receipt is about B2B services/items
customerCountryCode	The country code of where the Vat Number is registered to.	GR	50 characters	✅ Required only if the receipt is about B2B services/items
customerStreet	The customer’s street.	Amarousiou Chalandriou 18-20	50 characters	✅ Required only if the receipt is about B2B services/items
customerCity	The customer’s city	Athens	50 characters	✅ Required only if the receipt is about B2B services/items
customerZip	The customer’s zip code	15125	50 characters	✅ Required only if the receipt is about B2B services/items
receiptDateTime	The receipt’s date & time	2025-02-03T09:32:41.604Z	The value of this constant is equivalent to 23:59:59.9999999 UTC, December 31, 9999 in the Gregorian calendar	✅
receiptUniqueReference	A reference identification key for this specific receipt	fiscal-12345678	100 characters	✅
lineItems	Array of Objects. Please see the next sections for more details.
payments	Array of Objects. Please see the next sections for more details.

Example

The order includes two products, one Coffee Latte and two Coffee Cappuccino, with grand total amount of 20 euro (1 item Coffee Latte x 10 euro + 2 Coffees Cappuccino x 5 euro). The payments array, will be the below:

{
   "processingIndicator":"5139205309155246081",
   "customerVatNumber":"EL036098541",
   "customerName":"Professional Services LTD",
   "customerCountryCode":"GR",
   "customerStreet":"Amarousiou Chalandriou 18-20",
   "customerCity":"Athens",
   "customerZip":"15125",
   "receiptDateTime":"2025-02-03T09:32:41.604Z",
   "receiptUniqueReference":"fiscal-12345678",
   "lineItems": [{...}],  //array of objects
   "payments": [{...}]   //array of objects
}

LineItems Array

Inside the fiscalisationData object, the LineItems array holds the product/item details that the invoice includes.

Value	Description	Example	Max Length	Required
amount	The amount with VAT of each item/product	1000 = 10 euro	4 integers where tha last two linked with the decimals	✅
description	The description of the item/product	Coffee Latte	100 characters	✅
position	The position on the receipt	1	An integer	✅
productBarcode	The product barcode content passed through from the cashier system	1234567890123	50 characters
productNumber	The product number passed through from the cashier system	15709	50 characters
quantity	The quantity of this specific product item	2	An integer	✅
vatAmount	The VAT amount that applied to this specific product	240	100 characters	✅
vatRate	The VAT rate that applied to this specific product	2400 (as value, not 24% in percentange)	4 characters	✅
processingIndicator	You can find all possible values of the LineItem Processing Indicator under each country’s LineItem Processing Indicator section	5139205309125846083	50 characters	✅

Example

The order includes two products, one Coffee Latte and two Coffee Cappuccino, with grand total amount of 20 euro (1 item Coffee Latte x 10 euro + 2 Coffees Cappuccino x 5 euro). The line item array, will be the below:

"lineItems":[
      {
         "amount":1000,
         "description":"Coffee Latte",
         "position":1,
         "productBarcode":"1234567890123",
         "productNumber":15709,
         "quantity":1,
         "vatAmount":240,
         "vatRate":2400,
         "processingIndicator":"5139205309155246083"
      },
      {
         "amount":500,
         "description":"Coffee Cappuccino",
         "position":2,
         "productBarcode":"1234567890200",
         "productNumber":15710,
         "quantity":2,
         "vatAmount":120,
         "vatRate":2400,
         "processingIndicator":"5139205309125846083"
      }
   ]

Payments Array

Inside the fiscalisationData object, the payments array holds the payment details for the items in the order.

Value	Description	Example	Max Length	Required
amount	The grand total amount of the payment	2000 = 20 euro	4 integers where tha last two linked with the decimals	✅
dateTime	The payment’s date and time	2025-02-03T09:32:41.604Z	The value of this constant is equivalent to 23:59:59.9999999 UTC, December 31, 9999 in the Gregorian calendar	✅
description	A short description for this receipt	Order XXXX, Cashier 1, Central Store	50 characters	✅
position	The position on the receipt for details	1	An integer	✅
processingIndicator	You can find all possible values of the Payments Processing Indicator under each country’s Payments Processing Indicator section	5139205309155246083	50 characters	✅

Example

"payments":[
  {
      "amount":2000,
      "dateTime":"2025-02-03T09:32:41.604Z",
      "description":"Payment via card",
      "position":1,
      "processingIndicator":"5139205309155246083"
  }
]

Understanding processingIndicators for Greece

As you might have already noticed, the FiscalisationData object contains a parameter called processingIndicator. This parameter exists in the main object, inside lineItems object, and payments object.

Receipt processingIndicator: The ProcessingIndicator in the ‘main body’ indicates the receipt type and defines how it should be processed by the Viva Fiscalisation. The data type is Int64 and contains the country specific code, which is a value following the ISO-3166-1-ALPHA-2 standard converted from ASCII into hex and used as byte 8 and 7. For definitions regarding national laws, please refer to each country seperately.

LineItems processingIndicator: The ProcessingIndicator in the ‘lineItems’ object defines the type of service or item in the line item block and thus how Viva processes the individual receipts with regards to receipt generation. The data type is Int64 and contains a country specific code which is a value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex and used as byte 8 and 7.

Payments processingIndicator: The ProcessingIndicator in the ‘payments’ object indicates the type of payment within the pay items block and defines how the Viva Fiscalisation processes the individual payment in terms of the receipt. The data type is Int64 and contains a country specific code which is a value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex and used as byte 8 and 7.

Receipt ProcessingIndicator for Greece

For Greece (GR), the country code is 4752. Thus, the value of an unknown Receipt ProcessingIndicator in Greece is 4752000000000000.

Format

The format of the processingIndicator parameter on fiscalization level, should be the below.

CCCC_vlll_gggg_txcc

Example

4752_2000_0002_0001

CCCC = 4752 | The two ASCII letters that specify the ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. GR = 4752)
vlll = 2000 | This section is for versioning the tagging system (the current is the v2) (e.g. 2000)
gggg = 0002 | This item is used for flag. Flag can change the basic behavior of a given type, but will live the overall semantical meaning of a type the same. (e.g. voiding of a receipt)
txcc = 0001 | In this item specified the receipt type.

The 4752200000010004 is hex and should be converted to decimal number (5139205309155377153). So, the value that should be passed through in the body request.

A helpful online tool for your converting tests is this.

Flag (gggg)

Value	Description
`0001`	Process as Late Signing Receipt The cash register lost connection to the queue and processed receipts without communicating with the queue. All processed receipts marked with the hint “Security mechanism not reachable” need to be sent to the queue with this marker.
`0002`	Training Receipt
`0004`	IsVoid Marks Receipt as Void to previous one. Mark line items also as IsVoid to signal clear data.
`0008`	Process as Handwritten Receipt During a power outage, the Cash register will not work, and the merchant hands out handwritten receipts. These handwritten receipts need to be sent to the Security Mechanism by using this flag.
`0010`	IssuerIsSmallBusiness Businesses below a country-specific size in revenue need not declare VAT. With this marker, the receipt shows no VAT, all prices are gross, and a country-specific hint must be printed.
`0020`	ReceiverIsBusiness Specific data need to be placed onto the receipt.
`0040`	ReceiverIsKnown Characteristics related to VAT taxes are given. For example, Name, Address, VAT-ID, other local info.
`0080`	IsSaleInForeignCountry
`0100`	IsReturn/IsRefund Marks Receipt as Return of good or service.
`0800`	Group by Position-Number / 100 100 = first position, 101 first subitem, 102 second subitem. The sum of all charge items within a position must count toward the total receipt amount. If the quantity and amount are 0.00, the quantity and amount will not be visualized for this line on the digital receipt, independent if main or subitem.
`8000`	ReceiptRequest If you don’t receive a response, try this flag first before taking any other action. This will return a stored result, for example, in case of a timeout when cash register calls queue.

t - Receipt Type

Value	Category	Description
`0`	Receipt	A basic receipt that is generated as part of a POS sale. A receipt usually serves as proof of payment. The receipt is used after the transaction is done (if goods are received). This is the usual process that is done at a POS.
`1`	Invoice	An invoice is generated for those cases where payment isn't handled immediately.
`2`	DailyOperations	This category contains receipt cases that the Middleware requires for various downstream processes (e.g. book keeping)
`3`	Log	Logs can be used for storing / securing events that need are needed for additional processing or downstream processes. (e.g. log for cash drawer opened)
`4`	Lifecycle	These operations are used for changing the overall state of the Middleware. Depending on the local regulations these receipts are handed over as part of a notification (e.g. FinanzOnline)

txcc - ReceiptCase

Value	Category
`0000`	Unknown type for country-code "GR"
`0001`	POS receipt Represents the main kind of receipt processed by a POS system. Creates a turnover and/or a change in the amount of cash in the till or similar operations.
`0002`	Payment transfer receipt type
`0003`	Point-Of-Sale receipt without fiscalization Obligation or with exeption on fiscalization regulation.
`0004`	E-Commerce receipt type
`0005`	Delivery Note
`1000`	Unknown invoice type
`1001`	B2C invoice type
`1002`	B2B invoice type
`1003`	B2G invoice type
`2000`	Zero Receipt
`2001`	(reserved) One Receipt
`2010`	Shift Closing Receipt
`2011`	Daily Closing Receipt
`2012`	Monthly Closing Receipt
`2013`	Yearly Closing Receipt
`3000`	Protocol (unspecified type)
`3001`	Protocol (technical event)
`3002`	Protocol (audit event / accounting event)
`3003`	Internal usage / Material consumption
`3004`	Order
`3010`	Copy Receipt / Print existing Receipt
`4001`	Queue-Start-Receipt (Initial operations receipt)
`4002`	Queue-Stop-Receipt (Out of operations receipt)
`4011`	Initiate SCU-switch
`4012`	Finish SCU-switch

LineItems ProcessingIndicator for Greece

Format

The format of the processingIndicator parameter on line item level, should be the below.

CCCC_vlll_gggg_NNSV

Example

4752_2000_0001_0013

CCCC = 4752 | The two ASCII letters that specify the ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. GR = 4752)
vlll = 2000 | This section is for versioning the tagging system (the current is the v2) (e.g. 2000)
gggg = 0001 | This item is used for flag. Flag can change the basic behavior of a given type, but will live the overall semantical meaning of a type the same. (e.g. voiding of a receipt)
NN = 00 | The first part of the NNSV section, specify the nature of VAT.
S = 1 | The second part of the NNSV section, specify the type of the service.
V = 3 | The third part of the NNSV section, specify the type of the VAT.

The 4752200000010013 is hex and should be converted to decimal number (5139205309155311635). So, the value that should be passed through in the body request.

A helpful online tool for your converting tests is this.

Flag (gggg)

Value	Description
`0001`	IsVoid Marks ChargeItem as Void previous position. Quantity and amount are inverted, related to original item.
`0002`	IsReturn/IsRefund Marks ChargeItem as Return of good or service. Quantity and amount are inverted, related to original item.
`0004`	Discount Marks ChargeItem as Discount/Extra for previous position. Positive (+) amount is extra. Negative (-) amount is discount.
`0008`	Downpayment Marks ChargeItem as a downpayment. Positive (+) amount is creation of downpayment. Negative (-) amount is reduction of downpayment.
`0010`	Returnable Marks ChargeItem as returnable. Positive (+) amount/quantity is handout. Negative (-) amount/quantity is reverse.
`0020`	TakeAway Marks ChargeItem as TakeAway item to prove special VAT application.
`8000`	ShowInPayments Visualize the item after Total Amount. This inverts amount and does not include it into the visualized total amount on the receipt.

NN - Nature of VAT

Value	Description
`00`	Usual VAT applies
`10` `11` `12` `13` `14` `15`	Not Taxable 10 = exports 11 = intra-community supplies 12 = transfers to San Marino 13 = transactions assimilated to export supplies 14 = following declarations of intent 15 = other operations which do not contribute to the formation of the ceiling
`20`	Not Subject 20 = not subject to VAT pursuant to articles from 7 to 7-septies of Presidential Decree ⁶³³⁄₇₂.
`40`	Margin scheme 40 = margin scheme - VAT not shown on invoice.
`50`	Reverse charge 50 = reverse charge - disposal of scrap and other salvage materials.
`60`	VAT paid in other EU country 60 = paid in another EU country.
`70`	VAT distribution
`80`	Excluded 80 = excluded pursuant to art. 15 of Presidential Decree ⁶³³⁄₇₂.

S - Type of Service

Value	Description
`0`	Unknown type of service
`1`	Delivery (supply of goods)
`2`	Other service (supply of service)
`3`	Tip - For owner use V=0 to 7, related to total amount. - For Employee use V=8, Not Taxable (as of 1.1.2022, this is calculated with 5%).
`4`	Voucher -For Single-Use-Voucher use V=0 to 7. - For Multi-Use-Voucher use V=8, Not Taxable - Voucher Sale is a positive (+) amount. - Voucher Redeem is a negative (-) amount.
`5`	Catalog service
`6`	Not own sales / Agency business
`7`	Own Consumption
`8`	Grant - For Unreal Grant use V=0 to 7. - For Real Grant use V=8.
`9`	Receivable - Receivable creation is negative (-) amount. - Receivable reduction is positive (+) amount.
`A`	Cash Transfer - Cash Transfer to till is positive (+) amount. - Cash Transfer from till is negative (-) amount. - Only useable with V=8, Not Taxable.

V - VAT

You may find more information about the VAT rules and rates that applied to EU here.

Value	Description
`0`	Unknown type of service for GR
`1`	Discounted-1 VAT rate
`2`	Discounted 2 VAT rate
`3`	Normal VAT rate
`4`	Super reduced 1 VAT rate
`5`	Super reduced 2 VAT rate
`6`	Parking VAT rate
`7`	Zero VAT rate
`8`	Not Taxable

Payments ProcessingIndicator for Greece

Format

The format of the processingIndicator parameter on payment item level, should be the below.

CCCC_vlll_gggg_xxPP

Example

4752_2000_0001_0004

CCCC = 4752 | The two ASCII letters that specify the ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. GR = 4752)
vlll = 2000 | This section is for versioning the tagging system (the current is the v2) (e.g. 2000)
gggg = 0001 | This item is used for flag. Flag can change the basic behavior of a given type, but will live the overall semantical meaning of a type the same. (e.g. voiding of a receipt)
xx = 00 | The first part of the xxPP section should be ever 00.
PP = 04 | The first part of the xxPP section, specify the Payment Type.

The 4752200000010004 is hex and should be converted to decimal number (5139205309155311620). So, the value that should be passed through in the body request.

A helpful online tool for your converting tests is this.

Flag (gggg)

Value	Description
`0001`	IsVoid Marks PayItem as Void previous position. Amounts and quantities are inverted. Used when the exchange of money has not yet been executed.
`0002`	IsReturn/IsRefund Marks PayItem as a return of goods or services. Amounts and quantities are inverted. Used when the exchange of money has already been executed.
`0004`	(reserved)
`0008`	Downpayment + Amount reduces downpayment, - Amount creates downpayment.
`0010`	IsForeignCurrency Amount is in EUR at the moment of acceptance. Requires `foreignCurrencySymbol` and `foreignCurrencyAmount`.
`0020`	IsChange Usually contains a negative amount (-). Can be inverted when `IsVoid`.
`0040`	IsTip Must be a negative amount (-) to flow out of payment method. `ShowInChargeItems` flag can visualize the tip separately.
`0080`	IsDigital/IsElectronic Electronic money, digital money.
`0100`	IsInterface/AmountVerified Verified by interface, automated amount transfer.
`8000`	ShowInChargeItems Visualizes the item before the total amount, inverting it to be included in the receipt total.

Payment Type (PP)

Value	Description
`00`	Unknown payment type for GR Handled like a cash payment in national currency.
`01`	Cash payment Cash
`02`	NonCash Cash
`03`	Crossed cheque Cash
`04`	Debit card payment Cash
`05`	Credit card payment Cash
`06`	Voucher payment (coupon) - voucher by money value Cash
`07`	Online payment Noncash
`08`	Loyalty program Customer card payment
`09`	Accounts receivable
`0A`	SEPA transfer
`0B`	Other Bank transfer
`0C`	Transfer to Cashbook / Vault / Owner / Employee + Amount contributes to cashbox/vault, - Amount lowers the amount.
`0D`	Internal / Material consumption
`0E`	Grant
`0F`	Ticket Restaurant / (Sodexo, Edenred, etc.)

Examples of Usage

fiscalisationData for Cloud REST API and Local Terminal API integrations

For Cloud REST API and P2P(LOCAL Terminal API) integrations, please add fiscalisationData JSON object to the request body. This aproach is valid for both standard and ISV integrations.

JSON Format

"fiscalisationData":{
   "lineItems":[
      {
         "amount":1000,
         "description":"Coffee Latte",
         "position":1,
         "productBarcode":"1234567890123",
         "productNumber":15709,
         "quantity":1,
         "vatAmount":240,
         "vatRate":2400,
         "processingIndicator":"5139205309155246083"
      },
      {
         "amount":500,
         "description":"Coffee Cappuccino",
         "position":2,
         "productBarcode":"1234567890200",
         "productNumber":15710,
         "quantity":2,
         "vatAmount":120,
         "vatRate":2400,
         "processingIndicator":"5139205309125846083"
      }
   ],
   "payments":[
      {
         "amount":2000,
         "dateTime":"2025-02-03T09:32:41.604Z",
         "description":"Payment via card",
         "position":1,
         "processingIndicator":"5139205309155246083"
      }
   ],
   "processingIndicator":"5139205309155246081",
   "customerVatNumber":"EL036098541",
   "customerName":"Professional Services LTD",
   "customerCountryCode":"GR",
   "customerStreet":"Amarousiou Chalandriou 18-20",
   "customerCity":"Athens",
   "customerZip":"15125",
   "receiptDateTime":"2025-02-03T09:32:41.604Z",
   "receiptUniqueReference":"fiscal-12345678"
}

fiscalisationData for Interapp(app2app) Integration

For Interapp(app2app) integration, you should encode fiscalisationData JSON object as base64 format and pass it as uri parameter

Base64 format

ewogICAibGluZUl0ZW1zIjpbCiAgICAgIHsKICAgICAgICAgImFtb3VudCI6MTAwMCwKICAgICAgICAgImRlc2NyaXB0aW9uIjoiQ29mZmVlIExhdHRlIiwKICAgICAgICAgInBvc2l0aW9uIjoxLAogICAgICAgICAicHJvZHVjdEJhcmNvZGUiOiIxMjM0NTY3ODkwMTIzIiwKICAgICAgICA
gInByb2R1Y3ROdW1iZXIiOjE1NzA5LAogICAgICAgICAicXVhbnRpdHkiOjEsCiAgICAgICAgICJ2YXRBbW91bnQiOjI0MCwKICAgICAgICAgInZhdFJhdGUiOjI0MDAsCiAgICAgICAgICJwcm9jZXNzaW5nSW5kaWNhdG9yIjoiNTEzOTIwNTMwOTE1NTI0NjA4MyIKICAgICAgfSwKICAgIC
AgewogICAgICAgICAiYW1vdW50Ijo1MDAsCiAgICAgICAgICJkZXNjcmlwdGlvbiI6IkNvZmZlZSBDYXBwdWNjaW5vIiwKICAgICAgICAgInBvc2l0aW9uIjoyLAogICAgICAgICAicHJvZHVjdEJhcmNvZGUiOiIxMjM0NTY3ODkwMjAwIiwKICAgICAgICAgInByb2R1Y3ROdW1iZXIiOjE1N
zEwLAogICAgICAgICAicXVhbnRpdHkiOjIsCiAgICAgICAgICJ2YXRBbW91bnQiOjEyMCwKICAgICAgICAgInZhdFJhdGUiOjI0MDAsCiAgICAgICAgICJwcm9jZXNzaW5nSW5kaWNhdG9yIjoiNTEzOTIwNTMwOTEyNTg0NjA4MyIKICAgICAgfQogICBdLAogICAicGF5bWVudHMiOlsKICAg
ICAgewogICAgICAgICAiYW1vdW50IjoyMDAwLAogICAgICAgICAiZGF0ZVRpbWUiOiIyMDI1LTAyLTAzVDA5OjMyOjQxLjYwNFoiLAogICAgICAgICAiZGVzY3JpcHRpb24iOiJQYXltZW50IHZpYSBjYXJkIiwKICAgICAgICAgInBvc2l0aW9uIjoxLAogICAgICAgICAicHJvY2Vzc2luZ0l
uZGljYXRvciI6IjUxMzkyMDUzMDkxNTUyNDYwODMiCiAgICAgIH0KICAgXSwKICAgInByb2Nlc3NpbmdJbmRpY2F0b3IiOiI1MTM5MjA1MzA5MTU1MjQ2MDgxIiwKICAgImN1c3RvbWVyVmF0TnVtYmVyIjoiRUwwMzYwOTg1NDEiLAogICAiY3VzdG9tZXJOYW1lIjoiUHJvZmVzc2lvbmFsIF
NlcnZpY2VzIExURCIsCiAgICJjdXN0b21lckNvdW50cnlDb2RlIjoiR1IiLAogICAiY3VzdG9tZXJTdHJlZXQiOiJBbWFyb3VzaW91IENoYWxhbmRyaW91IDE4LTIwIiwKICAgImN1c3RvbWVyQ2l0eSI6IkF0aGVucyIsCiAgICJjdXN0b21lclppcCI6IjE1MTI1IiwKICAgInJlY2VpcHREY
XRlVGltZSI6IjIwMjUtMDItMDNUMDk6MzI6NDEuNjA0WiIsCiAgICJyZWNlaXB0VW5pcXVlUmVmZXJlbmNlIjoiZmlzY2FsLTEyMzQ1Njc4Igp9

Fiscalisation response and receipt handling

When you fiscalize a transaction via a sale request, the response contains critical fiscalization data that ensures the transaction complies with the relevant fiscal regulations. Among the details returned, two key parameters(transmissionIndicator and signatures) stand out and should be carefully reviewed. It is important to note that these fiscalization details, should also be printed or displayed on the receipt according to instructions below. Including this information is a legal requirement in many fiscal jurisdictions.

1) transmissionIndicator: This parameter reflects the status of the fiscal data’s transmission to the tax authority or fiscal system. It indicates whether the transaction was successfully reported, is pending transmission, or encountered an error. Monitoring this value is crucial for audit readiness and legal compliance, especially in jurisdictions where real-time or near-real-time reporting is mandatory.

Parameter	Value	Description
transmissionIndicator	0	Succesfully fiscalised transaction. Please use the signature object and create your receipt/invoice accordingly.
transmissionIndicator	1	TRANSMISSION_FAILURE_1: Please mark the transaction as TRANSMISSION_FAILURE_1 and print "TRANSMISSION_FAILURE_1" on the sale receipt/invoice
transmissionIndicator	2 or it is either missing or not present in the response.	TRANSMISSION_FAILURE_2: AADE myDATA is unreachable. Please mark the transaction as TRANSMISSION_FAILURE_2 and print "TRANSMISSION_FAILURE_2" on the sale receipt/invoice

Please see the below table for more detailed scenarios.

Scenario	Local network connection disruption	Viva Terminal app/device unresponsive	Internet connection disruption	Viva.com cloud infrastructure unreachable	AADE myDATA cloud infrastructure unreachable
Payment + Fiscalisation integration APIs	Reachable	Unreachable	Reachable	Reachable	Reachable
Fiscalisation outcome	Fiscalisation temporarily unavailable. TRANSMISSION_FAILURE_1 Viva informs POS via API response that fiscalisation cannot proceed due to a TRANSMISSION_FAILURE_1 error. According to myDATA reporting regulations, POS should mark the sale as TRANSMISSION_FAILURE_1 and print this message on the sales receipt/invoice. No follow-up receipt/invoice needs to be generated. Simultaneously, Viva polls continuously the Viva infrastructure endpoint and when the connection is restored, it automatically transmits the contents of the receipt/invoice, marked with TRANSMISSION_FAILURE_1 designator to AADE myDATA. Lastly, the fiscalised response is also returned to the POS for safekeeping.
Fiscalisation outcome (Alternate scenario)	Fiscalisation temporarily unavailable. TRANSMISSION_FAILURE_2 Viva informs POS via API response that fiscalisation cannot proceed due to a TRANSMISSION_FAILURE_2 error. According to myDATA reporting regulations, POS should mark the sale as TRANSMISSION_FAILURE_2 and print this message on the sales receipt/invoice. No follow-up receipt/invoice needs to be generated. Simultaneously, Viva polls continuously the AADE myDATA infrastructure endpoint and when the connection is restored, it automatically transmits the contents of the receipt/invoice, marked with TRANSMISSION_FAILURE_2 designator to AADE myDATA. Lastly, the fiscalised response is also returned to the POS for safekeeping.
Electronic payment outcome	Electronic payments possible (offline mode)	Electronic payments not possible	Electronic payments possible (offline mode)	Electronic payments possible (offline mode)	Electronic payments possible (online mode)

2) signatures: These are cryptographic signatures applied to the transaction data. They serve as proof of authenticity and integrity showing that the fiscalized data has not been tampered with. Signatures include a unique hash or token generated based on the transaction’s content and a secure private key, aligning with the digital security requirements set by fiscal authorities.

Parameter	Value	Description
signatures.caption	Example values -invoiceUid -invoiceMark -authenticationCode -[www.viva.com] -Σημείωση: Με βάση την ΠΟΛ.1002/2014 (ΦΕΚ Β’ 3/2-1-2014), τα δεδομένα αυτά δεν επιδέχονται αλλοίωση.	The caption that needs to be printed above the signature data
signatures.data	Sample values -400001948544829 -https://receipts-sandbox.viva.com/8c0a4594 -112545020\|27/03/2025\|0\|Item113\|0\|128	The signature data that needs to be printed under the relevant caption according to the mentioned format
signatures.fortmat	0: Unknown / no format defined 1: Text 2: Link 3: QR-Code (2D Code) 4: Code128 (Barcode) 5: OCR-A (optical character recognition, possible for Base32 data) 6: PDF417-(2D Code) 7: DATAMATRIX-(2D Code) 8: AZTEC-(2D Code) 9: EAN-8 (Barcode)/td>	Specifies the format that you need to use when printing the signature data. For example, if format is 3, the data value should be presented as QR code.

Response Example

The following data sample is returned during session retrieval, whether through the Cloud REST API or the Local Terminal API, or as a Base64-encoded format in inter-app responses when using app-to-app integration.

{
  "signatures": [
    {
      "caption": "invoiceUid",
      "data": "FDF3F4414097B4786363FA8A70A98653CFC92B0C",
      "format": 1
    },
    {
      "caption": "invoiceMark",
      "data": "400001948544829",
      "format": 1
    },
    {
      "caption": "authenticationCode",
      "data": "D4824EB973D3E0E2A802FC0FF55B1283F22A8629",
      "format": 1
    },
    {
      "caption": "[www.fiskaltrust.gr]",
      "data": "https://receipts-sandbox.fiskaltrust.eu/8c0a4594-ab69-43bb-a7ef-ebc4bef51494/8abf2ada-afa8-4616-a07a-562dbe1ee211",
      "format": 3
    },
    {
      "caption": "Σημείωση: Με βάση την ΠΟΛ.1002/2014 (ΦΕΚ Β’ 3/2-1-2014), τα δεδομένα αυτά δεν επιδέχονται αλλοίωση.",
      "data": "112545020|27/03/2025|0|Item113|0|128",
      "format": 1
    },
    {
      "caption": "S A N D B O X",
      "data": "8c0a4594-ab69-43bb-a7ef-ebc4bef51494",
      "format": 1
    }
  ],
  "transmissionIndicator": 0
}

E-commerce

While the Fiscal API is not yet available for web payments, it will be launching soon.

Account Setup

To activate fiscalization for your integration, please contact your sales representative.

Get Support

If you would like to integrate with Viva, or if you have any queries about our products and solutions, please see our Contact & Support page to see how we can help!