QuickBooks Error C=304: Damaged Chart of Accounts Record

Error C=304 stops QuickBooks Desktop when a chart of accounts record is damaged; here is what the code means and how to get your file working again.

Error C=304 belongs to the C= family of QuickBooks Desktop codes, the ones the program uses for internal data trouble. This particular code points at the chart of accounts, where a single record has been damaged. Our engineers meet it at file open, during list work, and most often during a verify run. In most files the damage is limited, and a rebuild clears it. This page covers what the code means, what causes the damage, and the steps that fix it, most common first.

What does the C=304 message say?

You meet this code in one of two forms. The first is a small dialog that reads "Error: C=304", or in some releases just "C=304", occasionally with "QuickBooks has encountered a problem and needs to close." The second form appears in the Verify Data results, which report "A data problem prevents QuickBooks from continuing" and name C=304 as the fault. The surrounding wording shifts between versions. The code itself is the part that stays constant.

What does the code mean?

C= codes are internal. QuickBooks writes one when its database engine meets something it cannot read or write cleanly. C=304 points at the chart of accounts. A field in one account record may be unreadable, the link from that account to its transactions may be broken, or the list's internal index may no longer match the records underneath it.

The program will not open a damaged record, and it will not skip past one. That is the constraint you are hitting. Rather than show you a half-readable account, QuickBooks halts and hands you the code.

What triggers it?

An interrupted write leads the list. A power failure, a forced shutdown, or a dropped network connection can each leave an account record half written. So can a sync client, such as OneDrive or Dropbox, that touches the company file between the program's own writes.

A version upgrade comes next. When an older file is converted to a newer release, the account list is rebuilt, and a record that converts badly can surface later as C=304.

Two more paths appear in the files we handle. Very large company files, grown over many years, strain the structures that keep the chart of accounts indexed. Third-party add-ons that write directly to the file can also leave records the program later refuses to read.

How do you fix it?

Run verify and rebuild. This clears most C=304 cases and takes one sitting.

1. Back up first. Choose File > Back Up Company > Create Local Backup, with complete verification selected. Keep that backup until the file verifies clean.
2. Switch to single-user mode from the File menu, so nothing else writes to the file while you work.
3. Run File > Utilities > Verify Data and note what the results window reports.
4. Run File > Utilities > Rebuild Data. A rebuild makes its own backup; let it finish even if the progress bar appears stuck near the end, which is normal.
5. Verify again. If damage is still reported, rebuild a second and third time. Repeat passes are expected with list damage.
6. Close the company file, reopen it, and repeat the action that produced the error.

Restore a backup if a rebuild does not clear it.

1. Back up the current file under a new name first. Never overwrite the damaged copy.
2. Restore the most recent backup that predates the error, then run Verify Data on it.
3. If the restored file verifies clean, re-enter the transactions recorded since that backup, and verify once more afterward.

If verify still names C=304, take two further steps.

1. Copy the file to a local drive if it lives on a network share, open it there, and run the verify and rebuild cycle again. Network overhead can stop a rebuild from completing.
2. Resort the account list. Open Lists > Chart of Accounts, click the Name column heading so the list sorts, then close and reopen the window. Sorting rewrites the list's internal order and clears some index damage by itself. Verify once more after resorting.

Beyond that point, the record itself needs repair inside the data tables. Our engineers perform that repair directly, and it does not require re-creating your chart of accounts or re-entering history.

How do you keep it from coming back?

Prevention is mostly about protecting writes.

Back up on a schedule, with complete verification selected, so damage is caught while it is still small. Let QuickBooks finish a task before shutting down; a forced quit during a save is a common seed of this code. Keep the live company file out of cloud sync folders. On a network, keep the host machine on a wired connection, and let only that machine host multi-user access.

Update QuickBooks when a release appears, since updates often include fixes for the database engine. Run Verify Data every month or two; a dirty result found early is a small repair. If the file has grown very large, condensing closed periods shrinks it and lowers the odds of this class of damage.