他システムからの移行

勘定科目、取引先、期首残高または全履歴、未決済請求書、固定資産、在庫など、企業の帳簿データを1回のAPIコールで移行します。

企業が別のアカウントプログラムから Nordlet へ移行する場合、帳簿データがゼロから始まるわけではありません。履歴帳簿インポーターは、旧システムに残されたすべてのデータを受け取り、1回のAPIコールと1回のデータベーストランザクションで書き込みます。つまり、1行でもバリデーションチェックに失敗した場合、何も保存されません。同じパッケージを事前にチェック専用のエンドポイントを実行してテストすることができます。これにより、すべてのバリデーションが実行された後にロールバックされます。

POST /v1/migration/books/validate   # すべてをチェックし、何も書き込まない
POST /v1/migration/books/import     # すべてを書き込むか、一切書き込まない

Webアプリでも、アカウント (Account) → 移行 (Migration) に同じ2つのボタンがあります（JSONを貼り付けるか、ファイルをアップロードします）。APIキーには、ledger:write および、含める各セクションの書き込みスコープ（partners:write、catalog:write、sales:write、purchases:write、assets:write、inventory:write）が必要です。両方のエンドポイントとも、最大32 MBまでのリクエストボディを受け付けます。

カットオーバー日

カットオーバー日（Nordletでの運用を開始する初日）を選択します。それより前のすべてのデータは旧システムに残るか（または後述するように履歴として取り込まれます）、その日以降のすべてのデータは通常の経由で Nordlet に入力されます。パッケージ内のすべての金額は「カットオーバー前日の時点」のものとなります。つまり、締め高試算表、未払いの請求書、棚卸しの在庫、台帳上の固定資産などです。

インポートする前に、Nordlet で次の作業を行います。

企業を作成し、勘定科目テンプレートを適用する（ledger/accounts/apply-template）、またはパッケージの accounts セクションに必要な勘定科目を列挙する。
在庫をインポートする場合は、少なくとも1つの倉庫を作成する（inventory/warehouses/create）。
エラーが報告されなくなり、警告内容が許容できる状態になるまで、パッケージに対して migration/books/validate を実行する。

パッケージ

すべてのセクションは任意であり、必要なものだけを含めます。セクション間のすべての参照はコード（勘定科目コード、取引先コード、品目コード、資産グループコード、倉庫コード）で行われ、コードは Nordlet にすでに存在するレコード、または同じパッケージ内の前のセクションによって作成されたレコードのいずれかを参照できます。

{
  "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" }
  ]
}

金額は API 全体と同様に小数文字列です。source は自由記述のラベルであり、期首残高取引の説明や移行された請求書の備考に記載されます。

`accounts`

勘定科目の行：code（コード）、name（名称）、type（種類：asset、liability、equity、income、expense）、およびオプションの parentCode と isPostable。すでに存在するコードは変更されず、existing としてカウントされます。旧システムの勘定科目がテンプレートと異なる場合に使用するか、またはこれをスキップして最初にテンプレートを適用します。

`partners` と `items`

顧客、サプライヤー、およびカタログ品目であり、code をキーとします。リトアニアでは、パートナーコードは通常企業登録コードです。個人手動の場合は、企業内で一意となる任意のコードを使用します。既存のコードは更新されず、スキップされます。品目では、type（product または service）、unit、barcode、vatRatePercent、salePriceExclVat、purchasePriceExclVat を指定できます。

`openingBalances`

旧システムの締め高試算表であり、勘定科目ごとに1行：accountCode に debit または credit のいずれかを指定します。これらの行は、ドキュメントタイプ migration_opening を持ち、日付が openingBalances.date（デフォルトはカットオーバー日）である1件の仕訳取引として計上されます。各行は記帳可能な勘定科目を参照している必要があります。

取引の借貸が一致している必要があります。旧システムの試算表が一致しない場合（端数の丸め、資本に振り替えられなかった利益、欠落している勘定科目など）、balancingAccountCode（通常は利益剰余金であり、リトアニアのテンプレートでは 3410）を指定すると、その差額がそこに計上されます。レスポンスではその金額が balancingAmount として報告されます。

期首残高取引は、1社につき1件のみ存在可能です。openingBalances を含む2回目のインポートは拒否されます（409）。事後的な修正は、通常の個別手動仕訳（ledger/journal/transactions/create）によって行います。計上済みの取引は変更不可であるため、元のデータはインポート時のまま維持されます。

`journal` - 残高の代わりに、または残高に加えて全履歴を取り込む場合

旧システムの取引を Nordlet に取り込みたい場合（過去の期間のレポートを機能させるため）、ここにデータを送信します。各取引につき1つのオブジェクトを指定し、date、オプションの description および reference を含め、さらに accountCode と debit/credit の entries を指定します。各取引はそれ単体で借貸が一致している必要があります。これらはドキュメントタイプ migration として計上されます。

日付はカットオーバー日より前である必要があります。パッケージに openingBalances も含まれている場合、履歴の日付は openingBalances.date 以降である必要があります。一般的なパターンとしては、前事業年度の開始時点の残高に加え、その年度の取引を含め、当年度の初日をカットオーバー日とします。同じ期間に対して残高と履歴の両方を送信しないでください。残高が二重にカウントされてしまいます。

期首残高または履歴に関連するすべての月は、オープンな会計期間である必要があります（そうでない場合は 409）。

`openReceivables` と `openPayables`

カットオーバー時点でまだ未決済（全額または一部）だった請求書。これらは、paidAmount = grossTotal − outstanding が設定された発行済み売上請求書および登録済み仕入請求書として作成されます。これにより、銀行照合（bank/transactions/match、bank/transactions/suggest-matches）、債権年齢表、および支払 Webhook が、他の請求書と同様にこれらに対しても機能します。

outstanding のデフォルトは grossTotal です。vatTotal のデフォルトは 0 です（税抜金額はここから算出されます）。
dueDate のデフォルトは発行日です。
currency のデフォルトは企業の請求書通貨です。企業の基本通貨以外の通貨の場合は fxRate が必須となります（APIの残りの部分と同じ規則に従い、基本通貨1単位あたりの該当通貨の単位数を指定します）。これは、後日の支払時に実現為替差額を正しく計算できるように請求書に保存されます。
売上請求書の number は旧システムの完全な番号であり、企業内で一意である必要があります。仕入請求書は、取引先と documentNumber の組み合わせごとに一意である必要があります。
請求書は再計上されません。それらの受取債権/支払債務の残高はすでに期首残高の一部となっているためです。これらは期首残高取引にリンクされます。これが、openPayables が同じパッケージ内に openingBalances を必要とする理由です。
請求書の明細行はインポートされず、請求書には合計のみが記載されます。明細の詳細およびカットオーバー前期間の VAT 登録簿については、引き続き旧システムがソースとなります。

旧システムが未決済明細なしで顧客残高を管理していた場合、決済できるように残高ごとに取引先につき1枚の請求書を作成してください（例：番号 OB-301111222）。

番号の連続性は維持されます。 インポートされた売上請求書の番号が PREFIX-N の形式であり、その発行日がカットオーバーの年に該当する場合、そのプレフィックスと年の番号シリーズは N + 1 に設定されます（値が下がることはありません）。レスポンスには結果の numberSeries がリストされます。その他のケースでは、reference/series/create（{ documentType: "sale_invoice", prefix, year, startAt }）を使用してご自身でシリーズを設定してください。

`assetGroups` と `fixedAssets`

固定資産は、現在までの減価償却費とともに引き継がれます。acquisitionCost（取得原価）、salvageValue（残存価額）、accumulatedDepreciation（減価償却累計額）、depreciatedMonths（償却月数）、および usefulLifeMonths（耐用年数月数。グループのデフォルトを使用することも可能）。定額法による実行（assets/depreciation/post）は、残存耐用年数にわたる残存価値から継続されます。減価償却累計額がすでに償却可能額に達している資産は、fully_depreciated（全額償却済み）として作成されます。何も計上されません（取得原価と減価償却累計額は期首残高の一部となります）。

グループは code をキーとし、assetAccountCode および depreciationAccountCode（デフォルトの費用勘定 6206）が必要です。

`stock`

品目ごとの手許在庫：itemCode（品目コード）、quantity（数量）、unitCost（EURでの単価）、およびオプションで warehouseCode（デフォルト：デフォルト倉庫）、ロットまたはシリアル管理される品目の lotNumber および expiryDate。各行は、ドキュメントタイプ migration を持ちカットオーバー日の日付が設定された入庫移動となり、そのコストで FIFO（先入先出法）レイヤーを開始します。何も計上されません（在庫価値は期首残高の一部となります）。

チェックと警告

バリデーションエンドポイントは、勘定科目の欠落、記帳不可の勘定科目、貸借不一致の取引、不明な取引先・品目・グループ・倉庫コード、パッケージ内の重複するコードや番号、総額を超える未決済額、償却可能額を超える減価償却累計額、および為替レートの欠落がある場合に失敗し、422を返します。Nordlet にすでに存在する番号やコードは 409 を返します。

それに加えて、両方のエンドポイントは、サブレジスタと、同じパッケージ内の総勘定元帳のエントリを比較し、エラーではなく**warnings（警告）**として差異を返します。

openReceivables の総未決済額 vs 受取勘定科目の残高（sales.receivable 記帳ルール、デフォルトは 2410）；
openPayables の総未決済額 vs 支払勘定科目（purchases.payables、4430）；
stock の総原価 vs 在庫勘定科目（inventory.stock、2040）；
資産グループごとの、資産の原価 vs グループの資産勘定科目、およびそれらの減価償却累計額 vs 減価償却勘定科目。

警告は、旧システムの補助元帳と総勘定元帳が一致していないことを意味します。インポートする前に、パッケージを修正するか（または差異を意図的に許容するか）してください。

レスポンス

{
  "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": []
}

dryRun: true はバリデーション実行を示し、その場合 journalTransactionId は null になります。インポートは、同じサマリーとともに migration.imported として監査ログに記録されます。

インポート後

移行された履歴に誤って何も記帳されないように、カットオーバー日より前の期間をロックします（ledger/periods/lock）。
旧システムの締め高レポートと照らし合わせて、カットover日時点の試算表と貸借対照表を確認します。
通常のフローを継続します：請求書の発行、銀行明細書のインポート、支払の消し込み。移行された未決済請求書は、他の請求書と同様に消し込みが行われます。

インポーターの対象外となるもの：過去の期間の請求書明細および VAT 登録簿（旧システムまたはそのアーカイブに残してください）、給与計算履歴、および請求書以外のドキュメント（注文書、納品書、契約書）。

他システムからの移行

カットオーバー日

パッケージ

accounts

partners と items

openingBalances

journal - 残高の代わりに、または残高に加えて全履歴を取り込む場合

openReceivables と openPayables

assetGroups と fixedAssets

stock