First you need to define rounding between you and the vendor, they may have properly done it based on their definition.
Second if you are only talking about two decimal places there is no reason to use floating point, you should have spec'ed it without floating point, and maybe you can change it to be defined to not use floating point. 8 bit micro or not, not needed can easily do 8 or 16 bit math and sort out all the rounding you desire for a few decimal places (a competent programmer never needs floating point hardware because he should always be able to keep the point in his head, credited to John Von Neumann).
It doesnt matter if it is a microcontroller or a cray, floating point formats have problems, as do compilers as do programmers. Just like 1/3rd and 2/3rds are a problem in a decimal world, 1/10th for example is a problem in binary based floating point programs. If I want to add 2/3rds to 0.83 is that 0.667+0.83 = 1.49... or 0.67+.83 = 1.50 one would round up the other wouldnt, both could be argued to be correct. Yes, true you still have to define your rounding when using fixed point (do you take 200/3 and get 66 (representing 0.66) or do you use rounding and take ((400/3)+1)/2) and get 67?) Your question is not doing divides but multiplies, you still end up with the same kinds of problems. Also note floating point in hardware in a processor is not something to get all excited about, much harder to work around the bugs that are likely there (the pentium was not the first nor the last fpu with problems, your operating system has to fix them or maybe they just leave them there for you to fail these days). A soft fpu is slower but much easier to fix after the chip is in production.
2.36 is like 1/3rd is to decimal it is a repeating digit thing when represented in binary float. this bit pattern appears fairly early. 101110000101000111 (easier to see in double than single, once seen in double you can then see it in the single). I cant make that or an abbreviated version of that cause enough error to push it to 133 though. Looking at single precision ieee, which isnt the only floating point format...
01000000000101110110110110110111 (132.5/56 = ~2.36607...)
the 110 repeats and is rounded on the backend. not that this is remotely related at this point, but just a curiosity, change it to
times 56 and you get 132.499...
The bottom line is that as you stated here when you use a pencil and paper or use a calculator and you multiply 56 * 2.36 and get 132.16 and that rounds to 133 you need to make that clear that you consider this a failure/bug they need to fix. Perhaps it doesnt matter how or why they came up with the wrong answer, so long as the next rev of the software gives the right answer. I dont know how hard it is to cause this product to perform this math, but you should test it for many different values to see if it always gets the expected answer, or even better if possible have the section of code that does the math extracted and validate it in isolation against a long list of operands. Or even specify it that way, the software must be able to get the expected result for this list of operands and answers.