The Interchange System, or SDI, is a computer system managed by the Revenue Agency, which takes care of receiving and forwarding the invoices, compiled according to certain patterns provided by the agency itself.
Although the SdI carries out some checks on the invoices, it has no administrative role, and it does not fulfill the role of filing and storing invoices.

The electronic invoicing obligation concerns all resident subjects established in Italy.
Therefore, invoices issued both to VAT subjects (B2B, Business to Business) and those towards final consumers (B2C, Business to Consumer) fall within this obligation.

The following are excluded from the electronic invoicing obligation:

Basically there are 4:

The last two methods require prior accreditation to the SdI, through which the system associates at least a numerical code of 7 digits to the activated telematic channel (the "recipient code").

For each electronic invoice file or set of electronic invoices correctly received, the SdI checks the file itself. In case of failure to pass the checks, it will be delivered – within 5 days – a "reject receipt" of the file to the transmitting subject on the same channel with which the file has been sent to the SdI. The electronic invoice or the set of invoices referred to the discarded file by the SdI are considered not issued.

The SdI will carry out checks on the internal logic of the electronic invoice, so that by passing it, it guarantees the consistency necessary to conclude the billing process. The file name and its size are checked, which responds to the requirements defined by the model established with the mandatory data, the consistency and the validity of internal data, that the invoice is unique and deliverable, if there is an electronic signature that this is valid, and that the file is intact as declared by the signature.

The sender can send electronic invoices to the SdI through an intermediary. The customer can also receive electronic invoices from the SdI through an intermediary, communicating to the sender the "electronic address" (recipient code or PEC) of the intermediary himself.
The delegation to an intermediary to send and to receive electronic invoices can be conferred and revoked by the sender directly through the functions made available on the website of the Revenue Agency or by submitting the appropriate form at any territorial office of the Revenue Agency itself.

By "electronic invoice" we mean an IT document, in a structured format, transmitted electronically to the Interchange System which delivers it to the receiving subject.

The format of the electronic invoice is XML, eXtensible Markup Language, as indicated in the Provision of the Director of the Revenue Agency No. 89757/2018. The invoice can have attachments, and the maximum size must not exceed 5MB.

Those established by art. 21 (21bis for the simplified invoice) of the Decree of the President of the Republic 633/1972.

Yes you have. The self-invoice follows the same rules as other electronic invoices, therefore it must be sent to the SdI.

There are various types of self-invoice document, which uniquely identify the type.

Code TD01 will be used for all types not included in the previous cases.

The correct valuation of the different types of self-invoice is described in "User Manual eCON FE", in "Document" chapter.

The legislator provides precise instructions on the correct information compilation in the "Linked invoices" section. This section contains references to previously issued invoices to which the document is linked.

In particular:

Yes, you have to. All invoices must be sent to the SdI, therefore electronic invoices also to final consumers (B2C) must be issued. In this case, the tax code and the conventional code "0000000" must be included in the "recipient code" section of the invoice.
At the time of issuance, an analogue or electronic copy of the invoice must be made available, the customer will be able to find it in the AgID reserved area.

The electronic invoice XML file may not even be digitally signed. The signature is not mandatory for invoices to private individuals and final consumers (B2B and B2C), while it is always mandatory in the case of invoices to the Public Administration (PA invoice).

For cross-border transactions carried out up to 30 June 2022, the 2018 Budget Law decreed that, starting from 01 January 2019, it is mandatory to send them to AgID. The transmission must take place by the last day of the month following the date of the issued document and the date of receipt document proving the operation. For payable invoices the registration date is considered.
For transactions carried out from 1 July 2022, with the conversion into law of Decree no. 146/2021, the obligation of electronic invoicing abroad comes into force.
With the new obligation, it will be necessary to respect the typical rules of electronic invoices, it means:

The obligation applies only to subjects with a VAT number established in Italy, therefore to (and by) the subject abroad, an analogue copy of the invoice, on paper or electronically (for example a .pdf file), will still be sent. This is because the recipient, not being resident in Italy, will not have the possibility to access to the SdI to view the document.
The obligation ceases only when a customs declaration is issued for operations abroad: in this case the VAT subject can decide whether or not to send the electronic file to the SdI.

In order to compile an electronic invoice for a foreign customer, whether a company or a private individual, some fields with certain data must be filled in:

The "spesometro" was repealed by the 2018 Budget Law, therefore this is not mandatory for the communication of invoices and fees for VAT holders. The obligation to communicate invoice data relating to cross-border transactions ("Esterometro") remains until 30 June 2022.

For all cross-border transactions carried out between 1 January and 30 June 2022, it will be necessary to send the first quarter "esterometro" by 30 April (Monday 2 May) and the second quarter one by 31 July (22 August, due to the weekday extension).
For cross-border transactions carried out from 1 July 2022, since they are transmitted exclusively using the SdI, it will no longer be necessary to send the "esterometro" communication.

The XML model includes the "Divisa" field in the "DatiGeneraliDocumento" section, which can be completed with the currency abbreviation (expressed according to the standard ISO 4217). However, as reported by the art. 13, paragraph 5 of Presidential Decree 633/1972:
"For the purpose of determining the tax base, the due fees and the incurred expenses and charges in foreign currency are calculated according to the exchange rate on the day of execution of the operation or, failing that such indication in the invoice, of the issue day of the invoice. Failing that, the calculation is carried out based on the closest previous day’s quote. The conversion into euros, for all operations carried out in the calendar year, can be made on the basis of the exchange rate published by the European Central Bank."
Therefore, the due amounts, expenses and charges must be indicated in euros on the invoice, reporting the exchange rate and conversion in the "Description" field. If necessary, it is possible to issue to the foreign customer an analogue copy with amounts in foreign currency.

The SdI carries out a check on the VAT number, checking its presence in the Tax Registry. Even if it is terminated the invoice will be correctly issued. The case of a non-existent VAT number is different: in this case the SdI will discard the invoice.

Whoever receives the wrong invoice must dispute it by contacting the seller directly, by email or telephone, but both parties will have to register the incorrect invoice, and the seller will have to issue a credit change note canceling the previous invoice.

The application does not provide the data management, except for the seller (see below). However, thanks to the "Duplicate invoice" blue button, which is present on each row of the saved invoices list, you can duplicate an invoice already present in the system.
The duplicate invoice can be used as a "base" to create a new one, modifying only the involved fields.

No you do not have to. By clicking on the username (top right of the invoice editor page), you can access a menu that contains the item "Company settings" where it is possible to enter all the company personal data recurring in the invoices' compilation.

If an invoice is rejected by the SdI, it must be resubmitted, with the same date and document number, within five days of the rejected notification.

If an invoice is rejected by the Public Administration, the eCON FE System does not allow reissue with the same number and date. This is because the reissue with the same number, although permitted by the SdI, is in violation of the Dpr. 633/1972. Therefore, if the PA has already registered the invoice, a credit note and a new invoice must be issued, while if the PA has not yet registered the invoice it is sufficient make an internal correction note.

The checks that are carried out on the .xml file of the issued invoice by the editor application invoices are only formal checks on the file structure, in compliance with the SdI directives.
The consistency and compliance checks of the data displayed in the .xml file are performed by the SdI later, and they are outside the correct file structure.
Therefore, for this reason, an .xml file of issued invoice, even if formally correct, could be rejected by the SdI due to data incongruity.

The Entaksi invoice editor was designed to manage sales invoices, not fees: at the moment, it is not possible to enter unit amounts inclusive of VAT.

Yes, you do. The new decree of 13 April 2022 introduces a series of important innovations in the field of taxation such as the extension of the electronic invoice obligation to flat-rate schemes, to taxpayers in the scheme advantage and to amateur sports associations starting from 1 July 2022.
For the next two years (therefore until 2024), subjects with revenues or fees exceeding 25,000 euros will remain exempt from the new obligation.
Furthermore, for the subjects affected by the new obligation, for the first three months, therefore until September 2022, it will be possible to issue the document by the end of the month following the one in which it is issued without sanctions application.

Starting from 1 July 2022, the electronic invoicing obligation will come into force between Italy and San Marino for transfers of goods between economic operators residing in the two countries, to which the only exception is the subjects not yet bound by the obligation of electronic invoicing.
As regards the provision of services, electronic invoice will be optionally not a requirement.
The transmission of electronic invoices between Italian and San Marino operators will take place thanks to the interaction between the SdI and the HUB-SM platform managed by San Marino tax office, which is certified as node at the SdI.
Therefore, an Italian supplier who will have to send an electronic invoice to a San Marino customer company will be able to continue to operate as usual, paying attention only to some information that will need to be entered within the invoice itself.
Similarly, San Marino companies that will have to send an electronic invoice to an Italian client company will make use the HUB-SM and the SdI, which will validate and deliver the invoices to the Italian assignee.

In order to correctly send an electronic invoice to an economic operator resident in San Marino, it is necessary to enter the following data:

Using this information, The SdI will be able to correctly deliver the invoice to the economic operator of San Marino.

For active invoices (from an Italian transferor to a San Marino transferee), the results of the checks on the correct fulfillment of the import tax and on the regularity of the invoice are the responsibility of San Marino Tax Office, and they are made available to Italian companies (also viewable on the Invoices and Payments portal) within four months from the invoice issuing.
In the event of denied endorsement, the invoice cannot be included in the non-taxability regime and for the Italian company it will be necessary to proceed with the regularization of the tax which must take place within thirty days with an issuing of a variation note.

For passive invoices (from a San Marino transferor to an Italian transferee), it is necessary to make a distinction between invoices with and without a tax charge.
In the case of invoice with tax charge, it is the San Marino supplier who pays VAT to San Marino tax office, which sends it to the Italian Revenue Agency office which, within 15 days, will do the appropriate controls and, in the event that the tax has been paid in excess or insufficient, it will communicate it to the San Marino Office, in order to proceed with the necessary additions. At the end of the checks, the positive outcome of the checks (which can also be viewed by accessing the portal Invoices and Payments) will be made available to the Italian transferee who will be able to proceed with the tax deduction.
In the case of invoices without tax charge, on the other hand, it is up to the Italian company that receives the invoice to pay the due VAT , by issuing a self-invoice/electronic integration and using the TD19 document type.

Certified Electronic Mail, it means a type of electronic mail with a legal value, as it guarantees proof of dispatch and delivery.

The electronic invoice is considered issued only if it is sent to the SdI. If it is sent directly to the customer’s PEC box, without going through the SdI, it is considered unissued.
However, it is possible to use the PEC to send the XML invoice to the SdI, by inserting the XML file of the electronic invoice as an attachment to a PEC message, and by sending it, for the first time, at sdi01@pec.fatturapa.it.
Once the PEC has been received, the SdI will communicate – with a specific message sent to the same PEC address from which the email was received - a new PEC-SdI address to which to send subsequent PEC emails containing the other electronic invoices.

By "preservation" we mean the activity aimed to protect and to preserve the archives of documents and computer data in the long term.
The storage system, as required by art. 44 of the CAD, must guarantee authenticity, integrity, reliability, legibility and availability of the stored IT documents. Conservation performed in accordance with the law allows you to give electronic documents the same legal effect of the analog ones.

By "long-term conservation" we refer to the qualified electronic signatures and seals preservation service, delivered in accordance with art. 34 of the EU Regulation n° 910/2014 eIDAS. This preservation, which follows international standards, allows you to extend the signatures and seals validity over time, in order to preserve their legal value in the long term.

The Agency for Digital Italy (AgID) takes care to set and to pursue technological innovation goals in both the Italian public administration and services aimed to private citizens and businesses. In order to support and to organize digital development, AgID can issue binding documents regarding these topics. The "Guidelines on the formation, management and preservation of IT documents", in force since 1 January 2022, defines the rules concerning training, logging, management and storage of IT documents.

As defined by the "Guidelines on the formation, management and preservation of IT documents", the roles identified in the preservation process are:

As defined in chapter 4.5 of the "Guidelines on training, management and preservation of IT documents", the person in charge of preservation, which operates in accordance with the provisions of art. 44, paragraph 1-quater of the CAD, "defines and implements the overall policies of the preservation system and governs its management with full responsibility and autonomy".
While as far as the Public Administration is concerned, the role must be covered by an internal subject (who belongs to the administration responsible for the preservation object), for the other subjects, the role can be performed by "a subject external to the organization, in possession of suitable legal, IT and archiving skills, different from the qualified preservation service providers in order to guarantee the function of the Holder of the preservation object respect to the preservation system".
In any case, the preservation manager can delegate part of the activities under his responsibility to the preservation service manager, maintaining however general legal responsibility for preservation processes in any case.

Also in chapter 4.5 of the "Guidelines on the formation, management and preservation of IT documents", the activities entrusted to the preservation manager are listed:

a) he defines the preservation policies and functional requirements of the preservation system, in accordance with current legislation and takes into account the international standards, due to the specificities of the digital objects to be preserved (IT documents, IT aggregations, IT archive), the nature of the activities that the Holder of the preserved object carries out and the characteristics of the adopted IT document management system;
b) he manages the storage process and ensures its compliance to current legislation over time;
c) he generates and signs the payment report, according to the established procedures from the preservation manual;
d) he generates and signs the distribution package with digital signature or qualified electronic signature, in the cases envisaged by the preservation manual;
e) he monitors the correct functionality of the preservation system;
f) he carries out the periodic verification, with frequency not exceeding five years, of the integrity and the legibility of IT documents and documentary aggregations of archives;
g) in order to ensure the conservation and the access to IT documents, he adopts measures to promptly detect any degradation of the preservation systems and to restore the correct functionality; he also adopts similar measures in regard to the obsolescence of formats;
h) he provides to duplicate or to copy the electronic documents in relation to the evolution of the technological context, according to the provisions of the preservation manual;
i) he prepares the necessary measures for the physical and logical security of the preservation system as provided by par. 4.11;
j) he ensures the presence of a public official, in cases where his intervention is required, guaranteeing him the necessary assistance and resources in order to help him in his activities;
k) he provides the competent bodies envisaged by the current legislation with the necessary assistance and resources in order to carry out the verification and supervisory activities;
l) he provides to pay the electronic documents, IT aggregations and IT archives for the central and peripheral state administrations, as well as the tools that guarantee their consultation, respectively to the Central State Archives and to the territorially competent State Archives, according to the timescales established by art. 41, paragraph 1, of the Code cultural heritage;
m) he prepares the preservation manual referred to in par. 4.7 and he takes care to update it periodically in case of significant regulatory, organisational, procedural or technological changes.

All activities can be delegated to the preservation service manager except the letter m).

As reported in chapter 4.7 of the "Guidelines on training, management and preservation of IT documents", the preservation manual "is an IT document that must describe in detail the organization, the subjects involved and their roles, the operating model, the process description, the used architectures and infrastructures description, the adopted security measures and any other information useful for management and verification of the functioning, over time, of the preservation system".

Yes, it is both for public administrations and private individuals. In fact, the "Guidelines on training, management and preservation of IT documents" are applied, according to art. 2 paragraph 3 of the CAD, "even to private individuals, unless otherwise provided".
The obligation to keep the preservation manual derives from the need, facing external controls deriving from the civil and fiscal obligations of the Digital Administration Code, to be able to easily control processes which allow the correct conservation of electronic documents in accordance with the law.

The preparation and periodic updating of the preservation manual are included among the non-delegable tasks of the preservation manager, who can request the collaboration of the preservation service manager for the manual drafting in any case.

"Regulation on criteria for the provision of IT document preservation services" issued by AgID in December 2021 "determines the new provision criteria of the preservation service of IT documents, setting the general requirements in a special attachment as well as the quality, safety and organizational requirements necessary for the provision of the service, in addition to what has already been defined in the Guidelines on training, management and conservation of the electronic document".
Possession of the aforementioned requirements is a necessary condition for the registration in the "Preservation Services Marketplace"

The Preservation Services Marketplace is a platform set up by AgID in which you can find conservatives who respect the "Guidelines on the formation, management and preservation of IT documents" and the "Regulation on criteria for the provision of IT document preservation services". Since registration is not compulsory, the marketplace constitutes a "showcase" of preservation services in possession of the requisites of quality, safety and organization, a necessary condition for the provision of preservation services on behalf of the Public Administration.

Yes, you do. Electronic invoices are natively digital documents, therefore they must be digitally stored in a compliant preservation system, in accordance with the provisions of the DPCM of 3 December 2013 and the DMEF of 17 June 2014.

A Submission Information Package (SIP) is a set of documents and related data, which must be stored. It is sent by the producer to be stored. The system accepts the package, verifies it, and forms an Archival Information Package (AIP) to be stored from it, returning to the producer a Receipt of Payment certifying the successful operation.

The Archival Information Package (AIP) contains documents and information to be kept digitally. It is a unit that cannot be altered over time.

In order to access the AIPs contained in the preservation system, Dissemination Information Packages (DIP) are used. They are digitally signed and timestamped information packages of one or more AIPs contained in the system.

EU Regulation no. 910/2014 (eIDAS) introduces three types of electronic signatures:

Electronic signature is broadly defined by eIDAS as "data in electronic form, enclosed or connected by logical association with other electronic data and used by the signatory to sign".
If an electronic signature has not the requirements of an advanced or a qualified signature, it is called a "simple electronic signature".
It is a "weak" signature, because the quality and safety characteristics of this type of signature depend on the implementation made and on the context in which it is used; the probative value of the simple signature is neither implied nor certain, but must possibly be evaluated on a case-by-case basis.

The requirements of the advanced electronic signature (AES) are defined in the art. 26 of the eIDAS regulation.
This type of signature is suitable to identify the signatory, to which it is directly connected. The signer can use it under his exclusive control with a high level of security; it is connected to the subscribed data in order to allow the identification of any subsequent modification.
The creation of advanced electronic signature solutions is not subject of binding technical rules, for this reason various types of implementations have appeared on the market over time (such as, for example, the so-called "graphometric signature").
When properly implemented, the AES is a "strong" signature: the documents to which it is affixed satisfy the requirement of the written form, and they have the effectiveness provided by article 2702 of the Civil Code.
However, in the Italian legal system, it has a probative value limited to the existing legal relationships between the subscriber and the person offering the signature service and cannot be used in some contexts (e.g. real estate transactions).

The digital signature is defined in Article 1, paragraph 1, letter s) of Legislative Decree no. 7 March 2005. 82 - Digital Administration Code (CAD) - as a particular type of qualified signature (defined in eIDAS in art. 3 paragraph 1 point 12) based on a system of cryptographic keys, a public and a private one, correlated to each other, which allows the holder to have an electronic signature by the private key and to a third party by the public key, respectively, to disclose and verify the origin and integrity of an electronic document or a set of electronic documents.
From a legal point of view, the digital signature is the "strongest" signature: it can be used in any context and has probative value fully equivalent to a handwritten signature posted on a paper document.
Due to its characteristics, it is a widely used tool for all types of IT documents.

Given the generality of its definition, there are many ways to affix a simple signature, often already unknowingly used.
For example, sending an e-mail message is a simple way to sign the content of the message.

It is sufficient to use the method and tools proposed by those requesting that signature type.
As in the case of the simple signature, it is not normally necessary to adopt particular devices or procedures.

The digital signature can be affixed to a document using specific programs which access the signing certificate contained in a local device (smart card, USB token) or remote (a server with specific security features (HSM)).

In order to obtain a digital signature certificate, you must contact accredited operators called Certification Authorities (CA), including the Chambers of Commerce (which can have its own procedures for issuing the certificate).
These subjects will create the digital signature certificate, uniquely associate it, after identification, to the applicant, and they will release all the material necessary for its affixing to the electronic documents.

The OTP Codes (one time passwords) are strong passwords with high IT security such as described in the relevant FAQ in the "Security" section.
When signing, requesting an OTP code sends an SMS containing the password to the signatory’s registered number automatically confirming his identity: this allows the signer to authorize signature processes in a quick and secure way.

There’s no problem. In case the electronic address of the invoice is wrong, but its VAT number is correct, the invoice is valid and the seller/customer will be able to find it in his own reserved area in AdE website.

In this case, however, the invoice is issued to the wrong seller/customer. He must be contacted by email or telephone, and both parties will need to register the incorrect invoice, and the assignee will have to issue a variation note which cancels the previous operation.

The invoice with Missed Delivery notification is considered duly issued. The customer will receive the invoice in his AdE reserved area in the "Invoices and fees" section. This invoice should not be re-submitted: the system would interpret it as duplicate, and it would return error.
In this case, it is advisable to notify the recipient via email or PEC of the fact that the SdI was unable to deliver the invoice, and that it is available for download in AdE reserved area, attaching the invoice and the MC receipt XML file to the communication.
Remember that an MC notification is issued for all private customers with recipient code 0000000, which is to be ignored.

The Service activation email is usually sent immediately, but sometimes it can take a few minutes longer than expected. If it persists in not being delivered, it could have been identified as spam by your provider, and placed in the relative folder. Another problem that occurs frequently, is the use of a PEC email for registration. Certified mailboxes must be specifically enabled for the receipt of ordinary mail, such as the registration email is, which otherwise can not be delivered.

If the user logs in more than five times with wrong login and\or password in Entaksi’s Console, the system temporarily blocks the user for approximately fifteen minutes. For each further login attempt, the user’s block becomes incremental up to a maximum of one hour.
When the user is blocked, every access made to the Console, even with correct login and password, will be rejected.
In the meanwhile, any attempt to change the password is also rejected and the relative request email is not sent.
The user will be reactivated automatically after the above-mentioned blocking minutes, by reactivating the functions temporarily suspended.

The Console version and the service version, with their publication date, are visible in each page on the right side of the footer.

In the Entaksi Console, searches, sorts or any column views are preserved while browsing the site.
This useful feature is made possible by saving some information in the browser’s cache.
In case of service updates, this saved information could be inconsistent with the new version of the site.
We therefore recommend that you clear your browser’s cache at each service update, in order to not run into any malfunctions.

It is advisable to save the link for quick access to Entaksi services on the login page and not to the internal pages of the service.
This is for two fundamental reasons.

When operational, each of the management stations continuously try to access the Console in order to allow normal work activity using Console credentials saved within the management system itself.
Therefore, when the password is changed on the Console, the management system will continue to be active and to log in with the password previously saved in the system, which will be different from the one just updated.
These continuous accesses with an incorrect password cause the user to be blocked as described in the previous FAQ.
To overcome this, before performing the password change in Console, you will have to ensure that none of the management workstations is operational. Change your password in Console, return to a management system workstation and enter the new password, close the management again and wait for the user reset times.

The search service aims to be as simple and intuitive as possible, nevertheless the search keys (document metadata) are many and it is not always possible to easily integrate these values with customers' management systems.
All the metadata currently available are present in the selection criteria of the page "Search and request documents" allowing multiple selections (more values or the same metadata, more metadata that can be combined).
The metadata mapping for each document type and how the search page works are described in the corresponding chapters of the user manuals of each service. Service user manual, in the "Metadata" section.

The downloading procedure for DIPs is described in the Service user manual, in the "Search and request documents" section.

Usually the processing time of a Dissemination Information Packages (DIP) is in the order of a few minutes. Higher processing times are possible if the package contains a considerable number of documents (in the order of thousands).

When requesting a DIP (Dissemination Information Packages) from the System, it should be taken into consideration that there may be Submission Information Packages (SIP) still to be "closed", it means to be processed in the AIP.
The elaboration process occurs at a defined frequency and approximately monthly: it is therefore advisable to carry out the DIP training procedure only after having verified, through the AIP list in the Console, that all the AIPs have been correctly closed.

Regarding the possibility of obtaining a single PDF that includes all the documents of a period, it should be noted that, for 'natively' IT documents stored in the preservation system, this possibility is precluded by the law.
This happens in particular for LULs managed as natively IT documents, for which the specific legislation provides that each slip / tag that makes up the LUL is an electronic document. Finally, from the point of view of operational management, we believe that the availability of search for multiple metadata (and also, in the document system, by document content) and the ability to obtain and manage a single .zip file containing search results are much better than managing a single PDF.

For the sent and received invoices, the system obtains a series of notifications from the SdI, which are coded as described in the eCON FE User Manual, in "Transmitted invoices" chapter.

The distinction between invoices that have already been viewed and those yet to be viewed is made within the "Invoices received" section highlighting in bold the unread ones, while those already read appear in a lighter color, in a similar way to what happens in e-mail boxes.

In order to enter the date and registration number of not preserved invoice, you can do one of the following:

The date and registration number entered as above will be recorded in special metadata of the received invoice, allowing a subsequent search with these criteria.

Sometimes when entering the date and protocol number on a received invoice, the box "Accounting record" does not allow entering the data and the "Registered Invoice" flag appears disabled.
This situation arises when the invoice has already been preserved, and therefore it is no longer possible to "annotate" it using the metadata dedicated to the purpose. See the following FAQ in this regard.

Yes, it is. Using the "Registration date (cons)" and "Registration number (cons)" fields, in the respective summary columns of received invoices. In this case it will be created and attached to the preserved invoice a specific document with the same metadata, so that later searching for these values, it is possible to obtain the set of the original document and the protocol attribution document.

You can search them using the filters in the "Sender" and "Recipient" columns in the summary views for, respectively, received and transmitted invoices. In fact, it is possible to specify both the name / company name and the VAT number (even if this indication does not appear clearly in the header of the relative column).

A digital signature can be affixed in different ways:

The Entaksi Preservation Manual Service only accepts documents signed in CAdES mode.

The criteria for closing the Archival Information Packages (AIP) are as follows:

It is possible to create a complete Dissemination Information Packages (DIP), without inserting any criteria, for interoperability only if the company has a revoked or inactive mandate.
In the event that a company appears to be active, despite having sent the cancellation, it is mandatory to indicate at least a selection criteria to create DIPs.
When the company has been revoked or inactive mandate, the service remains active for 6 months from the date of the cancellation in order to extrapolate the DIPs for interoperability.

Entaksi has obtained the following certifications:

For more information, consult the page dedicated to the certifications.

The OTP Code (One Time Password) is a particular type of password also defined "strong password" and ensures a high level of security.
This password consists of an alphanumeric code that is automatically generated by an algorithm and is sent to the user generally via SMS.
Only valid for a single login session or transaction, this type of password solves the problems associated with using the traditional static password ensuring high safety standards.
A static password, in fact, is vulnerable to replay-attacks (attacks with replication) and, once intercepted, it is easily used to simulate the user’s identity.
On the other hand, even if intercepted, an OTP code would no longer be reusable to gain access to the service because it is valid only once for a limited period.

A multi-factor authentication (MFA Multi-Factor Authentication), also known as strong authentication, is a form of authentication based on several factors:

The most commonly used form of multi-factor authentication is the two factors authentification (2FA: two factor authentication) which is based on the joint use of "Knowledge" factor and the "Possession" factor which is verified by sending an OTP code via SMS (see previous FAQ) to the mobile number registered in the account.
Therefore, access to the service will be completed by entering both the simple and the password the obtained OTP code.

To create a correct password that is accepted by the service, it must have:

The password will last 90 days, after which the system will automatically ask you to update it.
The previous five passwords cannot be used for the update.

In the event that our services are used through a third-party management product, the new password must also be included in that environment.