Navigation:

Viva Fiscalisation

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

Overview
Benefits
POS Integrations
- How to Fiscalize POS Payments
- Fiscalisation Data Object
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.

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 Fiscalisation data object consists of 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 may find all the possible values of the process indicator paymentitem	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 may find all the possible values of the process indicator here	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 may find all the possible values of the process indicator paymentitem	5139205309155246083	50 characters	✅

Example

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

Understanding processingIndicators

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

The ProcessingIndicator in the main object specifies the receipt type and defines how Viva should process it according to country-specific laws.

Receipt processingIndicator

The processingIndicator in the main body specifies the receipt type and dictates how Viva should process it in compliance with the law.

The following data pertains to Greek law. We will be adding the data for other countries soon.

Its data type is Int64 and contains a country-specific code, which follows the ISO-3166-1-ALPHA-2 standard. This code is converted from ASCII to hexadecimal and used as bytes 8 and 7.

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
`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

LineItem processingIndicator

The processingIndicator inside the lineItem objects defines the type of service or item in the charge item block, determining how Viva processes individual receipts with regard to receipt generation. The data type is Int64, containing a country-specific code that follows the ISO-3166-1-ALPHA-2 standard. This code is converted from ASCII to hexadecimal and used as bytes 8 and 7.

The following data is applicable to Greek market. We will be adding the data for other countries soon.

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

The processingIndicator inside the payments object indicates the type of payment within the pay items block and defines how Viva 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.

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.)

Encode to Base64 format

The fiscalisationData object value, should be encoded and provided in base64 format.

Base64 is a group of similar binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation. Base64 is another way to represent binary or text data.

Example

JSON Format

{
   "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"
}

Base64 format

ewogICAibGluZUl0ZW1zIjpbCiAgICAgIHsKICAgICAgICAgImFtb3VudCI6MTAwMCwKICAgICAgICAgImRlc2NyaXB0aW9uIjoiQ29mZmVlIExhdHRlIiwKICAgICAgICAgInBvc2l0aW9uIjoxLAogICAgICAgICAicHJvZHVjdEJhcmNvZGUiOiIxMjM0NTY3ODkwMTIzIiwKICAgICAgICA
gInByb2R1Y3ROdW1iZXIiOjE1NzA5LAogICAgICAgICAicXVhbnRpdHkiOjEsCiAgICAgICAgICJ2YXRBbW91bnQiOjI0MCwKICAgICAgICAgInZhdFJhdGUiOjI0MDAsCiAgICAgICAgICJwcm9jZXNzaW5nSW5kaWNhdG9yIjoiNTEzOTIwNTMwOTE1NTI0NjA4MyIKICAgICAgfSwKICAgIC
AgewogICAgICAgICAiYW1vdW50Ijo1MDAsCiAgICAgICAgICJkZXNjcmlwdGlvbiI6IkNvZmZlZSBDYXBwdWNjaW5vIiwKICAgICAgICAgInBvc2l0aW9uIjoyLAogICAgICAgICAicHJvZHVjdEJhcmNvZGUiOiIxMjM0NTY3ODkwMjAwIiwKICAgICAgICAgInByb2R1Y3ROdW1iZXIiOjE1N
zEwLAogICAgICAgICAicXVhbnRpdHkiOjIsCiAgICAgICAgICJ2YXRBbW91bnQiOjEyMCwKICAgICAgICAgInZhdFJhdGUiOjI0MDAsCiAgICAgICAgICJwcm9jZXNzaW5nSW5kaWNhdG9yIjoiNTEzOTIwNTMwOTEyNTg0NjA4MyIKICAgICAgfQogICBdLAogICAicGF5bWVudHMiOlsKICAg
ICAgewogICAgICAgICAiYW1vdW50IjoyMDAwLAogICAgICAgICAiZGF0ZVRpbWUiOiIyMDI1LTAyLTAzVDA5OjMyOjQxLjYwNFoiLAogICAgICAgICAiZGVzY3JpcHRpb24iOiJQYXltZW50IHZpYSBjYXJkIiwKICAgICAgICAgInBvc2l0aW9uIjoxLAogICAgICAgICAicHJvY2Vzc2luZ0l
uZGljYXRvciI6IjUxMzkyMDUzMDkxNTUyNDYwODMiCiAgICAgIH0KICAgXSwKICAgInByb2Nlc3NpbmdJbmRpY2F0b3IiOiI1MTM5MjA1MzA5MTU1MjQ2MDgxIiwKICAgImN1c3RvbWVyVmF0TnVtYmVyIjoiRUwwMzYwOTg1NDEiLAogICAiY3VzdG9tZXJOYW1lIjoiUHJvZmVzc2lvbmFsIF
NlcnZpY2VzIExURCIsCiAgICJjdXN0b21lckNvdW50cnlDb2RlIjoiR1IiLAogICAiY3VzdG9tZXJTdHJlZXQiOiJBbWFyb3VzaW91IENoYWxhbmRyaW91IDE4LTIwIiwKICAgImN1c3RvbWVyQ2l0eSI6IkF0aGVucyIsCiAgICJjdXN0b21lclppcCI6IjE1MTI1IiwKICAgInJlY2VpcHREY
XRlVGltZSI6IjIwMjUtMDItMDNUMDk6MzI6NDEuNjA0WiIsCiAgICJyZWNlaXB0VW5pcXVlUmVmZXJlbmNlIjoiZmlzY2FsLTEyMzQ1Njc4Igp9

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!