MCP per la finanza non basta: perché collegare un LLM al tuo ERP continua a sbagliare i calcoli

Un controller collega un server Model Context Protocol a NetSuite, chiede all’IA il margine lordo trailing-twelve-month per segmento, e ottiene una risposta in quattro secondi. Il numero è sbagliato di 90 punti base. Non perché l’IA non riuscisse a raggiungere i dati: li ha raggiunti perfettamente. Ha estratto i conti di mastro giusti, i periodi giusti, le entità giuste. Poi ha fatto la divisione da sola, nello spazio dei token, e ha silenziosamente sbagliato il segno su un conto di ricavi in contropartita.

Questa è la trappola in cui MCP fa cadere i team finance. Collegarsi sembra la parte difficile, quindi una volta aperto il tubo il lavoro sembra fatto. Non lo è. Il recupero dei dati è un problema risolto. La matematica no.

Cosa risolve davvero MCP

Diamo a MCP il merito che gli spetta. Anthropic ha introdotto il protocollo a fine 2024 come standard aperto per collegare i modelli a strumenti e dati esterni, e con la specifica di novembre 2025 ha acquisito denti veri: definizioni strutturate degli strumenti, esecuzione concorrente degli strumenti, tracciamento delle attività per lavori di lunga durata, e flussi mediati dal browser così un client non deve mai custodire credenziali grezze. Microsoft distribuisce un server MCP per Dynamics 365 Finance and Operations. Esistono server MCP per dati di mercato, per piattaforme contabili, per data warehouse.

Il vero vantaggio è la governance. Prima di MCP, “collega l’IA al nostro ERP” significava di solito un’integrazione custom fragile, una chiave API con permessi troppo ampi, e nessuna traccia di cosa il modello avesse toccato. MCP standardizza quell’accesso: un protocollo, capacità dichiarate, permessi limitati, una superficie verificabile. Se l’alternativa era incollare un export CSV in un chatbot, MCP è un salto di qualità serio su fuga di dati e spiegabilità.

Quindi quando un fornitore dice “siamo nativi MCP”, credete che abbia risolto l’idraulica. Solo non lasciate che quell’affermazione si espanda silenziosamente in “e quindi i numeri sono corretti”. Sono due frasi diverse.

Le due cose che MCP non ti dà

Ecco il divario, detto chiaramente. MCP è un livello di trasporto e accesso. Sposta il contesto verso il modello ed espone strumenti che il modello può chiamare. Non dice nulla su due problemi che decidono se una risposta finanziaria è affidabile.

Non riconcilia. Ciò che torna attraverso una connessione MCP sono dati di mastro grezzi. Righe di prima nota, saldi contabili, tag dimensionali, entità multiple ciascuna con il proprio piano dei conti, scritture infragruppo non ancora eliminate, una cifra di ricavo nel mastro che non quadra con quella nel sottomastro di fatturazione. MCP consegna al modello una copia fedele del disordine. A quel punto il modello deve decidere quale “ricavo” sia quello reale, se nettare la riga infragruppo, come mappare quattro piani dei conti di entità diverse su un’unica definizione di margine lordo. Questo non è recupero dati. È giudizio contabile, e un LLM lo improvvisa in modo diverso martedì rispetto a lunedì.

Non calcola in modo deterministico. Anche con input puliti, un LLM connesso via MCP fa comunque l’aritmetica nell’unico modo in cui un LLM può farla: prevedendo il token successivo. I benchmark sono espliciti su dove questo porta. I modelli migliori si fermano intorno all’82% sui compiti di foglio di calcolo finanziario e a circa il 90% sulle domande e risposte finanziarie. Un tasso di risposta del 90% sembra accettabile finché non si ricorda che significa una cifra sbagliata su dieci, senza alcun segnale su quale. Il protocollo ha spostato i dati giusti nel prompt e poi ha lasciato il calcolo al componente meno affidabile dello stack.

Puoi dare a un LLM una situazione contabile impeccabile via MCP e ottenere comunque un margine sbagliato, perché il fallimento non è nel percorso dei dati. È nella matematica.

”Basta dargli uno strumento calcolatrice”

L’obiezione ovvia: MCP supporta il tool calling, quindi esponi uno strumento calculate e l’LLM smette di fare aritmetica a mente. Metà giusta, e la metà giusta conta. Instradare l’operazione vera verso il codice invece che verso la previsione di token è esattamente l’istinto corretto.

Ma una semplice calcolatrice come strumento eredita il problema un livello più su. Il modello deve comunque scegliere cosa darle in pasto: quali conti, quali periodi, quali entità, se questa riga è già al netto dei resi. Selezione scadente in una calcolatrice perfetta produce comunque risultati scadenti. E gli strumenti costruiti ad hoc divergono nel tempo. La definizione di margine incorporata in una chiamata di strumento non coinciderà con quella che il modello assembla nella conversazione successiva, quindi due persone che fanno la stessa domanda ottengono due risposte e nessuna delle due può dimostrare quale sia corretta. Una calcolatrice senza un modello condiviso e riconciliato sottostante è solo un modo più veloce per essere incoerenti.

Cosa si mette tra il protocollo e la risposta

La soluzione non è rifiutare MCP. Usalo per ciò in cui è bravo e metti i livelli mancanti dove appartengono: tra la connessione e il modello linguistico.

Primo, un modello riconciliato. Un unico posto dove gli input disordinati e multi-fonte vengono mappati su definizioni concordate, le partite infragruppo vengono eliminate, le entità vengono consolidate, e ogni cifra quadra con il mastro. Questa è l’unica fonte di verità, ciò che un controller firmerebbe davvero. La definizione semantica di “margine lordo” vive qui una sola volta, non viene riderivata a ogni prompt.

Secondo, un motore deterministico. I calcoli girano come codice contro quel modello riconciliato, non come previsioni dentro l’LLM. Stessi input, stesso output, ogni volta, con un percorso di ritorno alla fonte. Il compito del modello si riduce a ciò in cui è davvero bravo: capire la domanda, scegliere la metrica pre-definita giusta, e spiegare il risultato in linguaggio semplice. Recupera e racconta. Non inventa il numero.

Questa è la divisione del lavoro su cui è costruito Rexfin. Collega le tue piattaforme contabili e di dati finanziari, oppure carica i bilanci. Costruiamo un modello riconciliato unico che quadra con il mastro. Poi l’IA recupera le cifre, esegue la matematica attraverso un motore deterministico, modella scenari di ipotesi (what-if), e produce insight tracciabili alla fonte. MCP può essere una delle porte da cui entrano i dati. Non è un sostituto del modello e del motore dietro quella porta.

Se sei più a monte nell’architettura, un foglio di calcolo è la fondazione sbagliata su cui costruire tutto questo per lo stesso motivo: collegare un’IA a una base viziata automatizza semplicemente il vizio. E lo standard su cui un consiglio di amministrazione ti giudicherà è più affilato di “ha risposto”: è se il numero è ripercorribile, dimostrabile come lo è una formula. Il quadro più ampio per trattare la modellazione finanziaria affidabile come un livello a sé stante è delineato in il pilastro.

In sintesi

MCP risponde a “l’IA può raggiungere i nostri numeri?”. Non risponde a “i numeri sono corretti?”. Sono le uniche due domande a cui un CFO tiene, e un fornitore che risolve la prima lasciando intendere di aver risolto anche la seconda ti sta vendendo fiducia, non accuratezza. Insisti sulla seconda. Chiedi dove avviene la riconciliazione e dove gira l’aritmetica. Se le risposte sono “ci pensa l’LLM”, hai un tubo veloce verso un numero sbagliato.

Vedi l’architettura modello-riconciliato-più-motore-deterministico applicata ai tuoi dati disordinati: prenota una demo.