Classificao: 0 0 0 . 0 1 . 0 9 Seg.: P b l i c a Proc.

: 1 6 / 2 0 1 2

GABINETE DO SUBDIRETOR-GERAL DA INSPEO TRIBUTRIA

CIRCULAR LETTER N: 50 000/2012

Subject: Technical requisites which e) of Article 3 of Decree n 363/2010, of 23 June According to e) of n 3 of Decree n 363/2010, of the 23 June, the computer invoicing programmes shall further obey to the technical requisites approved by dispatch of the Director-General of AT. The aforementioned requisites, to which all the computer invoicing programmes shall obey, in spite of th being already certified, were approved, by my dispatch of the 26 January 2012, and are now divulged for common knowledge. 1. DIGITAL SIGNATURE PROGRAMMES OF THE DOCUMENTS ISSUED BY COMPUTER INVOICING
rd rd rd

1.1. The computer invoicing programmes shall use a digital signature, pursuant to article 6 th of Decree n
363/2010, of the 23 June, on the following documents: Invoices, equivalent documents and receipts/ tickets; Transportation or delivery notes or any other documents which function as transportation th documents, pursuant to Decree n 147/2003, of the 11 July.
rd

1.2. A digital signature shall also be used pursuant to article 6th, on any other documents, irrespective of
their designation, susceptible of being submitted to a customer to confirm the goods delivery or services, namely the so-called table checks.

1.3. Any other documents with external efficacy possibly issued by a computer invoicing programme, not
subject to the aforementioned signature, namely, budgets or pro forma invoices, shall express explicitly their nature and, when susceptible of being mistaken for an invoice, they shall bear the expression Este documento no serve de fatura (This document does not function as an invoice). Consequently the software developer is obliged to create the conditions necessary not to allow such alterations of layouts.

1.4. The invoices or equivalent documents which are originated in other issued documents, namely,
delivery notes or table checks, shall have the identification of those documents, and the aforementioned identification shall be included too in the SAF-T(PT) in the field of the line of the sale document with the index 4.1.4.14.2 (OrderReferences).

1.5. Whenever the programme in Training Mode is used, the issued documents shall, in a specific series,
indicate in the title the data that identify the software company, contrarily to what happens with the customers company and the following expression shall be printed in the documents: Documento emitido para fins de Formao (Document issued for Training purposes), although the documents are printed on the customers business writing paper (letterhead).

1.6. All types of documents shall be issued chronologically in one or more series (at least annual lists)
duly referred to, and within each one they must be numbered sequentially.

1.7. If invoices are issued by more than one invoicing programme, due to the existence of several
establishments, the document number shall have printed an identifier code of the specific series of each one of the establishments.
MOD. 004.01 Av Duque de vila, n 71- 6 1000-139 Lisboa Email: dspcit-dec@at.gov.pt

www.portaldasfinancas.gov.pt

Tel: (+351) 21 358 48 00 Fax: (+351) 21 358 48 06 Centro de Atendimento Telefnico: (+351) 707 206 707

GABINETE DO SUBDIRETOR-GERAL DA INSPEO TRIBUTRIA

1.8. No document still in preparation can be printed, unless it is immediately completed, according to the
procedures listed in 2.1 and 2.2.

1.9. The software/application cannot allow any alteration of fiscally relevant information in a document
that has already been digitally signed, namely the elements referred to in article 36th of VAT Code, in Decree n 147/2003, of 11th July and in the article 6th of the Decree n 363/2010, of the 23rd June. 2. DOCUMENTS IDENTIFICATION PROCESS (DIGITAL SIGNATURE) AND SUBSEQUENT RECORDING IN DATA BASES

2.1. Documents identification process 2.1.1. In the identification process of documents - namely an invoice or equivalent document, bill of lading for goods in circulation, indicating their amount or not, receipt, etc. - a digital signature shall be generated through the rsa algorithm based on the information pursuant to n1 of article 6th n 363/2010, of the 23rd june, and on the private key of the computer invoicing programme producer. 2.1.2. The aforementioned digital signature shall be recorded in the invoicing data base (which cannot be encrypted), being directly associated to the original documents record, according to n2 of article 6th of Decree n 363/2010, of the 23rd June. 2.1.3. Additionally the version of the private key (sequential integers) that was used to generate the signature of the respective document shall be recorded, pursuant to n2 of article 6th of Decree n363/2010, of the 23rd of June. 2.1.4. Whenever it is recorded the first document of a series/ for instance a document of an invoicing type, or a first document of the fiscal year of each type, the field referred to in e) of article 6th shall be assumed as not filled in.

2.2. Moment to print or send an electronic document

2.2.1. The documents susceptible of being digitally signed can only be printed after having been duly identified pursuant to article 6th of Decree n. 363/2010, of the 23rd June. 2.2.2. The printed document submitted to the customer or the sent electronic document shall have (obligatorily) four characters of the signature [Field 4.1.4.3 Hash of the SAF-T(PT)] corresponding to the positions 1st, 11th, 21st, and 31st, followed by - (an hyphen) to separate the expression Processado por programa certificado n. (Processed by a certified programme n) <Number attributed to the certificate by the AT>/AT replacing the sentence Processado por computador (Processed by computer). Example: AxAx-Processado por programa certificado n. 0000/AT (Processed by a certified programme n 0000/AT), (without quotation marks). 2.2.3. The documents referred to in n 1 shall also have date, series and its own sequential numeration. 2.2.4. In the receipts/tickets issued pursuant to article 40th of VAT Code (CIVA), submitted to customers who do not provide their Tax Identification Number (final consumers), the corresponding line shall be cancelled by means of dashes or shall contain the expression Consumidor final (Final consumer) (without quotation marks). 2.2.5. The final amount of the documents printed by the computer invoicing programme shall not be negative. Whenever necessary, among other documents, debit notes and credit notes will be used
2/9

GABINETE DO SUBDIRETOR-GERAL DA INSPEO TRIBUTRIA

(please refer to n13 of article 29th of VAT Code) as documents of correction of purchases and sales, the form, contents and purpose of which must be respected.

2.3. Documents integrated in the invoicing data base, originated in other solutions
2.3.1. Given the existence of various invoicing solutions to meet the taxpayers different needs, namely the invoicing in decentralized systems or in mobile systems (the so-called mobility solutions), one shall bear in mind rules which aim at the definition of the information integration conditions among different invoicing systems. 2.3.2. Thus: a) In these cases, the original solution bears the responsibility for the digital signature referred to in n1, and it shall always reside in the original system ( for only this system knows the private key and has the capacity of identifying the printed characters in the original invoice); The documents coming from other systems, which are integrated in a central system (integrator system) shall be recorded in the latter system by series/types of invoicing documents which are distinct and autonomous from those used by the system, being understood as copies of the original document and the respective field 4.1.4.3 Hash shall be equal to that generated in the issuing system; The integrator central system shall also fill in the respective field 4.1.4.4 - Hash Control with the n of the certificate with which the document was signed in the original system and the key version; The format of the information to be recorded, pursuant to the previous paragraph will result of linking together the number of the original certificate + dot + version of the private key used in the original signature of field 4.1.4.3 Hash: Example: 9999.1, where 9999 is the number of the certificate of the issuing application and 1 is the version of the key used in the respective signature; e) These documents, when are printed by the integrator system, shall mention their quality through the expression Cpia do documento original (Copy of the original document) (without quotation marks), without prejudice of other qualities that may be applied to them.

b)

c)

d)

2.3.3. A certain series/type of invoicing document cannot contain documents from different origins (ex.: contain documents created in the system and documents imported from an external system in the same series/type of invoicing document).

2.4. Integration of invoices or equivalent documents manually processed in forms issued by

authorized printing presses whenever the programme is out of order. 2.4.1. In the cases provided by article 8th of Decree n. 363/2010, the following procedures shall be carried out: 2.4.1.1. Through the programme, and in a specific series, annual, and with sequential numeration of its own, a new invoice will be processed, which gathers all the elements of the manual th invoice, obeying to the requisites defined in article 6 of Decree 363/2010. 2.4.1.2. In the field 4.1.4.4 - Hash Control after the number of the version of the private key (1,2, etc.) and separated by a - (hyphen) shall be recorded:
3/9

GABINETE DO SUBDIRETOR-GERAL DA INSPEO TRIBUTRIA

The acronym filled in field 4.1.4.7 - Invoice Type corresponding with the respective document type, followed by letter M One space The series The character / The number of the manual document Example: 1-FTM abc/00001 2.4.2. The invoices created for this procedure shall contain, when printed, the expression Cpia do documento original (Copy of the original document) followed by a hyphen which separates the expression referred to in the previous paragraph. Example: Cpia do documento original-FTM abc/00001 (Copy of the original document-FTM abc/00001) (without quotation marks)

2.5. Moment to export the file SAF-T(PT)

2.5.1. At the moment to export the file SAF-T(PT), the Hash shall be exported to the fields 4.1.4.3 and to field 4.1.4.4 The Hash Control of each structure, Invoice (sale document shall be exported to field 4.1.4) the signature and the version (sequential integers) of the respective keys, recorded previously in the data base when the recording process of the document started. 2.5.2. Documents that may be stored in the data base of a certain management solution, but which were originally created in another system, shall be the object of export to the SAF-T (PT) with fields 4.1.4.3 Hash and 4.1.4.4 Hash Control filled in pursuant to paragraphs 2.3.2 in b) c) d) and, cumulatively, shall also be exported from the original solution, with the referred to fields filled in accordingly. 2.5.3. The value of field 4.1.4.15.3 - Total amount of the document with taxes (Gross Total) shall be exported with the same amount which was considered in the signature (that is, rounded up to two decimal points), so that the divergence between the signed amount and the exported amount can be eliminated, and shall coincide with the amount printed in the issued document. 2.5.4. In the case of transportation notes or delivery notes without any expressed amount, field 4.1.4.15.3 Total amount of the document with taxes (GrossTotal) shall be filled in with 0.00 (without quotation marks). 3. TECHNICAL REQUISITES RELATING TO THE IDENTIFICATION SYSTEM WHICH B) OF N3 OF DECREE N 363/2010, OF THE 23RD JUNE, REFERS TO The rsa algorithm (algorithm of data cryptography which uses asymmetric keys, public key and private key) shall be used. The public key to be supplied shall result from its extraction from the private key in PEM format basis 64 and the respective file with the extension .txt shall be created. The software developer shall ensure that the private key used for the creation of the signature is known exclusively by him and shall be protected in the software.

3.1.

3.2.

3.3.

4/9

GABINETE DO SUBDIRETOR-GERAL DA INSPEO TRIBUTRIA

3.4.

The text to be signed relating to the document shall contain the following data linked in the following format, separated by ;(Semicolon) as in the following example:

Field of SAF-T(PT) a) 4.1.4.6 - InvoiceDate b) 4.1.4.9 SystemEntryDate c) 4.1.4.1- InvoiceNo AAAA-MM-DD

Format

Data Example 2010-03-11 2010-03-11T11:27:08

AAAA-MM-DDTHH:MM:SS

Made up by the internal code of the document, followed by a space, followed by an identifier of the series of the document, followed by a bar (/) and by a sequential number of the document within the series. ([a-zA-Z0-9./_-])+ ([a-zA-Z0-9]*/[0-9]+)

FAC 001/9

(Space)

d) 4.1.4.15.3 - GrossTotal

Numerical field with two decimal points, decimal separator . (dot) and without any separator for the thousands. Basis-64

1200.00

e) 4.1.4.3 - Hash Fields of the previous document in the same series, (empty when we are dealing with the first document of the series or of the fiscal year)

mYJEv4iGwLcnQbRD7dP s2uD1mX08XjXIKcGg3G EHmwMhmmGYusffIJjTd SITLX+uujTwzqmL/U5nvt 6S9s8ijN3LwkJXsiEpt099 e1MET/J8y3+Y1bN+K+Y PJQiVmlQS0fXETsOPo8 SwUZdBALt0vTo1VhUZK ejACcjEYJ9G6nI=

3.5.

Example of the message to be signed for the indicated data:

3.5.1. 2010-03-11;2010-03-11T11:27:08;FAC 001/9;1200.00;mYJEv4iGwLcnQbRD7dPs2uD1mX08XjXIKcGg3GEHmwMhmmGYusffIJjTdSITL X+uujTwzqmL/U5nvt6S9s8ijN3LwkJXsiEpt099e1MET/J8y3+Y1bN+K+YPJQiVmlQS0fXETsOPo8 SwUZdBALt0vTo1VhUZK ejACcjEYJ9G6nI 4. CREATION OF BOTH KEYS PRIVATE/PUBLIC To exemplify the creation of both RSA keys, it was used the application OpenSSL, which is performed directly on the command line, and can be obtained in www.openssl.org It allows among other functionalities, to create RSA keys, DH and DSA, to create certificate X.509, CSRs and CRLs, to sign digitally, to encrypt and to decrypt, etc.

5/9

GABINETE DO SUBDIRETOR-GERAL DA INSPEO TRIBUTRIA

In the analysis of the presented examples, we must take into account that: a) They are merely exemplificative, and it doesnt mean that the software producer has to or must use the application OpenSSL; The respective command lines were prepared and tested either in Linux or Windows, and the same final result was achieved; The use of the command ECHO applied on the commands line of the Windows/Dos, may present results different from those obtained in Linux, so it must not be used for test purposes; They are carried out with the format PEM.

b)

c)

d)

4.1. IN ORDER TO CREATE THE PRIVATE KEY It is enough to operate the OpenSSL with the following elements: Openssl genrsa-out PrivateKey.pem 1024 Where Private-Key.pem is the name of the file which is going to contain the private 1024 is the size in bits. The result, in this case, is the following information part of which is as follows: -----BEGIN RSA PRIVATE KEY----MIICXQIBAAKBgQCjgbQG27+lNWKdW5SXLFzFgqZu+xFWTkx0Woloo6z1gD5DhllRgQ 5hxitOW0QV1LAGlHVMfZ8PDk9e+N4YJ7cDwW4D+iflyCAEvi4xvKejEGVEInEsnA7actm g9OROrMHXKqy 7mA41P//.. -----END RSA PRIVATE KEY----4.2. IN ORDER TO CREATE THE PUBLIC KEY BASED ON THE PREVIOUS PRIVATE KEY It is enough to operate the command OpenSSL with the following elements: Openssl rsa-in PrivateKey.pem -out Public Key.pem -outform PEM pubout WherePublicKey.pem is the file which contains the public key. To upload the PublicKey together with the Return Model 24, it is enough to rename its extension from pem to .txt (without quotations). The result, in this case, is the following information part of which is as follows: -----BEGIN PUBLIC KEY----MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCjgbQG27+lNWKdW5SXLFzFgqZu+xFWT kx0Woloo6z1gD5DhllRgQ5hxitOW0QV1LAGlHVMfZ8PDk9e+N4YJ7cDwW4D+iflyCAEvi4xv KejEGVEInEsnA7actmg9ORO ... -----END PUBLIC KEY----6/9

key and

GABINETE DO SUBDIRETOR-GERAL DA INSPEO TRIBUTRIA

4.3. IN ORDER TO VERIFY THE PUBLIC KEY It is enough to operate the OpenSSL command as follows: Openssl rsa -in ChavePublica.pem -noout -text pubin 5. CERTIFICATES CREATION

5.1. Both keys used dont require the issue of a certificate on the part of an accredited entity. The software producer may generate an auto-signed certificate for certification purposes and from this certificate the public key can be extracted to submit to the AT, with the extension .txt. 5.2. For the creation of the certificate from the private key, the RSA algorithm shall be used with the following specifications in the parameters: Format = x.509 Charset = UTF-8 Encoding = Base-64 Endianess =Little endian OAEP Padding = PKCS1 v1.5 padding Size of the private key = 1024 bits Format of the Hash of the message = SHA-1 6. PRACTICAL EXAMPLE OF THE SIGNATURE MECHANISM 6.1. Creation of the digital signature by means of a private key Independently of the RSA implementation that is adopted and that is more adequate to each solution, it must be ensured that the signatures have 172bytes, without any lines separating characters.

FIELDS OF THE SAF-T(PT) 4.1.4.6 - InvoiceDate 4.1.4.9 - SystemEntryDate 4.1.4.1-InvoiceNo 4.1.4.15.3 - GrossTotal 4.1.4.3 - Hash

RECORD 1 2010-05-18 2010-05-18T11:22.19 FAC 001/14 3.12 See first record

RECORD 2 2010-05-18 2010-05-18T15:43.25 FAC 001/15 25.62 See second record

7/9

GABINETE DO SUBDIRETOR-GERAL DA INSPEO TRIBUTRIA

The elements to be signed (InvoiceDate, SystemEntryDate, InvoiceNo, GrossTotal and Hash) shall be linked together just by the separator ; , between each of the fields, and they must not be between quotation marks or any character of end of line, when it is to be encrypted, aiming at obtaining the signature. 1 RECORD Being the first record, field 4.1.4.3 - Hash is filled in with the hash resulting from the application of the private key previously created, to sign digitally the fields (InvoiceDate, SystemEntryDate, InvoiceNo and GrossTotal). The text to be signed will be as follows: 2010-05-18; 2010-05-18T11:22:19; FAC 001/14;3.12; 1 STEP: Save the message to be signed 2010-05-18; 2010-05-18T11:22:19; FAC 001/14;3.12; In a text file (which in this example we will name as Record1.txt), ensuring that in the end of the message without any break of lines, just ; without quotation marks. 2 STEP To sign the message contained in the file Record1.txt with the following command: openssl dgst -sha1 -sign PrivateKey.pem -out Record1.sha1 Record1.txt The file Record1 shall contain the hash in the binary system generated by the application OpenSSL. 3 STEP Afterwards it is necessary to do the encoding for basis 64 of file Record1.sha1: openssl enc -based64 -inRecord1.sha1 -out Record1.b64 -A The file named as Record1.b64 is the one that contains the 172 characters in ASCII of the signature which shall be transported to the data base and later on exported to the field 4.1.4.3 Hash of the SAF-T(PT) The parameter A aims only at generating the signature by the OpenSSL in just one line avoiding the additional line breaks. Consequently the file Record1.b64 will have the following signature: oso2FoOw4V94ICwKTrv6xwzUrOtxBWCwUOyLVAgKwfOCNKZHMETGIXZZC4spRSyby1uDXBgg plogrl8gHnvevA00OEoAvGJo9Fa3DOAOMhZNDa9/rNvu71pp+OzHmN2ra5lWpiHcgmUYxm5gamL Bk49rkgvl7h1myKCYBKggu60=
8/9
RD ND ST

ST

GABINETE DO SUBDIRETOR-GERAL DA INSPEO TRIBUTRIA

The latter signature shall be recorded in the field HASH of the previous table in the position corresponding to Record1 2 RECORD Using an identical procedure, but now with the data of Record2 and the hash of the previous record we should have as a message to be signed in the file Record2.txt: 2010-05-18;2010-05-18T15:43:25;FAC 001115;25.62;oso2FoOw4V941CwKTrv6xwzUrOtxBWCwUOyLVAgKwfOCNKZHMETG1XZ ZC4spRSyby1uDXBggplogrl8gHnvevA00UEoAvGJo9Fa3DOAOMhZNDa9/rNvu71pp+OzHm N2ra5lWpiHcgmUYxmSgamLBk49rkgvl7hl myKCYBKggu60= Using the procedures abovementioned for Record1, from step 1 to step3 File Record2.sha1 and File Record2.b64 were created. Consequently the latter file, Record2.b64 shall have the digital signature of record 2: Y2ogVAC9rcmm9hilZCGGrxjpkZP9NHn5shhp9phBIVWIn+Ta2zKf+O+05brA6VUOLULtMQ P98P29q+vcSwVtxSzLDbmmkHMt416nQmh9IQaOJwPpz2uMgtR3aMkWYPK4Ntc/yfnXpY 1 cSeUGbQkqAsJOFSidRE4+DibJaC7WMpw= Which shall be recorded in field 4.1.4.3 Hash of the previous table and in the position corresponding to Record 2. 6.2. Validation of the created digital signature To confirm the validity of the signatures it is enough to operate the command: openssl dgst sha1 -verify publickey.pem -signature registo1.sha1 registo1.txt
ND

Taxation and Customs Authority, the 26th of January, 2012 The Director-General of the Taxation and Customs Authority

(Jose A. de Azevedo Pereira) DISCLAIMER: THIS TRANSLATION IS NOT, AND DO NOT PURPORT TO BE, OFFICIAL, AND IS INTENDED FOR INFORMATIONAL USE ONLY. IT HAS NO STATUS OTHER THAN AS AN INFORMAL, UNOFFICIAL, AID TO NON-PORTUGUESE SPEAKERS IN UNDERSTANDING THE PORTUGUESE SOFTWARE CERTIFICATION LAW. ONLY THE PORTUGUESE ORIGINAL CAN BE RELIED ON FOR INTERPRETATIVE PURPOSES, AND IN ANY DEALINGS WITH THE PORTUGUESE TAX SYSTEM OR ITS OFFICIALS.

9/9