Starting a Fresh QuickBooks Desktop Company File When Repair Fails
When Verify and Rebuild stop holding a damaged Desktop file together, a disciplined restart can keep your lists, balances, and history intact.
A QuickBooks Desktop file that fails Verify, survives a Rebuild, then fails the same way again is telling you something. Our engineers read that pattern as structural damage rather than a stubborn glitch. This playbook covers the restart: freezing the evidence, setting a cutover date, carrying lists and opening balances into a new file, and proving the result in a parallel run.
When do you stop rebuilding and call it?
Rebuild is a blunt tool. It rewrites damaged records in place and cannot judge whether the structure around them still hangs together. Our engineers stop recommending repair cycles when three signals line up.
First, Verify keeps failing on the same targets after a Rebuild that reports success. Second, the damage reproduces: the same error, the same out-of-balance report, the same crash on the same operation. Third, the failure sits in linking, not display. Broken transaction links and a balance sheet that will not balance are structural; a misprinted memo is not.
At that point, do not run another Rebuild. Every pass rewrites the whole file, and each rewrite of an unsound file risks data a direct extraction could still reach. The call between repairable and beyond repair should rest on the file itself. Our QuickBooks Verify and Rebuild repair service exists for exactly that judgment: an engineer examines the file before anyone commits to a restart.
Freeze the evidence before you change anything
Collect the old file before the new one exists. Copy the company file and its companions: the transaction log, recent backups, any Accountant's Copy, and any portable copy predating the damage. Store the set where nobody can post into it.
Work on copies from this point forward. If the old file still opens, keep daily posting in it until the cutover date, but stop every repair attempt. This frozen set is the project's rollback point. No later phase deletes it, and any phase can restart from it.
Set the cutover date before you build anything
The cutover date is the boundary between the two files. Everything before it becomes opening balances in the new company. Everything after it is posted fresh, transaction by transaction.
Pick a boundary the books already respect: fiscal year end, quarter end, or at minimum month end. Mid-period cutoffs force you to split bank statements and payroll cycles by hand, so avoid them. Tell everyone who posts, and treat the date as hard. If it must move, move it back to the last closed period, never forward into open books.
Build the new file and carry the lists across
Create the new company in the same edition and version year as the old one, or newer. Set the preferences you depend on before importing anything.
Export each list to Excel from the old file and import it into the new company: chart of accounts, customers, vendors, items, other names, tax codes. Import day is also cleaning day. Merge duplicate names, mark dead accounts and customers inactive, and drop what you no longer use. A file pressing the 14,500 name limit needs genuine QuickBooks list reduction, not a light trim.
Two constraints deserve respect. An item's type locks once the item carries transactions, so settle inventory versus non-inventory per item during import. Multicurrency cannot be switched off once enabled, so decide it at setup if the old file uses foreign currencies.
Load opening balances you can defend
Draft the opening balances from the old file's cutoff-date trial balance, then distrust them. Cross-check every material figure against sources outside the damaged file. Bank statements prove cash, aged reports prove receivables and payables, a count proves inventory, and filed returns prove tax and payroll liabilities.
Enter the result as one journal entry dated the cutoff, routed through Opening Balance Equity and then cleared to proper equity. A single dated entry is a clean rollback point: reverse and re-enter it if a check exposes a wrong figure.
Inventory is the exception. Bring quantities and costs in per item so quantity on hand agrees with the inventory asset account. Then reconcile the first bank statement in the new file. A clean first reconciliation is the strongest single proof that cash carried over correctly.
Run the two files side by side
From the first day after the cutoff, post every transaction in the new file. If the old file is stable, post the same transactions there as a shadow. If it is not, freeze it at the cutoff and use its reports as a read-only reference.
Hold the parallel run for at least one full closed period, two when payroll or heavy inventory is involved. At each close, compare trial balances, receivable and payable agings, and bank reconciliations. Every difference must be explained line by line. Never plug a gap to force agreement; an unexplained difference is usually the old damage showing through, and it belongs on the investigation list.
Cut over, then retire the old file
Once the parallel period closes clean, all posting happens in the new file only. In the old file, set a closing date with a password and take a final backup. Label the frozen set as the archive of record for everything before the cutoff.
Write the decisions down while they are fresh: which lists were merged, which names were dropped, how each opening balance was sourced. A later audit will ask, and the answers should not live in one person's memory.
What does a clean outcome look like?
Three checks define done. The new file passes Verify and keeps passing after a full period of real posting. Its cutoff-date balance sheet agrees with the old file, with every difference documented to zero. The first bank and credit card reconciliations complete without adjusting entries.
When those hold, the restart has done its job. The damaged file becomes an archive, and the books move forward on structure you can trust.