--- title: "An instalment is partly paid: keeping the payment schedule accurate" canonical: https://www.billabex.com/en/blog/partly-paid-instalment-payment-schedule/ lang: en alternate: https://www.billabex.com/fr/blog/echeance-partiellement-payee-echeancier.md updated: 2026-10-14 index: https://www.billabex.com/llms.txt --- # An instalment is partly paid: keeping the payment schedule accurate The customer was expected to pay €3,000 and sends €1,800. Accounting records the receipt correctly, but the collections view marks the entire instalment as paid. Elsewhere, someone moves the schedule back a month to remove the alert. In either case, the overall balance can remain correct while the record of commitments becomes misleading. Following a partial payment, separate the unpaid portion of the affected instalment, amounts scheduled for later and any proposed change to the arrangement. Receipt of money is a fact. Rescheduling is a separate decision. Keeping them distinct allows the team to acknowledge the payment and ask a precise question about the shortfall. This approach applies to operational follow-up in France and Europe. The legal references below concern French law; contracts governed elsewhere require their own review. ## Start with the arrangement that actually applies A schedule can represent an invoice's original payment dates or a later arrangement for collecting an already overdue debt. The distinction matters. A collections table should not automatically turn a recovery arrangement into new invoicing terms. Retain the contract, the applicable payment agreement and the original dates needed to understand the case. Odoo 18 documentation distinguishes payment terms for one invoice from issuing several down-payment invoices. It also describes separate accounting items for individual due dates. That technical distinction explains why a single balance on screen is insufficient to establish which portion is expected when. [Odoo payment terms and instalment plans](https://raw.githubusercontent.com/odoo/documentation/18.0/content/applications/finance/accounting/customer_invoices/payment_terms.rst). Before changing anything, identify the agreed amounts, dates and invoices covered. Then check subsequent transfers, credit notes, refunds or cancellations. A schedule based on an old export may already contain an amount that is no longer owed. ## An example with €7,200 open, but not all overdue The following simulation excludes interest, fees and credit notes. A €9,000 invoice has three instalments agreed from the outset: €3,000 on 7 October, €3,000 on 7 November and €3,000 on 7 December. The customer sends €1,800 on 7 October with an explicit reference to the first instalment. We inspect the case on 14 October. | Agreed due date | Scheduled amount | Allocated receipt | Position on 14 October | | --------------- | ---------------: | ----------------: | ---------------------: | | 7 October | €3,000 | €1,800 | €1,200 overdue | | 7 November | €3,000 | €0 | €3,000 scheduled later | | 7 December | €3,000 | €0 | €3,000 scheduled later | | Total | €9,000 | €1,800 | €7,200 open | The first instalment is 60% covered because €1,800 divided by €3,000 equals 0.60. The invoice as a whole is 20% covered because €1,800 divided by €9,000 equals 0.20. These percentages answer different questions. Neither supports describing the first instalment as fully paid. The amount to clarify immediately is €1,200, subject to checking the agreement and recent transactions. Demanding all €7,200 as overdue would contradict the dates in this simulation. Moving the €1,200 into the next instalment without an agreement would instead hide the observed shortfall. The useful customer message acknowledges the €1,800 receipt, identifies the remaining €1,200 for October and asks for clarification. It should not imply that November's and December's amounts were also missed. ## Check allocation before declaring a missed instalment A bank transaction establishes that money arrived, but it does not necessarily identify the instalment paid. The customer may have paid another invoice or sent several transfers. In our simulation, allocation to the first instalment is explicitly known. In a real case, that fact must be established before the same calculation is applied. Microsoft Dynamics 365 documentation describes a partial payment without a discount as leaving the invoice open with a balance. It distinguishes that treatment from configuration options that settle a difference. This helps when reviewing an integration or export: a closed status can reflect an accounting rule rather than full cash receipt. [Microsoft customer payments for a partial amount, updated 4 August 2026](https://learn.microsoft.com/en-us/dynamics365/finance/accounts-receivable/customer-payments-partial-amount). Also check whether [one transfer covering several invoices](https://www.billabex.com/en/blog/one-payment-multiple-invoices/) has been allocated arbitrarily. A correct total for the customer account does not establish that each instalment is accurate. A valid credit note should likewise remain distinguishable from cash received. A team member investigating the discrepancy needs both the receipt reference and the schedule reference. Keeping them together avoids repeated requests for information the business already possesses. ## Receiving money does not automatically approve every extension Article 1342-4 of the French Civil Code allows a creditor to refuse a partial payment. That principle does not remove an instalment arrangement already agreed or the need to examine the circumstances of a receipt. It should not be turned into an automatic instruction to refund every insufficient payment. [French Civil Code, article 1342-4](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000032035243). Article 1193 establishes mutual consent as the principle for modifying a contract, subject to legally authorised grounds. Changing a software field alone does not establish that consent. [French Civil Code, article 1193](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000032041314). The team can acknowledge €1,800 and ask how the customer proposes to address the missing €1,200. If the customer proposes 20 October, record the proposal and its current status first. Once the appropriate people confirm the agreement, track that catch-up payment while retaining the November and December dates. Identifying [who may approve an extension](https://www.billabex.com/en/blog/payment-extension-approval-collections-tool/) prevents an administrative correction from becoming an unexamined concession. Any clause addressing a missed instalment needs to be reviewed in context before action. Its existence does not justify a standard message automatically claiming the entire balance is immediately payable. ## Update the forecast without counting the shortfall twice In our example, a €1,200 catch-up payment on 20 October, if accepted and subsequently received, leaves €6,000 for the two later dates. Before receipt, the forecast should therefore contain €1,200 in October, €3,000 in November and €3,000 in December, with appropriate confidence attached to the expected receipts. An alternative proposal might move the shortfall into November: €4,200 followed by €3,000. That still totals €7,200 but changes the customer's payment burden and the cash timetable. Keep it separate from the first scenario. Leaving an additional €1,200 catch-up line in October would incorrectly forecast €8,400. The approach to [payment promises in cash forecasts](https://www.billabex.com/en/blog/cash-forecast-payment-promises-confidence/) preserves the distinction between a proposal, an agreement and cash. After each receipt, reconcile the amount, reduce the appropriate instalment and reassess the next action. One partial payment should neither close the case nor create a fictitious additional receivable. For a demonstration of [payment-promise tracking with Billabex](https://www.billabex.com/en/product/payment-promises/), bring a case containing an incomplete instalment and another that is still scheduled for later. Check the expected amount, the context used in the customer message and what happens after reconciliation. The practical value lies in maintaining these distinctions during everyday follow-up. ## Sources - Odoo 18, _Payment terms and installment plans_, introductory and journal-entry sections. - Microsoft Dynamics 365, _Customer payments for a partial amount_, 4 August 2026. - French Civil Code, articles 1342-4 and 1193, versions effective from 1 October 2016. Sources consulted on 7 September 2026.