NetSuite to QuickBooks Migration: Convert NetSuite to QuickBooks Online with CSV to QBO

Split the job in two and do it in order. First move the lists, meaning the chart of accounts, customers, vendors and items, using QuickBooks' own list import. Then move the money: export the transactions from NetSuite as CSV, convert them to .qbo, and import them through Bank Feeds oldest period first. Reconcile after each period rather than at the end.

The order matters more here than in most migrations. NetSuite's account names and numbers rarely match the QuickBooks chart you are about to build, so if transactions land before the accounts exist, everything piles into Uncategorized Expense and you spend the reclassification budget you were trying to save. Build the chart in QuickBooks first, map NetSuite's account column to it in a spreadsheet, then convert.

Not from Intuit or Oracle. Intuit publishes two conversion routes and NetSuite is on neither: the QuickBooks Conversion Tool handles Quicken and Sage 50 releases after 2014 into QuickBooks Desktop, and Dataswitcher handles Sage 50 (US edition), Xero and QuickBooks Desktop into QuickBooks Online. Intuit's guidance for any other source software is to move the data with a spreadsheet.

Third party conversion firms do sell NetSuite to QuickBooks projects, and several are competent, but under the hood most of them are doing the same thing: pulling saved search exports out of NetSuite, reshaping them in a spreadsheet, and importing them. You are paying for the mapping work and the reconciliation, not for a secret connector. That is worth knowing before you sign a five figure statement of work for a file that is mostly bank activity.

Build a saved search for what you want, run it, and use the Export buttons on the results page. NetSuite offers Export - CSV, Export - Microsoft Excel, which produces an XLSX, and Export - PDF, plus Export to Tableau Workbook if an administrator has enabled it. You need both the Export Lists and the Perform Search permissions or the buttons will not appear.

Two things trip people up. Popup searches and their results pages have no Export option at all, so run the search from a full results page. And if the export is slow, NetSuite's own advice is to persist the search results first, which caches the result set and makes the CSV write far faster on large date ranges.

Use a transaction saved search filtered to type Journal, not the Journal report. Add Date, Account, Memo, Debit and Amount (Credit) as result columns, then Export - CSV. For a bank or credit card account, filter the same search to that account and export a single signed amount column instead, which is the shape the converter and QuickBooks both prefer.

Keep the internal ID column in the export even though QuickBooks will never see it. It is the only reliable way to trace a row in QuickBooks back to the NetSuite record it came from when a balance does not tie, and adding it later means re-running the whole export.

A saved search result set is capped at 10 MB, which Oracle documents as roughly 20,000 rows by 50 columns once exported to CSV. Saved search emails are stricter and truncate at 10,000 rows or 5 MB. Reports are limited differently again, and Oracle's own documentation gives conflicting figures, which is a good reason to export from searches rather than reports.

To be specific about the conflict: one Oracle page puts most reports at 25,000 rows with a named list of financial reports allowed 75,000, while another puts report results at 100,000 rows on demand and 1,000,000 in the background. Whichever applies to your account, a report that exceeds it is silently truncated, and a silently truncated general ledger export is the worst possible input to a migration. Saved searches do not have report row limits, so use them, and if a single search still will not fit, narrow the date range and export a quarter at a time.

No. NetSuite has no QuickBooks export format and QuickBooks has no NetSuite importer. The formats QuickBooks actually accepts for transactions are .qbo, .ofx, .qfx and, on Desktop only, IIF, and NetSuite writes none of them. CSV is the bridge, which is why the export and convert route is not a workaround so much as the only route.

It ranges from almost nothing to six figures depending on how much history and customization you insist on carrying over. Published quotes for full professional migrations sit far above what most small companies expect, so it is worth deciding early whether you are moving a business or moving an archive. Those are very different budgets.

For attributed figures: Broken Rubik publishes $20,000 to $40,000 for a simple single entity migration, $40,000 to $70,000 for two or three entities, and $60,000 to $120,000 or more where heavy customization has to be rebuilt, on a three to six month timeline. Other providers quote far lower, in the $500 to $15,000 band, and several of the better known conversion firms, Dancing Numbers among them, publish no rate at all and quote per file. Always ask what is excluded before you compare two numbers.

The gap between those figures is not vendor greed, it is scope. A quote at the low end usually covers lists plus one or two years of transactions. A quote at the high end includes rebuilding NetSuite customizations, approval workflows and reporting that QuickBooks cannot reproduce natively. If your NetSuite file is mostly bank, card and AR activity with a normal chart of accounts, you are closer to the low end than any ERP consultant will tell you, and converting the transaction CSVs yourself removes the largest line item from the estimate.

Plan three to six weeks for a straightforward file and three to six months if you are carrying multiple entities or rebuilding custom reporting. The export itself takes hours. What consumes the calendar is mapping the chart of accounts, agreeing what history matters, and reconciling each period after it lands. Budget more time for reconciliation than for the import.

Anything QuickBooks has no equivalent field for. Conversion providers publish similar exclusion lists, and Dancing Numbers states plainly that bank reconciliation status does not carry over, paychecks come across as journal entries rather than paychecks, employee year to date payroll figures do not move, and custom templates, budgets, fixed asset items, work tickets and job to transaction links are all excluded.

On top of that, the NetSuite specific layer simply has nowhere to go: SuiteScript automation, multi entity consolidation, ASC 606 revenue recognition schedules, approval workflows, advanced inventory tracking and SuiteCommerce data have no QuickBooks counterpart. Read the exclusions list before you sign anything, because it is where the surprises live, and it is usually a truer description of the project than the sales page above it.

For most companies, move forward-looking data plus opening balances, and keep the history somewhere you can read it. That is what the majority of NetSuite to QuickBooks moves actually do: they migrate one to two years of transactions and retain the old system read only for audit and comparative reporting, rather than trying to reproduce five years inside QuickBooks.

There is a real trade-off, so decide it deliberately rather than by default. Carrying full history makes prior year comparisons work inside QuickBooks and keeps your accountant from working in two systems. Carrying only opening balances gets you live in weeks instead of months and avoids importing every quirk you were trying to leave. If you do choose partial history, agree with your accountant in writing what the opening balance journal contains, and confirm with your Oracle account manager how long read access survives cancellation before you rely on it.

No. QuickBooks Desktop cannot import bank or credit card transactions from a CSV in any version, Enterprise included. The Import Excel and CSV Toolkit imports four list types only: customers, vendors, items and the chart of accounts. Its only transaction import paths are a .qbo Web Connect file through Bank Feeds, or an IIF file posted straight to the ledger.

That single fact decides the shape of a Desktop migration. Lists go in through the toolkit, transactions have to become .qbo or IIF first. Between the two, prefer .qbo: it lands in the Bank Feeds review queue where you can accept or fix rows before they post, whereas an IIF import writes directly to the ledger with no undo.

Usually because the export is too wide or too long. QuickBooks Online accepts a bank CSV of exactly three columns (Date, Description, Amount) or four (Date, Description, Credit, Debit), in English, under 350 KB, and under 1,000 transactions. A NetSuite saved search export carries account, internal ID, memo, class, department and location columns that QuickBooks does not expect and will not ignore.

The row cap is the sharper problem for anyone leaving an ERP. NetSuite will happily hand you 20,000 rows and QuickBooks Online will take 1,000 at a time, so a single year of card activity fails on upload with no useful error. Converting to .qbo sidesteps the column mismatch entirely because the converter maps the headers itself, and splitting the export by month or quarter keeps each file under the size cap. The same 350 KB ceiling applies to .qbo, .qfx and .ofx files, not just CSV.

MM/DD/YYYY for a US company file. This catches people out because the Intuit CSV formatting article that ranks best in search is the global edition, and it recommends DD/MM/YYYY. Follow it against a US QuickBooks file and every transaction dated before the 13th of a month silently lands on the wrong day.

Excel adds a second trap on the way through. Opening a NetSuite CSV in Excel and saving it again can rewrite two digit years, where 00 to 29 become 2000 to 2029 and 30 to 99 become 1930 to 1999, and a workbook moved between Windows and Mac shifts every date by four years and a day because the two default to different date systems. If you have to touch the file in Excel, import it as text rather than double-clicking it.

A .qbo import protects itself. Every OFX and .qbo transaction carries a FITID that is unique within the account, and QuickBooks skips any FITID it has already seen, so re-running the same file does not double your ledger. A raw CSV has no transaction identifier at all, which is why CSV imports are the ones that duplicate.

Two cautions. QuickBooks remembers a FITID even after you delete the transaction, so re-importing a file to restore a row you deleted by mistake will not work; you have to enter it manually. And if you leave a live bank feed connected while you import history, the feed and the file will both deliver the overlap period. Disconnect the feed, or import only up to the day before the feed starts.

Use the first day of a fiscal year if you can and the first day of a quarter if you cannot. A clean year boundary means your NetSuite trial balance at year end becomes the QuickBooks opening balance with no partial period arithmetic, and it keeps the prior year filed and closed in the system that produced it.

Whatever date you choose, freeze NetSuite on it. Post nothing new to the old system after cutover, even for a day, because a stray journal entry in NetSuite after the line has been drawn is invisible in QuickBooks and turns up months later as an unexplained trial balance difference nobody can source.

Run three comparisons at the cutover date. Bank and credit card balances in QuickBooks against the actual statements. A trial balance from NetSuite against the trial balance in QuickBooks, account by account. And AR and AP aging totals in both systems. If all three tie, the migration is done, whatever else is still cosmetic.

Do this per period rather than once at the end. Converting and reconciling a quarter at a time means a mapping error shows up in the first quarter, when fixing it costs an hour, rather than after four years of history have landed on the same wrong account. Accountants running several of these will find the batch workflow on the CSV to QBO converter for accountants page more useful than doing it client by client.

Upload the NetSuite CSV at the top of this page. The converter reads the headers a NetSuite saved search writes, normalizes dates to the US format QuickBooks expects, works out the sign convention for bank versus credit card accounts, and returns a balanced .qbo file with a unique FITID on every row. It totals the transactions before the download so you can check the figure against NetSuite before anything reaches your books.