France
Fiscalisation for France
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
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.
Required only if the receipt is about B2B services/items |
||||
Required only if the receipt is about B2B services/items |
||||
Required only if the receipt is about B2B services/items |
||||
Required only if the receipt is about B2B services/items |
||||
Required only if the receipt is about B2B services/items |
||||
Required only if the receipt is about B2B services/items |
||||
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.
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.
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:
"payments":[
{
"amount":2000,
"dateTime":"2025-02-03T09:32:41.604Z",
"description":"Payment via card",
"position":1,
"processingIndicator":"5139205309155246083"
}
]
Understanding processingIndicators for France
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 France
For France (FR), the country code is 4652. Thus, the value of an unknown processing indicator in France is 4652000000000000.
Example for POS receipt : 4652000000000000
The value 4652000000000000 is in hexadecimal format and needs to be converted to its decimal equivalent, which is 5067112530745229312. Therefore, the value to be included in the request body should be 5067112530745229312.
A helpful online tool for your converting tests is [this](https://www.rapidtables.com/convert/number/hex-to-decimal.html).
Value | Description |
---|---|
4652000000000000
|
Unknown receipt for FR
Processed like a ticket |
4652000000000001
|
Ticket
Legal document; has to be signed. Sign: Yes Chain and national numbering: T Details: GT counters are raised |
4652000000000002
|
Payment Prove
Payment without knowing what was paid. Legal document; has to be signed. Sign: Yes Chain and national numbering: P No ChargeItems on payment-prove, the total amount is always zero, a negative payitem of type 4652000000000011 is used to get the sum of PayItems to zero. Details: GT counters are not raised |
4652000000000003
|
Invoice
Legal document; has to be signed. Sign: Yes Chain and national numbering: I A reference to the ticket can be created by using cbPreviousReceiptNumber in the request. Detail: GT counters are raised |
4652000000000004
|
Shift Receipt / Grand Total Ticket / Grand Total Invoice: Shift
Sign: Yes Chain and national numbering: G Details: Resets the shift-counter, keeps all other counters |
4652000000000005
|
Daily Receipt / Grand Total Ticket / Grand Total Invoice: Daily
Sign: Yes Chain and national numbering: G Details: - Adds a daily-counter to the monthly-counter and then resets the daily-counter - keeps the shift-counter |
4652000000000006
|
Monthly Receipt / Grand Total Ticket / Grand Total Invoice: Month
Sign: Yes Chain and national numbering: G Details: - Adds a daily-counter to the monthly-counter and then resets the daily-counter - Adds a monthly-counter to the yearly-counter and then resets the monthly-counter - keeps the shift-counter |
4652000000000007
|
Yearly Receipt / Grand Total Ticket / Grand Total Invoice: Year
Sign: Yes Chain and national numbering: G Details: - Adds a daily-counter to the monthly-counter and then resets the daily-counter - Adds a monthly-counter to the yearly-counter and then resets the monthly-counter - Resets the yearly-counter - keeps the shift-counter |
4652000000000008
|
Bill
List of ChargeItems to be paid. Used to inform customers about their open ChargeItems. PayItemType 4652000000000011 is used Sign: Yes Chain and national numbering: B Details: GT counters are not raised. When the bill is used, the phrase "document provisoire" is returned with the fiscalisation signature and must be printed on the bill. If bill and payment prove are created, this does not replace a ticket creation. A ticket or an invoice has to be issued to raise turnover and raise the GT counters as well |
4652000000000009
|
Delivery Note
Sign: no Chain and national numbering: no |
465200000000000A
|
Cash pay-in / Cash Deposit
Same handling as payment prove Chain and national numbering: P |
465200000000000B
|
Cash pay-out
Same handling as payment prove Chain and national numbering: P |
465200000000000C
|
Payment transfer
Switch between payment method, e.g. from cash to credit card Sign: Yes Chain and national numbering: P |
465200000000000D
|
Internal / Material
Sign: No Chain and national numbering: no |
465200000000000E
|
Foreign sales
Same handling as bill. To be used when something sold in an other country. Sign: Yes Chain und national numbering: B |
465200000000000F
|
Zero-Receipt
Sign: Yes Chain and national numbering: G Details: A receipt with empty charge items block ftChargeItem and empty payment block ftPayItem which amounts to a total of "0".
|
4652000000000010
|
Start-Receipt
Sign: Yes Chain and national numbering: G |
4652000000000011
|
Stop-Receipt
Sign: Yes Chain and national numbering: G |
4652000000000012
|
Protocol / Technical Event Log
Has to be signed Sign: Yes Chain and national numbering: L Details: Can be used by the POS-System to log custom data. |
4652000000000013
|
Protocol / Accounting / Audit
Has to be signed Sign: Yes Chain and national numbering: L Details: Can be used by the POS-System to log custom data. |
4652000000000014
|
Protocol / Custom
Does not need to be signed Sign: No Chain and national numbering: No Details: Can be used by the POS-System to log custom data. |
4652000000000015
|
Archive
Has to be Signed Sign: Yes Chain and national numbering: A Details: Will trigger a daily closing automatically. Creates an archive starting with the first receipt of the queue (or the last archive receipt) until the last receipt before this request. It must not contain more than 365 days. To retrieve the export as a zip-file (containing the certificate, ReceiptJournals and QueueItems), a normal /journal request has to be sent to the ftJournalType : 4652000000010010 . The value of ftQueueRow in the response of this ReceiptCase has to be sent in the from -parameter.
|
4652000000000016
|
Copy
Has to be Signed Sign: Yes Chain and national numbering: C Details: in a request the cbPreviousReceiptReference is mandatory. It contains the receipt number which was handed out as a copy, issued by the original cash register. When a copy of a receipt is requested, the phrase "duplicata" is returned with the fiscalisation signature and must be printed on the receipt. Every time the receipt is reprinted, an up-counting number denoting how many times the receipt has been printed, is returned. It must be printed on the receipt and is then recorded in the journal.The layout and the information contained shall be the same as in the original document.
|
LineItems ProcessingIndicator for France
Example for lineItem processingIndicator : 5067112530745229312
Calculation: After you identify the type of service value (Eg: The value 4652000000000000 in hexadecimal format in the below table) you should convert it to its decimal equivalent(Eg: 5067112530745229312) and then include it in the request data.
A helpful online tool for your converting tests is [this](https://www.rapidtables.com/convert/number/hex-to-decimal.html).
Value | Description |
---|---|
4652000000000000
|
Unknown type of service for FR
With the help of the VAT-rates table saved within Viva fiscalisation, an allocation to standard /reduced-1 /reduced-2 / super-reduced/zero is attempted. |
4652000000000001
|
Undefined type of service for FR reduced-1
(as of 1.1.2017, this is calculated with 5,5%). |
4652000000000002
|
Undefined type of service for FR reduced-2
(as of 1.1.2016, this is calculated with 10%, Loi n° 2015-1786 du 29 décembre 2015, art. 79). |
4652000000000003
|
Undefined type of service for FR normal
(as of 1.1.2014, this is 20%, Loi n° 2012-1510 du 29 décembre 2012, art. 68-III-B). |
4652000000000004
|
Undefined type of service for FR special (super-reduced)
Includes all rates that are not contained in the previous ones (as of 1.1.2017, this can be, for example, 2,1%). |
4652000000000005
|
Undefined type of service for FR zero
Includes data indicated with 0% sales tax and data where the sales tax is unknown, for example, about an outgoing invoice. Also, in cases where the sales tax should not be apparent, for example, in differential taxation, the data can be issued with this code. |
4652000000000006
|
Reverse charge
Reversal of tax liability. |
4652000000000007
|
Not own sales
In the data, a VAT-rate can be indicated. |
4652000000000008
|
Delivery reduced-1
For processing, see ( 4652000000000001 )
|
4652000000000009
|
Delivery reduced-2
For processing, see ( 4652000000000002 )
|
465200000000000A
|
Delivery normal
For processing, see ( 4652000000000003 )
|
465200000000000B
|
Delivery special
For processing, see ( 4652000000000004 )
|
465200000000000C
|
Delivery zero
For processing, see ( 4652000000000005 )
|
465200000000000D
|
Other services reduced-1
For processing, see ( 4652000000000001 )
|
465200000000000E
|
Other services reduced-2
For processing, see ( 4652000000000002 )
|
465200000000000F
|
Other services normal
For processing, see ( 4652000000000003 )
|
4652000000000010
|
Other services special
For processing, see ( 4652000000000004 )
|
4652000000000011
|
Other services zero
For processing, see ( 4652000000000005 )
|
4652000000000012
|
Catalogue services reduced-1
For processing, see ( 4652000000000001 )
|
4652000000000013
|
Catalogue services reduced-2
For processing, see ( 4652000000000002 )
|
4652000000000014
|
Catalogue services normal
For processing, see ( 4652000000000003 )
|
4652000000000015
|
Catalogue services special
For processing, see ( 4652000000000004 )
|
4652000000000016
|
Catalogue services zero
For processing, see ( 4652000000000005 )
|
4652000000000017
|
Own consumption reduced-1
For processing, see ( 4652000000000001 )
|
4652000000000018
|
Own consumption reduced-2
For processing, see ( 4652000000000002 )
|
4652000000000019
|
Own consumption normal
For processing, see ( 4652000000000003 )
|
465200000000001A
|
Own consumption special
For processing, see ( 4652000000000004 )
|
465200000000001B
|
Own consumption zero
For processing, see ( 4652000000000005 )
|
465200000000001C
|
Prepayment reduced-1
For processing, see ( 4652000000000001 )
|
465200000000001D
|
Prepayment reduced-2
For processing, see ( 4652000000000002 )
|
465200000000001E
|
Prepayment normal
For processing, see ( 4652000000000003 )
|
465200000000001F
|
Prepayment special
For processing, see ( 4652000000000004 )
|
4652000000000020
|
Prepayment zero
For processing, see ( 4652000000000005 )
|
4652000000000021
|
Account of a third party/ third party name/ collection
For processing, see ( 4652000000000007 )
|
4652000000000022
|
Obligation |
Payments ProcessingIndicator for France
The format of the `processingIndicator` parameter on payments item level, should be as below.
Example for payments processingIndicator : 5067112530745229312
Calculation: After you identify the type of payment value (Eg: The value 4652000000000000 in hexadecimal format in the below table) you should convert it to its decimal equivalent(Eg: 5067112530745229312) and then include it in the request data.
A helpful online tool for your converting tests is [this](https://www.rapidtables.com/convert/number/hex-to-decimal.html).
Value | Description |
---|---|
4652000000000000
|
Default value
Unknown payment type: Automatic processing through the Viva fiscalisation settings is attempted. |
4652000000000000
|
Unknown payment type for FR
This is handled like a cash payment in national currency. |
4652000000000001
|
Cash payment in national currency
cash |
4652000000000002
|
Cash payment in foreign currency
cash |
4652000000000003
|
Crossed cheque
cash |
4652000000000004
|
Debit card payment
noncash |
4652000000000005
|
Credit card payment
cash |
4652000000000006
|
Voucher payment (coupon) - voucher by money value
cash |
4652000000000007
|
Online payment
noncash |
4652000000000008
|
Customer card payment
noncash |
4652000000000009
|
Other debit card
noncash |
465200000000000A
|
Other credit card
cash |
465200000000000B
|
Account receivable
Delivery note/ settlement in foreign currency internal |
465200000000000C
|
SEPA transfer
noncash |
465200000000000D
|
Other transfer
noncash |
465200000000000E
|
Cash book expense
internal |
465200000000000F
|
Cash book contribution
internal |
4652000000000010
|
Levy
internal |
4652000000000011
|
Internal/ material consumption
Can be used for bill internal |
4652000000000012
|
Change
tip cash |
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
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!