Invalid code combinations, and how the matrices decide

Seven matrices, one verdict

CDE publishes valid-combination tables covering the pairings among fund, resource, goal, function, and object. Each matrix answers one question: for this row code, which column codes are allowed? A district-valid pairing carries the D flag; a combination without it is invalid for district reporting even when both codes exist and both post happily in your ledger all year.

That last part is the trap. Your financial system will usually accept any structurally well-formed string. The combination tables are a separate, stricter layer, and they change: codes retire, new-year-only codes appear, and pairings that were legal last fiscal year quietly stop being legal this one.

The usual suspects

• Carry-forward strings. A budget rolled from last year keeps a pairing the new year's tables no longer allow.
• Restricted resources on the wrong function or goal. The resource is fine, the function is fine, the pair is not.
• Object families with narrow homes. Certain objects are only valid against specific funds or resource ranges.
• One-digit slips. A typo lands on a real code, so nothing looks wrong until the pairing check runs.

Recode one side, then re-verify the whole string

An invalid pair has exactly two candidate fixes: change the row code or change the column code. In practice the substitution should come from codes you already use (your chart is your vocabulary), and the resulting string must be re-checked against all the matrices, not just the one that failed, because fixing the resource-function pair can break the resource-object pair.

The verification step is the part worth automating. Checking one repaired string against seven matrices is clerical; checking forty of them in deadline week is an evening.