Delivering Bad News
You absolutely need to raise the matter promptly, however if you can do so in a reasonable timescale (that is a few hours, not more) you should do a bit of an impact assessment before you do.
As with all bad news it's best to provide detailed information (rather than just blurt out "it's going to be late") so provide as much / many of:
1) Revised estimates / timescales for the tasks which have slipped.
2) Revised estimates / timescales for future tasks which you now think, in light of knowing that some things have already over run, may take longer.
3) Very brief reasons why the slippage has occurred (don't spin, just the truth, but don't sound like you're making excuses). In this case you state "We estimated based on rules X and Y but they've now included Z which was never mentioned". He may be able to use this in explaining the delay to clients and educating them on the importance of being thorough in the first place.
4) If possible alternatives to bring things back on track (usually reducing scope but there may be other options - other parts of the project may be ahead of time and it may be possible to move tasks around).
Remember with slippages the psychological / credibility impact is culmulative. You may be able to get away with one but the second one will be a lot tougher and the third on tougher still.
That's why point 2 is important - revise not just what's already slipped but also future tasks which you now think may take longer than originally anticipated. Slipping happen in ITs, not learning from your mistakes is a bigger sin.
Preventing Having To Deliver Bad News
There are two scenarios here: first, you didn't do the estimates yourself in which case there's not much you can do other than to push to be involved in the estimates next time round.
Second, you did do the estimates yourself in which case you need to look at how to do better estimates. For me the key phrase in the question is "there are always surprises since the business rules are too complex".
With respect, if it always happens, it shouldn't be a surprise. If you only ever get half of the business rules then you need to assume that in your estimates and allow for the feature creep.
You can either do this by increasing the estimates for the rules you do have (it works but you're not educating anyone as to what's really happening), but better is to state with your estimates "Historically the rules we get are a simplified version of what they really want. The rules they've stated will take 3 days to implement, however we should allow another 3 days contingency for the rules that haven't been mentioned but are likely to be discovered during development and testing."
If the PM questions this then you need to remind him of all the times it's been true (with examples - it's hard to argue examples) and also gently suggest that it's in his interest to deliver on time as well as yours so isn't it better to be conservative?
But the bottom line: if you always underestimate because of a specific factor (in this case feature creep) then figure that into your estimates.