Quando si collega un sito e-commerce all'ERP e alla fatturazione elettronica, la decisione si riduce a una domanda più semplice di quanto molte aziende immaginino: il suo negozio online è su una delle piattaforme supportate da un connettore pronto, oppure è una soluzione su misura, basata su codice proprio? Nel primo caso, il più delle volte basta un connettore pronto (come Entegra, Sopyo o Sentos): si paga un abbonamento mensile più un credito (kontör) per ogni documento, la configurazione è rapida e il peso della manutenzione non ricade su di Lei. Nel secondo caso, cioè se non si trova su una piattaforma nominata e in elenco come WooCommerce, Shopify o İkas, il «percorso standard» dei connettori pronti non la copre: commissionare un bridge API su misura (oppure richiamare l'API di un connettore dal proprio bridge) diventa l'unica strada sensata. Il dato tecnico decisivo è questo: in Turchia e-Fatura ed e-Arşiv (i sistemi nazionali di fatturazione elettronica) sono documenti XML strutturati, imposti dall'amministrazione fiscale turca (GİB). Non si fa alcun OCR su PDF o scansioni: il documento viene generato via software e trasmesso in pochi secondi. In altre parole, «integrare la fatturazione» non significa riconoscere immagini, ma produrre e interpretare XML a tag. Di seguito presentiamo questa decisione non come uno slogan, ma attraverso una matrice decisionale misurabile e il ragionamento sul costo totale di possesso (TCO). Come software house B2B / white-label con sede a Sakarya, facciamo questa scelta di continuo per titolari di agenzie e grandi aziende: qui condividiamo esattamente il metodo che usiamo.
In questo articolo, invece della solita predica sul fatto che «l'integrazione fa bene», entriamo nella meccanica: la realtà XML della fatturazione elettronica, che cosa va davvero sincronizzato (giacenze, prezzi, ordini, fatture, resi), i pro e i contro di un connettore pronto, i pro e i contro di un bridge su misura, una matrice decisionale e infine il ragionamento sul TCO «crediti o sviluppo + manutenzione». Abbiamo già trattato il tema in una cornice più ampia nei nostri articoli su software su misura e software standard e su ERP/CRM su misura per l'azienda; qui aggiungiamo un livello specifico per il triangolo e-commerce + ERP + fatturazione elettronica.
La realtà XML della fatturazione elettronica: qui non c'è OCR
L'ipotesi sbagliata più diffusa è immaginare l'integrazione della fatturazione elettronica come «scansionare una fattura e importarla nel sistema». In Turchia la situazione è diversa. Per e-Fatura ed e-Arşiv la GİB ha adottato uno standard XML strutturato chiamato UBL-TR; i documenti vengono preparati secondo questo pacchetto di schemi (con codifica UTF-8). Integrazione API significa che il suo software di ordini, vendite o ERP si collega alla GİB o al web service di un integratore privato e crea la fattura, la invia e ne segue lo stato senza intervento umano: poiché il documento è XML strutturato per le macchine dall'inizio alla fine, non esiste alcun passaggio OCR, né in emissione né in ricezione.
La conseguenza pratica è questa: il cuore dell'integrazione consiste nel mappare sui campi XML corretti dati come righe della fattura, aliquote fiscali, dati della controparte (acquirente) e tipo di documento. Secondo la definizione ufficiale della GİB, un'e-Fatura può essere emessa con tre metodi: il Portale e-Fatura, l'Integrazione (il sistema del contribuente si collega direttamente, 24/7) e l'Integrazione privata / Integratore privato. Nella formulazione ufficiale della GİB, un integratore privato serve a ricevere e inviare fatture elettroniche per conto del contribuente «attraverso il sistema informatico di un integratore privato dotato di competenza tecnica»; deve aver superato i test della GİB ed essere stato approvato (GİB — Integrazione privata). In pratica, l'integratore privato si fa carico della connessione con la GİB e dell'infrastruttura e di solito le mette a disposizione una REST API. Questa distinzione è anche la base della sua decisione «connettore pronto o bridge su misura»; del lato API ci occupiamo nell'ambito del nostro servizio di integrazione API.
Che cosa va davvero sincronizzato?
Un bridge e-commerce ↔ ERP ↔ fatturazione elettronica non è un unico «trasferimento di dati»: sono cinque flussi con cicli di vita distinti. Qualunque soluzione scelga, deve modellarli tutti e cinque:
- Giacenze: di solito bidirezionali. Una variazione di quantità nell'ERP deve riflettersi sul sito e una vendita sul sito deve riflettersi nell'ERP. Altrimenti si continua a vendere un prodotto già esaurito.
- Prezzi e prodotti: nella maggior parte delle configurazioni la definizione di prezzi e prodotti passa dall'ERP al sito; qui i prezzi promozionali richiedono un'attenzione particolare.
- Ordini: passano dal sito all'ERP. Il punto critico: nella maggior parte dei connettori questo flusso non è un push in tempo reale, ma funziona con un polling a intervalli (dettagli più avanti).
- Fatture: conversione dell'ordine in fattura. Qui il documento e-Fatura, e-Arşiv o e-SMM (la ricevuta elettronica dei liberi professionisti) viene prodotto via software e registrato formalmente presso la GİB.
- Resi: il flusso trascurato più spesso. Un'e-Fatura emessa non si può «cancellare»; un reso, anche parziale, si modella con un documento contabile separato (una fattura di reso).
Questi cinque flussi hanno requisiti di latenza e coerenza diversi. Nella sincronizzazione degli ordini, per esempio, molte integrazioni ERP lavorano con una logica batch/polling: secondo la documentazione di IdeaSoft e di connettori simili, gli ordini provenienti dal sito vengono trasmessi a Mikro ERP attraverso un livello di web service sicuro a intervalli di circa 15 minuti (non tramite accesso diretto al database), mentre giacenze, prodotti e prezzi si sincronizzano in entrambe le direzioni (IdeaSoft — integrazione Mikro). Questi 15 minuti circa sono un comportamento dell'applicazione connettore, non una garanzia della piattaforma «Mikro»; inoltre, «Mikro» comprende linee di prodotto diverse (Jump/Fly/versioni precedenti) con superfici di integrazione differenti. Quando pianifica la latenza ordine→fattura, deve tenere conto di questa realtà del polling.
Idempotenza: il rischio tecnico più insidioso del bridge
Poiché la sincronizzazione funziona a polling e i documenti e-Fatura ed e-Arşiv vengono registrati una sola volta presso la GİB, un bridge ingenuo può emettere una fattura doppia in caso di nuovo tentativo (retry) o di webhook dell'ordine ripetuto. Significa duplicare un documento legale: un problema sia verso il cliente sia sul piano fiscale. Un bridge robusto richiede una chiave di idempotenza per ogni ordine, la creazione della fattura esattamente una volta e una gestione attenta di flag di stato come e_invoice_sent/e_archive_sent. È un requisito ingegneristico diretto, che deriva dal modello di documento registrato della GİB e dal comportamento di polling osservato. Abbiamo affrontato lo stesso rigore su webhook e idempotenza, sul versante dei pagamenti, nella nostra guida all'integrazione del POS virtuale; la stessa disciplina vale per il flusso di fatturazione.
Connettore pronto: pro e contro
I connettori pronti (come Entegra, Sopyo, Sentos e İkas) si collegano a sistemi ERP e di contabilità di base (Logo, Netsis, Mikro, Paraşüt e altri) e al sistema di fatturazione elettronica; il loro supporto, però, ruota attorno a un elenco fisso di piattaforme e-commerce, in gran parte SaaS. Entegra, per esempio, collega in modo bidirezionale sistemi ERP come Logo, Netsis, Mikro, SAP, ETA, Zirve, DİA, Nebim, Paraşüt, Link e Microsoft Dynamics a piattaforme e-commerce come IdeaSoft, Ticimax, OpenCart, T-Soft, Hipotenüs, WooCommerce, Shopify, PrestaShop e Magento; offre la conversione ordine→fattura con un clic, la sincronizzazione bidirezionale di giacenze e prezzi e la creazione automatica delle anagrafiche (Entegra — integrazione e-commerce). Allo stesso modo, Sopyo elenca piattaforme come Shopify, WooCommerce, IdeaSoft, İkas e Ticimax accanto a Logo/Mikro/Paraşüt e ai sistemi di fatturazione elettronica.
| Pro | Contro |
|---|---|
| Configurazione rapida: ordine→fattura, sincronizzazione di giacenze e prezzi e creazione automatica delle anagrafiche senza scrivere codice. | Supporta solo le piattaforme nominate e in elenco; un negozio su misura o basato su codice proprio resta fuori dal «percorso standard». |
| Il peso della manutenzione ricade sul fornitore: i cambi di versione delle API e la conformità alle regole GİB sono un suo problema. | Costo ricorrente: abbonamento + credito per documento; cresce con i volumi. |
| Compatibilità già pronta con molti sistemi ERP e di fatturazione elettronica; l'onere dei test non ricade su di Lei. | Personalizzazione limitata; poca flessibilità per regole di business e mappature dei campi specifiche. |
| Costo d'ingresso basso per volumi piccoli o medi e flussi standard. | Un picco da campagna o da Black Friday fa salire direttamente il consumo di crediti e il rischio legato a volumi e limiti. |
Ecco il vero vuoto: questi connettori puntano alle piattaforme nominate, in gran parte SaaS, e non elencano il supporto per negozi interamente su misura o basati su codice proprio. La pagina di integrazione di Sentos riporta solo piattaforme specifiche (İkas, Ticimax, Shopify, IdeaSoft, Hipotenüs, T-Soft, OpenCart, WooCommerce, Ethica) e non cita software su misura o proprietari (Sentos — integrazione B2C). Allo stesso modo esistono le integrazioni di İkas con contabilità di base ed ERP (Logo İşbaşı, Mikro, Nebim, Uyumsoft, Akınsoft Wolvox, DİA, Microsoft Dynamics, Netsis, Zirve, Link, le gratuite BirFatura/Bizim Hesap ecc.), ma esistono perché İkas stessa è una piattaforma SaaS in hosting: la superficie di integrazione sta tra la piattaforma İkas e l'ERP, quindi un negozio su misura basato su codice non può riutilizzarla senza migrare su İkas (İkas — integrazioni con la contabilità di base).
Bridge API su misura: pro e contro
Un bridge su misura è un livello scritto sulle sue regole di business, in cui il suo sito (o un servizio intermedio) richiama direttamente le API dell'ERP e di un integratore privato o di una piattaforma contabile. Le API dei sistemi moderni si prestano bene a questo scopo. Paraşüt, per esempio, offre una REST API ufficiale (v4) e per l'autenticazione usa OAuth2 (host api.parasut.com, basePath /v4). L'autorizzazione passa dagli endpoint /oauth/authorize e /oauth/token; l'access_token è di tipo Bearer, scade entro 2 ore e si rinnova con un refresh_token. La specifica documenta tre tipi di grant OAuth2: authorization_code, password e refresh_token; l'URI di reindirizzamento predefinito è urn:ietf:wg:oauth:2.0:oob (Paraşüt — documentazione API ufficiale (swagger)).
Ancora più importante, l'API di Paraşüt espone direttamente le risorse e-Fatura, e-Arşiv ed e-SMM: /{company_id}/e_invoices, /{company_id}/e_archives, gli endpoint .../pdf per il PDF e un enum documentato dello stato della fattura (printed, not_printed, invoices_not_sent, e_invoice_sent, e_archive_sent, e_smm_sent). Per creare fatture via software e recuperare i PDF, quindi, non serve alcun passaggio separato di OCR o di gestione documentale. Sul fronte ERP, Logo Netsis offre, nella sua documentazione ufficiale, una REST API chiamata «NetOpenX Rest»; questa API standardizza le funzioni NetOpenX per inviare dati all'ERP e riceverli da esso nelle integrazioni web e mobile senza compromettere la logica di business (Logo — strumenti di personalizzazione Netsis). L'esistenza e il perimetro funzionale di questa API sono verificati; qui non ci pronunciamo sul suo esatto meccanismo di autenticazione (token o sessione): basta inquadrarla come una REST API con una propria autenticazione.
| Pro | Contro |
|---|---|
| Funziona con un negozio su misura o basato su codice proprio; non è vincolato a un elenco predefinito. | Costo iniziale di sviluppo + manutenzione continua (cambi di versione delle API, retry, disallineamenti di sincronizzazione). |
| Piena aderenza alle regole di business: mappatura dei campi, idempotenza e flusso dei resi restano sotto il suo controllo. | Richiede un'ingegneria corretta; il rinnovo del token OAuth e la gestione di errori e code non vanno trascurati. |
| L'architettura la progetta Lei, al di là dei crediti; non è alla mercé del lock-in di un fornitore. | Deve seguire con i suoi tempi le novità normative e della GİB e le modifiche alle API degli integratori. |
| Un'architettura prevedibile e indipendente dai volumi; versioning e osservabilità sono nelle sue mani. | Nota: i documenti di fatturazione elettronica passano comunque da un integratore privato o dalla GİB; la voce dei crediti di solito non scompare. |
Nota: un bridge su misura non significa «liberarsi del tutto dei crediti»; i documenti di fatturazione elettronica continuano ad arrivare alla GİB o all'integratore privato, dove si consuma un credito per documento. Ciò che un bridge su misura le fa guadagnare è che il livello di orchestrazione e di logica di business appartiene a Lei, su qualunque piattaforma si trovi. Realizziamo i bridge su misura all'interno dei servizi software web su misura e soluzioni CRM ed ERP.
Matrice decisionale: quando basta il connettore pronto e quando serve il su misura?
Per rendere la decisione intuitiva, ecco alcune regole in una riga:
| Situazione | Orientamento | Motivazione |
|---|---|---|
| Negozio su una piattaforma SaaS elencata dal connettore (WooCommerce, Shopify, İkas, Ticimax…) | Connettore pronto | Il percorso standard lo copre; la configurazione è rapida, la manutenzione spetta al fornitore. |
| Negozio interamente su misura o basato su codice proprio, soluzione non in elenco | Bridge su misura | I connettori pronti non coprono questo negozio; l'API dell'ERP o dell'integratore la richiama direttamente Lei. |
| Flusso standard, poca personalizzazione, volumi medi | Connettore pronto | Se non ci sono regole particolari, non serve sostenere un costo iniziale di sviluppo. |
| Regole di business specifiche (logica dei resi personalizzata, prezzi B2B, multi-negozio/multi-controparte) | Bridge su misura | Mappatura dei campi, idempotenza e flusso delle fatture di reso richiedono il pieno controllo. |
| Volumi molto alti o variabili, SLA (accordo sul livello di servizio) rigoroso | Di solito su misura (o ibrido) | La gestione di crediti e limiti e un'architettura con code e retry richiedono prevedibilità. |
La decisione non è «quale sia migliore», ma «in quale casella rientra il suo negozio». Se è su una piattaforma SaaS in elenco, di solito basta un connettore pronto; se ha un negozio su misura o basato su codice proprio, oppure regole di business specifiche, il bridge su misura non è una preferenza, ma una necessità.
Il flusso dei resi non va sottovalutato
Qualunque strada scelga, i resi vanno modellati a parte. Poiché un documento e-Fatura o e-Arşiv emesso è registrato presso la GİB, non si può semplicemente «cancellare»: entro una breve finestra di annullamento un documento e-Arşiv può essere annullato e comunicato alla GİB; chiusa quella finestra, la correzione o il reso avvengono con un documento di reso (nota di credito) (Paraşüt — annullamento e-Arşiv o reso). Gestire separatamente resi totali e parziali è essenziale per mantenere coerenti giacenze, saldi delle controparti e registrazioni fiscali. Qui non indichiamo il numero di giorni della finestra di annullamento come regola rigida, perché le fonti divergono; se le serve una durata precisa, faccia riferimento al comunicato o alla guida GİB vigente su e-Arşiv.
Ragionamento sul TCO: crediti o sviluppo + manutenzione?
La decisione è in realtà una scelta di forma di costo: il connettore pronto è una spesa ricorrente (abbonamento + credito per documento), il bridge su misura è una spesa di sviluppo iniziale + manutenzione continua. Nel 2026 i numeri sono variabili e cambiano a seconda del fornitore e dei volumi; legga quindi quanto segue non come prezzi esatti, ma come fasce di mercato approssimative.
- Credito (unità digitale consumata per documento): in genere si spende circa 1 credito per ogni documento in uscita (alcuni fornitori addebitano anche quelli in entrata). Secondo i dati comparativi di mercato del 2026, il prezzo unitario del credito presso i fornitori più diffusi è in media di circa 0,75–1,50 lire turche a documento; presso gli integratori enterprise collegati all'ERP può essere più alto a documento (vengono riportate cifre di circa 5–10 lire turche) (Faturaport — prezzi dei crediti 2026 (non è un listino ufficiale)). Non sono prezzi ufficiali dei fornitori, ma un confronto di mercato riferito a una data precisa.
- Abbonamento: la guida ai costi 2026 di Faturaport indica fasce di abbonamento su base annuale (per esempio: solo fattura elettronica circa 300–1.500 TRY/anno; PMI circa 1.500–6.000 TRY/anno; grandi aziende circa 6.000–50.000+ TRY/anno, su preventivo); si aggiungono i costi ricorrenti dei certificati di sigillo fiscale/firma elettronica (Faturaport — guida ai costi della fatturazione elettronica 2026 (non è un listino ufficiale)). Anche queste fasce sono approssimative e dipendono dal fornitore.
- Sensibilità ai volumi: poiché crediti e abbonamenti crescono con i volumi, un picco da campagna o da Black Friday fa salire direttamente il consumo di crediti e può avvicinarla alle soglie di volume o ai limiti.
Un bridge su misura sostituisce questo modello ricorrente con sviluppo iniziale + manutenzione continua: voci come i cambi di versione delle API, la logica di retry e code e i disallineamenti di sincronizzazione generano costi nel tempo. Non si concentri sul memorizzare il prezzo unitario, ma sul capire il meccanismo: se il suo volume di documenti è grande e prevedibile, la voce ricorrente dei crediti può finire per superare il costo di sviluppo iniziale + manutenzione; se il volume è basso o la sua piattaforma è già supportata, un connettore pronto è molto più economico. Valutare il quadro generale insieme alla logica del nostro articolo su software su misura e software standard chiarisce questo compromesso.
Come La aiuta Partnerfy
Come software house B2B / white-label con sede a Sakarya, trattiamo questa decisione non come una «promessa», ma come un processo: prima individuiamo in quale casella rientra il suo negozio (piattaforma SaaS in elenco, soluzione su misura o basata su codice proprio, oppure con regole di business specifiche), poi mappiamo i cinque flussi (giacenze/prezzi/ordini/fatture/resi) e infine posizioniamo correttamente un connettore pronto oppure scriviamo un bridge API su misura con idempotenza e flusso dei resi impostati come si deve. Per le agenzie consegniamo questo bridge con il loro marchio, in modello white-label; per le grandi aziende uniamo piattaforme e-commerce e soluzioni CRM ed ERP in un unico flusso osservabile.
Diciamolo con franchezza: nessun bridge può garantire di azzerare i crediti o che le norme della GİB non cambieranno mai; sono variabili esterne. La nostra promessa non è una garanzia, ma una base solida: un'architettura che emette ogni fattura esattamente una volta, modella i resi con un documento separato, non trascura il rinnovo dei token e i retry e regge i picchi di volume. Anche i progetti con una base di codice propria, regole di business particolari o una linea ERP inattesa rientrano nel nostro software web su misura.
Conclusioni
In un bridge e-commerce ↔ ERP ↔ fatturazione elettronica, la domanda giusta non è «quale sia migliore», ma «in quale casella rientra il mio negozio». Se si trova su una piattaforma SaaS in elenco e i suoi flussi sono standard, di solito basta un connettore pronto, a patto di accettare il costo ricorrente di abbonamento + crediti. Se ha un negozio su misura o basato su codice proprio, oppure regole di business specifiche, un bridge API su misura non è un lusso, ma una necessità. In entrambi i casi, la fatturazione elettronica non è un lavoro di OCR, ma di XML UBL-TR; modellare correttamente l'idempotenza e il flusso dei resi non è negoziabile. Se non sa da dove iniziare, ci contatti: classificheremo il suo negozio e prepareremo per Lei una decisione personalizzata «connettore pronto o bridge su misura» e un confronto tra forme di costo.
Fonti
- GİB — Integrazione privata (i tre metodi e-Fatura e la definizione ufficiale)
- GİB — Portale e-Belge (e-Fatura/e-Arşiv) e pacchetto e-Fatura (schemi UBL-TR)
- Paraşüt — Documentazione API ufficiale (OAuth2, v4, e_invoices/e_archives, endpoint PDF, enum di stato)
- Logo — Strumenti di personalizzazione Netsis / NetOpenX Rest API
- Entegra — Integrazione e-commerce (sistemi ERP + elenco delle piattaforme)
- Sentos — Integrazione e-commerce B2C (elenco fisso di piattaforme)
- İkas — Integrazioni con contabilità di base ed ERP
- IdeaSoft — Integrazione Mikro (polling ogni 15 minuti circa, livello di web service)
- Faturaport — Prezzi dei crediti 2026 (confronto di mercato, non è un listino ufficiale)
- Faturaport — Guida ai costi della fatturazione elettronica 2026 (fasce di abbonamento annuali, non è un listino ufficiale)
- Paraşüt — Annullamento e-Arşiv o fattura di reso (concettuale)