Embedded Accounting: Sviluppare in proprio o acquistare per i marketplace
Un elenco dei requisiti, un modello di costo con ipotesi dichiarate e le condizioni in cui ciascuna risposta è corretta.
Prima o poi, ogni marketplace realizza un proprio registro contabile. L'unica vera domanda è se venga costruito consapevolmente, come sistema dotato di controlli, o per caso, come una colonna balance su cui scrivono tre servizi diversi e di cui nessuno si fida ciecamente.
Questo articolo serve a compiere questa scelta con cognizione di causa. Analizza cosa comporta realmente il lavoro, come calcolarne i costi senza autoinganni e le condizioni specifiche in cui lo sviluppo interno rappresenta la risposta corretta, perché a volte lo è davvero.
Cosa significa "embedded accounting" in questo contesto
Per contabilità integrata (embedded accounting) si intende che la contabilità risiede all'interno del vostro prodotto anziché in un'applicazione aperta separatamente. Il software registra le voci man mano che gli eventi si verificano, gli utenti vedono ciò che l'interfaccia mostra loro e nessuno esporta fogli di calcolo per passarli a un commercialista alla fine del mese.
Per un marketplace questo copre, come minimo: i pagamenti dei acquirenti ricevuti, gli importi dovuti ai venditori, le commissioni guadagnate, le commissioni di elaborazione dei pagamenti, l'IVA sulle vostre commissioni e sulla fornitura sottostante, i rimborsi, i chargeback, i fondi di riserva (reserves), i pagamenti ai venditori (payouts) e la riconciliazione di tutto ciò rispetto a una banca o a un fornitore di servizi di pagamento.
Cosa state realmente costruendo se scegliete lo sviluppo interno
Il registro contabile (ledger) in sé è solo la parte minore. I team stimano regolarmente solo la prima voce per poi scoprire tutto il resto in seguito.
| Componente | Cosa comporta |
|---|---|
| Giornale e conti | Scritture bilanciate, piano dei conti, tipi di conto, saldi di apertura |
| Immutabilità | Archiviazione di solo accodamento (append-only), flusso di storno e correzione, nessuna modifica in loco |
| Controllo dei periodi | Chiusura, blocco, rifiuto delle registrazioni tardive, riapertura controllata con tracciato di audit |
| Idempotenza | Chiavi, memorizzazione delle risposte precedenti, rilevamento delle collisioni su payload modificati |
| Gestione del denaro | Aritmetica esatta a virgola mobile decimale o basata su unità minori, codici valuta, tassi di cambio e relativa fonte, conti di arrotondamento |
| Motore IVA | Aliquote per paese con date di validità, luogo di cessione, inversione contabile (reverse charge), regole per i fornitori presunti (deemed supplier), esenzioni |
| Verifica delle partite IVA | Validazione rispetto al registro ufficiale, memorizzazione nella cache, timestamp, identificatori di richiesta, una coda di revisione manuale per i casi di errore |
| Documenti | Fatture, note di credito, numerazione progressiva continua per serie e anno, rendering PDF, consegna |
| Fatturazione elettronica | Formati strutturati come EN 16931 UBL e formati nazionali specifici per paese ove obbligatori |
| Acquisizione bancaria | Importazione degli estratti conto o connessione bancaria tramite consenso (consented bank connection), deduplica delle transazioni già importate |
| Riconciliazione | Regole di abbinamento, punteggio di corrispondenza, corrispondenze parziali, eccezioni che un operatore umano può risolvere |
| Erogazioni (payouts) | Generazione di file di pagamento, raggruppamento dei pagamenti in batch, abbinamento dei pagamenti alle voci sottostanti |
| Rendicontazione | Bilancio di verifica, stato patrimoniale, conto economico, rendiconto finanziario, riepiloghi IVA, scadenzario crediti (aged debt) |
| Registri fiscali e dichiarazioni | Quanto richiesto dai vostri paesi, nel formato accettato dall'autorità |
| Audit | Attore, azione, entità e la modifica stessa, interrogabili per ogni mutazione |
| Conservazione ed esportazione | Conservazione decennale per i registri OSS, esportazione completa dei dati, archivio difendibile |
Più o meno due di queste diciassette righe costituiscono la parte che la maggior parte dei team immagina quando dice "costruiremo un registro contabile".
Stimare i costi in modo onesto
Qualsiasi cifra qui riportata dipende dal vostro team, quindi considerate quanto segue come un metodo piuttosto che come un preventivo. Prendete i componenti sopra elencati, assegnate a ciascuno una dimensione in settimane-ingegnere basata sulla velocità del vostro team, e applicate quindi tre correzioni che le stime di solito trascurano.
Prima correzione: i componenti di conformità non sono una tantum. Le aliquote cambiano, le soglie cambiano, i formati cambiano e il pacchetto europeo IVA nel mondo digitale (ViDA) introduce obblighi legati a scadenze precise: modifiche a OSS e IOSS dal 1° gennaio 2027, regole estese per le piattaforme dal 1° luglio 2028 e rendicontazione digitale transfrontaliera dal 1° luglio 2030. Scegliere di sviluppare in proprio significa farsi carico di ciascuna di queste migrazioni.
Seconda correzione: il lavoro sulla correttezza dura più delle funzionalità. La prima versione gestisce il percorso ideale (happy path). La coda lunga è rappresentata dai rimborsi successivi al pagamento, dai rimborsi parziali, dai chargeback che arrivano settimane dopo, dagli arrotondamenti di valuta, dai webhook duplicati e dai file di regolamento che non coincidono con i vostri registri. È qui che il calendario scompare.
Terza correzione: il commercialista è uno stakeholder, non un revisore. Una contabilità che un professionista finanziario non firma non è un prodotto finito, e quel riscontro arriva tardi nello sviluppo.
Un utile controllo di realtà: calcolate il costo della build minima credibile - registro contabile, correzioni, blocco dei periodi, idempotenza, gestione del denaro, IVA di un paese, fatture, importazione bancaria, abbinamento e un set di report di base - e confrontatelo con un anno di un servizio a consumo. I piani pubblicati di Nordlet partono da 10 euro al mese con 3.000 richieste incluse e arrivano a 300 euro al mese con 200.000 richieste. Se lo sviluppo costa una frazione di anno-ingegnere singolo, esiste un argomento concreto a favore dello sviluppo interno. Se costa diversi anni-ingegnere più la manutenzione permanente, il confronto non regge, e diventa ancora meno favorevole ogni volta che le regole cambiano.
Quando lo sviluppo interno è davvero la scelta giusta
Tre casi, tutti reali.
Il vostro registro contabile è il vostro prodotto. Se state creando una piattaforma di pagamento, un prodotto bancario o un wallet in cui il comportamento del saldo in condizioni di concorrenza è l'elemento differenziante, il registro è centrale e deve essere vostro. Prendete in considerazione prodotti di infrastruttura di registro (ledger infrastructure) anziché partire da zero, e tenete separata la contabilità civilistica e fiscale.
Il vostro modello non si adatta ad alcun sistema contabile. Alcuni marketplace presentano strutture di regolamento davvero insolite: suddivisioni multi-parte con rilasci condizionati, depositi a garanzia (escrow) con traguardi intermedi, complesse politiche di riserva. Se nessun prodotto le modella e i workaround sono peggiori dello sviluppo, allora sviluppate.
I vostri volumi rendono errata la tariffazione a consumo. A tassi di transazione sufficientemente estremi, la tariffazione per richiesta smette di essere vantaggiosa. Modellate questa ipotesi con numeri reali prima di darla per scontata, perché qui il termine "estremo" è superiore a quanto la maggior parte delle piattaforme riesca a raggiungere.
Quando l'acquisto è la scelta giusta
L'acquisto vince quando la contabilità è necessaria ma non differenziante, che è il caso più comune. Nessuno sceglie il vostro marketplace perché le vostre registrazioni contabili sono eleganti. Se ne accorgono solo quando la contabilità è errata.
L'acquisto è la scelta giusta anche quando i vostri obblighi riguardano più paesi. Le regole IVA paese per paese, la conservazione delle prove e gli obblighi di fatturazione elettronica costituiscono un flusso di manutenzione permanente, e un fornitore ammortizza questo lavoro su ogni singolo cliente. Nordlet integra IVA UE per paese con validazione VIES, calcolo delle dichiarazioni OSS e IOSS, registri i.SAF e EN 16931 UBL per Peppol come parte del prodotto anziché come un progetto da pianificare.
Una via di mezzo a cui la maggior parte dei team arriva
La risposta pratica di solito non è nessuna delle due alternative estreme. È: acquistate il registro, sviluppate il flusso di lavoro.
Il backend contabile gestisce le registrazioni, il trattamento fiscale, i documenti, la chiusura del periodo e la traccia di audit. Il vostro prodotto gestisce tutto ciò che gli utenti vedono e ogni regola di business specifica per il vostro marketplace: quando i fondi vengono rilasciati, qual è la politica di riserva, come vengono gestite le controversie, cosa mostra la dashboard del venditore. Chiamate l'API contabile nei momenti in cui il denaro viene impegnato e mantenete le parti che sono effettivamente vostre.
Questo confine resiste anche meglio ai cambiamenti rispetto alle alternative. Un nuovo paese richiede una configurazione anziché un progetto. Una nuova politica di pagamento è il vostro codice, non una richiesta al fornitore.
Cosa decidere prima di impegnarsi
- Il vostro registro contabile è un elemento differenziante o un obbligo? Siate onesti; la maggior parte sono obblighi.
- Quanti paesi e cosa richiede ciascuno di essi? Solo aliquote, oppure dichiarazioni, registri o invii telematici.
- Qual è la vostra strategia di correzione? I rimborsi dopo il pagamento e i chargeback tardivi sono i casi che mettono a nudo una progettazione debole.
- Chi firma i libri contabili? Coinvolgete quella persona prima che la progettazione sia definita, non dopo.
- Qual è il piano di conservazione decennale? I registri OSS devono essere conservati per dieci anni dalla fine dell'anno della transazione, e un archivio è un sistema, non un backup.
- Come si prospetta una migrazione tra tre anni? In entrambe le direzioni. Create un'esportazione di test fin dal primo giorno e mantenetela funzionante.
FAQ
Quanto tempo ci vuole per costruire il registro contabile di un marketplace?
Una prima versione che registra scritture bilanciate può essere operativa in poche settimane. Una versione che gestisce rimborsi post-pagamento, chargeback tardivi, arrotondamenti multivaluta, webhook duplicati dei fornitori, chiusura di periodo e un audit accettabile per un commercialista richiede molto più tempo, e la manutenzione non finisce mai. Stimate la seconda opzione, perché è questo che significa la messa in produzione.
Possiamo iniziare con una colonna balance e migrare in seguito?
Potete farlo, e molti lo fanno, ma mettete in conto che la migrazione sarà più complessa dello sviluppo originale. Ricostruire la cronologia partendo da un saldo modificabile è possibile solo se avete conservato ogni singolo evento che lo ha modificato, il che equivale a dire: solo se avevate già un registro contabile.
Un'API di contabilità integrata sostituisce il nostro team finanziario?
No. Elimina la registrazione manuale e la riconciliazione. Qualcuno deve comunque chiudere il mese, esaminare le eccezioni, esprimere giudizi professionali e presentare le dichiarazioni.
Come la mettiamo con il GDPR se il registro contabile è immutabile?
Conservate i dati monetari e i riferimenti pseudonimi nei record immutabili, e i dati personali in un sistema separato dotato di un proprio processo di conservazione ed eliminazione. L'immutabilità si applica all'evento finanziario, non a ogni attributo ad esso associato.
Il software contabile open source rappresenta una via di mezzo?
È un'opzione reale, e sposta il costo anziché eliminarlo: vi assumete in prima persona l'hosting, gli aggiornamenti, la localizzazione per paese e gli aggiornamenti normativi. Calcolate questi costi prima di considerare il risparmio sulla licenza come il quadro completo.