ANNEX I

Technical requirements

For validation purposes, taxpayers' electronic billing processing systems must ensure:

1. The export of the SAF-T (AO) XML file, in accordance with Decree
Presidential No. ______ / ____, and the respective data validation scheme “XSD”;

2. The incorporation of mechanisms to identify the recording of documents,

through an asymmetric encryption algorithm and a private key of exclusive knowledge of the respective
manufacturers;

3. That do not have functions and functionality that, locally or remotely,

allow to alter, directly or indirectly, the information of fiscal nature, without generating evidence aggregated
to the original information;

4. That in the process of creating documents issued by electronic billing processing systems, the
following requirements must be observed:
a) The referred systems must sign any documents issued with external effectiveness (with the
exception of receipts), namely:
• Invoices and corrective documents;
• The transportation slips, delivery notes and any other documents that constitute the
transport document;
• Any other documents, regardless of their designation, that can be presented to the
client for a conference on the delivery of goods or the provision of services, namely the
so-called table consultations.

b) The signature of the documents referred to in the previous paragraph, must obey and be in accordance
with the requirements defined in number 34 of this annex (s);

c) Any documents that are not invoices or amending invoice documents, must clearly contain
their nature and, if liable to be presented to the client, including those that must appear in
the tables 4.2, 4.3 and 4.4 of the SAF-T (AO), contain the expression " This document is not
an invoice ";

d) Invoices, documents for the movement of goods, conference documents for the delivery of
goods or the provision of services that may be presented to the customer, which originated
in other documents issued, namely, invoices, guides for the movement of goods,
consultations with or other documents likely to be presented to the client, must contain the
identification of those documents, in the structure Reference to the source document
(OrderReferences) of the tables 4.1 to 4.3, as the case may be;
 e) Rectifying invoice documents must contain the identification of the rectified document (s) in
the structure References to invoices (References) in table 4.1;

f) In the case of using the program in training mode, the documents thus issued must, in a
specific series, always indicate in the header, the identifying data of the software company,
instead of that of the client company and must also have the expression: " Document issued
for training purposes ", even if printed on the client's letterhead;

g) All types of documents, identified through the respective designations, must be issued
chronologically in one or more series, conveniently referenced, according to the commercial
needs, and must be dated and numbered in a progressive and continuous way, within each
series, for a period of not less than one fiscal year ;

h) In the identification of documents, characters that violate the validation scheme or can be
interpreted as XML operators must not be used. No other information (such as the year or
number of the computer terminal, etc.) may appear in the numerical sequence, which, if any,
should always appear in the series identification;

i) The identification code of the series (s) must be specific to each of the establishments and
or program (s), and can never be repeated in the same taxpayer, for the same type of
document, in order to uniquely identify each document issued , even if documents are
issued by more than one billing program;

j) If, for technical or operational reasons, the use of a series is discontinued, the application must
inhibit its use, and cannot in any way erase any information related to it;

k) No document in a state of preparation or in preview may be printed before its finalization and
respective signature;

l) The application must not allow any tax-relevant information to be altered in an already signed
document, namely the fields defined in paragraphs e) and g) of number 34 of this annex.

5. That in the signature process for document identification, the information systems
a) Invoices or corrective documents, documents accompanying goods in circulation, valued or
not, documents issued for conference, among others, a signature must always be
generated through the
 RSA algorithm based on the information related to the document in point 34 of this annex;

b) The signature referred to in the previous paragraph must be recorded in the database of the
electronic billing processing system (which cannot be encrypted and must be maintained during
the legal filing period), with a direct association with the full registration of the original
document. ;

c) The version (sequential integers) of the private key that was used to generate the signature of the
respective document must be recorded in addition, under the terms of paragraph f) of number 34
of this annex;

d) The change in the key pair used by the electronic invoicing processing system can only be carried out
by the manufacturer after communication to the AGT through the Model 8 Declaration and the
respective sending “ Upload ”Of the respective public key;

and) As a rule, documents are signed taking into account the hash of the last document issued in
the same series / type. In the case of recording a first document of a series / type of billing
document, the applicable Document Key (Hash) field in tables 4.1 to 4.3, must be assumed
as not filled in. In the case of using multi-annual series, at the beginning of each year, the
first document may be signed taking into account the hash of the last document issued in
the same series / type, in the previous fiscal year;

f) The amount to be considered in the Total document with taxes (GrossTotal) fields in tables 4.2
and 4.3, for the signature of goods movement documents or conference documents is what
appears in the database, regardless of the model used in its impression, valued or not. In
the absence of a value in the database, the said field must be filled in with "0.00" (without
quotes) and thus considered when signing;

g) If the document is issued in foreign currency, the value to be signed must be the equivalent
amount in AOA since this will be the value to be exported in the SAF-T (AO) file.

6. That in the process of printing or sending electronic documents, billing processing systems must
meet the following requirements:
a) Documents that can be signed, can only be printed after being duly identified in accordance
with the requirements contained in number 34 of this annex;

b) The printed document delivered to the customer or the electronic document sent must contain
four characters of the signature [Key fields of the
 document (Hash) of the subordinate tables in table 4 - Commercial documents
(SourceDocuments) of SAF-T (AO)] corresponding to positions 1, 11, 21, and
31st and separated by a "-" (hyphen) the expression Processed by validated program
No. "Certificate number assigned by AGT» / AGT.
Example: "PbRc-Processed by validated program No. 0000 / AGT" (without quotes);

c) Any document issued by the application validated for tax purposes, printed or sent
electronically, not capable of being signed under the terms of number 5 of this annex,
namely receipts, must contain printed the expression - Issued by validated program no. "
Certificate number assigned by AGT »/ AGT. Example: "Issued by validated program No.
0000 / AGT" ( without quotes);

d) The documents referred to in number 4 must, in their printing, contain the date in the format
"YYYY-MM-DD" or "DD-MM-YYYY" (without quotes);

e) In the invoices issued under the terms of the Legal Regime of Invoices and Equivalent Documents,
delivered to customers who do not provide their tax identification (final consumers), the
corresponding line of the purchaser's TIN must be rendered useless or the expression " Final
costumer" ( without quotes);

f) Documents printed by the billing program must not contain negative values. When
necessary, amending invoice documents (debit notes and credit notes, as documents for
the correction of purchase and sale transactions, whose form, content and purpose must be
respected, will be used. Negative values can only be printed in cases of cancellation of
records that are already part of the document or to adjust estimates in the provision of
continued services. The negative value can never be greater than the positive value of the
same item or service in each invoice. If the adjustment, per item, is higher than the positive
value, we are facing a regularization that requires the issuance of the respective credit note;

g) The mention of deductibles, guarantee values or withholdings at source must appear in

specific fields, developed for the purpose in the computer application, whose description cannot
be modified. These amounts will have no influence on the totals of the issued document and
should be referred after the total of the document with taxes is calculated (GrossTotal field of
the tables
4.1 to 4.4). Under no circumstances can types of products or services be created or use the
table of products / services (Product) for this purpose;

h) The printing by the document integrating system integrated in it, must mention this quality, through
the expression "Copy of the original document" (without quotes), without prejudice to others that
are applicable to it;
 i) The documents created by the procedure indicated in number 8 of this annex, must contain, when
printed, the expression - "Copy of the original document" and separated by a hyphen the
elements referred to in point e) of paragraph e) of number 8 of this annex, with the exception of
the HashControl element;
Example: Copy of the original document - FTM abc / 089

j) The documents created by the procedure indicated in number 9 of this annex, must contain, when
printed, the expression - "Copy of the original document" and separated by a hyphen the elements
referred to in the respective point ii) of section e), with the exception of element related to
HashControl;
Example: Copy of the original document - FTD XY 2019B / 092

k) The documents referred to in number 4 of this annex, when printed on more than one page,
must show in all of them the type designation of the document, the respective numbering in
accordance with paragraph
d) (of this number), the accumulated values (transported and to be transported), the respective
page number and the total number of pages. The global calculations of taxable base, tax
calculation and total of the document, when they exist, must appear exclusively on the last page;

l) If preprinted paper is used for printing the documents referred to in paragraph 4 of this annex,
the application must ensure the printing of all the relevant tax elements including the
mandatory information, the identifying details of the issuing taxable person and the nature of
the document. Logo printing is not included in this context;

m) The printing of documents in which the transmission of goods or provision of services are
exempt from tax, must display the legally provided expression that confers the exemption or,
in its absence, the applicable legal norm. If there is no reason for exemption in the respective
line, you should use any type of referencing that allows the association of the exempt line with
the respective reason. The same is valid for associating any tax rate to the respective product
/ service;

n) The printing of a duplicate of a document must preserve its original content, even though it
must contain any expression that indicates that it is not an original. Thus, for example, if a
customer's address or name is changed in the database, the reprint of a document must
respect the original address and name.

7. That in the process of integrating documents in the database of the billing processing system,
originating from other computer applications, the following requirements must be observed:

a) Given the existence of several billing solutions to meet different taxpayers' needs, namely
billing in systems
 decentralized or mobile systems (so-called mobility solutions), rules should be taken into
account in order to define the conditions for integrating information between different billing
systems.
In these terms, the integrating application must not process any recalculation or modification of
the content of the integrated documents from other systems, including respecting the unique
identification of the documents (InvoiceNo, DocumentNumber or PaymentRefNo), except for what
is mentioned in the following points.

b) The signature referred to in number 5 of this annex is, in this case, the responsibility of the
original solutions (integrated solutions);

c) A certain series / type of billing document, goods movement or any other document that can
be delivered to the customer for goods delivery or service provision conference cannot
contain documents with different origins (example: contain documents created in the system
and imported from an external system in the same series / type of billing document).

d) Thus, the central system that performs the integration must:

• Integrate documents from other systems, in the series / types of original documents,
distinct and autonomous from those used for own issuance, in the corresponding tables
of commercial documents (4.1., 4.2. Or
4.3) the integrated documents being understood as copies of the original document, in these
tables;

• Put the information related to the Document Key (Hash) field the same as that generated in the issuing
system, in the corresponding tables 4.1 to 4.3 in which the document is integrated, that is, they must
be the same, in the integrating and integrated system;

• Fill in the Document Origin (SourceBilling) fields in tables 4.1 to 4.3, as the case may be,
with the value "I" (without quotes);

• Fill in the Control key field (HashControl), from tables 4.1 to 4.3, as the case may be, with the
number of the certificate with which the document was signed in the original system and the
respective version of the key;

• The format of the information to be registered, in the Control key (HashControl) fields in tables
4.1 to 4.3, under the terms of the previous paragraph, will result from the concatenation of the
number of the original certificate + a point + version of the private key used in the original
signature respectively of the fields Document key (hash) from the mentioned tables 4.1 to 4.3;
 • In the case of the information to be included coming from a program not validated by the AGT,
the value of the Control key field (HashControl) of tables 4.1 to 4.3, applicable to the type of
information, must be marked "Not Validated by AGT" (without quotes) . The value of the
respective field (Hash) must be "0" (zero). Documents in these conditions must not be reprinted
by the integrating application.

8. That in the process of integrating documents processed manually into forms issued in authorized
printers, in cases of inoperability of the billing processing systems, the following requirements
must be observed:

a) The integration of invoices or other corrective documents and transport documents, processed
manually, must be carried out in the program validated in a specific series, of annual or higher
frequency and with its own sequential numbering, starting in paragraph 1;

b) For this purpose, a new document of the same type will be processed, which collects all the elements of
the issued manual document, in compliance with the requirements defined in number 34 of this
annex;

c) In the recovery series, the date of the document corresponds to the date of the manual document
and it is in the best interest to create separate, mandatory fields, one to accommodate the
identification of the manual series and the other for the manual number, in order to avoid lapses
in the collection of this type of documents, namely, the series. As many series can be created as
there are in manual documents or just a single series.

d) Fill in the Document Origin field (SourceBilling) of tables 4.1 and 4.2, as appropriate, with the
value "M" (without quotes).

e) In these cases, in the Control key field (HashControl) of tables 4.1 and 4.2, depending on the case, the
following information must be added:

i. Version number of the private key (1,2, etc.) and separated by a "-" (hyphen);

ii. Sequential registration of the following elements: the acronym in the Document Type field
(InvoiceType or MovementType), corresponding to the respective type of document, followed by
the letter M; a space; the manual document series; the "/" character; the manual document
number.
Example: 1-FTM ab / 0001, where "ab / 0001" is the series / number of the manual document.

f) To reference a manual document collected in the application, the series and the number of the original
manual document must be used, and not the unique document identification (InvoiceNo or
DocumentNumber) assigned by the application to the
 recovered document. (Example: The issuance of a credit note must reference the original
invoice number, issued manually.)

g) When there is a need to integrate other types of manual documents, the applicable fields of the
table that fits them will be used, proceeding in the same way as already mentioned in the
previous numbers.

9. That in the process of document integration through duplicates that do not integrate the backup
copy, when there is a need to replace data due to system inoperability, the following
requirements must be observed:
a) When a program error or anomaly occurs, the series in use must be closed and new ones
created, to proceed with the issuance of documents, after the replacement of the last
backup copy;

b) The integration of documents issued that are not included in the backup copy, must be carried out in
the certified program, through duplicates of these documents, in a specific annual series and with
their own sequential numbering, starting in paragraph 1;

c) For this purpose, a new document of the same type as the duplicate will be processed that collects all
the elements of that issued document, in compliance with the requirements defined in number 34 of
this annex;

d) The Document Origin field (SourceBilling) of tables 4.1 to 4.2, as the case may be, must be filled in
with the value "M" (without quotes);

e) In these cases, in the Control key field (HashControl) of tables 4.1 and 4.2, depending on the case, the
following information must be added:
i. Version number of the private key (1,2, etc.) and separated by a "-" (hyphen);

ii. Sequential registration of the following elements: the acronym in the Document Type field
(InvoiceType or MovementType as applicable), which must correspond to the type of document
to be retrieved through the duplicate, followed by the letter D; a space and the unique
identification of the document (InvoiceNo or DocumentNumber, as the case may be).

Example: 1-FTD KM 2019A / 0099, where "KM 2019A / 0099" is the unique identification of the
integrated document.

f) In data recovery series, the date of the document corresponds to that of the duplicate of the
document. It is in the best interest to create separate, mandatory fields to accommodate the
internal code for the type of document, series and duplicate number in order to avoid lapses
in the collection of this type of documents, namely, the internal code of the document. type of
document and series. You can create as many series as there are duplicates of documents,
or just a single series;
 g) To reference an original document collected in the application, the internal code of the document type, the
series and the number of the original document must be used, and not the unique identification of the
document (InvoiceNo or DocumentNumber) assigned by the application to the document recovered;

h) When there is a need to integrate other duplicates of other types of documents, the applicable
fields and procedures of the previous numbers will be used.

10. That in the process of exporting the SAF-T (AO) XML file, in addition to the
referred to in point 1, the following conditions are met:
a) The said SAFT-T (AO) data file must contain all the elements of the indexes of the fields
defined as mandatory in the tables applicable to the type of file, as well as all fields that,
although not mandatory, have values in the database. Dice;

b) The rule of guaranteeing unique values for the elements indicated in the technical notes of the
data structure, within the respective tables, must be respected, in order to maintain the integrity of
the content of the SAF-T (AO) XML file. The elements referred to in the commercial document
tables (4.1 to 4.3) must exist in the respective master tables (2.2 to 2.5);

c) The user should not have any possibility of defining which types of documents or information to
be registered in the database that are susceptible of being extracted to the SAF-T (AO) file;

d) The aforementioned file must contain in the fields of tables 4.1 to 4.3, of the commercial
documents (SourceDocuments), related to the Document Key (Hash) and those related to
the Control Key (HashControl) of each structure, respectively, the signature and the version
(sequential integers) of the private key used, both previously recorded in the database,
when the document issuing process started;

and) In the case of documents contained in the database, but which were originally created in
another system, these must be extracted to the XML file SAF-T (AO) with the fields
Document key (Hash) and Control key ( HashControl) of the respective tables 4.1 to 4.3,
completed in accordance with paragraphs b), c) and d) of number 7 of this annex and,
cumulatively, must also be exported from the original solution, with the aforementioned
fields duly completed, in accordance with ;

f) The values of the Total fields of the document with taxes (GrossTotal) of tables 4.1 to 4.3, must be
extracted with the same value that was considered in the signature, that is, rounded to two
decimal places.
11. The access control to the application and must oblige the user to change the password
periodically. The new password cannot be empty and the administrator cannot know or view
users' passwords;

12. The incorporation of a mandatory backup copies policy;

13. Control of the database you use and record the number of backup copies made;

14. Total protection of the private key;

15. The sequential numbering according to the evolution of the date and time of issue of the documents;

16. That there is no more than one active document (with the fields Current document status -
InvoiceStatus, MovementStatus, WorkStatus or PaymentStatus - value "N") from the collection of
the same manual document or the procedure mentioned in number 9 of this attachment;

17. The use, for the purpose of calculations, of a value with more than 2 decimal places to avoid
rounding errors;

18. In mobility solutions, sequential numbering, as well as information on the signature of the last
documents issued by series, after they have exported the data to the integration application;

19. The demandability of the user for the reason for not calculating the tax, when this occurs;

20. The control of issuing partial credit notes, given the quantities and values of the respective invoices to be
rectified;

21. That when discounts are applied, these must be between 0 and 100%;

22. That the parameterization and design of the forms for printing the documents be carried out by
the software manufacturer or, if the user is given the possibility of creating new types of
documents, these must be validated by the manufacturer through digital signature, or any other
mechanism that produces the same effects;

23. The annotation of the date on which the goods were made available to the purchaser or on which the
services were provided, in order to allow the correct completion of the TaxPointDate field;
24. That the user cannot define which types of documents are signed and \ or exportable to the
SAF-T (AO) XML file;

25. That there is no reprocessing of any calculation on documents collected or resulting from the
integration of other systems;

26. That the Tax Identification Number (TIN), contained in an existing customer form and with issued
documents, is not changed. Only the missing TIN can be noted, in case the field is not filled out,
or if it is filled out with the generic customer's TIN "999999999";

27. That the name on an existing customer form and with documents issued, but whose TIN was not
provided, be changed. This limitation ceases when the respective TIN is registered in the client's file;

28. That in an existing product sheet and with issued documents, the information in the Product or
service description field (ProductDescription) in table 2.4 be changed;

29. That does not allow the reuse of user codes (SourceID) after the respective user has made
tax-relevant movements;

30. That it does not allow the creation of credit notes for documents previously canceled or already
fully rectified;

31. That does not allow the annulment of documents on which an amending document has already been
issued (credit or debit note), even if partial, without the prior annulment of the respective amending
document;

32. That does not allow the acceptance of returns in sales documents or transmissions in rectification
documents;

33. The appropriate alerts to users, namely:

a) If any of the mandatory fields of the SAF-T (AO) is not filled in by the user, when processing
documents;

b) When the issuance of the document has a date after the current one, or it is higher than the date of the
system. In that case, after that issue, a new document with the current or previous date cannot be
issued, within the same series;

c) If the system date and time is less than the last document issued, confirmation must be
requested, before issuing, that the system date and time is correct. This validation must be
done using the SystemEntryDate date / time of any type of document issued, regardless of
its series;
 d) Others that the software manufacturers deem pertinent and that do not violate the legislation in force.

34. The following technical requirements referred to in point 2 of this Annex:

a) The RSA algorithm (data encryption algorithm that uses the system of asymmetric keys,
public key and private key) must be used;

b) The public key to be supplied together with the model 8 declaration must result from its extraction
from the private key, in PEM - base 64 format and the respective file with the extension ".txt" must
be created;

c) 4.3 - The software manufacturer must ensure that the private key used to create the signature
that is known to him and must be properly protected in the software;

d) 4.4 - The text to be signed in relation to the document must contain the concatenated data in the format
indicated in the technical notes for each field, separated by ";" (Semicolon);

e) The documents issued and included in table 4.1 - Commercial documents to customers
(SalesInvoices) referred to in the Document type field (InvoiceType), must use (for the signature
of the respective documents) the following fields:
i. The date of creation of the sales document [field 4.1.4.7 - date of the sales
document (InvoiceDate) of SAF-T (AO)];

ii. The date and time of the creation of the sales document [field 4.1.4.12 - SAF-T (AO)
document recording date (SystemEntryDate));

iii. The sales document number [field 4.1.4.1 - unique identification of the SAF-T (AO)
sales document (InvoiceNo)];

iv. The value of the sales document [field 4.1.4.20.3 - total tax document (GrossTotal) of
SAF-T (AO)];

v. The signature generated in the previous document, of the same type and series of document [field
4.1.4.4 - document key (Hash) of the SAF-T (AO)].

f) The signature resulting from the provisions of the previous paragraph and the version of the encryption
private key must be kept in the database of the billing program;
SAF-T (AO) Field Data Format Example data
InvoiceDate YYYY-MM-DD 2019-01-01
SystemEntryDate YYYY-MM-DDTHH: MM: SS 2019-01-11T11: 27: 08
InvoiceNo Composed of the internal code of the FAC 001/9
document, followed by a space, followed by the
document series identifier, followed by a forward
slash (/) and a sequential document number within
the series. ([a-zA-Z0-9./_-▪)+ ([a-zA-Z0-9] * / [0-9] +)

GrossTotal Numeric field with two decimal places, 1200.00 decimal

separator (dot) and without any
thousands separator.
Hash, field of Base-64 mYJEv4iGwLcnQbRD7
previous document in dPs2uD1mX08XjXIKc
same series, empty Gg3GEHmwMhmmGY
when it comes to the first usffIJjTdSITLX + uujTwz
document of the qmL / U5nvt6S9s8ijN3L
series or exercise) wkJXsiEpt099e1MET / J
8y3 + Y1bN + K + YPJQiV
mlQS0fXETsOPo8SwU
ZdBALt0vTo1VhUZKej
ACcjEYJ9G6nI =

Example of the message to sign: 2019-01-11;

2019-01-11T11: 27: 08; FAC
001/9; 1200.00; + mYJEv4iGwLcnQbRD7dPs2uD1mX08XjXIKcGg3GEHmwMhm mGYusffIJjTdSITLX
uujTwzqmL / U5nvt6S9s8ijN3LwkJXsiEpt099e1MET / 8y3 + Y + K + 1bn =
YPJQiVmlQS0fXETsOPo8SwUZdBALt0vTo1VhUZKejACcjEYJG6nI

g) The documents issued and included in table 4.3 - Conference documents for the delivery of
goods or services (WorkingDocuments) referred to in the field Type of document
(WorkType), must use (for the signature of the respective documents) the following fields :

i. The creation date of the conference document [field 4.3.4.7 - SAF-T (AO) document
date (WorkDate)];
ii. The date and time of the creation of the conference document [field 4.3.4.11 - SAF-T (AO)
document recording date (SystemEntryDate));
iii. The conference document number [field 4.3.4.1 - unique document identification
(DocumentNumber) of SAF-T (AO)];
iv. The value of the conference document [field 4.3.4.15.3 - total of the document with taxes
(GrossTotal) of SAF-T (AO)];
v. The signature generated in the previous document, of the same type and series as the document
[field 4.3.4.4 - document key (Hash) of the SAF-T (AO)].
The extraction of the invoice type file, must contain the following SAF-T (AO) tables and the respective elements
defined in the data structure.

1-Header;

2.2-Customer Table (Customer);

4.1-Customer Commercial Documents (SalesInvoices);

4.3-Documents for checking goods or providing services (WorkingDocuments);

4.4-Receipt documents issued (Payments).

The file sent monthly must contain only:

The Commercial Documents issued in the period (Month, Day);

Customers who have reference in the Commercial Documents, excluding those who did not carry out
commercial transactions in that period.

Depending on the volume of invoices issued, the extraction and shipping may be divided into shorter periods,
for example, per week or per day.
 ANNEX II

Relevant example information:

1. Creation of the private / public key pair

To exemplify the creation of the RSA key pair, the OpenSSL application was used, which runs directly on the
command line with arguments (Windows / Linux, among others), and can be obtained at www.openssl.org.

It allows, among other features, to create RSA, DH and DSA keys, create X.509 certificates, CSRs and CRLs,
digitally sign, encrypt and decrypt, etc.

When analyzing the examples presented, it should be taken into account that:

• They are merely illustrative, in no way meaning that the software manufacturer has or should use the
OpenSSL application;
• The respective command lines were prepared and tested both based on Linux and Windows, and the
same final result was obtained;
• The use of the ECHO command, applied to the Windows / Dos command line, may present different
results from those obtained in Linux, so it should not be used for testing purposes;

• They are performed in the PEM format.

• To create the private key:

Just run the openssl command with the following arguments:

cmd> openssl genrsa -out PrivatePrivate.pem 1024

Where "ChavePrivada.pem" is the name of the file that will contain the private key and "1024" is the size in bits.

As a result, it was obtained, in this case, the information that a part is presented:

- - - - - BEGIN RSA PRIVATE KEY -----

MIICXgIBAAKBgQDWDX9wVqj6ZqNZU1ojwBpyKKkuzHTCmfK39xx / T9vWkqpcV7h3s x ++
ZOv2KhhNkIe / 1I4OCWDPCXRE4g0uIQr0NS29vMlP3aHV ...
- - - - - END RSA PRIVATE KEY -----

• To create the public key based on the previous private key: You must run the
OpenSSL command with the following arguments:

cmd> openssl rsa -in PublicParty.pem -out PublicParty.pem -outform PEM –pubout

Where "ChavePublica.pem" is the file containing the public key.

To upload it together with the Model 8 Declaration, simply rename its extension from ".pem" to ".txt" (without the
quotes).
As a result, the following information was obtained, in which case a part is presented:
- - - - - BEGIN PUBLIC KEY -----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDWDX9wVqj6ZqNZU1ojwBpyK KkuzHTCmfK39xx /
T9vWkqpcV7h3sx ++ ZOv2KhhNkIe / 1I4OCWDPCXRE4g0uIQr0NS29 vMlP3aHHayy76
lbBCNVcHFxM0ggjre1acnD0qUpZ6Vza7F + + PpCyuypD2V / pkL1n X9Z6z5uYyqc0XaSFdwIDAQAB

- - - - - END PUBLIC KEY -----

• To verify the public key:

Just run the OpenSSL command with the following arguments: cmd> openssl
rsa -in PublicKey.pem -noout -text -pubin

2. Creating the certificate

The key pair used does not require a certificate to be issued by an accredited entity. The software manufacturer
can generate the self-signed certificate for the purpose of certification and extract from it the public key to provide
to AGT, with the extension txt.

For the creation of the certificate from the private key, the RSA algorithm must 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 Private
key size = 1024 bits Message hash format =
SHA-1

3. Practical example of applying the mechanism and signature to documents included in the table

3.1 Creation of the digital signature with the private key.

Regardless of which RSA implementation is adopted and which best suits each solution, it must be guaranteed
that the signatures contain 172 bytes, without any line separator characters.

InvoiceDate 5/18/2018 5/18/2018

SystemEntryDate 2018-05-18T11: 22: 19 2018-05-18T11: 43: 25
InvoiceNo Fac 001/18 Fac 001/19
GrossTotal 53.00 75.00
Hash See 1st record See 2nd record
The elements to be signed (InvoiceDate, SystemEntryDate, InvoiceNo, GrossTotal and Hash) must be
concatenated only with the ";" between each of the fields, and must not contain quotes or any end of line
characters, when encrypted, with a view to obtaining the signature.

1st Registration

In the case of the first record, the field (Hash) is filled with the hash resulting from the application of the
previously created private key, to digitally sign the fields (InvoiceDate, SystemEntryDate, InvoiceNo and
GrossTotal).
The text to be signed will be:

2018-05-18; 2018-05-18T11: 22: 19; FAC 001/18; 53.002;

1st Step:
Save the message to sign
2018-05-18; 2018-05-18T11: 22: 19; FAC 001/18; 53.00;

In a text file (in this example we will call Registry1.txt), making sure that at the end of the message there is no
line break, just the ";" without quotes.

2nd Step:
Sign the message contained in the file Registo1.txt with the following command:
openssl dgst -sha1 -sign ChavePrivada.pem -out Registo1.sha1 Registo1.txt

The file Registo1.sha1 will contain the binary hash generated by the OpenSSL application.

3rd Step:
Then it is necessary to perform the encoding for base 64 of the file Registo1.sha1:
openssl enc -base64 -in Registo1.sha1 -out Registo1.b64 -A

The file called Registo1.b64 contains 172 characters in and later exported to the SAF-T (PT) field (Hash).

The -A parameter is only for the OpenSSL application to generate the signature on a single line avoiding
additional line breaks.

As a result, the file Registo1.b64 will contain a signature of the type:

oso2FoOw4V941CwKTrv6xwzUrOtxBWCwU0yLVAqKwf0CNKZHM
ETG1XZZC4spRSyby1uDXBggplogrl8gHnvevA00UEoAvGJo9Fa3DO
A0MhZNDa9 / rNvu71pp + 0zHmN2ra5IWpiHcgmUYxm5qamLBk49rk
gvl7h1myKCYBKqgu60 =

Which should be registered in the HASH field of the previous table and in the position corresponding to the 1st Record.

2nd Registration

Proceeding in the same way, now with the data from the 2nd record and the hash of the previous record, we would have the
message to sign in the file Record2.txt:
2019-07-18; 2019-05-18T15: 25; FAC
001/19; 75.00; oso2FoOw4V941CwKTrv6xwzUrOtxBWCwU0yLVAqKwf0CNKZHMETG1X ZZC4spRSyby
1uDXBggplogrI8gHnvevA00UE
 oAVGJo9Fa3DOA0MhZNDa9 / rNvu71pp + 0zHmN2ra5IWpiHcgmUY
xm5qamLBk49rkgvI7h1myKCYBKqgu60 =
Using the procedures described above for the 1st registration, steps 1 to 3, the files Registry2.sha1 and Registry2.b64 were
created.

As a result, this last file, Registry2.b64 will contain the digital signature of the 2nd registry of its kind:

Y2ogVAC9rcmm9hilZCGGrxjpkZP9NHn5shhp9phBIVWIn + Ta2zKf +
O + 05brA6VU0LULtMQP98P29q + vcSwVtxSzLDbmmkHMt4I6nQmh
91QaOJwPpz2uMqtR3aMkWYPK4Ntc / yfnXpY1cSeUGbQkqAsJOF
SidRE4 + DibJaC7WMpw =

Which should be registered in the field (Hash) of the previous table and in the position corresponding to the 2nd Record.

3.2 Validation of the created digital signature

To confirm the validity of the signatures, just execute the command:
openssl dgst -sha1 -verify publickey.pem -signature Registro1.sha1 Registro1.txt

Webservice (Data structure).

The request is made according to the SOAP protocol and consists of two sections:

• SOAP: Header;

• SOAP: Body

The Header includes all the authentication fields of the user who will be responsible for invoking the Webservice. This
user will be a subuser of the taxpayer TIN (merchant issuing the invoice) with a WFA profile.

The Body, contains the data of the commercial document.

SOAP: Header

Required: S - Yes; N - No.

Data type: To be validated in the WSDL (Web Service Definition Language) specification of the service.

Parameter Thanks description Data type

1 - User (Username) Yes String

Identification of the user who will submit the data, composed

as follows and according to the authentication of the finance
portal:
<Issuer TIN> / <UserId>
Possible examples:
1. 99999999/1 (sub-user # 1)
2. 99999999/0002 (sub-user no. 2)
 2 - Nonce Yes String

Symmetric key generated for each request and for encrypting the
contents of fields 3 - Password and 4 - Created. Each invocation of
the Webservice must contain this randomly generated key, which
cannot be repeated.

To guarantee confidentiality, the symmetric key must be

encrypted with the public key of the Authentication System
according to the RSA algorithm and encrypted in Base 64.

The public key of the finance portal authentication system

must be obtained at your own request

The field is built according to the following

procedure
: 64 (()) RSA, Kpub s Nonce Base CK SA

KS: = byte array with the 128-bit symmetric key, produced

according to the AES standard. CRSA, KpubSA: = Symmetric
key encryption function with the RSA algorithm using the public
key of the authentication system (KpubSA).

Base64: = Base 64 encoding of the result.

3 - Password Yes The Password field must contain the password of the user / String

sub-user, the same as that used to enter the Taxpayer Portal.

This Password must be encrypted using the symmetric key of the

request (see Nonce field) and encrypted in Base64.

4 - System date The Created field should contain the system date and time of String

(Created) the application that is invoking the web service. This date is
used for temporal validation of the order, so it is crucial that the
client application system has its right clock.

SOAP: Body

Parameter Thanks description Data type

1 - Issuer TIN Yes Issuer TIN: string

(TaxRegistrationNumber) Tax Identification Number (without any country prefix).

2 - Document Number Yes string

(InvoiceNo) Unique identification of the sales document

 It must be identical to that contained in the SAF-T (AO) file,
when generated from the billing system that issued this
document;

Composed of the document's internal code, followed by a

space, followed by the document's series identifier, followed
by a slash (/), and a sequential document number within the
series;

There can be no records with the same identification.

3 - Issue Date Yes Document issue date gives you

(InvoiceDate)
4 - Type (InvoiceType) Yes Document Type: string

FT - Invoice;
NC - Credit Note; ND -
Debit Note;

4.1 - Status Yes Document status: string

(InvoiceStatus) N - Normal;
A - Canceled

5 - Purchasing TIN National purchaser's TIN string

(CustomerTaxID) Tax Identification Number (without any country prefix);

It must be completed whenever it is a national purchaser;

When it has not been collected in the issuer's billing system,

it must be filled in with 999999990

6 - Foreign Purchaser This field is mutually exclusive with the field “5 string

TIN - Acquiring TIN (CustomerTaxID) ”. One and only one of the

fields must be completed.
(InternationalCustomerTa
xID)

It must be completed whenever it is a foreign acquirer, whose

TIN has been collected in the issuer's billing system;

7 - Document Lines by Rate Summary of invoice lines by tax rate, and reason for
(Line) exemption or non-settlement.
There must be one and only one line for each fee (TaxType,
TaxCode) and reason for exemption or non-settlement
(TaxExemptionReason)

7.1 - Debit Amount

(DebitAmount) Sum of the value of the lines, excluding tax, less line and header
discounts, where the rate and / or reason for exemption
described in “7.3 - Rate (Tax)” was applied.
 Mandatory for Credit Notes. In the remaining types of
document, only the field “7.2 - Amount to Credit
(CreditAmount)” must be completed.

7.2 - Amount to Credit

(CreditAmount) Sum of the value of the lines, excluding tax, less line and header
discounts, where the rate and / or reason for exemption
described in “7.3 - Rate (Tax)” was applied.

Mandatory for Invoices and Debit Notes. In the Credit Notes,

only the field “7.1 - Debit Amount (DebitAmount)” must be
filled.

7.3 - Tax Rate

7.3.1 - Tax Regime

(TaxType)
7.3.2 - Reason for Exemption VAT exemption reason
(TaxExemptionReason) Mandatory field in the case of an exempt transmission or
service provision or in which, justifiably, there is no VAT
settlement.

It must be filled in with the codes from the table of reasons for
exemption or non-payment of VAT.

8 - Document Totals
(DocumentTotals)
8.1 - Tax Amount Amount of tax payable.
(TaxPayable) Only include the taxes included in the summary lines per fee
in “7 - Document Lines per Fee (Line)”.

8.2 - Taxable Amount Total document without tax.

(NetTotal)
8.3 - Total Amount
(GrossTotal) Total document with tax.
It must include the taxable amount and all taxes applicable to
the document, even if not included in the summary lines for
fee in “7 - Document Lines for Fee (Line)”.