Saxon

Adding some xsl:message tracing, it appears the test fails with

LHS = -.00 
RHS = .00

That is, the expression on the left, format-number(sum(cbc:PayableAmount) *-1,'##.00') is returning "-.00".

This raises two questions, (a) should zero times -1 evaluate to negative zero, and (b) should format-number() applied to negative zero include a leading minus sign?

Note that the stylesheet specifies version="1.0" so we have to answer this questions for the case where 1.0 backwards compatibility applies.

Although I don't have the IEEE floating point spec to hand, I'm pretty sure the answer to (a) is yes: the multiplication yields negative zero. As for (b), reading the rules for format-number() in the Functions&Operators 3.1 spec clearly says yes: if the value is negative zero, it is formatted with a leading minus sign. There's no special rule here for backwards compatibility mode, but it's interesting to see whether the spec here has changed since XSLT 1.0. Unfortunately the spec for format-number() in XSLT 1.0 refers normatively to the spec for the DecimalFormat class in Java version 1.1.8, which is no longer obtainable; but it was grossly underspecified; indeed, the spec in more modern Java versions is still rather vague, though I read at saying that a "-" sign is included by default.

I've tried this under a number of XSLT processors invoked from Oxygen: specifically looking at the result of format-number(0.0 * -1, '##.00'). The results I get are:

Saxon 9.8:       -.00
Saxon 6.5.5:    -.00
Xalan:               -.00
xsltproc:           .00

Without being able to find the Java 1.1.8 specification, I think the XSLT 3.0 specification clearly requires -.00, and the 1.0 specification is either the same, or is ambiguous.

I would suggest that you replace (XXX * -1) by (0.0 - XXX) as the preferred way to make a number negative. This delivers positive zero rather than negative zero as the result, and the formatting is then the same for all processors.