Come testare le fatture elettroniche 1.9.1 nell'ambiente sandbox SDI
Prima del cutover del 15 maggio 2026 verso la specifica tecnica 1.9.1, software house, sviluppatori e responsabili IT possono validare il proprio tracciato XML, i nuovi controlli (Gruppo IVA → 00327, ESENZSPORT) e i canali WS/SFTP nell'ambiente di sperimentazione SDI fornito dall'Agenzia delle Entrate. La sandbox è completamente isolata dalla produzione: nessuna fattura test entra in cassetto fiscale.
Pre-cutover: usa la sandbox
L'ambiente di test SDI è gratuito e accessibile previa accreditamento. Configurazione: 1-2 ore. Esegui almeno un test end-to-end per ogni caso d'uso (Gruppo IVA, ESENZSPORT, multi-codice destinatario) prima del 15 maggio 2026.
Differenza ambiente test vs produzione
- Produzione SDI: ogni fattura accettata genera ricevute reali, entra nel cassetto fiscale del cessionario, è soggetta alle regole di conservazione decennale.
- Test SDI: le fatture transitano sull'infrastruttura di sperimentazione, vengono validate con le stesse regole della produzione, ma non finiscono in cassetto fiscale e non hanno valore legale.
- Le ricevute (scarto, consegna, mancata consegna, attestazione) generate in test hanno lo stesso formato XML della produzione, utili per l'integrazione lato client.
Come ottenere accesso alla sandbox
- Accedere a accreditamento.fatturapa.gov.it con SPID, CIE o CNS.
- Selezionare la sezione "Sistema di Accreditamento → Test di interoperabilità".
- Richiedere l'abilitazione al canale di test (WS o SFTP, oppure via web tramite portale F&C).
- Ricevere le credenziali dedicate per la sandbox e il manuale tecnico WS/SFTP versione test.
- Importare i certificati di test (vedi sezione successiva).
I certificati richiesti per il test
Sono due i certificati da installare nello store di sistema del client che si interfaccia con SDI test:
CAEntratetest.cer→ store "Autorità di certificazione radice attendibili" (Trusted Root CA). È la CA che firma i certificati emessi nell'ambiente test.SistemaInterscambioFatturaPATest.cer→ store "Trusted People". È il certificato del server SDI di test, usato per il mutual TLS handshake.
Su Windows: certmgr.msc → Importa nei due store. Su Linux: usa il keystore Java ( keytool -import) o il truststore del client HTTP. Su macOS: Keychain Access → System.
Senza questi certificati il client TLS rifiuta l'handshake con un errore generico "untrusted certificate" — primo errore tipico in sperimentazione.
Codici destinatario di test
Due famiglie di codici, da usare a seconda dello scenario simulato:
- 6 caratteri → simulano una PA destinataria (ufficio della pubblica amministrazione). Es.
XXXXXX(placeholder generico). Per ottenere codici PA di test specifici: sezione "Gestione test interoperabilità → Codici destinatario" nel Sistema di Accreditamento. - 7 caratteri → simulano un soggetto privato (azienda o intermediario). Es.
XXXXXXX.
Per il test di accreditamento di un canale SFTP, il codice destinatario di test viene assegnato al canale stesso e va valorizzato nel campo <CodiceDestinatario> della fattura test in ricezione.
Importante: i codici test NON sono validi in produzione e viceversa. Non riusare un codice destinatario produttivo in sandbox.
Simulare i 4 casi nuovi della 1.9.1
Test minimi consigliati prima di andare in produzione il 15 maggio 2026:
- Caso A — Gruppo IVA OK: fattura con P.IVA Gruppo + CF partecipante corretto → ricevuta di consegna attesa.
- Caso A.bis — Gruppo IVA KO: fattura senza P.IVA Gruppo e con CF errato (CF del Gruppo invece del partecipante) → ricevuta di scarto con codice 00327.
- Caso B — ESENZSPORT: fattura sportiva con
<TipoDato>ESENZSPORT</TipoDato>valorizzato → ricevuta di consegna; verifica che il blocco AltriDatiGestionali sia persistito correttamente nell'XML processato. - Caso C — Multi codici destinatario: invio di 2 fatture passive verso 2 codici destinatario distinti dello stesso soggetto → 2 ricevute di consegna distinte.
- Caso D — Schema 1.9 dopo cutover (post 15/5): invio con schema vecchio → ricevuta di scarto codice 00200.
Errori frequenti in fase di test
- Certificato non importato negli store corretti → handshake TLS fallisce.
- Endpoint sbagliato (URL produzione invece di test) → fatture spedite in produzione per errore (incidente reale e ricorrente).
- Parser XSD aggiornato a 1.9 ma controller backend ancora su 1.8 → fatture passano validazione ma falliscono in semantica.
- Codice destinatario di test riusato in produzione → fattura va in deposito senza notifica.
- Tempi di propagazione: in test alcune ricevute hanno latenza maggiore (anche minuti); non scambiare la latenza per fallimento.
Quando il test non basta: casi edge
Test che non puoi simulare in sandbox:
- Conservazione decennale: in sandbox le fatture non finiscono in cassetto, non puoi testare la firma di conservatori accreditati.
- Notifiche di mancata consegna (decorrenza 15 giorni) dipendono dalla configurazione del canale reale del cessionario.
- Interazioni con il portale F&C per fatture passive (consultazione cassetto): disponibili solo in produzione.
Per queste casistiche: pianifica una finestra di test in produzione con fatture di valore basso (es. ricarica interna 1 €) il giorno del go-live 1.9.1.
Domande frequenti
L'accesso all'ambiente test è gratuito?
Posso usare la sandbox SDI senza essere software house?
Quanto tempo serve per il setup completo?
Le fatture test impattano i contatori IVA?
Posso testare il canale SFTP senza accreditarlo prima?
Fonti consultate
Verificate a aprile 2026. Le normative possono cambiare: consulta sempre la fonte ufficiale prima di agire.