Nordlet

← Documentation / Guides

Migration depuis un autre système

Importez la comptabilité d'une entreprise en un seul appel (plan comptable, tiers, soldes d'ouverture ou historique complet, factures ouvertes, immobilisations et stock).

Lorsqu'une entreprise passe à Nordlet depuis un autre logiciel comptable, sa comptabilité ne repart pas de zéro. L'outil d'importation des données historiques récupère tout ce que l'ancien système vous laisse et l'enregistre en un seul appel et une seule transaction de base de données : si une seule ligne échoue lors d'un contrôle, rien n'est enregistré. Ce même paquet de données peut être testé au préalable via un point de terminaison de validation (endpoint), qui effectue toutes les vérifications et annule les modifications le cas échéant.

POST /v1/migration/books/validate   # vérifie tout, n'écrit rien
POST /v1/migration/books/import     # écrit tout ou rien

L'application web propose les deux mêmes boutons sous Compte → Migration (collez le JSON ou téléchargez un fichier). La clé d'API requiert l'autorisation ledger:write ainsi que l'autorisation d'écriture de chaque section incluse (partners:write, catalog:write, sales:write, purchases:write, assets:write, inventory:write). Les deux points de terminaison acceptent des corps de requête allant jusqu'à 32 Mo.

La date de bascule

Choisissez la date de bascule (cut-over date), qui correspond au premier jour d'exploitation de l'entreprise sur Nordlet. Tout ce qui précède reste dans l'ancien système (ou est importé en tant qu'historique, voir ci-dessous), et tout ce qui intervient à partir de cette date est saisi dans Nordlet par le biais des points de terminaison habituels. Tous les montants du paquet de données s'entendent "au jour précédant la bascule" : balance de clôture, factures encore impayées, stock présent en rayon et immobilisations figurant au fichier des immobilisations.

Avant de procéder à l'importation, effectuez les opérations suivantes dans Nordlet :

  1. Créez l'entreprise et appliquez le modèle de plan comptable (ledger/accounts/apply-template), ou listez les comptes dont vous avez besoin dans la section accounts du paquet de données.
  2. Créez au moins un entrepôt (inventory/warehouses/create) si vous importez des stocks.
  3. Soumettez le paquet de données à migration/books/validate jusqu'à ce qu'il ne signale plus aucune erreur et que vous en acceptiez les avertissements.

Le paquet de données

Chaque section est facultative ; incluez celles dont vous disposez. Toutes les références entre sections sont établies par code (code de compte, code de tiers, code d'article, code de groupe d'immobilisations, code d'entrepôt). Un code peut faire référence soit à un enregistrement existant dans Nordlet, soit à un enregistrement créé par une section précédente du même paquet.

{
  "cutoverDate": "2026-01-01",
  "source": "Rivilė GAMA",
  "accounts": [
    { "code": "6210", "name": "Advertising expenses", "type": "expense", "parentCode": "6" }
  ],
  "partners": [
    { "code": "301111222", "name": "UAB Klientas", "vatCode": "LT100001112223", "isCustomer": true },
    { "code": "302222333", "name": "UAB Tiekėjas", "isCustomer": false, "isSupplier": true }
  ],
  "items": [
    { "code": "SKU-1", "name": "Widget", "type": "product", "unit": "vnt", "vatRatePercent": "21" }
  ],
  "assetGroups": [
    { "code": "TRANSP", "name": "Vehicles", "assetAccountCode": "1230", "depreciationAccountCode": "1239",
      "defaultUsefulLifeMonths": 60 }
  ],
  "openingBalances": {
    "balancingAccountCode": "3410",
    "entries": [
      { "accountCode": "2710", "debit": "5000.00" },
      { "accountCode": "2410", "debit": "1500.00" },
      { "accountCode": "2040", "debit": "300.00" },
      { "accountCode": "1230", "debit": "12000.00" },
      { "accountCode": "1239", "credit": "2400.00" },
      { "accountCode": "4430", "credit": "700.00" },
      { "accountCode": "3010", "credit": "10000.00" }
    ]
  },
  "openReceivables": [
    { "partnerCode": "301111222", "number": "SF-1050", "issueDate": "2025-12-10", "dueDate": "2026-01-09",
      "grossTotal": "1210.00", "vatTotal": "210.00" },
    { "partnerCode": "301111222", "number": "SF-1049", "issueDate": "2025-11-20",
      "grossTotal": "500.00", "outstanding": "290.00" }
  ],
  "openPayables": [
    { "partnerCode": "302222333", "documentNumber": "T-77", "documentDate": "2025-12-15", "grossTotal": "700.00" }
  ],
  "fixedAssets": [
    { "groupCode": "TRANSP", "code": "CAR-1", "name": "Delivery van", "acquisitionDate": "2025-01-01",
      "acquisitionCost": "12000.00", "accumulatedDepreciation": "2400.00", "depreciatedMonths": 12 }
  ],
  "stock": [
    { "itemCode": "SKU-1", "quantity": "30", "unitCost": "10" }
  ]
}

Les montants sont des chaînes de caractères représentant des décimaux, conformément au reste de l'API. La propriété source est un libellé libre qui figurera dans le libellé de l'écriture de solde d'ouverture ainsi que dans les notes des factures migrées.

accounts

Lignes du plan comptable : code, name, type (asset, liability, equity, income, expense), ainsi que les champs facultatifs parentCode et isPostable. Les codes déjà existants ne sont pas modifiés et sont comptabilisés comme existing. Utilisez cette option lorsque le plan comptable de l'ancien système diffère du modèle, ou passez cette étape et appliquez d'abord le modèle.

partners et items

Clients, fournisseurs et articles du catalogue, identifiés par leur code. En Lituanie, le code du tiers correspond généralement au code d'immatriculation de l'entreprise ; pour les personnes physiques, utilisez n'importe quel code unique au sein de l'entreprise. Les codes existants sont ignorés et ne sont pas mis à jour. Les articles acceptent les champs type (product ou service), unit, barcode, vatRatePercent, salePriceExclVat, purchasePriceExclVat.

openingBalances

Balance de clôture de l'ancien système, à raison d'une ligne par compte : accountCode avec soit debit, soit credit. Les lignes sont comptabilisées en tant qu'une seule écriture de journal datée du openingBalances.date (par défaut, la date de bascule) avec le type de document migration_opening. Les lignes doivent faire référence à des comptes imputables.

L'écriture doit être équilibrée. Si la balance de l'ancien système présente un désécart - dû à des arrondis, à un bénéfice jamais affecté aux capitaux propres ou à un compte manquant -, indiquez un balancingAccountCode (généralement le report à nouveau, 3410 dans le modèle lituanien) et la différence y sera imputée. La réponse indique ce montant sous la clé balancingAmount.

Une seule écriture de solde d'ouverture est autorisée par entreprise. Une seconde importation contenant openingBalances sera refusée (409). Les corrections ultérieures doivent être effectuées par le biais d'écritures de journal manuelles ordinaires (ledger/journal/transactions/create). Les écritures validées étant immuables, l'écriture d'origine reste telle qu'importée.

journal - historique complet au lieu ou en plus des soldes

Si vous souhaitez intégrer les transactions de l'ancien système dans Nordlet (afin que les rapports des périodes antérieures soient fonctionnels), transmettez-les ici : un objet par transaction comprenant date, les champs facultatifs description et reference, ainsi que les lignes (entries) composées de accountCode et de debit/credit. Chaque transaction doit être équilibrée de manière autonome. Elles sont enregistrées avec le type de document migration.

Les dates doivent être antérieures à la date de bascule. Si le paquet contient également des openingBalances, l'historique doit porter une date postérieure ou égale à openingBalances.date. Le scénario classique consiste à reprendre les soldes au début de l'exercice précédent ainsi que les opérations de cet exercice, avec une date de bascule fixée au premier jour de l'exercice en cours. N'envoyez pas simultanément des soldes et un historique pour la même période, sous peine de voir les soldes comptabilisés en double.

Chaque mois concerné par les soldes d'ouverture ou par l'historique doit correspondre à un exercice ou une période comptable ouverte (sous peine d'un code erreur 409).

openReceivables et openPayables

Factures qui étaient encore impayées (totalement ou partiellement) à la date de bascule. Elles sont créées respectivement comme des factures clients émises et des factures fournisseurs enregistrées avec paidAmount = grossTotal − outstanding, ce qui permet au rapprochement bancaire (bank/transactions/match, bank/transactions/suggest-matches), au rapport de vieillissement de la créance et aux webhooks de paiement de fonctionner comme pour n'importe quelle autre facture.

  • outstanding prend par défaut la valeur de grossTotal ; vatTotal prend par défaut la valeur 0 (la base HT est calculée automatiquement).
  • dueDate prend par défaut la date du document.
  • currency prend par défaut la devise de facturation de l'entreprise. Pour toute devise autre que la devise de référence de l'entreprise, le taux de change fxRate est obligatoire (exprimé en unités de cette devise pour 1 unité de la devise de référence, selon la convention adoptée dans le reste de l'API). Il est enregistré sur la facture afin que les règlements ultérieurs calculent correctement les écarts de change réalisés.
  • Le numéro (number) de la facture client correspond au numéro complet de l'ancien système et doit être unique au sein de l'entreprise. Pour les factures fournisseurs, l'unicité est requise par tiers et par documentNumber.
  • Les factures ne sont pas comptabilisées à nouveau : leur solde de créance ou de dette est déjà inclus dans les soldes d'ouverture. Elles sont liées à l'écriture de solde d'ouverture, raison pour laquelle openPayables exige la présence de openingBalances dans le même paquet.
  • Les lignes de facture ne sont pas importées ; la facture ne comporte que les totaux. L'ancien système demeure la source de référence pour le détail des lignes et pour les déclarations de TVA des périodes antérieures à la date de bascule.

Si l'ancien système suivait les soldes clients sans ventiler les factures ouvertes, créez une facture par tiers pour le montant du solde (par exemple avec le numéro OB-301111222) afin de permettre son apurement.

La numérotation se poursuit. Lorsqu'un numéro de facture client importé respecte le format PREFIX-N et que sa date d'émission se situe dans l'année de bascule, la souche de numérotation correspondante pour ce préfixe et cette année est initialisée à N + 1 (cette valeur ne peut pas être abaissée). La réponse liste les éléments numberSeries résultants. Dans les autres cas, configurez vous-même la souche avec reference/series/create ({ documentType: "sale_invoice", prefix, year, startAt }).

assetGroups et fixedAssets

Les immobilisations sont importées avec leur amortissement cumulé à ce jour : acquisitionCost, salvageValue, accumulatedDepreciation, depreciatedMonths et usefulLifeMonths (ou la valeur par défaut du groupe). Le calcul de l'amortissement linéaire (assets/depreciation/post) se poursuit sur la base de la valeur résiduelle et de la durée restante. Les immobilisations dont l'amortissement cumulé est déjà égal à la valeur amortissable sont créées avec le statut fully_depreciated. Aucune écriture n'est générée, car le coût d'acquisition et l'amortissement cumulé font déjà partie des soldes d'ouverture.

Les groupes sont identifiés par leur code et requièrent les comptes assetAccountCode et depreciationAccountCode (le compte de charge par défaut étant 6206).

stock

Stock en stock par article : itemCode, quantity, unitCost (coût unitaire en EUR) et, de manière facultative, warehouseCode (par défaut : l'entrepôt principal), lotNumber et expiryDate pour les articles suivis par lot ou par numéro de série. Chaque ligne génère un mouvement de stock entrant daté de la date de bascule avec le type de document migration et initialise une couche FIFO à ce coût unitaire. Aucune écriture n'est générée, la valeur du stock étant incluse dans les soldes d'ouverture.

Contrôles et avertissements

Le point de terminaison de validation renvoie une erreur (422) en cas de comptes manquants, de comptes non imputables, de transactions non équilibrées, de codes de tiers, d'articles, de groupes ou d'entrepôts inconnus, de doublons de codes ou de numéros au sein du paquet, de montants ouverts supérieurs au montant total TTC, d'amortissements cumulés supérieurs à la valeur amortissable, ou de taux de change manquants. Les numéros ou codes qui existent déjà dans Nordlet génèrent une erreur 409.

En outre, les deux points de terminaison comparent les balances auxiliaires aux écritures comptables du même paquet et signalent les divergences sous forme d'avertissements (warnings) plutôt que d'erreurs :

  • total des soldes de openReceivables par rapport au solde du compte de clients (règle de comptabilisation sales.receivable, par défaut 2410) ;
  • total des soldes de openPayables par rapport au solde du compte de fournisseurs (purchases.payables, 4430) ;
  • coût total du stock par rapport au compte de stock (inventory.stock, 2040) ;
  • pour chaque groupe d'immobilisations, comparaison entre le coût des immobilisations et le compte d'immobilisation du groupe, ainsi qu'entre leur amortissement cumulé et le compte d'amortissement.

Un avertissement indique un désaccord entre la comptabilité auxiliaire et la comptabilité générale de l'ancien système. Corrigez le paquet (ou acceptez la divergence en connaissance de cause) avant de procéder à l'importation.

La réponse

{
  "dryRun": false,
  "cutoverDate": "2026-01-01",
  "accounts": { "created": 1, "existing": 0 },
  "partners": { "created": 2, "existing": 0 },
  "items": { "created": 1, "existing": 0 },
  "assetGroups": { "created": 1, "existing": 0 },
  "openingBalances": { "journalTransactionId": "…", "date": "2026-01-01", "entries": 8,
                        "debitTotal": "18800.00", "creditTotal": "18800.00", "balancingAmount": "5700.00" },
  "journal": { "transactions": 0, "entries": 0 },
  "openReceivables": { "created": 2, "outstandingTotal": "1500.00" },
  "openPayables": { "created": 1, "outstandingTotal": "700.00" },
  "fixedAssets": { "created": 1, "costTotal": "12000.00", "accumulatedDepreciationTotal": "2400.00" },
  "stock": { "movements": 1, "costTotal": "300.00" },
  "numberSeries": [],
  "warnings": []
}

La propriété dryRun: true indique qu'il s'agit d'un test de validation ; dans ce cas, journalTransactionId a la valeur null. Une importation effective est consignée dans le journal d'audit sous l'événement migration.imported avec le même résumé.

Après l'importation

  • Clôturez et verrouillez les périodes antérieures à la date de bascule (ledger/periods/lock) afin d'éviter toute imputation accidentelle dans l'historique migré.
  • Vérifiez la balance générale et le bilan arrêtés à la date de bascule par rapport aux rapports de clôture de l'ancien système.
  • Poursuivez le cycle habituel : émission de factures, importation des relevés bancaires, rapprochement des règlements. Les factures ouvertes migrées s'apurent de la même manière que n'importe quelle autre facture.

Éléments non pris en charge par l'outil d'importation : les lignes de facture et les déclarations de TVA des périodes antérieures (à conserver dans l'ancien système ou dans ses archives), l'historique de paie, ainsi que les documents autres que les factures (commandes, bons de livraison, contrats).