There are a number of things that could result in those figures not lining up, but the main thing is that sys.dm_exec_query_stats only has information for plans that are still in cache, and only information for those plans since they were last put in cache.

If a query has used 5 hours of CPU time and then its plan is pushed out of the cache, that information is gone from sys.dm_exec_query_stats.

Another aspect that has to be accounted for is the amount of time a plan has been in cache. If a query has used 5 minutes of CPU time, it matters a great deal whether its current plan was cached 48 hours ago or 1 minute ago. The former would not necessarily be much of a contributor to CPU pressure, while the latter would.

There are other confounding factors (CPU used for compiles, just to pick one), so I wouldn't worry too much about trying to make the numbers line up.

Is this mostly out of curiosity, or is there a specific problem you're wanting to address?

Cheers!