Sage Intacct to QuickBooks Migration: Convert Sage Intacct CSV Exports to QBO

Move the lists first, then the transactions, then reconcile. Export the chart of accounts, customers and vendors from Intacct as CSV and load them through QuickBooks' own list import. Then export bank, credit card and journal activity by period, convert each file to .qbo, and bring it in through Bank Feeds so QuickBooks matches and de-duplicates as it goes. Finish by tying the QuickBooks trial balance back to Intacct at the cutover date.

The sequencing matters more here than in most migrations because of how Intacct account numbers are built. An Intacct chart is usually short and flat, with the analytical detail carried in dimensions rather than in the account itself, which is the opposite of how most QuickBooks charts grow. If you load transactions before you have decided what the QuickBooks chart looks like, every row lands against a placeholder and you end up reclassifying thousands of lines by hand. Build the target chart, map Intacct accounts to it in a spreadsheet, then start converting.

Not from Intuit and not from Sage. Intuit publishes two conversion routes and Sage Intacct appears on neither. The free QuickBooks Conversion Tool takes Quicken and Sage 50 into QuickBooks Desktop. Dataswitcher, Intuit's supported partner for QuickBooks Online, currently accepts Sage 50, Xero, Acomba and QuickBooks Desktop. Third party firms do sell Intacct to QuickBooks projects, but they are doing the same export, map and import work by hand.

There is a detail worth knowing before you shop for help. Intuit covers the cost of moving the last two years of data for QuickBooks Desktop, Sage 50 and Xero, and one year for Acomba. Someone leaving Xero pays nothing for their conversion. Someone leaving Intacct pays for all of it. That is not a small difference when you are building the business case, and it is the single strongest reason to do the transaction half yourself with a converter rather than buying a full-service project you may not need.

Two ways, depending on volume. For anything you can express as a report, open it in the Reports center, add any required parameters such as location or department, then choose Export and pick the format from the dropdown. Sage Intacct offers HTML, CSV, PDF, Excel, Word, Text and XML depending on the report type. For bulk extracts, Company then Setup then Data Delivery Service exports whole objects to CSV files and posts them to cloud storage you configure.

For a QuickBooks migration, use reports rather than Data Delivery Service unless you are moving a very large file. Reports let you filter by date range and account, which is exactly how you want to slice a migration: one period at a time, one account at a time. Data Delivery Service is built for feeding a data warehouse, it writes to cloud storage rather than your desktop, and it exports whole objects with every field attached, which means more cleanup before QuickBooks will look at the file.

Run the General Ledger report, set the period to the range you are converting, then use Export and choose CSV. Keep Date, Account, Description or Memo, and the debit and credit columns. If you are converting bank or credit card activity specifically, the account activity report for that single GL account is a cleaner source than the full ledger, because it is already scoped to one account, which is exactly how a .qbo file has to be built.

Export CSV rather than Excel here even if Excel feels more convenient. Sage Intacct's Excel export writes the older .xls format, which stops at 65,536 rows, and a year of ledger detail from a mid-market company can pass that without anyone noticing. A truncated export is worse than a failed one, because the file opens, looks complete and quietly balances to the wrong number. CSV has no such ceiling, and it is also the format the converter above reads.

There is no single published figure, which is itself the thing to plan around. The hard limit people actually hit is the 65,536 row cap on Sage Intacct's .xls Excel export. The specialist DATEV export caps a posting batch at 99,999 records and Sage's guidance there is to run several shorter periods. Sage does not publish a row limit for CSV report exports, so treat large exports as untested rather than safe.

The practical rule is to export by period and count the rows every time. If a month of activity comes out at 4,000 rows and the year comes out at 41,000, something dropped. Reconciling each period against the Intacct trial balance as you convert it catches truncation on the spot, and it splits the work into pieces small enough that a mistake costs you one month instead of one year.

No. Sage Intacct has no QuickBooks export format and QuickBooks has no Sage Intacct importer. The formats QuickBooks accepts for transactions are .qbo Web Connect, .ofx, .qfx and, on QuickBooks Online only, a plain bank CSV. Intacct writes none of those. So the file has to be converted in between, which is what the tool at the top of this page does: Intacct CSV in, valid .qbo out.

You will find marketplace listings that describe an Intacct to QuickBooks connector. Read them carefully, because most of them run the other direction, pushing QuickBooks data up into Intacct for companies growing into the ERP rather than out of it. Sage's own marketplace is built for adding capability to Intacct, not for leaving it, and there is no commercial incentive for either vendor to build a clean exit path.

Full-service conversions are quoted from a few thousand dollars up, and the DIY route costs a converter subscription plus your own time. Numerawise publishes a fixed price from $3,500, with most projects landing between $3,500 and $10,000 depending on entity count, dimension usage and how much history you carry. Dancing Numbers and MMC Convert both sell Intacct conversions and neither publishes a price, so you get a quote per file.

Attribute those figures rather than treating them as a market rate, because scope drives them completely. A quote at the low end usually covers lists plus one or two years of transactions with a trial balance tie-out. The upper end is multi-entity work, dimension mapping and rebuilt reporting. Numerawise also states a 4 to 6 week base timeline with roughly two more weeks per additional entity, and includes 30 days of post-conversion support, which is a fair benchmark for what a fixed-price engagement covers. Our breakdown of what a Sage Intacct to QuickBooks migration costs works through the DIY route, the vendor quotes and the costs that never appear in a quote.

Weigh that against what you stop paying. Published Sage Intacct estimates from ERP advisory sites put per-user pricing at roughly $400 to $800 per named user per month, with entry deployments starting around $12,000 a year and typical annual subscriptions in the $25,000 to $35,000 range. Against a QuickBooks Online subscription in the low thousands, the conversion usually pays for itself inside the first year, which is why the cost question is rarely the one that stops a migration.

They flatten, and you pick which one survives. Sage Intacct tags every transaction with multiple dimensions at once: department, location, project, customer, vendor, employee and any custom dimensions you built. QuickBooks Online has two comparable fields, classes and locations, and QuickBooks Desktop has classes. So a company running four active Intacct dimensions has to decide which two matter enough to keep and where the rest go.

Decide this before you export anything, because it changes the shape of every file. The usual answer is to map the dimension you report on most often to classes, the one closest to a physical or legal split to locations, and push a third into the account structure by splitting accounts. Note that class and location tracking starts at QuickBooks Online Plus, so a Simple Start or Essentials subscription gives you nowhere at all to put a dimension. Check the plan before you promise anyone the reporting will survive.

Anything QuickBooks has no field for. Dancing Numbers, which sells these conversions, lists complex multi-entity structures, detailed project accounting, highly customized reports, detailed audit trail information and advanced user permission settings as things that do not carry across, and notes that certain transaction types arrive as journal entries rather than in their original form.

The Intacct-specific layer has nowhere to land either. Dimensional accounting has to be flattened, multi-entity consolidation has no QuickBooks equivalent at all, and contract revenue management, dynamic allocations and Intacct's approval workflows simply stop existing. Budgets, memorized report definitions and attachments are the quiet ones that catch people, so decide now whether you archive them or rebuild them, rather than discovering the gap during your first month-end close in QuickBooks.

No. QuickBooks Desktop cannot import bank or credit card transactions from a CSV in any version, Enterprise included. The Import Excel and CSV Toolkit that Intuit ships handles exactly four list types: customers, vendors, items and the chart of accounts. Transactions have to arrive as a .qbo Web Connect file through Bank Feeds, or as 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, .qbo is the safer choice, because it lands in the Bank Feeds review queue where you can check and match before anything posts. An IIF import writes directly to the ledger with no undo, which is a poor place to discover a mapping error across 8,000 rows.

Usually because the file 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 per upload. An Intacct report export arrives with account codes, dimension columns, entity identifiers and reference numbers attached, and QuickBooks rejects the file rather than ignoring the extra columns.

The row cap is the sharper problem for anyone leaving an ERP. Intacct will hand you a year of ledger detail in one file and QuickBooks Online will take 1,000 rows at a time, so a real migration becomes dozens of hand-split uploads. Converting to .qbo removes both limits at once, because a .qbo file has no transaction count ceiling and carries the account structure inside the file rather than in a column layout you have to match.

MM/DD/YYYY for a US company file. This trips people up because the Intuit CSV formatting article that ranks best in search is the global edition, which recommends DD/MM/YYYY. Follow it against a US file and every date from the 1st to the 12th of a month imports silently to the wrong day, while the 13th onward fails outright, which is the confusing part: a partly successful import looks like a formatting quirk rather than a systematic error.

Excel adds a second trap on the way through. Opening an Intacct CSV in Excel and saving it again can rewrite two digit years, where 00 to 29 becomes 2000 to 2029 and 30 to 99 becomes 1930 to 1999. A workbook moved between Windows and Mac shifts every date by four years and a day, because Windows defaults to the 1900 date system and Mac to 1904. If you must open the file, open it and close it without saving, or convert straight from the export.

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. Convert overlapping date ranges by accident and the second file simply contributes nothing. A raw CSV has no transaction identifier at all, which is why re-running a CSV upload after a partial failure is the most common way people end up with a doubled bank feed.

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, and you have to enter it manually. And if any account is also receiving rows through an API integration rather than a bank feed, those rows carry no FITID, so keep the converted date ranges from overlapping what the integration already posted.

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 the Intacct trial balance at year end becomes the QuickBooks opening balance, with nothing to split. Mid-year cutovers work but you carry a partial year in one system and a partial year in the other, so every annual report for that year has to be assembled from two sources.

Whatever date you choose, freeze Intacct on it. Post nothing new to the old system after cutover, not even for a day, because a stray journal entry in the closed system is invisible until a reconciliation fails months later. Keep read-only access for a full year afterward if your contract allows it, since prior year comparatives and any audit request will send you back to the source, and re-subscribing to an ERP for one report is an expensive way to find that out.

Run three comparisons at the cutover date. Bank and credit card balances in QuickBooks against the actual statements. A trial balance from Intacct against the trial balance in QuickBooks, account by account. And AR and AP aging totals against the open item lists you re-entered. If all three tie, the migration is done. If one does not, the difference itself usually names the problem.

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 rather than after you have loaded three years on top of it. A difference that divides evenly by nine is almost always transposed digits. A difference equal to exactly twice a transaction is a sign flip, which on an Intacct export usually means a credit column was read as a debit.

Upload the Sage Intacct CSV at the top of this page. The converter reads the column headers an Intacct report export writes, normalizes dates to the US format QuickBooks expects, splits separate debit and credit columns into signed amounts, and writes a balanced .qbo file with opening and closing balances and a unique transaction ID on every row. No column template to build, no 1,000 row limit, and the output imports through Bank Feeds in both QuickBooks Online and QuickBooks Desktop.