Comptabilité Odoo 20 : ce qui change pour une société française, écran par écran

Odoo 20 est sorti en octobre 2026. Pour la Comptabilité, le changement de numéro cache une refonte plus large que les versions précédentes : les immobilisations, les relances, le rapprochement bancaire, la liasse fiscale et le plan comptable français ne se paramètrent plus comme en 19. Un cabinet ou un service comptable qui prépare une montée de version a besoin de savoir où regarder avant de cocher « mettre à jour ».

J'ai comparé les sources des deux versions, module par module, le 15 octobre 2026, puis j'ai monté une société française fictive, « Cycles Demo », sur une instance Odoo 20.0 Enterprise hébergée par akolio : plan comptable des sociétés, factures, relevé bancaire, immobilisations, emprunt, budget. Les captures de cet article viennent de cette instance. Le panorama complet, 72 pages et 113 écrans, est en bas de l'article ; voici les dix points qui changent le quotidien d'un comptable.

1. Le plan comptable français se choisit, et se hiérarchise autrement

En 19, la localisation française livrait un plan unique. En 20, l'installation propose deux plans : celui des sociétés (fr_comp, 670 comptes) et celui des associations (fr_asso, 504 comptes, avec la classe 8 des contributions volontaires en nature). Les comptes arrivent avec leur description, leurs taxes par défaut et, pour vingt-cinq d'entre eux, un modèle d'amortissement déjà relié.

Le changement qui se voit le moins et coûte le plus : les groupes de comptes disparaissent. La hiérarchie des rapports (bilan, grand livre) passe désormais par un compte parent posé sur chaque compte. Le plan livré n'en pose aucun. Une base qui tenait ses regroupements par groupes de comptes perd sa hiérarchie à la montée de version, sans message.

Deuxième point à préparer : les bilans et comptes de résultat français ne s'affichent que pour une société dont le plan est exactement fr_comp. Une base migrée reste sur le plan fr de la 19, et aucun script ne la bascule. Le choix du modèle de plan fait partie du projet de migration.

2. Le SIRET change de case

Le champ « N° de société » n'existe plus sur les contacts. Le SIRET, le SIREN, le GLN et l'identifiant de facturation électronique se saisissent dans une liste d'identifiants additionnels, typés et contrôlés. Le SIREN se déduit du SIRET. Ces identifiants alimentent le pied de page des documents, les mentions « SIRET » et « SIREN » de la facture, Chorus Pro, la plateforme agréée, la DEB et le FEC.

Là encore, pas de migration automatique : le SIRET saisi en 19 dans l'ancien champ ne se retrouve pas dans les identifiants. À reprendre pour la société, et pour chaque client public facturé par Chorus Pro, sinon l'envoi échoue.

3. Les taxes TTC ont disparu

La localisation française passe de 67 à 48 taxes. Les dix-neuf taxes « TTC », celles dont le prix saisi incluait la TVA, ne sont plus livrées. À la place, chaque facture porte un sélecteur HT / TTC sur son onglet de lignes, et le réglage de la société se modifie à tout moment, même après les premières factures (la 19 le verrouillait). Les notes de frais et les tickets de caisse saisis en TTC passent par ce sélecteur, ou par une taxe créée à la main.

Les comptes de TVA à payer et à récupérer quittent les groupes de taxes pour le type de déclaration : c'est là qu'on les reparamètre après migration.

4. Les paiements ne disent plus la même chose

C'est le piège le plus sournois. En 19, un paiement passait par « En cours » puis « Payé ». En 20, les états s'appellent Paid puis Reconciled. Un paiement « Paid » de la 20 est un paiement « En cours » de la 19 : comptabilisé, pas encore rapproché de la banque. Tout filtre, rapport, export ou automatisation qui testait l'état change de sens sans erreur.

En contrepartie, l'assistant de paiement déduit ce qui est déjà payé mais pas encore rapproché, et le dit : fini le double règlement d'une facture réglée la veille par virement. Un nouveau champ « Transaction ID » porte la référence de l'opération et sert au rapprochement automatique.

5. La banque : relevés brouillons, règles de correspondance, import par e-mail

Trois nouveautés sur le rapprochement bancaire.

Un relevé saisi à la main naît en brouillon et ses écritures ne sont comptabilisées qu'avec lui. Sur un journal de caisse ou de carte scellé, un relevé validé ne repasse plus en brouillon.

Les règles de correspondance s'ajoutent aux modèles de rapprochement : elles lettrent automatiquement une opération avec les factures ouvertes du client, dans l'ordre choisi, avec une tolérance en montant ou en pourcentage pour absorber les frais. Un bouton « Run Auto Reconciliation » lance le rapprochement sur une période sans attendre la tâche nocturne, et Odoo propose d'automatiser un modèle qu'on a utilisé deux fois de suite.

Chaque journal de banque reçoit un alias e-mail : un relevé CAMT ou OFX envoyé en pièce jointe est importé. Les fichiers CSV et XLS restent à importer à la main.

6. Les immobilisations se paramètrent sur le compte

C'est la refonte la plus profonde. Les « modèles d'immobilisation » de la 19, qui étaient des immobilisations à l'état modèle, deviennent des modèles d'amortissement : une méthode (linéaire, dégressif, ou sans amortissement pour un terrain ou une immobilisation en cours), une durée ou un taux, une périodicité. Le compte d'immobilisation porte le modèle par défaut, le compte d'amortissement et le compte de dotation.

À la validation d'une facture fournisseur imputée sur ce compte, l'immobilisation est créée et confirmée. Plus de choix « brouillon ou validée » : si le compte n'a pas ses comptes d'amortissement, la facture est bloquée. Sur Cycles Demo, la facture d'outillage de l'atelier a créé son immobilisation de 8 000 € sur cinq ans sans une saisie.

Pour les sociétés qui tiennent plusieurs référentiels (comptable, fiscal, IFRS), une immobilisation porte une variante par référentiel, chacune avec son plan d'amortissement. C'est le support natif de l'amortissement dérogatoire.

7. Les emprunts gagnent l'analytique, l'OCR et la tranche de un à cinq ans

L'emprunt porte désormais une distribution analytique reportée sur toutes ses écritures, ses échéances sont datées du premier du mois, et un tableau d'amortissement scanné peut être lu par la numérisation pour remplir l'échéancier. Pour la France, une tranche de un à cinq ans s'ajoute au court et au long terme, celle qu'attend l'annexe des dettes de la liasse.

8. Les relances tiennent en une case

Les niveaux de relance de la 19, avec leur nom, leurs pièces jointes et leur case « automatique », laissent place aux Invoice Reminders : une case dans les Paramètres, qui crée trois niveaux à 7, 15 et 30 jours avec leurs modèles d'e-mail, et un délai saisi « avant » ou « après » l'échéance. Depuis la liste des factures, un bouton relance plusieurs clients d'un coup, et une facture échue envoyée avec le modèle de relance joint le relevé du client.

Ce qui part : le statut de relance du client, et le filtre « nécessite une relance » de la liste des relevés.

9. La liasse fiscale et la DAS2 sortent d'Odoo

Deux rapports nouveaux sous le menu France. La liasse du régime simplifié, formulaires 2033 A à G, 2031, 2065 et 2069 RCI, se calcule dans Odoo, se complète par un fichier XLSX pour les cases non calculables, et part à la DGFiP en EDI-TDFC par ASPOne. Le régime réel normal (2050 à 2059) n'est pas couvert : à ce régime, la soumission renvoie au portail ASPOne. La DAS2 liste les honoraires et commissions versés au-delà de 2 400 € par bénéficiaire, à partir d'étiquettes posées sur les comptes 62x, et se télétransmet.

Pour la facture électronique, l'adresse d'un client se cherche désormais dans l'annuaire par une loupe à côté du champ. Le profil UBL émis change, et le traitement spécifique des factures d'acompte a quitté le module : à tester avant la mise en production.

10. Les rapports suivent l'exercice, et se souviennent des périodes closes

Le sélecteur de dates propose « exercice fiscal » et suit l'exercice de la société, même décalé. Chaque ligne du bilan et du compte de résultat peut s'exprimer en pourcentage d'une ligne de référence. Les soldes des périodes verrouillées sont figés en base : le bilan et le grand livre s'ouvrent plus vite sur un long historique, et se recalculent à chaque déverrouillage.

Deux fonctions disparaissent : le filtre analytique du grand livre et de la balance (seule reste la ventilation en colonnes par axe), et le regroupement automatique des longues listes par tranches alphabétiques. En consolidation, l'écart de conversion est enfin calculé et affiché au bilan, là où la 19 se contentait d'un avertissement de déséquilibre.

Ce qu'il faut retenir avant de migrer

Sur les seize points de vigilance du panorama, cinq demandent une action humaine qu'aucun script ne fera à votre place :

Le reste (mandats de prélèvement renommés, multinormes inversées, taxes à formule à retester, lettrage facture-avoir en TVA sur encaissement) est détaillé dans le panorama.

Le panorama complet, à télécharger

Le document qui accompagne cet article décrit toute l'application : 69 pages, 113 écrans, les 73 réglages de la page Paramètres bloc par bloc, chaque menu, chaque écran, avec pour chaque sujet un encadré « En version 20.0 » qui renvoie à la ligne de code concernée dans les sources 19.0 et 20.0. Il est établi sur Cycles Demo, société de démonstration montée pour l'occasion : les chiffres qu'on y voit sont fictifs, les écrans sont les vrais.

Il est réservé aux lecteurs inscrits sur akol.io. L'inscription demande une adresse e-mail et un mot de passe, rien d'autre : pas de carte, pas d'abonnement. Une fois connecté, le PDF (16 Mo) se télécharge en un clic.

Se connecter pour télécharger ou créer un compte.

Si vous préparez une montée de version vers Odoo 20, ou une première mise en place de la comptabilité, écrivez-nous depuis la page contact d'akol.io avec votre plan comptable et la liste de vos modules : c'est là que se décide ce qui migre tout seul et ce qui demande une main.