Sage 100 to QuickBooks Conversion: Convert Sage 100 to QuickBooks Online

Yes, but not with an Intuit tool. Every Sage 100 to QuickBooks conversion is either a manual rebuild or a paid job handed to a specialist conversion shop. Intuit's conversion tool documentation explicitly lists Sage100 among the products it does not work with, and the funded Dataswitcher route covers only Sage 50 US edition and Xero. Nothing automated ships from Intuit for Sage 100.

This surprises people because Sage 50 leavers get so much help. Intuit pays for the last two fiscal years of a Sage 50, Xero or QuickBooks Desktop conversion. A Sage 100 leaver pays for one hundred percent of the work, or does it themselves. The distinction is not about the Sage brand, it is about which specific products Dataswitcher has built importers for, and Sage 100 is not one of them.

No. Intuit's article on converting from Sage 50 to QuickBooks Desktop states that the conversion tool does not work with Peachtree, Sage 50 versions 2014 or older, Sage100, Sage 300, or the Sage industry specific products, and adds that users can still move their data with Excel. Sage 100 is named on that exclusion list, so this is not an untested edge case or a version problem you can work around by upgrading.

The Intuit community forums carry the same answer in blunter form, including threads from Sage 100 owners asking for a help ticket to have their data files converted and being told the tool does not support them. Take the exclusion at face value and plan a spreadsheet based move from the start rather than losing a week discovering it.

Work in the order the books were built. Set up the chart of accounts first, then customers, vendors and inventory items, then opening balances as of a chosen cutover date, then transaction history. Every later step depends on the accounts and lists existing, so a shortcut here creates rework that is far more expensive than the time it saves.

Pick a cutover date that lands on a period end you have already closed and reconciled in Sage 100. A mid month cutover means reconciling a partial period against a bank statement that does not stop where your data stops, which is the single most common reason a conversion drags on. Close the month in Sage 100, reconcile it there, and use that date as the line.

The everyday route is Business Insights Explorer. Open the view you want, choose File then Export Options, and pick a format. Sage's documentation lists Microsoft Excel, Microsoft Access, Microsoft Word, a Microsoft Query Definition file, XML, a text file that is comma or tab delimited, and HTML. You need Excel, Word or Access installed locally to export to those formats, and you can limit the export to selected rows by holding SHIFT or CTRL while you select.

Two details in that list catch people out. The Microsoft Query Definition option exports no data at all, only the DSN and the SQL statement behind the view, so it looks like an export and produces nothing usable for a migration. And exporting to XML also writes a matching .xsl stylesheet file alongside it. For a migration you want the comma delimited text option or Excel saved down to CSV.

Use Visual Integrator rather than the Explorer grid. Visual Integrator is Sage 100's import and export module, and its Export Job Maintenance task defines a reusable job that names a table, a destination, a field mapping and selection criteria. Data from any Sage 100 file can go out to an ODBC database or an ASCII delimited file using the same selection logic available to import jobs, and jobs can be scheduled to run on their own.

For a conversion this matters because you will export the same shapes repeatedly as you test. Building a job once for GL detail, once for AR open items and once for bank activity means each re run is a click rather than a rebuilt query. Save the jobs, because you will run them again when a validation pass turns up a gap.

Sage 100 account numbers carry segments for things like division, department, warehouse or product line, and QuickBooks has nothing shaped like that. QuickBooks gives you an account, plus classes and locations as separate tracking dimensions. So a Sage 100 account structure has to be flattened into a shorter account list with the segment meaning moved sideways into classes or locations.

Decide that mapping before you export anything, because it determines how many accounts you end up with and which QuickBooks plan you need. Class and location tracking starts at QuickBooks Online Plus, so Simple Start and Essentials have nowhere at all to put a segment. QuickBooks Desktop has classes in every edition but no separate location field. Getting this wrong means a chart of accounts that multiplies every account by every division.

Items and quantities move. The costing method usually does not. Sage 100 supports several valuation methods including FIFO, LIFO, average, standard cost and lot or serial costing. QuickBooks Desktop values inventory at weighted average cost, with FIFO available only in Enterprise with Advanced Inventory, and QuickBooks Online tracks inventory on Plus and Advanced only, using FIFO.

That means LIFO and standard cost have no destination. If your Sage 100 file is on either, the conversion is a restatement, not a transfer, and the difference has to be booked and explained. Talk to your CPA before the cutover rather than after, because a change in inventory valuation method has tax consequences that are not a bookkeeping detail. Also note that journal entries cannot carry inventory items in QuickBooks, so you cannot paper over an inventory gap with a journal.

Assume nothing transfers automatically and treat anything that does as a bonus. Beyond the costing methods and account segments already covered, custom reports built in Crystal Reports do not move, which conversion specialists state plainly in their own scope documents. Sage 100 customizations, user defined fields, module specific workflows such as job cost detail, and any third party module bolted onto the ERP all stop at the boundary.

The honest way to read that list is as a scope document rather than a loss. Most of what does not transfer is either reporting you can rebuild once in the new system or complexity you were carrying because the ERP allowed it. Write down which reports the business actually reads each month, and rebuild only those.

Independent conversion shops price a Sage 100 job well above a small business file. Numerawise publishes a fixed price range of $2,000 to $6,000 for Sage 100 on its dedicated page, with a quote returned within one business day, and its general conversion page puts mid market files with inventory or payroll history in a $2,000 to $5,000 band against $500 for a small single entity file. Those are the vendor's own published figures as of August 2026.

Other shops in this market publish no price at all. Dancing Numbers and MMC Convert both sell Sage 100 conversions and quote only on request. Doing it yourself trades that fee for your own time, and the realistic split is that a specialist earns the fee when inventory, payroll history or multiple entities are involved, while a clean single entity file with a couple of years of history is genuinely doable in house.

Published timelines cluster around two to six weeks. Numerawise states two to three weeks for a standard single entity conversion and four to six weeks where there is multi entity structure, heavy inventory or full payroll history. MMC Convert describes completing its migration in three to five working days once it has the file, with a quality analysis report and a comparative trial balance at the end.

Those numbers describe the vendor's work, not your project. Add your own time for deciding the account mapping, cleaning up the Sage 100 file before export, testing, and running both systems in parallel for a period. A realistic internal plan for a single entity is a month from decision to full cutover.

You can move to Desktop, but not with the conversion tool, which excludes Sage 100 for Desktop just as Dataswitcher excludes it for Online. On Desktop the mechanics split by data type. Lists go in through the QuickBooks Import Excel and CSV Toolkit, which handles exactly four list types: customers, vendors, items and the chart of accounts. Transactions cannot follow that path.

This is the point most people miss about Desktop. QuickBooks Desktop cannot import a bank or card CSV in any version. Its only routes for transactions are a .qbo Web Connect file through Bank Feeds, or an IIF file that posts straight to the ledger with no review and no undo. Converting your Sage 100 CSV exports to .qbo gives you the reviewable route instead of the irreversible one.

Let the shape of the Sage 100 file decide. If you track inventory, you need QuickBooks Online Plus or Advanced, because Simple Start and Essentials do not track inventory at all. If you are mapping account segments into classes or locations, that also starts at Plus. If your flattened chart of accounts is large, check the account limits on the plan you are considering before you commit.

Sage 100 shops are the group most likely to need Advanced rather than Plus, because the things that made an ERP worth buying, multiple dimensions of reporting and a deep chart of accounts, are the same things that push past the Plus thresholds. Price the destination at today's rate rather than a figure you remember, since Intuit changed QuickBooks Online monthly pricing for renewals on or after August 1, 2026.

Export the activity from Sage 100 as a delimited file, convert it to .qbo, and import it through Bank Feeds. Going in as a raw CSV instead runs into hard limits: QuickBooks Online accepts a CSV with three columns of date, description and amount, or four columns of date, description, credit and debit, in English only, at a maximum of 350 KB and 1,000 transactions per upload.

That 1,000 transaction ceiling is the squeeze that defines an ERP exit. Sage 100 will happily hand you an export with tens of thousands of rows through Visual Integrator, and the destination takes a thousand at a time. A .qbo file is not held to the CSV row limit in the same way, though the 350 KB cap does apply to .qbo, .qfx and .ofx files too, so very large years still get split by period.

Not with .qbo files. Every transaction inside an OFX or .qbo file carries a FITID, a transaction identifier that is unique within the account and never reused. QuickBooks skips FITIDs it has already seen, and it remembers them even after you delete the transaction, which is why a re import of a corrected file lands cleanly rather than doubling your balances.

A plain CSV has no equivalent. Nothing in a CSV identifies a transaction, so QuickBooks has no way to tell a genuine second $412.00 payment from the same one uploaded twice. During a migration, when you will re run exports several times as validation finds gaps, that difference is the whole argument for converting to .qbo first.

Use MM/DD/YYYY for a United States QuickBooks company file. The Intuit help article that ranks highest for CSV formatting is the global edition, which recommends DD/MM/YYYY, and following it in a US file silently misposts every transaction dated the 1st through the 12th of a month into the wrong month. Nothing errors, the numbers just land wrong.

Watch the spreadsheet as well as the export. Two digit years from 00 to 29 resolve to 2000 through 2029 and 30 to 99 resolve to 1930 through 1999. Windows Excel defaults to the 1900 date system and Mac to 1904, so a workbook passed between them shifts every date by four years and a day.

Reconcile every balance sheet account against its source before you call the conversion finished, and do it for the first full period after the cutover as well. The trial balance in QuickBooks as of the cutover date should match the trial balance in Sage 100 as of the same date, line for line. If it does not, find it now, while both systems are still open in front of you.

Three diagnostics resolve most differences quickly. A difference that divides evenly by nine is transposed digits somewhere. A difference exactly equal to twice a transaction is a sign flip, which shows up constantly on credit card accounts because the sign convention reverses. A difference that matches one transaction exactly is a row that either did not convert or got accepted twice.

Keep it live longer than feels necessary. Run both systems in parallel until you have reconciled at least one full period in QuickBooks and closed it, and keep read access for as long as your retention policy and your auditors require. An ERP file is not something you can casually re open once the licence lapses.

Before anything gets switched off, export everything you might conceivably want later: the full general ledger, trial balances by period, AR and AP aging as of the cutover, inventory valuation, payroll registers, and the customer and vendor master lists. Store them as flat files somewhere outside the ERP. Sage 100 subscriptions are priced per named user per month and billed annually according to ERP advisory sites, so the parallel period has a real cost, but it is far smaller than the cost of discovering a gap after the file is gone.

Upload a Sage 100 CSV export at the top of this page. The converter reads the column headers a Business Insights Explorer or Visual Integrator export writes, normalizes dates to the format a US QuickBooks file expects, turns separate debit and credit columns into signed amounts, and writes a balanced .qbo with opening and closing balances and a unique transaction ID on every row. There is no column template to build first, no 1,000 row ceiling, and the output imports through Bank Feeds in both QuickBooks Online and QuickBooks Desktop.