This is a BC break (even if it's preferable), and we have not nearly enough unit test coverage to explicitly show the breakages. Will need to think on this!

I was thinking something like this at the top of the function might solve the problem.
if (strpos($amountString, '.') === FALSE && strpos($amountString, ',') === FALSE) { $amountString .= ".00"; }

The OFX spec 2.2, page 91 http://www.ofx.net/downloads/OFX%202.2.pdf states:

Amounts that do not represent whole numbers (for example, 540.32), must include a decimal
point or comma to indicate the start of the fractional amount. Amounts should not include any punctuation
separating thousands, millions, and so forth.

Are files breaking the standard format common?

They rarely conform to specs, sadly! There's lots of edge cases taken into account, hence why we could really do with some more unit tests.

Note: tests showing this weird behaviour are commented with @todo now: https://github.com/asgrim/ofxparser/blob/master/tests/OfxParser/OfxTest.php#L40

As this is a BC break, I'm going to schedule this for 2.0.

We're seeing the same problem when the amount is formatted as 1.00000, it's converted to 1000 rather than 1.

Same problem over here. -699 is converted to -6.99, -2000 to -20.00

Same problem here i solved with

       $handle = $this->openFile();
        while (($line = fgets($handle)) !== false) {
            $line = trim($line);
            if (starts_with($line, "<TRNAMT>") && ends_with($line, "00")){
                $line.="00";
            }
            $this->fixed .= $line."\n";
        }
        $parser = new \OfxParser\Parser();
        $ofx = $parser->loadFromString($this->fixed);