Sometimes you just sit there and wonder about how the code managed to get to a certain end point... take my current Amex online bill...
Now it could be the surprise that its the lowest monthly bill I've had since I got the card, but I don't quite think that "surprise" is something that should be built into a financial system. But some how the amount that I have to pay (the last bill) is now less than the minimum payment, which includes stuff for which the bill hasn't been sent yet.
Part of this is because Amex have two billing elements, the first is the date that they want you to pay by, the 2nd is when the next bill comes out. If you pay before the later then everything is fine, but they'd prefer you to do it before the former.
This is clearly a historical thing with Amex and it clearly reflects back into their core operational systems which are almost certainly batch oriented. What this also means is that like many companies out there Amex haven't really adapted their systems or processes for the web they've just lobbed the paper processes on line which delivers oddities such as this which aren't possible in a paper only world.
When people put systems on-line they often seem to forget that the interactional model for on-line working is significantly different to off-line working. If you want customers to engage more in your on-line solution and move away from the more manual and higher cost channels then it really isn't good enough to shift crap processes onto the web, you should be looking at how customers will be interacting with your company in real-time and therefore what new processes and opportunities this can bring.
I did feel like phoning up the call-centre and asking "which minimum payment should I make, the one that says minimum payment or the one with the lowest value" but I decided my life was too short to waste time on that.