Can you explain further about how the SU24 data is resulting in inaccurate results? While SU24 does not necessarily control which authorizations are required to use the tcode, it does show you which authorizations will be added to a role when the tcode is added.
SU24 is a good starting point - if the tcode has objects with SU24 indicators Check Indicator=Check, and Proposal=YES, then the authorization will be included in the role when adding the tcode. This typically means that tcode requires it, but not 100% of the time. Go to SU24, within Authorization Object tab enter F_BKPF_BUK for the Authorization Object field value, type of application=Transaction, and execute. In the output, if a tcode has Check Indicator=Check, and Proposal=YES, then you can posit that the tcode requires org-level security. Of course, negative testing is the only way to prove with 100% certainty.
I would also look at table AGR_1251, include the roles that are assigned to users, and see if the org-level objects exist within the role. If the role contains some org-level objects, then you can view the role's authorizations in PFGC and click to view which tcodes the object relates to (which is the same info as in SU24). Then you could test those particular tcodes and see if restricting the org-level object limits the access. Example, for role X that includes object F_BKPF_BUK, first restrict the BUKRS field to specific Company Codes, generate the role, assign the role to a test account, execute the tcodes within that role as the test account, and see if you can access data within the tcode to company codes other than the Company Codes that you have restricted within the role. If you cannot get to the data for the other company codes, then you know the org-level security is required for that tcode.
Give us some more context about your task and we can try to elaborate more.
-Ken