In a better world you would not have any org. levels, but rather application tools to cascade authorization values with a link to role variables. That is also what org. levels set out to do, but had the nasty consequence with derived roles and objects sharing the same field types that it sends them everywhere and you cannot have combined instances of authorizations such as display all but change only some within the same role. So you are forced to have more and smaller roles. Then you start using composite roles to put it together so that the customer can still make sense of thousands of roles and then you are lost (or you leave the project and it is the customer's problem).
CLASS was "accidentally" promoted to an org. level in the standard but it is not at all appropriate for an org. level. The GRC Add-on software packages did that by sending USORG values for it into systems but not adjusting roles and Su24 in the way it should be done. This is not delivered anymore by SAP and there is a SAP note and correction tools in Su25 to degrade it again and undo the damage done. Search for USORG and CLASS on OSS.
Your system appears to have inconsistencies in this customizing caused by importing the GRC client system side add-on packages, or someone maintained the USORG table directly.
You should undo this and keep it as a normal field.
Promoting a field to an org.level is only sensible if it is a real org. element from the SPRO perspective, which CLASS is not. BUKRS is for example. KOART in F_BKPF_KOA is also and a big pain in the *** because of it. Other fields with TYPE and GROUPS are tempting to promote, but resist the temptation! They are shared by multiple objects and have the consequence that you cannot have multiple authorization instances anymore. You quickly reach the limits of the UST12 field lengths and end up with thousands of roles instead of only 50. Even without promoting the fields you can still end up with thousands of roles if you do not maintain Su24 and want to build based on a design which only works in .ppt presentations.
The moment you have the temptation to use composite roles, alarm bells must go off that the underlying concept is not well thought out at single role level and org. fields are one of the main reasons for this. Another is silly project goals like roles must be completely SOD free based on all 4 million GRC rules, etc which have no relation to the customer scenario nor can they ever be implemented. They just make the roles kaput...
Cheers,
Julius