How to use the trio for diagnosis: In QBWin.log, search C=73 and read the Verify Target. If C=21 and C=179 also appear pointing to the same record: all three levels failed on that record. Fix the C=21 first (field-level issue) — in many cases, this cascading fix also resolves C=73 and C=179 on the same record because C=73's cross-record reference failure is itself caused by the invalid field value that C=21 flagged. Open the named record → fix or resave → Verify again. If C=73 remains while C=21 is resolved: the cross-record reference itself (not just the field) is broken and the referenced record needs repair too.

Broken Cross-Record Reference

Primary C=73 cause — a transaction or record contains a reference (a pointer) to another record (customer, vendor, account, item) that is in an invalid state. The reference exists but what it points to has been damaged, deleted, or merged in a way that left the reference unresolvable. QB's cross-record validator flags this as C=73.

Cascade from C=21 Field Failure

When a record has an invalid field value (C=21), QB's cross-record validation often also fails on that record because the invalid field value disrupts the record's ability to correctly reference other records. C=73 appears as a downstream consequence of the C=21 failure. Fixing the underlying field corruption often clears both codes.

Referenced Record Deleted or Merged

A customer, vendor, item, or account referenced by existing transactions was deleted or merged with another record improperly. The transaction's reference now points to a record that no longer exists at the expected location, producing C=73 on every transaction that referenced the removed record.

Interrupted Multi-Table Write

QB transactions write to multiple internal tables simultaneously. A crash mid-write leaves some tables updated and others not — creating cross-record inconsistency. Record A was updated to reference Record B, but Record B's back-reference to A was never written. C=73 flags the one-sided reference.

Data Imported with Unresolvable References

IIF or SDK imports that reference customers, vendors, or accounts by ID that don't match existing records in the QB file create unresolvable references. QB creates the transaction but the cross-record reference fails validation at Verify time, producing C=73.

General File Corruption

Broader disk or file corruption can damage cross-record reference pointers throughout the file, producing C=73 across many Verify Targets. When C=73 appears across many different record types in a single Verify run, broader file repair (Rebuild or restore from backup) is needed.

METHOD 1 Update QB + Read QBWin.log + Fix Named Record + Verify/Rebuild Primary C=73 sequence

METHOD 2 Find and Repair the Referenced Record C=73 persists after Rebuild — broken reference

METHOD 3 Run File Doctor + Restore from Backup C=73 LVL_SEVERE_ERROR or across many records

If fixing C=21 also fixes C=73 on the same record, why does QB report both codes separately?

QB's Verify Data runs multiple validation passes at different levels of the data hierarchy. Each pass is independent — if a record fails the field-level check (C=21), QB doesn't stop there; it continues with the cross-record validation check and the structural check, generating C=73 and C=179 as additional errors on the same record. This multi-pass approach gives you a complete picture of all the ways a record has failed validation, not just the first failure found. In practice, the C=21 field failure is usually the root cause that cascades into C=73 and C=179. Fixing the root cause (resaving or re-entering the record to clear the invalid field) causes all three validation levels to pass on the next Verify run, clearing all three codes simultaneously. The fact that three codes appeared doesn't mean three separate problems — it means one problem that failed three validation layers.