As @HBruijn noted, dynamic updates are first stored in the journal and are not written immediately into the zone file. So, it is wrong to check an update is applied by viewing the zone file.
Instead, you should query it via DNS (use dig, host and so on) immediately after you did successful send in nsupdate. You will see it is already serving the updated/new data, despite the fact zone file is not yet rewritten. (You may need to direct a client to your server, to avoid caches of intermediate resolvers.) You may also notice in logs that it propagates the change to slave servers immediately after update arrived. Dynamic DNS update is instantaneous.
Textual zone file is ill-suited for quick updates. Such an update requires a full file rewrite. Imagine a server which receives a solid update stream to a big zone — it would be big waste to rewrite a zone file each time. That's why it caches recent updates into zone journal, and applies a journal only periodically. This is like a corrections/errata page at the end of the book: when the book body is already done it is costly to reprint the whole issue, so they add additional page which says where and what and into what should be changed for the book to be correct. And only on the next issue they actually incorporate these corrections into the text.
You can, however, send a command to it to apply journal right now and rewrite zone file:
rndc sync -clean zone.name
Don't do this too often; this is suboptimal. Don't worry about journal and non-immediate zone file update, mind your business (dynamic updates) and let BIND to do its work the way it prefers, without micromanagement.
