Thanks for taking the time to explain this to me. I had know idea that was how Round works, and I needed the refresher on PC float quirks (been on ~20 year hiatus from coding). Considering that a slight subtlety of how things work is involved in solving this kata, perhaps it demands a bit more depth of knowledge than should be put at a kyu 8 ranked kata. So in the spirit of teaching novice coders (since this kata is ranked as kyu 8) something to guide them to better discover this I think could improve this kata. Just something as simple as to include in the directions not to round until the end (and maybe even a mention of the float precision problem to help introduce the new coder to this concept in combination with the exercise). If it was kyu 7-, where more knowledge is expected to solve the given kata, then that is where no guidance would be more fitting in my opinion. Marking this as resolved, but I hope my suggestion is considered... I know it would've helped me to learn this more quickly with less hassle for all.

C#... Found that all must be calculated then the final answer rounded. If any sort of rounding occurs at the wrong place or any calculates are done a common math practice of using sigfigs (a sort of rounding) then the answer will vary by an unimportant amount (as defined by sigfigs). A slight change ammendment to the details I think could improve the clarity of the exercise. State that only the final answer is to be rounded to 2 decimal places, and all other steps in the calculation must retain their exact value till the end. It is strange that the test cases report back that it is expecting a non-rounded number for example this test case's results (this only happens if it is wrong, otherwise it does accept 9.45 OR the displayed "Expected" number of 9.4499999999999993d works also; one of those floating point quirks perhaps?):
Test Results:
Solution.SolutionTest
ExampleTests
Expected: 9.4499999999999993d
But was: 9.4399999999999995d
Completed in 0.023442ms

I noticed a lot of people used the stack to store the queue of brackets. Not being previously experienced with this basic data type I used a string as my LIFO queue. Not the best fit I know, but it was all I could think of at the time. Think I will have to refactor it to use the more fitting data type.

Once I figured out that the poster intended a need to track the amount of each individual bill it was easy. They might want to make it more clear that there are only 3 pieces of currency possible to pay with and make change with. Also the cashier is unable to break apart the bills into smaller denominations as they can normally do in real life from by making change from the big bills in a safe or another till with the smaller bills. Normally they would be able to turn that $100 bill in $25 bills x4.