A Coworker Converted the Company File: Getting Everyone Back on One QuickBooks Year
A newer QuickBooks year on one workstation converted the shared company file, and older releases now refuse it; here is how to get the team back in sync.
Someone on the team installs the new year's QuickBooks, opens the shared company file to check one report, and the conversion runs before anyone notices. From that moment the file carries a newer internal format than the release the rest of the office runs, and their copies refuse to open it. The data is not gone and the file is not damaged; it is simply ahead of the software. There are two ways back, and the right one depends on how much work has been posted since the conversion.
Why do older releases refuse a converted company file?
Every annual release of QuickBooks Desktop writes its own company-file format. When the new year's release opens an older file, it rewrites the internal structure where the format changed and stamps the file with the new format version. That rewrite is deliberate, which is why the converted file behaves normally on the workstation that did it.
An older release reads that stamp first. When it finds a format written by a year it does not know, it stops with a message about the file having been used in a newer version. It will not try to cope, because writing to a structure it cannot fully read risks silent data damage. The move is one-way: QuickBooks has no command that saves a file back into an older year's format.
The split often goes unnoticed for a few days, because the converted file keeps opening normally on the machine that converted it. Meanwhile the shared copy serves half the team a refusal.
First, stop the split from spreading
Decide which way back you are taking before anyone else opens the file. Every day of work posted on both sides makes the reunion harder, because one side of the history has to be re-entered or matched later.
Press F2 on every machine that touches the file and read the year and release in the Product Information window. The workstation that did the conversion shows the newer year; everyone else shows the old one. Have all users exit the company file, and keep further work in single-user mode until the file is back on one year.
Way one: restore the pre-conversion copy
Before converting, QuickBooks saves a copy of the file in the older format so the upgrade can be survived. Look in the folder that holds the company file for a copy named after the old company name; that is the pre-conversion file. A manual or scheduled backup taken shortly before the conversion serves just as well.
- Confirm every user has exited the file, then move the converted file out of the shared folder rather than deleting it.
- On a workstation running the older year, restore the pre-conversion copy or backup into the shared folder.
- Open the restored file in single-user mode and run Verify Data under File, Utilities.
- Compare the restored copy against the converted file for anything posted after the conversion, and re-enter it.
A few days of invoices and payments re-keys quickly; several weeks may be faster to rebuild from transaction reports.
If Verify reports damage in the restored copy, do not run Rebuild on it. A rebuild can lock some kinds of corruption in place permanently. Send the damaged file, with its matching .TLG, to our QuickBooks file repair service. Standard turnaround is 48 business hours, and we return the repaired file with our findings on the cause.
Way two: downgrade the file to the team's year
If the converted file already holds weeks of work, or re-entry is not practical, take the file down to the year the team runs instead. QuickBooks cannot do that internally, so the file has to be rewritten into the older format by engineers who work with the format directly. That is a QuickBooks version downgrade, and the converted file you already have is the correct starting point.
To scope the downgrade, we need the converted .QBW file or a backup of it, plus a screenshot of the Product Information window (F2). We also need the exact release on the file, the exact year the team is returning to, the admin password, and whether the file is a non-US international edition.
Lists and transaction history carry down into the older year. Features that only exist in the newer year's format do not, and we flag anything affected before the file comes back to you. Once the downgraded file is in place, bring the workstation that did the conversion back to the team's year before it opens the file again.
How do you stop it happening again?
The trigger is one machine running a different year from the rest. Keep the whole team on one year and one release, and treat the annual move as a planned project. Everyone upgrades in the same week, and the first person to open the company file does it after a fresh backup.
Maintenance releases within a year do not move the file format, so routine automatic updates are harmless here. The danger is the year boundary, and it arrives quietly. A trial install of the new year, or a machine that has updated itself ahead of the team, converts the file the first time someone opens it. If a second year must exist for any reason, it gets its own separate copy of the data, never the live company file.
An hour of planning around versions is far cheaper than a weekend of re-entry.