To be exact: You have to invert the transformation. Negation is the inversion for addition, but we have a multiplication here. Due to the fact that we deal with matrix math (where an equivalent of a division as the inverse of a normal scalar multiplication isn't defined) we speak of the matrix inverse. I mention this because negation is also a defined matrix operation but it will not result in what you want here.I had considered that the order would need reversed, in addition to negating the transformations. I actually was previously using a working local to global function. However, as you said, trying to convert all the verts in a 13000 poly model uses absurd amounts of processing power, made worse by my method of calculation. I had reversed the order, and inverted the calculations. Transformation and scale worked out fine, only rotation was behaving strangly.
That being said, I was unaware a method of calculating all transformations at once, and applying it existed. Shows where my math skills are at. In any case, that looks like it would solve my problem, so I'm going ot give it a shot.
W.r.t. the underlying math a rotation isn't different from a translation or even scaling. If you have considered the reverse order (notice please that this is also necessary within the 3 particular rotations if you deal with Euler angles) and inversions, then you probably just had a implementation bug. However, using the composed transformation makes things easier and will probably erase the bug anyway.