This is due to anomalies of 64-bit binary floating-point arithmetic.
Excel and VBA format only the first 15 significant decimal digits, but the binary representation has more precision.
In VBA, you can easily see the infinitesimal difference with a statement like:
Debug.Print aaaa - bbbb
Unforatunately, it is not always so easy in Excel. Excel likes to play games that sometimes hides the infinitesimal differences. But Excel is inconsistent.
For example, A1=B1 might return TRUE, and =A1-B1 might return exactly zero (0.00E+00).
But A1-B1=0 returns FALSE, MATCH(A1,B1,0) returns #N/A (not a match), and A1-B1-0 returns the infinitesimal difference. Of course, the redundant -0 should not make a difference; but it does, demonstrating the inconsistency.
These infinitesimal differences arise even when we expect arithmetic to be accurate to a small number of decimal places (e.g. 2). The reason is: most decimal fractions cannot be represented exactly in 64-bit binary floating-point, and the binary representation of a particular decimal fraction varies depending on the magnitude of the number.
In those cases, the work-around is: whenever you expect a calculation to be accurate to some number of decimal places, explicitly round to that number of decimal places. For example, ROUND(A1-B1,2) instead of simply A1-B1.
In your example, you might round to 15 decimal places. For example, Round(aaaa,15). But beware of anomalies of VBA "banker's rounding" (round half to even).
Ordinarily, I would prefer WorksheetFunction.Round(aaaa,15). Unfortunately, Excel ROUND has some defects that come to light when we round to 15 decimal places. But they are relatively rare.
