--- title: "Changing accounting software without losing invoice identity" canonical: https://www.billabex.com/en/blog/accounting-software-migration-invoice-identity/ lang: en alternate: https://www.billabex.com/fr/blog/changement-logiciel-comptable-identite-factures.md updated: 2026-10-07 index: https://www.billabex.com/llms.txt --- # Changing accounting software without losing invoice identity The new accounting system shows the right invoices and the right customer name. Yet the next reminder asks for money that has already been partly paid. During the migration, an invoice became a new record while its payment and credit note remained attached to the old one. The commercial document survived; continuity of the collection case did not. Before restarting reminders, answer a specific question: which record in the new system carries forward each receivable previously followed, with what balance and which commitments? Comparing imported row counts cannot answer it. For a business operating in France, the following approach brings accounting continuity and customer conversations into the same migration review without assuming that one export contains everything. ## Make the relationship between systems explicit The reference printed on an invoice, an internal database identifier and an identifier used by an integration serve different purposes. Changing accounting software can change the last two without creating a new commercial invoice. Record that distinction in the migration file, together with the issuing legal entity and the customer involved. Odoo 18 documents using an external identifier from the previous application to reconstruct relationships. It also warns that changing or removing that identifier during an update can create a duplicate. This is documented behaviour for that product; the corresponding behaviour must be checked in the chosen system. [Odoo documentation on imports and identifiers](https://raw.githubusercontent.com/odoo/documentation/18.0/content/applications/essentials/export_import_data.rst). Your mapping might therefore connect “old case A17” to “new case 803”. Retain the source of that connection, its validation date and the person who checked it. Simply matching the number 17 because it exists in both applications is unsafe: the new 17 may represent a completely different receivable. The method for [checking invoices that share a number](https://www.billabex.com/en/blog/duplicate-invoice-numbers-legal-entities/) helps establish commercial identity before making this technical connection. ## Carry forward an explainable balance Consider an entirely simulated example with three invoices issued by the same company, all denominated in euros. Amounts include applicable taxes. The payments and credit note below have been approved and allocated to the correct documents before the transition. | Invoice | Original amount | Allocated payments | Allocated credit note | Balance to carry forward | | --------- | --------------: | -----------------: | --------------------: | -----------------------: | | F2026-101 | €6,000 | €2,000 | €600 | €3,400 | | F2026-102 | €3,500 | €3,500 | €0 | €0 | | F2026-103 | €4,200 | €0 | €0 | €4,200 | | Total | €13,700 | €5,500 | €600 | €7,600 | An import limited to open invoices may legitimately contain two documents. However, importing their original amounts produces €10,200 instead of the €7,600 actually outstanding in this example. The €2,600 difference consists exactly of the €2,000 payment and the €600 credit note omitted from the first invoice. Two rows in the old export and two rows in the new system are therefore insufficient acceptance evidence. Request the calculation behind each balance. Depending on the accounting approach approved for the migration, the new application may carry forward transaction histories or opening balances. Those different presentations must remain reconcilable without subtracting movements a second time when they are already included. The settled invoice deserves a test too. It should no longer generate a reminder, but its old reference should still lead to evidence of payment. The process for [investigating an unallocated credit note](https://www.billabex.com/en/blog/unallocated-credit-note-balance-check/) explains why this review must reach the underlying movements rather than stop at a displayed status. ## Establish when the figures are comparable An export taken at 6 pm on Monday can legitimately differ from a review at noon on Tuesday. A payment may have arrived in between. Define a dated reference position, then identify separately the transactions occurring after that position was captured. Suppose invoice F2026-103 receives a further €1,200 payment after the export. The initial migration check still concerns €4,200. Once the new transaction has been incorporated, the expected balance becomes €3,000 and the portfolio total becomes €6,400. A comparison without a time reference may treat this normal change as an error, prompting someone to remove or count the payment twice. The person responsible for the transition must be able to explain where each movement received during that period appears. An explicit checkpoint is more useful than assuming business activity can become perfectly still. Customers continue paying, colleagues receive replies and finance approves corrections. The precautions used for a [delayed accounting synchronisation](https://www.billabex.com/en/blog/delayed-accounting-sync-pause-reminders/) remain relevant throughout this transition. Choose the transition boundary with the accountant and implementation team. A transaction date, an entry date and the time an integration received an update can differ. The reconciliation should say which reference it uses, so two teams do not silently compare different populations while both describe their figures as current. ## Test what the ledger does not explain A receivable of €3,400 can have a correct balance and an incorrect next action. The customer may have promised to pay on Friday or requested evidence your team agreed to provide. An accounting import does not necessarily carry those facts across. For every sampled case, open the conversation from the new reference. Find the last useful message, its author, the document being discussed and the next agreed action. Check that a justified pause remains understandable. An empty field in the new application does not establish that the old case had no unresolved issue. Include a partly paid invoice, a settled invoice, a credit note, a payment covering several documents and a disputed case. Add the unusual situations actually present in your portfolio. This sample tests how situations are handled; it does not replace reconciliation of totals and mappings across the complete migrated population. Merged customer accounts or newly split balances require specific review instead of an artificial one-to-one row match. Ask a colleague who did not prepare the mapping to follow one selected case from start to finish. If they need the migration specialist to interpret every screen, the handover remains incomplete. Record the missing explanation while the old system and its knowledgeable users are still available. ## Separate collection continuity from accounting obligations French tax guidance expressly addresses migration during a financial year. Paragraph 400 allows two accounting entry files under conditions when a single file cannot be produced. A changed accounting reference framework requires mapping and reconciliation tables. This tax framework is not a specification for exporting customer conversations. [DGFiP guidance, BOI-CF-IOR-60-40-20, VII-A](https://bofip.impots.gouv.fr/bofip/9028-PGP.html/identifiant=BOI-CF-IOR-60-40-20-20170607). The operational implication is nevertheless useful: ending a subscription should not make the accounts unintelligible. Have the accountant approve the accounting arrangements, then organise access to the supporting material needed for cases still being followed. A readable archive and a live collection queue serve different purposes, even when they refer to the same invoice. For French commercial companies, Service Public states that accounting records and supporting documents must be retained for at least ten years from the financial year end. That period applies to those records; it does not require indiscriminate retention of every message and item of personal information in every application. [Accounting obligations for a commercial company](https://entreprendre.service-public.gouv.fr/vosdroits/F37169?lang=fr). ## Restart reminders against concrete evidence A useful acceptance demonstration finds an old invoice, explains its new balance, opens the supporting documents and shows the expected next action. Keep a dated exception list with an owner and the consequences for outgoing reminders. An unreconciled case should not default to a confident demand for payment. [Billabex integrations](https://www.billabex.com/en/product/integrations/) provide a starting point for discussing the accounting system your business actually uses. Before migrating, ask how continuity of existing cases will be recognised and test your own examples. Success is observable: following the software change, the customer receives a coherent conversation and an amount whose components your team can explain. ## Sources - Odoo 18, import documentation covering external identifiers and relationships, accessed 7 September 2026. - DGFiP, BOI-CF-IOR-60-40-20 dated 7 June 2017, paragraph 400, accessed 7 September 2026. - Service Public Entreprendre, accounting obligations of a commercial company, retention section, accessed 7 September 2026.