--- title: "Rata pagata in parte: riallineare il piano di pagamento nel quadro francese" canonical: https://www.billabex.com/it/blog/rata-parzialmente-pagata-piano-di-pagamento/ lang: it alternate: https://www.billabex.com/fr/blog/echeance-partiellement-payee-echeancier.md alternates: fr: https://www.billabex.com/fr/blog/echeance-partiellement-payee-echeancier.md en: https://www.billabex.com/en/blog/partly-paid-instalment-payment-schedule.md de: https://www.billabex.com/de/blog/teilweise-bezahlte-faelligkeit-zahlungsplan.md es: https://www.billabex.com/es/blog/vencimiento-pagado-en-parte-ajustar-plan-de-pagos.md it: https://www.billabex.com/it/blog/rata-parzialmente-pagata-piano-di-pagamento.md nl: https://www.billabex.com/nl/blog/deels-betaalde-termijn-betalingsregeling.md pl: https://www.billabex.com/pl/blog/czesciowo-zaplacona-rata-aktualizacja-harmonogramu.md pt: https://www.billabex.com/pt/blog/prestacao-parcialmente-paga-plano-pagamento.md updated: 2026-10-14 index: https://www.billabex.com/llms.txt --- # Rata pagata in parte: riallineare il piano di pagamento nel quadro francese Il cliente doveva pagare 3.000 € e ne versa 1.800. La contabilità registra correttamente l’incasso, ma lo strumento di sollecito contrassegna l’intera rata come «pagata». Altrove, qualcuno sposta il calendario di un mese per far sparire l’avviso. In entrambi i casi, il saldo complessivo può restare corretto mentre il monitoraggio degli impegni diventa errato. Dopo un pagamento parziale, la priorità è distinguere il residuo della rata interessata, le somme previste più avanti e un’eventuale richiesta di modifica. L’importo ricevuto è un fatto. Lo spostamento del calendario è un’altra decisione. Trattarli separatamente permette di ringraziare il cliente per il versamento e di chiedere con precisione quanto manca. I passaggi giuridici di questo articolo si riferiscono alla Francia, senza adattamento al diritto italiano. ## Ripartire dall’accordo effettivamente applicabile Un piano di pagamento può descrivere le scadenze iniziali di una fattura oppure un accordo successivo per gestire un credito già scaduto. La differenza conta: la tabella di monitoraggio non deve trasformare automaticamente un accordo di recupero crediti in nuove condizioni di fatturazione. Conserva il contratto, l’accordo di pagamento applicabile e le scadenze originarie necessarie per comprendere la pratica. La documentazione Odoo 18 distingue le condizioni di pagamento della stessa fattura dall’emissione di più fatture di acconto. Descrive anche righe contabili separate per data di scadenza. Questa distinzione tecnica mostra perché un solo saldo sullo schermo non basta a capire quale parte sia attesa a quale data. [Odoo, condizioni e piani di pagamento](https://raw.githubusercontent.com/odoo/documentation/18.0/content/applications/finance/accounting/customer_invoices/payment_terms.rst). Prima di correggere i dati, ritrova gli importi concordati, le date e le fatture comprese nell’accordo. Verifica poi gli eventi intervenuti successivamente: bonifici, note di credito, rimborsi o annullamenti. Un piano costruito a partire da una vecchia esportazione può già includere una somma non più dovuta. Non ricreare il calendario guardando soltanto il saldo odierno: perderesti la distinzione tra quanto era previsto e quanto è effettivamente accaduto. ## Un esempio con 7.200 € ancora aperti, ma non tutti scaduti Ecco una simulazione senza interessi, spese o note di credito. Una fattura di 9.000 € prevede fin dall’origine tre rate concordate: 3.000 € il 7 ottobre, 3.000 € il 7 novembre e 3.000 € il 7 dicembre. Il cliente versa 1.800 € il 7 ottobre, indicando chiaramente la prima rata. Esaminiamo la pratica il 14 ottobre. | Scadenza concordata | Importo previsto | Pagamento imputato | Residuo da monitorare al 14 ottobre | | ------------------- | ---------------: | -----------------: | ----------------------------------: | | 7 ottobre | 3.000 € | 1.800 € | 1.200 € in ritardo | | 7 novembre | 3.000 € | 0 € | 3.000 € da scadere | | 7 dicembre | 3.000 € | 0 € | 3.000 € da scadere | | Totale | 9.000 € | 1.800 € | 7.200 € | La prima rata è coperta al 60 %, perché 1.800 / 3.000 = 0,60. L’intera fattura è coperta al 20 %, perché 1.800 / 9.000 = 0,20. Le due percentuali rispondono a domande diverse. Nessuna giustifica la dichiarazione che la prima rata sia interamente pagata. L’importo da spiegare subito al cliente è, in questo caso, 1.200 €, dopo aver verificato l’accordo e i movimenti recenti. Chiedere tutti i 7.200 € come se fossero già in ritardo contraddirebbe le date della simulazione. Al contrario, nascondere i 1.200 € nella rata successiva cancellerebbe lo scostamento senza una decisione. Il saldo di fattura e il ritardo sulla singola rata devono quindi restare visibili insieme: descrivono la stessa pratica da due prospettive diverse. ## Verificare l’imputazione prima di parlare di rata non rispettata L’estratto conto bancario conferma un incasso, ma la sua presenza non basta a determinare quale rata venga pagata. Il cliente potrebbe aver saldato un’altra fattura o inviato più bonifici. Nella simulazione, l’imputazione alla prima rata è esplicitamente nota. In una pratica reale, devi ricostruirla prima di applicare lo stesso calcolo. La documentazione Microsoft Dynamics 365 illustra il trattamento di un pagamento parziale senza sconto per pagamento anticipato: la fattura resta aperta con un saldo. Lo distingue dalle opzioni che chiudono una differenza secondo la configurazione. La separazione è utile quando controlli un connettore o un’esportazione: uno stato di chiusura può derivare da una regola contabile, anziché da un incasso integrale. È un riferimento al funzionamento di Dynamics 365, non la prova di un connettore nativo Billabex: un eventuale collegamento deve essere qualificato con l’assistenza necessaria. [Microsoft, pagamenti parziali dei clienti, aggiornamento del 4 agosto 2026](https://learn.microsoft.com/en-us/dynamics365/finance/accounts-receivable/customer-payments-partial-amount). Verifica anche che un [bonifico riferito a più fatture](https://www.billabex.com/it/blog/un-bonifico-piu-fatture-evitare-solleciti-errati/) non sia stato imputato arbitrariamente. Un totale corretto sul conto cliente non garantisce l’esattezza delle singole scadenze. Anche una nota di credito approvata richiede un’imputazione distinta dal pagamento ricevuto. Quando la destinazione di un versamento non è chiara, conserva il fatto dell’incasso e risolvi l’abbinamento: non scegliere una rata soltanto per eliminare l’avviso più vecchio. ## Ricevere una somma non significa accettare ogni rinvio In Francia, l’articolo 1342-4 del Code civil prevede che il creditore possa rifiutare un pagamento parziale. Il principio non esonera dal considerare un frazionamento già concordato, né dall’esaminare le circostanze di un versamento ricevuto. Non devi dedurne un’istruzione automatica di rimborso di ogni somma insufficiente. [Code civil francese, articolo 1342-4](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000032035243). La modifica del contratto richiede, in linea di principio, il consenso reciproco secondo l’articolo 1193, salvo le cause previste dalla legge. Il semplice cambiamento di una casella nel software non basta a stabilire questo accordo. [Code civil francese, articolo 1193](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000032041314). Il team può quindi confermare la ricezione dei 1.800 € e chiedere come il cliente intenda pagare i 1.200 € mancanti. Se propone il 20 ottobre, registra prima la proposta e il suo stato. Una volta confermato l’accordo dalle persone competenti, il monitoraggio può mostrare questo versamento a copertura dell’arretrato senza spostare le scadenze di novembre e dicembre. I piani negoziati e le loro modifiche restano decisioni umane: registrare una proposta serve a preparare la decisione, non a sostituirla. Il metodo per individuare [chi può approvare una proroga](https://www.billabex.com/it/blog/chi-approva-proroga-pagamento-software-solleciti/) evita che una correzione amministrativa diventi una concessione non esaminata. Una clausola sulle conseguenze di una rata non rispettata va riletta nel suo contesto prima di agire; non giustifica un messaggio standard secondo cui tutto il saldo sarebbe immediatamente esigibile. ## Aggiornare la previsione senza contare due volte l’arretrato Nel nostro esempio, il pagamento dei 1.200 € arretrati al 20 ottobre, se accettato e poi effettivamente incassato, lascerà 6.000 € da ricevere alle due date successive. La previsione deve quindi contenere 1.200 € in ottobre, 3.000 € in novembre e 3.000 € in dicembre, con il livello di fiducia appropriato prima dell’incasso. Un’altra proposta potrebbe trasferire l’arretrato su novembre: 4.200 € e poi 3.000 €. Questo scenario mantiene il totale di 7.200 €, ma cambia lo sforzo richiesto al cliente e il calendario di liquidità. Devi distinguerlo dal primo, senza lasciare contemporaneamente una riga di 1.200 € in ottobre per lo stesso arretrato. Altrimenti la previsione raggiungerebbe erroneamente 8.400 €. Confrontare scenari diversi non significa sommarli: soltanto quello adottato deve alimentare il calendario operativo, mantenendo riconoscibile l’accordo precedente. Il monitoraggio delle [promesse nelle previsioni di liquidità](https://www.billabex.com/it/blog/previsioni-liquidita-fiducia-promesse-pagamento/) aiuta a conservare la separazione tra proposta, accordo e denaro incassato. Dopo ogni versamento, riconcilia l’importo ricevuto, riduci la rata corretta e riesamina la prossima azione. Un singolo pagamento parziale non deve chiudere la pratica né creare un nuovo credito fittizio. Per preparare una dimostrazione del [monitoraggio delle promesse con Billabex](https://www.billabex.com/it/prodotto/promesse-di-pagamento/), porta un caso con una rata incompleta e un’altra ancora da scadere. Fai verificare l’importo atteso, il contesto comunicato al cliente e la reazione dopo la riconciliazione. Il valore del monitoraggio si misura nella capacità di conservare queste distinzioni nel lavoro quotidiano. ## Fonti - Odoo 18, _Payment terms and installment plans_, sezioni iniziali e scritture contabili. - Microsoft Dynamics 365, _Customer payments for a partial amount_, 4 agosto 2026. - Code civil francese, articoli 1342-4 e 1193, versioni dal 1° ottobre 2016. Fonti consultate il 7 settembre 2026.