← All posts

How to Map Account Codes During Accounting Migration

September 6, 2026 · LedgerSwitch Team

When you migrate a client's books to a new accounting system, the chart of accounts rarely lines up 1:1. The old system's account codes—701, 802, 5500—need to map to the new platform's structure, and getting this wrong means restating financials, rebuilding reports, or worse, losing client trust. To map account codes migration successfully, build a crosswalk spreadsheet that documents every old code, its new destination, and the logic behind each mapping decision, then test your map against a representative transaction sample before loading live data.

That three-step process—document, map, test—is the core of every clean accounting migration. The rest is discipline.

Key Takeaways

Why Account Code Mapping Breaks Migrations

Most bookkeepers underestimate this step. You've chosen the new platform, prepped the client, exported the data—and then you realize the old system's "Office Supplies" was account 6150, but the new one usesundefinedfor all supplies and wants you to tag departments differently. Your export hasundefinedtransactions coded to 6150. Do you merge them intoundefinedand lose granularity? Split them by memo field? Reclassify a subset?

Without a documented map, you'll make these calls on the fly, inconsistently, and you'll discover the errors when the client asks why Q2 COGS is upundefinedpercent. The map is your contract with the data.

Accounting systems impose structure—account types, numbering conventions, required parent-child hierarchies—and no two platforms agree. QuickBooks Online uses a loose four-digit scheme; Xero prefers shorter codes with required account types; NetSuite and Sage demand department and class segments. When you map account codes migration work, you're not just renumbering—you're translating one structural language into another.

The Three-Phase Mapping Framework

Phase 1: Export and Align Both Charts of Accounts

Pull a full chart of accounts report from the old system. You want every account code, name, type, and current balance. Export it to CSV or Excel. Do the same for the new system's default chart, or the custom chart you've built for this client.

Lay them side by side in a new spreadsheet with these columns:

Sort both lists by account type—Assets, Liabilities, Equity, Revenue, COGS, Expense—then by code. This surfaces structural gaps immediately. If the old system had five revenue accounts and the new one offers twenty sub-categories, you'll see it now, not during data load.

Phase 2: Map Top-Level Categories First

Start with the balance sheet. Map asset accounts first because they carry balances forward and errors compound. Cash and bank accounts are usually direct 1:1 maps. Accounts receivable and payable are often direct, but watch for systems that split AR by aging bucket or customer class.

Then equity. Retained earnings and owner capital are straightforward, but if the old system tracked partner draws in separate accounts and the new one uses classes or divisions, note that as a reclassification.

Revenue and expense accounts come next. This is where mapping gets creative. A small business might have used five expense codes in the old system; the new platform offers fifty. The client may want more detail going forward, which means you'll map old codeundefinedGeneral Expense to six new codes based on transaction memos or vendor names. Document that split logic in the Notes column because you'll need to script it or filter it during transformation.

How Do You Handle One-to-Many and Many-to-One Mappings?

One-to-many happens when you split an old account into several new ones for better reporting. Mark the Mapping Action as "Split" and list the new codes as a comma-separated set: "6000 → 6100, 6200, 6300." In your Notes column, write the rule: "6000 splits toundefinedif vendor contains 'Office',undefinedif memo contains 'Travel', else 6300."

Many-to-one happens when you consolidate. The old system might have had "Office Supplies," "Computer Supplies," and "Janitorial Supplies" as three codes; the new one uses a single Supplies account with tags. Mark those three old codes with Mapping Action "Merge" and the same new code. Note the loss of granularity so the client isn't surprised when legacy reports can't be recreated exactly.

Phase 3: Test the Map with Sample Transactions

Export a month of transactions from the old system—journal entries, invoices, bills, payments. Add a column to that export and use a VLOOKUP or INDEX-MATCH formula to apply your mapping crosswalk. Every old account code should resolve to a new one.

Run a trial balance on the transformed data. Does it balance? Do the totals by account type match the old system's reports for that month?

This sample run catches:

Fix the crosswalk, re-run the test, and repeat until the trial balance reconciles.

When to Reclassify vs. Preserve Old Structure

You'll face a choice: migrate the data exactly as coded and clean it up later, or reclassify during migration to match the new chart's best practices.

Preserve the old structure if:

Reclassify during migration if:

Most migrations land somewhere in the middle: preserve the structure for balance sheet accounts, reclassify selectively for P&L detail. Document every reclassification so the client knows why the numbers look different.

Comparison of Mapping Approaches

| Approach | Best For | Time Required | Risk of Error | Post-Migration Cleanup | |----------|----------|---------------|---------------|------------------------| | Direct 1:1 | Simple businesses, similar systems | 2-4 hours | Low | Minimal—mostly reporting tweaks | | Selective Merge | Clients wanting simplified reporting | 4-8 hours | Medium | Low if well-documented | | Full Reclassification | Messy old charts, fresh start | 8-16 hours | High during mapping, low after | Minimal—chart is clean day one | | Hybrid (preserve balance sheet, reclassify P&L) | Most small business migrations | 6-10 hours | Medium | Moderate—historical comparisons need context |

The Role of Account Types and System-Specific Rules

Every accounting platform enforces account type rules. QuickBooks Online won't let you post to a parent account if it has children. Xero requires every account to have a tax rate default. NetSuite demands segment values for every transaction.

When you map account codes migration tasks, check that your new codes match allowed types:

If the old system used type Other Expense for everything and the new one distinguishes Cost of Goods Sold, Operating Expense, and Other Expense, you'll need to reclassify based on account name or number range. Add a filter column in your crosswalk: if old code is 5000-5999, new type is COGS; if 6000-7999, Operating Expense.

What Do You Do with Abandoned or Duplicate Accounts?

Old systems accumulate junk.

Mark these with Mapping Action "Retire" and new code "None." If they carry a balance, map them to a catch-all like "Historical Adjustments" or "Uncategorized" and document it. Your goal is a clean new chart, not a faithful reproduction of legacy chaos.

Duplicates are trickier. If the old system has both "Office Expense" codeundefinedand "Office Supplies" code 6150, and both were used inconsistently, decide which new account they should merge into and make the call. The Notes column is your audit trail: "6100 andundefinedboth mapped to 6100-SUPP; historically used interchangeably per client."

How LedgerSwitch Automates the Mapping Process

Manual crosswalk spreadsheets work, but they're error-prone and time-consuming when you're migrating dozens of clients or handling complex multi-entity books. LedgerSwitch handles the full mapping workflow inside the platform: you upload both charts of accounts, and the tool suggests initial matches based on code similarity and account name. You review and adjust the mappings in a visual interface, flag splits and merges, and add mapping rules—"if vendor X, then new code Y"—without writing formulas.

Once the map is approved, LedgerSwitch applies it to the full transaction history, runs validation checks, and generates a reconciliation report showing old vs. new balances by account type. You catch errors before data loads into the production system. Learn more about how it works.

Step-by-Step: Building Your Mapping Crosswalk

Here's the repeatable process for every migration:

  1. Export both charts of accounts. Include code, name, type, and current balance from the old system; code, name, and type from the new.
  1. Create the crosswalk spreadsheet. Eight columns minimum: Old Code, Old Name, Old Type, Old Balance, New Code, New Name, New Type, Mapping Action, Notes.
  1. Map balance sheet accounts first. Start with cash, AR, AP, then other assets and liabilities, then equity. These carry balances and must be exact.
  1. Map revenue accounts. Decide if you're preserving detail or consolidating. If the client wants better visibility, plan splits now.
  1. Map COGS and expenses. This is the bulk of the work. Align categories logically, document merges and splits, and flag any reclassifications.
  1. Handle unmapped and retired accounts. Every old code needs a destination or an explicit "Retire" decision.
  1. Test with sample data. Export one month of transactions, apply the crosswalk with a lookup formula, generate a trial balance, and compare to the old system's report for the same period.
  1. Review with the client. Walk through any structural changes, especially reclassifications that will change how reports look.
  1. Lock the crosswalk version. Save a dated copy before you run the full migration. If something breaks, you need to know exactly what map you used.
  1. Run the migration and reconcile. Load data into the new system, pull a trial balance, compare account-by-account to the pre-migration snapshot.

Common Mapping Pitfalls and How to Avoid Them

Mapping parent accounts when the new system expects detail accounts only. Some platforms don't allow posting to parent accounts. If your old system posted directly to "6000 Operating Expenses" and the new one requires "6100 Rent," "6200 Utilities," and so on as children of 6000, you can't map to 6000. You'll need to split based on transaction description.

Ignoring account type mismatches. An old Expense account mapped to a new Liability account will break reports and tax filings. Double-check that Old Type and New Type align, or document why they don't.

Skipping the sample test. The crosswalk looks perfect in the spreadsheet, but you won't catch formula errors, typos, or logic gaps until you run real transactions through it. Test early.

Losing historical context. If you reclassify aggressively, year-over-year reports won't match. Add a note in the new system's account description: "Prior toundefinedmigration, this was part of General Expense account 6000."

Not documenting split and merge rules. Six months post-migration, the client asks why revenue by product line doesn't match last year. If you didn't write down "Old codeundefinedsplit to 4100/4200 based on invoice memo field," you'll spend hours reconstructing the logic.

Maintaining the Map Post-Migration

The crosswalk isn't disposable. Save it in the client's migration documentation folder because you'll need it to:

Add a version number and date to the filename: ClientName_AccountMapping_v3_2026-09-06.xlsx. If you make post-migration adjustments—consolidating two accounts the client decided were redundant—update the crosswalk and save a new version.

Frequently Asked Questions

How long does it take to map account codes for a typical small business migration?

For a small business with 50-150 accounts and straightforward books, plan for roughly 4-8 hours to build and test the crosswalk. Complex businesses with custom codes, multi-entity structures, or heavily customized charts can take 12-20 hours. The time scales with the number of non-obvious decisions—merges, splits, reclassifications—not just the account count.

Can you automate account code mapping or does it always require manual review?

You can automate the initial matching based on account names and number ranges, and migration tools like LedgerSwitch do this well. But every migration includes judgment calls—should these three accounts merge or stay separate, does this reclassification make sense for this client—that require human review. Automation speeds up the grunt work; a bookkeeper still needs to approve the final map.

What happens if you map an account code incorrectly and only catch it after go-live?

You'll need to reclassify the affected transactions in the new system and restate any reports that were pulled in the interim. If the error is caught within days and transaction volume is low, it's a quick fix. If it's caught months later after close or tax filing, you may need to amend filings and explain the restatement to the client. This is why the sample test phase is non-negotiable.

Should you map inactive accounts that still carry balances?

Yes. Any account with a non-zero balance must map to a valid account in the new system or the books won't balance. If the account is truly obsolete, map its balance to a catch-all like "Historical Adjustments" or "Prior System Balances" and document the reason. Then mark the old account as retired in your crosswalk so future transactions don't accidentally post to it.

Do you need separate mappings for accounts receivable and accounts payable sub-ledgers?

It depends on how the old system structured them. If AR and AP were single control accounts with customer and vendor detail tracked separately, map the control accounts and let the sub-ledger migrate as its own data set. If the old system used separate AR and AP accounts per customer or vendor, you'll need to map each one or consolidate them into control accounts. Check whether the new system even supports the old structure before you map.

How do you handle chart of accounts differences between industries?

Industry-specific charts—construction job costing, legal trust accounts, nonprofit fund accounting—require domain knowledge. The mapping crosswalk process is the same, but you'll need to understand which codes are regulatory or reporting requirements and which are discretionary. When migrating a nonprofit from a generic chart to a fund-based structure, for example, you'll reclassify every revenue and expense account by fund, which means adding a segment or class dimension that didn't exist before. Document those structural changes in detail and review them with the client and their auditor before go-live.

Account code mapping is repetitive, detail-heavy work, but it's the difference between a migration that sticks and one that unravels three months in. Build the crosswalk carefully, test it against real data, and document every non-obvious decision. The hour you spend now writing "splitundefinedinto 6100/6200 based on vendor name" saves ten hours of cleanup and client frustration later. If you're running migrations regularly, invest in tooling that makes the process repeatable and auditable. Your future self—and your clients—will thank you. For teams handling frequent switchovers, explore LedgerSwitch's migration platform to see how automated mapping and validation workflows scale across client portfolios.