Mapping Historical Account Codes

Bringing years of history along? Map your old account codes onto NP Ledger's chart of accounts in one pass.

Updated June 8, 2026

When you import years of QuickBooks history, the General Ledger export carries each account's code as it was on the day the transaction posted — not the code that account uses today. Established nonprofits renumber and restructure their chart of accounts over time (for example, 5100 Program Expenses became 6200 Program Services in a 2018 reorganization). Those retired codes don't match your current Chart of Accounts, so without a way to translate them the import would block.

Historical Code Mapping lets you map each retired code to the current account it belongs on, once. NP Ledger remembers the mapping and applies it automatically to every future import — so a 14-year history with three or four reorganizations becomes a one-time mapping exercise, not a per-batch cleanup project.

A QuickBooks General Ledger export is the cleanest source for multi-year history, but it preserves the posting-date code on every line. After a reorganization, the same real account can appear under several codes across the years. The two old workarounds — hand-creating placeholder accounts, or editing the GL export in a spreadsheet — are slow, error-prone, and have to be redone for every batch. Mapping retired codes to current accounts at import time means your account balances are right from the first report, and the work carries forward to the next year's import for free.

  • Export a General Ledger report from QuickBooks Online covering the period you want to bring in. Historical Code Mapping reads the account code and account name off each line.
  • Have your current Chart of Accounts in place (imported during setup, or built by hand). The remap dropdown picks destinations from your current accounts, so they need to exist first.
  • It helps to know, roughly, which old codes belong to which current accounts. NP Ledger will suggest matches by name, but you confirm each one.

When NP Ledger reads each GL line, it resolves the account with a four-step ladder:

  1. Exact code match against your current Chart of Accounts.
  2. A saved historical-code mapping for this organization, if one exists.
  3. An account-name match on the line's account label (preserved from how imports worked before — a line with no code but a recognizable name still resolves).
  4. Otherwise the code is unresolved, and it's collected for you to map.

Only codes that fall all the way through to step 4 land on the remap screen. A code you've already mapped resolves at step 2 on every later import and never prompts again.

Step 1: Upload the General Ledger export

Import the QuickBooks GL file the usual way — Spreadsheet Import, or Step 6 of the setup wizard. NP Ledger detects the QuickBooks GL format and opens a preview. If any codes don't resolve, an Account Code Mapping section appears on that preview listing every unresolved code at once.

Step 2: Map each retired code

For each unresolved code, choose the current account it should post to from the searchable dropdown. The section shows the code and the historical account name from the export so you can recognize what it was.

When the export includes the historical account name, NP Ledger pre-selects a suggested destination by matching that name against your current accounts, shown with a similarity score like Suggested (0.92). The suggestion is only a starting point — you always confirm, and you can change it. A high score (close to 1.0) is a confident match; a marginal score is a hint to look closer. Suggestions are never committed on your behalf.

Step 3: Save, then apply

Saving your mappings reloads the preview. Apply stays locked until every unresolved code is mapped — there is no "skip" or holding-account shortcut, by design, because an unmapped code means transactions with nowhere correct to land. If a long history leaves you with dozens of codes, the suggestions (and the bulk import below) are the fast path. Codes that resolved through a saved mapping appear as a confirmation note ("12 transactions on retired code 5100 Program Expenses will post to 6200 Program Services per a saved mapping") so you get one last review before committing.

If you already maintain a crosswalk of old-to-new codes outside NP Ledger, you can load it in one step. Go to Settings → Imports → Account mappings → Bulk import from CSV and upload a three-column file:

historical_code,historical_name,current_code
5100,Program Expenses,6200
5200,Fundraising Expenses,6300
5300,Management & General,6400
  • historical_code — the retired code as it appears in the GL export.
  • historical_name — the old account name (used for display and suggestions; may be left blank).
  • current_code — the code of a current account in your Chart of Accounts.

The upload runs as a preview, then commit. NP Ledger validates every row's current_code against your current accounts and shows how many rows will create mappings and how many have errors, with the reason per bad row, before any mapping is saved. The commit is all-or-nothing: if any row is invalid, nothing is written, so you fix the file and re-upload rather than ending up with a half-loaded crosswalk. Support teams can load the same CSV with the import_historical_code_map management command — it uses the identical validation, so the result matches the UI exactly.

Saved mappings live under Settings → Imports → Account mappings. From there an admin can:

  • Edit a mapping's destination account. Editing changes future imports only — it does not move transactions you've already imported under the old destination.
  • Delete a mapping. Already-imported transactions stay exactly where they are; future imports of that code simply fall through the ladder again (and will stop on the remap screen if the code still doesn't resolve).

Because the destination account is protected, you can't delete an account that a saved mapping still points at — NP Ledger asks you to unmap it here first. That guarantees a saved mapping can never dangle to an account that no longer exists.

The mapping is import-time only: it decides where lines land as they import. It does not retroactively move transactions, and deleting a mapping never unwinds an import. So if you mapped a code wrong and already imported under it, fixing the mapping won't move the transactions that already posted — you have two recovery paths:

  • Roll back the import batch — available for a limited window after the import, before the fiscal year is locked and before anything downstream (a reconciliation, an adjusting entry, a later import) references those transactions. Within that window, rolling the batch back lets you correct the mapping and re-import cleanly.
  • Post an adjusting entry — once the rollback window has closed (the period is locked, or other records now depend on the imported lines), the correct fix is an offsetting adjusting entry through the Adjusting Entry wizard, not a rollback.

A retired code maps to exactly one current account regardless of period. If the same old code legitimately belongs to different accounts in different years, split the GL export by date range and map each batch separately (delete and recreate the mapping between batches).

  • After applying, spot-check the accounts you remapped on the Chart of Accounts and in a Trial Balance — the balances should reflect the remapped history.
  • Re-importing more QuickBooks history later won't re-prompt for codes you've already mapped; they resolve automatically.
  • The remap step decides only which account a line posts to. It does not change the fund or program on the line — that's handled separately (see Mapping QuickBooks Classes to Funds). On a QuickBooks GL import that needs both, resolve the account codes first, then the classes.
  • Expecting a fixed mapping to move past transactions. Editing a mapping affects future imports only. Use an import-batch rollback (within the window) or an adjusting entry to correct history.
  • Mapping a code to the wrong type of account. The dropdown lets you pick any current account; double-check you're not sending an expense code onto a revenue account. The historical name and the suggestion score are there to help you catch this before you commit.
  • Trying to skip an unmapped code. Apply is blocked until every code is mapped — there's no holding account on purpose. Use the suggestions or a bulk CSV to move quickly through a long list.
  • Deleting a current account that a mapping uses. Unmap it from Settings → Imports → Account mappings first; the account is protected while a mapping points at it.

Open the AI Help panel and try: - "Why don't these account codes from my QuickBooks export match?" - "How do I map an old account code to a current account?" - "I mapped a code to the wrong account and already imported — how do I fix it?"

Ready to try NP Ledger?

Native fund accounting, Form 990 support, and smarter bookkeeping for nonprofits.