How To Guide Fiscal Portugal
Enactor Overview
Enactor is both the name of the software company and the product which it produces. The Enactor product contains an number of modules which fulfil various functions for the retail and hospitality sector. The core of this offering is the POS solution which runs on POS devices in the stores and restaurants of our customers. Enactor the company does not produce any hardware, instead our customers are free to choose POS hardware and the Enactor software solution is written in Java so as to be platform agnostic and support a wide variety of hardware and operating systems.
POS devices are configured and centrally managed from a single point, in a module referred to as the Estate Manager. Users are able to configure all the POS devices in their estate on the Estate Manager and broadcast this configuration to the POS devices as required. When sales people perform transactions on a POS in the store, the transaction is persisted to a local database on the POS but also transmitted to the Estate Manager which has a central repository of all transactions. It is this central repository called the retail transaction archive which is the master of transaction data. Typically our customers will take a feed from this database to populate sales data to their ERP and accounting platforms.
It is possible to maintain data such as products and prices within the Estate Manager but this is not the typical approach taken by our customers. Instead they usually integrate Enactor to other backend systems to take a feed of data for things like products, prices, users and locations. However the approach taken differs from customer to customer and Enactor has been developed in such a way that it gives great flexibility in this area.
Optionally, customers can choose to have store servers at each or some locations to distribute load and provide some level of fail over in the event of network outages, although this is not required.
While the above gives a very high level overview of the Enactor solution and modules that are relevant to Fiscal there are a number of other modules that are optionally available to our customers, including but not limited to:
-
Order Manager
-
Customer Manager
-
Payments
-
Inventory Manager
Our customers can either choose to use these modules or integrate Enactor to existing applications fulfilling these requirements.
Fiscal Overview
For shared background, see Fiscal Overview.
Portuguese Fiscalisation Introduction
In Portugal, POS fiscalisation is a legal requirement for businesses to ensure accurate and transparent financial reporting.
The process of POS fiscalisation in Portugal involves several key components:
-
Certified POS Software: Businesses must use certified POS software
that meets the requirements set by the Portuguese tax authorities. The software must have built-in features to record and store transaction data securely.
-
Electronic Signature: The certified POS software generates a secure
electronic signature for each transaction. This signature ensures the integrity and authenticity of the recorded data. The signature of the prior transaction is used as part of the data signed to create the signature for the next transaction. In this way a chain of signatures is created which allows the Tax Authority to detect transactions that have been altered after being signed, potentially fraudulently.
-
Transaction Recording: The POS system records all sales transactions,
including details such as the date, time, and amount which is also part of the signature for each transaction.
-
Reporting and Archiving: Periodically, the retailer must generate a
report in the SAF-T file format and submit this to the Tax Authority.
-
Auditing and Compliance Checks: Tax authorities in Portugal conduct
periodic audits and compliance checks to ensure businesses are adhering to fiscalisation regulations. During these checks, businesses must provide access to their POS system and transaction records to validate the accuracy and completeness of their financial reporting.
It's important for businesses in Portugal to select a certified POS software provider and ensure proper installation and configuration of the system to meet fiscalisation requirements. Failure to comply with POS fiscalisation regulations can result in penalties, fines, or legal consequences.
Overall, POS fiscalisation in Portugal aims to enhance transparency, combat tax evasion, and streamline the process of tax collection by leveraging electronic recording and reporting of sales transactions.
Enactor Portuguese Fiscal System Overview
In addition to the usual Enactor POS functions there are some additional features and requirements in Portugal that are necessary to comply with the fiscal legislation in force there. If the POS terminal is configured with a fiscalisation type of Portugal these requirements will become relevant and will be enforced, in some cases the POS will fail to start or complete transactions unless valid configuration for them is in place.
Transaction Signing
Transactions in Portugal must be signed using an asymmetric public/private key pair. Practically this means that the following data for each transaction is hashed and then signed using the private key of the key pair.
-
Receipt date
-
Last modified date and time of receipt
-
Receipt number
-
The total gross amount of the receipt in euro
-
Signature of the previous receipt
Note: The first receipt of the fiscal year will not include the previous signature.
In the event of the Tax Authority needing to verify a transaction or a series of transactions they can first hash the relevant transaction data in the same manner as Enactor did, then use the public key to decrypt the hash signed by Enactor to ensure it matches. In this way the Tax Authority can be sure that
-
Enactor signed the transaction, since only they have the private key.
-
The signed data has not been modified since the hashes match.
-
No transactions have been deleted, since the prior receipt signature
matches.
However, this is all dependant on the private key being known only to Enactor. This poses a technical challenge as the private key is required on each POS since this is where the signing of transactions takes place. This means that a mechanism must be in place to share the private key with each device in a secure manner.
To achieve this, an approved person at Enactor will generate the key pair and then encrypt the private key in an account credential using the Enactor system key which is known only to Enactor. Account Credentials are an Entity that is used within the Enactor solution for securely sharing credentials. This account credential can then be shared with the customer as an XML file, imported into their system and broadcast to all Portuguese POS devices. When a transaction needs to be signed on the POS (which has the System Key securely embedded within it) it can decrypt the private key and sign the transaction. Enactor has taken industry standard steps to ensure that both the system key and the decrypted private key are protected whilst they are being used.
Receipt
The general layout of the receipt in Portugal is not mandated, however, there are a number of mandatory elements that must be included on the receipt:
-
Retailer Company Information
-
Name
-
Address
-
Phone Number
-
Tax Number
-
Capital Social
-
-
Date and time of receipt issuing
-
Item
-
Price
-
Quantities
-
-
Total amount of receipt
-
VAT rate applied and VAT breakdown
-
Receipt Number
-
Fiscal mark
-
ATCUD code
-
QR code
The Enactor solution ships with a Portuguese fiscal receipt template that is compliant and has been verified with the Tax Authority. However, since the layout is not mandated and retailers often wish to customise the layout of the receipt to their needs the standard receipt configuration tools are still available. Care must be taken to ensure that any receipt modifications do not remove mandatory elements from the default receipt as this could render the retailers receipt non-compliant with the Portuguese legislation.
The majority of the receipt elements are self-explanatory but the fiscal mark requires some explanation of how it is formed. It takes the following construct:
-
Digital signature extract - a group of 4 characters of the signature
corresponding to the 1st, 11th, 21st and 31st positions, as the full digital signature is not visible on printed receipts/invoices
-
Hyphen “-” as a separator
-
The expression “Processado por programa certificado n.º”
-
The certificate number assigned to the respective program
-
/AT
Example: “09xW-Processado por programa certificado n.º 1234/AT”
Example Receipt:
All receipts issued in Portugal are invoices however in the case that the customer is a B2C customer and that they do not wish to provide their details it is permitted to print Consumidor Final in place of their tax ID, as shown on the above receipt. In the case of B2B sales the customer details must be captured and the Tax ID will be printed on the receipt.
Document Series
Documents produced by the system require document numbers which run is series and different types of documents have different series. The format is defined by the Portuguese legislation, in the above example the document number is “FT 11_3_2023/7”. At the beginning of each year it is necessary to register these series with the Portuguese Tax Authority and they provide a web service to do this. The response that is received from the Tax Authority when registering the document series is necessary to generate the ATCUD code which must be printed on the receipt.
The Web Service used to register the series is protected and is only available to retailers who are registered with the Tax Authority. Enactor manages the registration of the document series when required but to do this we must have available the required credentials, the retailer must obtain and provide these to Enactor.
Retailers can use the Tax Authority web portal to obtain these credentials which must be provided to Enactor in the account credentials, as documented in the Configuration Overview section of this document.
The Tax Authority also provide a test endpoint and credentials which can be used both by the retailer and the developer of the solution in their test environments. These test credentials are provided by Enactor for the purpose of testing, they are the only credentials available to Enactor. However, these must not be used in a production environment.
Advanced Payments
Enactor allows retail customers to place an order for goods to be collected at a future date. These goods can either be paid for in full or in part. At the time of placing the order and making the advanced payment an Invoice will be issued and fiscalised for the value of the advanced payment, be that full or partial. At the time of collection if there is any balance to be paid a second invoice will be produced and fiscalised for the balance amount.
Should the customer wish to cancel an order prior to collection and the payment of any balance a credit not will be issued at the time of cancellation. This will be for the amount of any deposits paid up to that point.
SAF-T File
Periodically retailers are required to produce a SAF-T file and share this with the Tax Authority on their online portal. This is done from the Estate Manager using the SAF-T File Generator, which is available at:
This will present the following screen where the details for the required SAF-T file to be produced can be provided.
Note: SAF-T files are used in both Norway and Portugal, however the format differs slightly so it is important to select the correct version.
The location should be selected but in normal operation SAF-T files will be produced for all devices at a location so the device selection should be left at the default of ALL.
On clicking Generate, a scheduled job is created to produce the SAF-T file in a background process. Once this has completed the SAF-T file will be available to download from File Downloads.
User Access
The Enactor solution implements standard user access functions. Each time a user interacts with a system they must log on, whether they are using a POS, the Estate Manager or a Store Server. Both individual per user, user name/password or SSO approaches are supported by Enactor. Since the Portuguese Fiscal Legislation requires the ID of the user to be recorded for certain operations it is imperative that the retailer using the Enactor solution does not circumnavigate these security measures by allowing the sharing of logins among their staff.
Data Integrity
Transaction data, including the fiscal records, are stored at the Estate Manager in its database. The Estate Manager is the master of this data, although it may also be held on the POS and Store Server it is the Estate Manager that is the authoritative source. Since there is a legal requirement to protect this data so as to be able to produce the SAF-T file, it is important that this data is backed up in a way that nothing would be lost in the event of a disaster recovery scenario.
The needs of every customer differ in this area and Enactor will work with each customer to ensure that this requirement is met but it will need to be addressed using industry standard approaches e.g. differential backups, clustering, mirroring.
Transaction data integrity is ensured in transit from the POS to the Estate Manager by employing queues to receive data, monitoring sequence numbers to ensure all data is received at the Estate Manager and offering the ability to replay transactions from the POS to the Estate Manager in the event of failures. Transactions in progress can also be recovered should, for example, their be a power failure mid transaction. However, it’s unlikely these types of failure would occur in the narrow window of transaction finalisation/fiscalisation/persistence so would not usually be a concern for fiscal compliance.
Configuration
The following configuration changes are required and should be broadcast to all Portuguese devices in preparation for go live. Detailed steps for how to do this are contained in supplementary How to Guides available on the Enactor Insights portal, as well as being covered in the Introduction to Enactor training course.
JAR Deploy
The pos-fiscalisation.jar taken from a POS that has the latest version of the Portuguese fiscal solution installed should be deployed to the EM using the JAR Deployer.
Note: The JAR taken from the POS will include the version number in its name as well.
Tax Groups
The following tax groups should be configured and broadcast to the appropriate Portuguese devices.
Tax Group ID | Description |
---|---|
PT_1 | PT Standard VAT - 23% |
PT_2 | PT Reduced Rate 1 - 13% |
PT_3 | PT Reduced Rate 2 - 6% |
PT_4 | PT Zero Rate - 0% |
Tax Scheme
The following tax scheme should be configured and broadcast to the appropriate Portuguese devices.
Tax Scheme ID | Description | Price Include Tax |
---|---|---|
PT | PT VAT | TRUE |
Tax Rates
The following tax rates should be configured and broadcast to the appropriate Portuguese devices.
Tax Rate ID | Description | Display Code | Percentage | Fiscal Tax Rate Reference | Tax Type | |
---|---|---|---|---|---|---|
PT_1 | PT Standard VAT - 23% | 23% | 23% | NOR | VAT | |
PT_2 | PT Reduced Rate 1 - 13% | 13% | 13% | INT | VAT | |
PT_3 | PT Reduced Rate 2 - 6% | 6% | 6% | RED | VAT | |
PT_4 | PT Zero Rate - 0% | 0% | 0% | ISE | VAT |
Tax Region
If it does not already exist, a Tax Region for Portugal should be created within the Tax Region Group Hierarchy. It should have the ID: “PT” and the Name: “Portugal”, it is not necessary to configure an External Reference ID.
Tax Group Tax Methods
The following tax group tax methods should be configured and broadcast to the appropriate Portuguese devices.
Tax Group ID | Tax Scheme ID | Description | Tax Rate |
---|---|---|---|
PT_1 | Portugal | PT Standard VAT - 23% | PT Standard VAT - 23% |
PT_2 | Portugal | PT Reduced Rate 1 - 13% | PT Reduced Rate 1 - 13% |
PT_3 | Portugal | PT Reduced Rate 2 - 6% | PT Reduced Rate 2 - 6% |
PT_4 | Portugal | PT Zero Rate - 0% | PT Zero Rate - 0% |
POS Terminal
Note: As per usual practice POS Terminal Templates should be used to ensure that configuration is consistent across Portuguese POS devices. For more details see the Enactor Books.
The POS Terminal configuration used by all devices in Portugal must have the fiscalisation Type set to Portugal. Currency should be set to Euros and Locale to Portuguese.
Product Tax
The following tax configurations should be configured againts the products and broadcast to the appropriate Portugal devices.Tax group can be defined to either configure the tax group or have a tax group by tax region.
The primary Receipt should be set to Fiscal 44 Standard Receipt.
Within the Tax section the Tax region should be set to Portugal and the tax scheme to the Portuguese tax scheme configured in the previous section.
Privileges
The following privileges will need to be configured against the appropriate roles and broadcast to the Portuguese devices. Consideration should be given to whether it is desirable for all operators to have all of these privileges or if some should only be granted to managers. For more detail on Privileges and roles refer to the How-To Guide Configuring User, User Roles and User Templates
Privilege ID | Application Package |
---|---|
enactor.pos.RequestSimpleFiscalInvoiceAllowed | Enactor POS |
enactor.pos.SavePagePrinterReceiptToFile | Enactor POS |
enactor.pos.SKipPagePrinterReceiptPrint | Enactor POS |
enactor.pos.AuthorisesTaxExemptTransaction | Enactor POS |
enactor.pos.AuthorisesTaxExemptLineItem | Enactor POS |
enactor.pos.TaxExemptLineItemAllowed | Enactor POS |
enactor.pos.TaxExemptTransactionAllowed | Enactor POS |
Account Credentials
The account credential XML file provided below should be imported into the Estate Manager. This account credential is suitable for test environments but must not be used in a production environment since it will configure the system to use test endpoints at the Tax Authority.
Before use in production, the account credentials provided will need to be updated in the estate manager. The values in the table shown below where the Obtain From field shows Tax Authority should be updated with the files and values obtained from the Tax Authority Portal which will be customer specific.
This configuration will need to be performed on the Estate Manager Account Credentials Maintenance Application.
Related To | Property | Value | Description | Obtain From |
---|---|---|---|---|
Document Series Web Service | CERTIFICATE | 2993a77b-99bd-4c21-bb2b-7f3836ead06a_ChaveCifraPublicaAT2023.cer | Client certificate issued by Portugal Tax Authority. | Tax Authority |
KEY_STORE | a092846e-9004-45fb-9f1f-dfc4e21aead1_PortugalKeystore.JKS | Contains the PFX file which contains private/public key pair provided by the Portugal Tax Authority for digitally signing messages. | Tax Authority | |
KEY_STORE_PASSWORD | password value | provided by the Portugal Tax Authority. | Tax Authority | |
TRUST_STORE | ed6473f6-9349-4e18-a82b-f02a49a28608_PortugalTrustStore.JKS | Contains certificate required for SSL handshake on service calls to Portugal tax authority on registering document series. | Tax Authority | |
TRUST_STORE_PASSWORD | password value | password for the trust store. | Tax Authority | |
USERNAME | 770011950 | Username to access the web service on registering document series. This is the same as the login username used for the finance portal. | Tax Authority | |
PASSWORD | password value | login password used for the finance portal. | Tax Authority | |
Sign Fiscal Transactions | PRIVATE_KEY | RSA keypair private key value | RSA key pair private key generated which is used sign Portugal fiscal transactions. public key is shared with the PT TA upon certification. | On the default Account Credential |
Certificate Number issued by PT TA. | CERTIFICATE_NUMBER | 9999 | This value should be updated after certifying the POS with the number sent by TA. | Tax Authority |