Costi di cloud hosting nell’IP Box cipriota

Classificare l’attività prima del fornitore

AWS, Azure o un altro fornitore possono fatturare insieme risorse per ricerca, produzione, assistenza clienti e dimostrazioni commerciali. Il nome del fornitore dice quindi poco sulla classificazione fiscale. Bisogna chiedersi quale lavoro la risorsa abbia sostenuto e come sia collegato al bene qualificato.

Le norme cipriote comprendono costi direttamente connessi allo sviluppo, al miglioramento o alla creazione di beni immateriali qualificati, fatte salve le esclusioni. Non stabiliscono che ogni fattura cloud sia R&S qualificata, né escludono in blocco i servizi cloud. L’analisi pratica parte dall’attività di sviluppo e identifica poi la spesa che la sostiene.

Tenere separate due decisioni. Prima stabilire come la spesa viene trattata nel calcolo del reddito netto IP. Poi verificare se soddisfa la definizione di spesa qualificata per il nexus. Registrare un costo di produzione nel primo calcolo non ne giustifica l’inserimento nel secondo.

Classificare ogni risorsa secondo lo scopo

La tabella è uno strumento di verifica, non un prospetto fiscale ufficiale. Ogni voce dipende comunque dall’attività effettiva, dal collegamento con il bene e dal trattamento fiscale applicabile.

Un esempio di ripartizione senza presumere l’ammissibilità

Supponiamo una fattura mensile di 12.000 €. Le etichette delle risorse identificano 7.000 € per produzione, 3.000 € per un progetto di sviluppo e 2.000 € per risorse condivise. I 3.000 € sono candidati alla verifica R&S, non un dato nexus automaticamente approvato. Il lavoro del progetto deve rispettare i criteri pertinenti ed essere collegato al bene qualificato.

Per i 2.000 € condivisi, il team finanziario acquisisce registri che mostrano quali ambienti hanno consumato le risorse. Applica un criterio di ripartizione documentato e chiede al team tecnico di confermare che rappresenti l’utilizzo effettivo. Non è giustificato attribuire tutto alla R&S solo perché la società sviluppa software.

Ipotizziamo, a titolo illustrativo, che dopo la ripartizione la verifica documenti 3.500 € di spese direttamente collegate a sviluppo qualificato. Tale cifra entra nel prospetto nexus secondo la base pertinente. Il trattamento del resto nel calcolo annuale dell’utile rimane una questione separata: non è necessariamente indeducibile solo perché fuori da QE.

Rendere il conto cloud comprensibile alla contabilità

Creare un linguaggio condiviso tra sviluppo e contabilità. Ogni progetto pertinente richiede un identificativo stabile del bene. Le etichette degli ambienti dovrebbero distinguere produzione, sviluppo, test e uso commerciale quando ciò rispecchia il sistema. Conservare la mappatura quando i progetti vengono rinominati o gli account migrati.

Esportare i registri di utilizzo insieme alle fatture. Una fattura sintetica con il solo nome del servizio e il totale può non spiegare i costi di più prodotti. Conservare periodo, identificativi delle risorse, calcolo della ripartizione e spiegazione dell’attività sottostante. Non riscrivere le etichette storiche come se fossero prove raccolte all’epoca.

Migliorare le etichette per il futuro può rafforzare i registri successivi senza dimostrare l’ammissibilità passata. Se i registri storici sono incompleti, utilizzare materiale di supporto autentico e indicare chiaramente stime e importi irrisolti. La mancanza di documentazione non deve trasformarsi in una percentuale qualificata presentata come certa.

• Collegare ogni importo richiesto a un progetto e a un bene qualificato.
• Spiegare perché il lavoro era sviluppo anziché normale esercizio.
• Riconciliare gli importi allocati con il totale della fattura.
• Distinguere acquisizione, parti correlate e altre categorie di costo quando pertinenti.
• Registrare chi ha approvato la ripartizione e perché.

Riesaminare la classificazione quando il progetto entra in produzione

Lo stesso ambiente può cambiare funzione nel tempo. Le risorse di calcolo di un progetto sperimentale possono diventare il servizio di produzione acquistato dai clienti. Una ripartizione ragionevole durante lo sviluppo può diventare fuorviante dopo il lancio. Verificare la finalità in occasione di versioni importanti e spostamenti dei carichi di lavoro.

Per i prodotti AI è particolarmente importante. Addestramento, valutazione, inferenza e normale utilizzo dei clienti non sono etichette intercambiabili. Non trattare tutte le spese GPU come R&S solo perché l’infrastruttura è costosa o tecnicamente complessa. Prima occorre stabilire il bene pertinente, l’attività di sviluppo e il rapporto con il costo.