Without the ability to recreate those credit charges on an item/individual basis, we can't continue to use ArcGIS Online (tragedy of the commons), as we need to be able to assign charges on an individual or project basis.
So, we're actually considering re-running the script every hour to pull the data from the REST API to store the granularity that we can't get from ArcGIS Online on our system.
The aggregated view does not let us effectively pass the cost of usage on to the project or user, meaning that it becomes an overhead cost which can and will be abused by the various users/projects, and is therefore not sustainable for us to use as an organization.
So... assuming the size of the reported feature is accurate, and that we're pulling the data from the REST API on an hourly basis, we, at least theoretically, should be able to recreate the credit usage total, but also support an itemized list of storage credits.
If the feature service is not hosted, it doesn't have an associated size, and is therefore not counted... so calculating credit usage based on whether or not the item is a "Feature Service" should still produce accurate results.
Currently, if I drill down as far as I can into the credit usage I can see that we're using 0.43 credits an hour, primarily in Feature Storage.
If I pull the data from the REST API using the above script, and calculate the credits used, I get, 0.404856765... So I'm close... but not quite correct. Once I can confirm that I have the correct calculation method, then it's just a matter of setting up a machine to pull the data and store/aggregate it for a monthly billing cycle. We'll also have to include credits used in other ways (i.e. enrichment, etc.). I agree this is difficult and painful, but our other option is to stop using ArcGIS Online, which I'm trying to avoid.