menu di navigazione del network

Fatture elettroniche firmate digitalmente dal titolare software gestionale

Buongiorno,
sono uno sviluppatore di un software gestionale che invia regolarmente le fatture allo SDI.

Ho un dubbio riguardo il soggetto che può/deve firmare digitalmente il file della fattura elettronica.

Leggendo questo documento sul portale:
https://www.fatturapa.gov.it/export/fatturazione/it/c-12.htm

io l’ho sempre interpretato che i file deve essere firmato dai miei clienti che usano il mio software, utilizzando la firma digitale a proprio nome.

Ho notato da subito che altri software firmano tutte le fatture con lo stesso certificato intestato alla software house. Per pigrizia loro, i miei clienti mi fanno continuamente pressione che io faccia altrettanto. Ho sempre sostenuto coi miei clienti che secondo me non è corretto.

C’è qualcuno che sa qualcosa di più preciso? Esempio qualche chiarimento ufficiale dell’agenzia che posso rimandare ai miei clienti?

Grazie
Davide

Sì, puoi firmarla anche tu la fattura, ma devi mettere i tuoi dati nella sezione <TerzoIntermediarioOSoggettoEmittente> e il valore TZ in <SoggettoEmittente>.

Il problema è che non è tanto semplice automatizzare la cosa. Non puoi estrarre il certificato da una chiavetta USB o da una smartcard, quindi o paghi parecchio per un servizio di firma automatica massiva, oppure devi lasciare la chiavetta fisicamente collegata al server (cosa impossibile da fare se non stai usando un server fisico).
Se ne era già discusso in altri thread.

dal mio punto di vista, firmare le fatture non è corretto.

bisogna fare una differenziazione tra “trasmittente” ed “emittente”

se il cliente fa la fattura autonomamente e poi la invia tramite il tuo software, allora è un intermediario alla spedizione e non va firmata

se il cliente ti incarica di fare le fatture per suo conto, allora essendo che se te a creare la fattura, sei l’emittente o terzo intermediario.

qualche tempo fa era stato affrontato il problema

concordo con le interpretazioni. Se la fattura la emette un soggetto è lui che se ne fa carico, a prescindere dal software o canale che usa. Se la emette un intermediario è lui che è delegato a farlo per nome dell’emittente, e quindi si fa carico di tutto, non solo di una trasmissione tecnica.

Per me i vari aruba che firmano per semplificare la vita ai loro clienti (e giustificare il loro servizio, che altrimenti sarebbe poveretto di contenuti) e si metteono come terzo intermediario non fanno una cosa corretta.

1 Like

Se si ha una delega soggetto emittente si può fare, altrimenti non è corretto

Ringrazio tutti per le risposte e i vostri pareri.

Concordo che apparire come terzo intermediario senza delega firmata secondo me è un ulteriore errore da parte dei software che lo fanno.

Sarebbe comunque interessante avere un chiarimento ufficiale da parte dell’Agenzia Entrate.

Saluti
D.

Ma forse su questo annoso tema ci sono novità,
devo fare delle verifiche, ma con il recepimento della normativa sulla fattura Europea,
dovrebbero essere recepite come qualificate anche le firme apposte con i provider accreditati dalla comunità europea.

Per cui anche i certificati emessi in Germania come questo che firma in cades
https://www.aloaha.com/aloaha-security-solutions/aloaha-crypt-sign-and-zip/aloaha-cms-signer/

1 Like

La tua è un’osservazione interessante, ti riferisci al regolamento eIDAS (2014/910/UE)?

E il certificato rilasciato da questo provider potrebbe essere estratto e utilizzato in modalità automatica?

“Il D.lgs. 148/2018 del 14 gennaio 2018, in attuazione della direttiva Ue 2014/55, ha introdotto l’obbligo per la Pubblica Amministrazione di ricevere ed elaborare le fatture elettroniche in formato conforme allo standard europeo. Secondo quanto previsto dalla normativa, dal 18 Aprile 2019 è scattato per tutte le amministrazioni pubbliche l’obbligo di ricevere e trasmettere fatture elettroniche conformi allo standard europeo.”

… In pratica per essere certi bisognerebbe provare a creare una fattura in cades firmarla con il certificato tedesco e vedere se viene accolta …

… e per il principio dell’interoperabilità delle firme elettroniche in ambito europeo (articolo 25, comma 3 del Regolamento 2014/910 che citavo) dovrebbe funzionare.
Ma il vantaggio di utilizzare questo certificato tedesco? E’ nella seconda domanda che ti avevo posto?

questa azienda offre tutto un SDK che in pratica emula un “mini” hsm, solo che In Italia nessuno vende un certificato iniettabile su un hsm, sono tutti marcati NOT exportable

nel frattempo in Romania: https://digisign.ro/products-services/electronic-signature/

Automatizzare la firma “in casa” non è un problema se si possiede un server fisico. Basta comprare una firma su smartcard o token usb, farla creare con limitazione (previsto dall’articolo 28 del codice di amministrazione digitale) indicando che è valida solo per firmare fatture elettroniche e adoperare un software per firma massiva (o sviluppare un “firmatore automatico” collegato alla produzione dei file xml delle f.e. come abbiamo fatto noi per esempio). La limitazione garantisce che se qualcuno dovesse impadronirsi della smartcard, al più potrebbe firmare delle fatture (e comunque dovrebbe conoscere il pin).

Gli HSM a mio parere sono utili per chi deve automatizzare firme di tipo diverso, per le fatture elettroniche sono il classico cannone per ammazzare la mosca.

si concordo, ma chi ha aperto questo thread ha indicato questa richiesta, per cui se vuole usare il cannone è una sua scelta.

In merito "adoperare un software per firma massiva " , quali sarebbero questi software (escludendo gli hsm) ?
Le smartcard hanno il PIN, anche per la sicurezza, ma sopratutto per esprimere la volontarietà di chi la possiede nel firmare il documento.
Il pin è strettamente personale e non deve essere condiviso o salvato in alcun modo.
come scritto sulla scatola.

Non era proprio in apertura thread l’argomento ma in una risposta successiva…

Ci sono molti software che fanno firma massiva su un insieme di file (per esempio uno potrebbe pensare che ogni giorno firma le fatture del giorno prima), per esempio anche il Dike di Infocert lo fa ma anche quello (non ricordo il nome) di Namirial ecc…

Vero e in questo senso va l’indicazione di usare certificati con limitazione d’uso e di conseguenza, se lo si ritiene un rischio accettabile, il fatto che il pin sia conosciuto dagli operatori aziendali oppure inserito in un file di configurazione di un servizio software non è un problema.

Intanto grazie alla spiegazione su cosa intendevi per firma massiva, ed in effetti quasi tutti lo fanno, ovvero l’operatore mette la spulcia a 1000 file ed inserisce il pin una volta sola.

Sul rischio accettabile invece, non è una discrezione per cui il programmatore A giudica il rischio accettabile, mentre il programmatore B no.

La legge non è basata sulla discrezionalità,
vale quello che c’e’ scritto sulla scatola, o sul foglio accompagnatorio della chiave.

poi a casa sua senza scriverlo in un forum ognuno agisce come crede

Credo sia una questione di “lana caprina”.
La firma massiva senza PIN (fatta per esempio tramite HSM) è comunque “pilotata” da un software. Software che viene scritto da programmatori.
Cioè per essere chiari anche le chiamate API che puoi fare con Aruba e simili che hostano gli HSM sono fatte in modo massivo da software automatizzati (nessun operatore digita nulla); e le chiavi che sono usate per effettuare le chiamate sono contenute nelle configurazioni di questi software.
E quindi in sostanza il concetto non cambia rispetto a quanto ho scritto sopra, l’unica differenza è che il certificato vero e proprio ce l’ha l’HSM invece di essere attaccato al server in sala CED.

Si tratta quindi di una sicurezza fisica, cioè il certificato non può essere “rubato” fisicamente, ma sul fatto che qualcuno possa fare chiamate a nome di qualcun altro non risolve nulla.

Per questa ragione, ANCHE Aruba (e simili), suggeriscono per le fatture elettroniche di fare certificati con limitazione d’uso.

Esattamente, stesso concetto ma con costi decisamente diversi, come testimonia il cartello creato in Italia da “Aruba (e simili)”… che però potrebbe essere smontato proprio dal D.lgs. 148/2018 citato da Diego.

1 Like

semplificando può essere tecnicamente vero,
formalmente per il governo italiano poi dovresti farlo certificare:
http://www.ocsi.isticom.it/index.php/elenchi-certificazioni/prodotti-certificati
la differenza la fa un semplice pezzo di carta, sottoscritto da un notaio nominato dal governo che dichiara che la tua soluzione è sicura.

ad Esempio che Banca! si è fatta il suo software:
http://www.ocsi.isticom.it/documenti/certificazioni/chebanca/rc_fea_chebanca_v1.0.pdf

Non vorrei addentrarmi in cose che non conosco, ma io sto dicendo che di fatto, vista dall’utilizzatore, la firma fatta tramite chiamata API a un HSM e la firma fatta con una smart card collegata ad un computer, porta allo stesso risultato, e ha gli stessi rischi (cioè mi possono rubare le chiavi API cosi’ come mi possono rubare il PIN della smart card), con l’esclusione della sicurezza fisica della chiave, che negli HSM è contenuta dentro l’HSM stesso mentre con una smart card qualcuno potrebbe impadronirsene.

E ciò è confermato dal fatto che se vai a prendere una fattura firmata tramite HSM e una tramite smart card, l’esito della verifica è lo stesso.

Qua comunque mi fermo perchè di norme di legge ne so poco.

Giusto per info … qualcosa si muove anche in Italia:
API standard per una facile integrazione
Dike GoSign BUSINESS €99/anno +IVA
https://www.firma.infocert.it/prodotti/dikegosign-business.php